> It would be better if the web browser world had pixel level render targets
We also have escape hatches when you need pixel controls: Canvas, and webGL which can be rendered to a Canvas. The only difference is that they're not the core that HTML is based on. This is on purpose, because using Canvas should be very rare. You should embed your (rare) pixel-based rendered component into an HTML tree with appropriate non-visual markup around it to describe what it is and what it does.
Pixel-level render targets are a design antipattern for most apps. Not all apps (games for example), but the vast majority of them.
To me this isn't a design thing -- it's a purely practical decision. Your app state needs to be accessible to people, people need to be able to build on it, programs need to be able to parse it and manipulate it, it needs to be responsive when high-definition displays or Apple Watches come out in the future, and it needs to degrade gracefully when parts of the browser stop working. We've been able to observe for a long time that apps that are built this way are better for end-users.
In the browser, text is your pixel. Of course you are welcome to build things on top of that with CSS, images, and Canvas. More to the point, I'm not saying that 95% of the time you should abandon your design and make a minimalist terminal interface -- I'm saying that for 95% of the phone apps and native apps I see, HTML would be fine. There is a pretty good chance the design someone has come up with is already representable in pure text, and they just haven't thought hard enough about how to do it. I'm not saying design everything minimalist, I'm saying your design is probably already a lot more minimalist than you think, and it probably wouldn't be that hard to separate content from pixel-positioning and style for most apps.
This is your opinion, and your opinion deserves to be fulfilled. My opinion is that the web is a multimedia platform that can do combinatorial designs where text motion and visualizations can be combined into something like this:
In my opinion what you see as 95% of all user interfaces is largely a because HTML and CSS are the rendering target not the other way around. There are less games and those types of UI interfaces on web browsers because HTML + CSS is bad for doing those things.
So if we have different opinions what's the best way to fulfill both? Libraries. One library for your text based philosophy and one for mine. The lower level technology should be agnostic to both of our opinions. What I don't like is having to submit myself to your design philosophy and write my canvas library on top of HTML + CSS.
webassembly makes logic language agnostic on the front end. It's time to do the same for the "render target"
Unless I'm misunderstanding, this example seems to be exactly what I'm talking about.
Even in its current state, there are only 2 or 3 things on this page I can see using Canvas. Everything else is already using HTML and CSS. It's not even lazy-loading the images -- this is a static page that is dynamically generated. And yet despite ultimately being a static page, it works fine. Great even, it's responsive if I resize the browser. HTML is doing everything you would ever need here.
You can use Canvas for the (optional) background animations in the deep water, Canvas (or gifs) for a few minor animations like the waves on the top. You use a very small amount of JS to update the text tracker and swap the sub to a fixed position when you hit its scroll-point. The sub is already an image being animated via CSS, so you're doing that correctly.
To me, this page is the perfect example of something that has an incredibly simple tree-based UI that is nevertheless being dynamically rendered with webGL for some inexplicable reason. I'm actually a little annoyed that it doesn't currently work with JS disabled. I wouldn't expect the depth-tracker to work without Javascript, but I should still be able to at least scroll to the bottom and see all of the pictures and text. It would not be hard to make this page degrade gracefully.
What do you want this page to do that isn't possible with the current state of HTML/CSS? I might be missing something, but I don't see what the complication is.
> In my opinion what you see as 95% of all user interfaces is largely a because HTML and CSS are the rendering target not the other way around.
I'll make a bolder claim then: 95% of native apps are just interactive documents (with a few category exceptions like games), and most native developers who claim that their interfaces couldn't be represented on the web in HTML are kidding themselves. In the majority of cases, HTML/CSS would be fine for what they're building.
The point isn't whether or not you can do this in CSS + HTML. (Which by the way CSS + HTML is proven to be turing complete so you can actually do anything in CSS + HTML including writing a JS interpreter so you can use javascript on non-JS enabled pages)
The point is to get to the above, you need to basically hack your way there. HTML + CSS is not the ideal medium to program something like that in. It would be better to have a library written over a pixel level API to construct the interfaces you see in the page rather then either hack your way through HTML and CSS or create a library of hacks on top of HTML and CSS.
>I'll make a bolder claim then: 95% of native apps are just interactive documents (with a few category exceptions like games), and most native developers who claim that their interfaces couldn't be represented on the web in HTML are kidding themselves. In the majority of cases, HTML/CSS would be fine for what they're building.
Sure make that claim, even if it were true nobody wants a computer to just be a platform for text based UI. Nobody wants the internet to be JUST that. People want the computer to be a universal computing platform. Games may be category but it's a huge category as no one will buy a computer that only has the capability of displaying text, they buy it for the computing potential to do anything.
Heck under your logic, why even have the OS expose the pixel level api? Just have the OS expose a DOM. 95% of apps are that way so an OS that does this is perfectly fine.
If you want to restrict the potential of what the internet is, then yes. If you want to expand it while keeping your design philosophy in place then the platform must expose a pixel level API and HTML and CSS must be moved to a library. It makes no sense for a lower level library to be written as a component of a higher level library, it should be reversed.
It won't look right because it literally blanks out the page if Javascript and CSS aren't enabled. That's not a limitation of the web, that's a conscious design choice by the author.
Without CSS, what this would look like is pure data -- a list of animals with a picture and their relevant depth printed next to them. It would be perfectly functional. This is your render target: "what is the information that I wish to convey?"
Now we move to CSS and we make things pretty. A pure CSS/HTML version of this page would look pretty much the same, it just wouldn't have animated backgrounds or an interactive depth calculation. But it would still look nice, and it would still get the point across.
Now we move to JS and we add fun touches like an animated background and interactive depth view. And at this point, we're back to the original page layout and we haven't sacrificed anything at all to get there.
> The point is to get to the above, you need to basically hack your way there.
I want to be clear here -- I'm not advocating for a less experimental, uglier web. The reason you (or whoever the author is) needed to hack their way to this page is because they are over-complicating and over-engineering their UI. This page is using a CSS grid, for no reason at all. It's pulling in webGL code to render a background that could be handled with a simple Canvas. None of the elements on the page are in the right order, so good heckin luck trying to read this if you're blind. Even though, to be clear, the information this page is displaying is an ordered list of animals with some text next to them.
There is zero reason for this page not to be accessible to blind people. There is zero reason why this page can't degrade gracefully without Javascript. Making it accessible would not require you to compromise on the design or the visuals in any way at all. It doesn't need React, it doesn't need inline styles, it doesn't need CSS grid -- you could build the exact same page with no frameworks, and the code would be cleaner and easier to understand.
> Heck under your logic, why even have the OS expose the pixel level api? Just have the OS expose a DOM. 95% of apps are that way so an OS that does this is perfectly fine.
I'm not going to go quite so far as to advocate that native apps shouldn't have direct access to a pixel-level API. And from a pure engineering perspective, it does make sense to build high-level controls on top of low-level ones. But what I will say is that on Linux right now, we still don't have fractional scaling in Gnome, very few of the native apps are responsive, and most will break layouts if you try to mess too much with your OS's font-size or settings. The last time I talked to the MyPaint devs about building a touch-friendly version of MyPaint with bigger buttons, they told me it was impossible because of whatever Python-based widget library they were using. And holy crap, the menu/toolbar in MyPaint is not complicated. If the widget library doesn't support fractional scaling, it doesn't mean that MyPaint menus are doing something crazy or revolutionary, it means the Python widget library being used is crap.
And that kind of makes me think, if we had forced native developers to use an HTML-like interface instead of building pixel-perfect interfaces that aren't future-proof, would touchscreen Linux on HDPI screens be in such an awful state today? Would Purism have needed to rewrite half of Gnome's apps to get them working on a phone?
I'm not sure I agree that the state of native apps is perfectly fine. And I definitely disagree that caring about stuff like accessibility necessarily means that you can't be creative, or that we'll be holding the web back. I think that 95% of the native apps on your computer are probably text based UIs, except they've got a little bit of styling applied on top of them to turn unordered lists into drop-down menus. We have escape hatches for the web apps that are more complicated, that genuinely need to do crazy pixel-level things. Most of them don't.
It's not about getting rid of that styling, it's not about making things ugly. It's about recognizing that we're working twice as hard for interfaces that are half as functional as they could be, and we wouldn't need to sacrifice any of the fun visual stuff we're doing to improve that situation.
No. The author wishes to convey a multimedia experience. This is evident, the page is unique because of this.
The author does not care to convey just textual information. You're just breaking down the core components of the system and picking the one that's required to have any semblance of a page. The "fun touches" are ultimately required. It's like a script vs. a movie, the movie isn't required and the script is ultimately all that's needed but nobody cares about the script do they? It's not even embedded in the movie.
>I want to be clear here -- I'm not advocating for a less experimental, uglier web. The reason you (or whoever the author is) needed to hack their way to this page is because they are over-complicating and over-engineering their UI. This page is using a CSS grid, for no reason at all. It's pulling in webGL code to render a background that could be handled with a simple Canvas. None of the elements on the page are in the right order, so good heckin luck trying to read this if you're blind. Even though, to be clear, the information this page is displaying is an ordered list of animals with some text next to them.
I have to be honest with you, and this is cruel. But when I design a page... I don't care for blind people. I don't focus my design so that it will cascade down into something blind people can read. Books don't have this property, movies don't and because of this... neither should web pages. It is not worth the effort.
>I'm not sure I agree that the state of native apps is perfectly fine. And I definitely disagree that caring about stuff like accessibility necessarily means that you can't be creative, or that we'll be holding the web back. I think that 95% of the native apps on your computer are probably text based UIs, except they've got a little bit of styling applied on top of them to turn unordered lists into drop-down menus. We have escape hatches for the web apps that are more complicated, that genuinely need to do crazy pixel-level things. Most of them don't.
I never said native apps are perfectly fine. I'm also not advocating all sites be designed with pixels. What I am advocating is freedom from HTML and CSS. If the platform of the browser exposed pixel level control with HTML and CSS only as a library and given the amount of people who hate the CSS + HTML... it's almost a guarantee that people will create sibling API's that are on the same High level as HTML + CSS but offering different philosophies. There are multitudes of UI layout languages and tools out there, who said HTML and CSS was the best, and why does it have to be the only way?
That's all I'm saying. You expose pixel level control at the core for the purpose of being able to use and create multiple high level libraries rather being vendor locked into HTML and CSS.
I do want to mention very quickly that on the subject of books and movies, literally every Hollywood movie you can buy ships with subtitles for the deaf, and since ~2015 US law has required that new theaters also include equipment that provides audio descriptions for blind viewers[0]. And I don't know anyone who would seriously claim that the Godfather is lessened as an artistic expression just because deaf people can turn on subtitles.
[0]: https://www.govinfo.gov/content/pkg/FR-2016-12-02/html/2016-...
This world already exists. You're delusional if it doesn't. I use the word cruel, but you must know that cruel = reality. That's all I'm saying. 99% of the world is not designed for deaf people or blind people. There are arbitrary restrictions on certain things but this is reality and it's not going to change because engineering everything to account for these people come with an engineering cost.
It is not "pointlessly excluding," it's just not worth the engineering cost. But you know this. Any person is aware of this and the reality of the world. There is zero need to call it "pointlessly excluding" that's just a manipulative way of advocating your agenda.
>And I don't know anyone who would seriously claim that the Godfather is lessened as an artistic expression just because deaf people can turn on subtitles.
I don't know either. Did you or I make this claim? Perhaps nobody made this claim and your pulling this example out of nowhere to serve your agenda. You know video games don't account for blind people. This is purely out of cruelty of course, no way does it have anything to do with engineering cost. Obviously you don't know a thing about the cost of engineering mechanisms to get these games to work for blind people so that's why you didn't mention it. Of course it wasn't at all a deliberate choice not to mention the engineering cost to serve your own agenda.
It's not a coincidence that this design also increases accessibility -- it encodes the most meaning.
Please stop accusing everyone of being biased and having an agenda. Not that there is anything wrong with that, since everyone is biased and has an agenda (including you), but the way you're saying it makes it sound like you think it's an important component of other people's comments but not yours.
Ok first of all. There is no universal law that says everyone has to be biased and have an agenda. There's no logic to it. This false notion comes from the fact that most people (not all) people are biased and that when people are biased they are unaware of it. However this does not mean that people can't be unbiased or have no agenda.
Second: Examine the sentence in reference to that phrase. It is literally word for word referring to "engineering" and Not a specific set of engineering projects.
Literally what you are doing is inserting your own opinion onto what that "engineering" is referring to and I am taking it at face value. So I am not wrong when I say that your observations are biased. There is no accusation here, just observation of events.
Being biased is pretty much a part of the human condition since we are limited, finite beings. Do you have all the information? Are you certain you have all the information? Have you taken into account everyone's wishes, desires, needs, analyzed every possible scenario in existence according to some yet-unspecified objective reasoning system? Then you are biased. You are missing something, you are concluding something erroneously. (using the generic you as a stand-in for anyone)
Your agenda is to incorporate a pixel-level API into the web. And that's okay. Mine is to prevent the web into devolving into an opaque black box. That's okay too.
As to the topic at hand, I won't try dissecting comments word for word, because I think this is a loss of time and devolves into a lot of who-said-what, when we can sidestep it by concentrating on the most charitable explanation.
Reading through the thread again, I think the other poster's point was that there are many situations (not all) where designing things in the simplest and most direct way, using HTML as the semantic underpinning, leads to both less engineering effort and to a more accessible design.
Specifically, I do not think he was arguing doubling or tripling a movie budget in order to make another similar movie for blind people. But then again, we weren't talking about movies. We were talking about web sites, in which the loss of HTML would lead to a net loss compared to what we have now.
No. statements of observation do not have agendas. "The sky is blue" is a statement without an agenda. Statements can be made separate from agendas, which makes the statement unbiased.
>Being biased is pretty much a part of the human condition since we are limited, finite beings. Do you have all the information? Are you certain you have all the information? Have you taken into account everyone's wishes, desires, needs, analyzed every possible scenario in existence according to some yet-unspecified objective reasoning system? Then you are biased. You are missing something, you are concluding something erroneously. (using the generic you as a stand-in for anyone)
This is completely false. Biased, means a leaning of ones mind towards a particular viewpoint. People usually use this word in the context of a leaning of ones mind despite being aware of evidence to the contrary or lack of supporting evidence. If the mind does not lean then it is unbiased.
Your judgement of the statement has leaning towards your agenda despite you being aware of lack of evidence supporting it. My statement does not have leaning.
>Your agenda is to incorporate a pixel-level API into the web. And that's okay. Mine is to prevent the web into devolving into an opaque black box. That's okay too.
This "agenda" had nothing to do with my observations, but for yours it colored your interpretation of words. Your observations were biased, mine were not. This is not something that is Okay. Biased observations are usually false.
Given at face value the sentence is referring to a world of engineering with the context of the web as a specific example out of a more general point. You need to make a biased modification to the sentence in order for it to fit your world view.
>As to the topic at hand, I won't try dissecting comments word for word, because I think this is a loss of time and devolves into a lot of who-said-what, when we can sidestep it by concentrating on the most charitable explanation.
The most charitable explanation is here:
Given the original sentence we are referring to:
"You're not advocating for a bold, artistic world when you talk about engineering things to pointlessly exclude people."
The terms:
"Bold artistic world" "engineering things"
"Bold artistic web" "engineering web pages"
"You're not advocating for a bold, artistic web when you talk about engineering web pages to pointlessly exclude people."
You applied context to the statement relevant to your agenda. I did not. There is no doubt when I say that your perspective is in alignment with your agenda given lack of supporting evidence within the sentence itself. When you are biased you are unaware of it.
Definitively from the logic your statement is biased, mine is not.
>Specifically, I do not think he was arguing doubling or tripling a movie budget in order to make another similar movie for blind people. But then again, we weren't talking about movies. We were talking about web sites, in which the loss of HTML would lead to a net loss compared to what we have now.
Earlier you were rude to me. Therefore I don't care to debate this topic with you. Keep your opinion. I care little for it. If you had chosen more wisely earlier I would have gladly engaged with you on this very topic but since you chose not to, there is now zero possibility of further discussion on this topic.
But the web is not a graphical API and that is precisely the point. The web is a semantic API and its components represent meaning. Devolving to pixels makes drawing graphics easier but it destroys meaning.
When you want to simply draw meaningless graphics, you get an element which represents an element into which you can draw pixels which aren't expected to be meaningfully structured: canvas. What's the problem with rendering into a canvas, again?
And no, HTML not being similar to graphics APIs doesn't count as a downside of canvas being a child object.
> while this is true I wouldn't center the design of a platform on whether or not ad blockers work for it. It is not central to the problem which is the creation of a universal platform that is versatile. Rather it is the implementer of the adblocker who must conform to the platform.
It should most certainly be the center point of this design if you truly want this platform to be universal and versatile, or even usable. It's not like we need to guess how an ad-infested web would look like -- we've experimented with the web of ads, we've seen how horrible it is and the only reason we are still using the web is because we can block those ads.
I'm genuinely surprised how easily some people are to dismiss the openness of the web, surrendering users' freedom in the process, simply for... I'm not sure why actually. I don't understand the argument.
Make the semantic API a library. Or how about seperating semantics from component. Semantics are listed in a single file which can be crawled and only possesses meta data that links to other semantic files. The pixel level API and web crawlers have libraries that can interpret these files. This is a much better design then the adhoc way the web formed.
>What's the problem with rendering into a canvas, again?
It's using low level components as a composition of high level components. The design is backwards and vendor locks people into html. There are other ways to display semantic UI. Html is an arbitrary choice.
> And no, HTML not being similar to graphics APIs doesn't count as a downside of canvas being a child object.
How can you be so sure footed about your argument when you literally say you don't understand the argument later on. You don't understand the argument therefore your entire argument is baseless. Little lesson for you: you need to ask questions and understand before you compose an argument otherwise your wasting time.
>It should most certainly be the center point of this design if you truly want this platform to be universal and versatile, or even usable.
Your saying ad blockers should be the center point of design? You realize that right now in html and css ad blockers aren't the center point of design. An adblock centered design implies something along the lines of replacing the html tag with one that has the word adblock in it. Literally adblockers are designed for the platform not the other way around.
>I'm genuinely surprised how easily some people are to dismiss the openness of the web, surrendering users' freedom in the process, simply for... I'm not sure why actually. I don't understand the argument.
You should of put your declaration of lack of understanding and comprehension in the beginning. That way readers can dismiss your entire argument without first reading it because things need to be understood first before you can make a counter argument to it. Reread my argument until you understand or take some classes at reading comprehension then you'll have what it takes to make an argument.
Honestly let's get a little more meta at what's going on here. Someone has composed a response that is rather rude. The responder dismisses my argument by implying that my arguments are so baseless that he doesn't "understand." Highly offensive. When you play games like this nobody wants to participate in an informed discussion. I'll play his game and say that his lack of understanding makes his whole counter argument ludicrous but literally this argument was over before it even began when the responder decided to be a rude and offensive. If I were the rude responder, I'd just walk away because nobody cares for his opinion anymore.
I'm not convinced it's a better design. It just makes semantics a separate, additional concern, rather than a frontal concern which you have to think about. It allows you to be lazy by not supplying the semantical layer at all, in any shape or form. Granted, you can have document websites with some pretty opaque form even today, but I would argue that enforcing the basic structure of HTML still keeps us in a much better place than we would otherwise end up.
I also don't think the way the web formed was ad hoc when you consider it from a semantical perspective. The most ad hoc bit about it is JavaScript, which was of course necessary due to the expansion of the web into being an application platform.
Pixel-level control sounds wrong to me as a default choice. You don't need pixel-level control in most cases, whereas meaning is crucial, both for humans and for ease of interoperability and extension.
> It's using low level components as a composition of high level components. The design is backwards ...
This is only so due the arbitrary meanings of "low" and "high" you picked here. You're imagining pixels as fundamental, meaningless atoms out of which meaning is built. Why not have meaning at the forecenter, though?
I would argue that having a semantic layer exposed as the front is the right design, not backwards. By default, you have a set of meaningful components composed in a meaningful way. One of those components can be "an array of arbitrary pixels", a canvas to draw on. That doesn't sound wrong nor difficult to me.
Does this argument boil down to the design being "wrong" due to some kind of first principles, or does it genuinely make things substantially harder in a large number of cases? Bear in mind that changing the web like this would also be an exceedingly hard effort.
> vendor locks people into html.
Which vendor would that be?
> There are other ways to display semantic UI. Html is an arbitrary choice.
I agree, but HTML is what we have and it's not half-bad compared to some other things we could have ended up with.
> Your saying ad blockers should be the center point of design? You realize that right now in html and css ad blockers aren't the center point of design. An adblock centered design implies something along the lines of replacing the html tag with one that has the word adblock in it. Literally adblockers are designed for the platform not the other way around.
Let's not get too literal. I was clearly pushing back to your suggestion that we shouldn't take requirement of ad blockers as a design consideration at all.
What I meant to say was that, given the knowledge we have today, any design should take the possibility of ad blockers as one of its central points. Ad blockers need to remain easy and they will remain easy as long as the platform forces you to encode basic meaning in a transparent way.
> You should of put your declaration of lack of understanding and comprehension in the beginning. That way readers can dismiss your entire argument without first reading it because things need to be understood first before you can make a counter argument to it. Reread my argument until you understand or take some classes at reading comprehension then you'll have what it takes to make an argument.
That's uncalled for. I read your argument multiple times and the best I've found is "I don't like being forced to write HTML." Even though you'd need only a small amount of boilerplate HTML in order to get a canvas which then gets you the pixel API you wanted.
I only realized I don't really understand your argument midway through writing that since I consider your request to have a pixel interface reasonable. I just don't consider it reasonable to request to uppend the web fundamentally -- to the detriment of the document platform facet and the use case of writing freely interoperable, transparent documents -- in order to cut away a small bit of boilerplate.
I decided to leave my comment as it was to reflect the time evolution of my thought. You may not like the style of my comment, but it's a bad reason for rudeness and instructing me to take reading comprehension classes.
> Honestly let's get a little more meta at what's going on here. Someone has composed a response that is rather rude. The responder dismisses my argument by implying that my arguments are so baseless that he doesn't "understand." Highly offensive. When you play games like this nobody wants to participate in an informed discussion. I'll play his game and say that his lack of understanding makes his whole counter argument ludicrous but literally this argument was over before it even began when the responder decided to be a rude and offensive. If I were the rude responder, I'd just walk away because nobody cares for his opinion anymore.
I'm not sure, but are you talking about me? I'm truly sorry if I was rude and offensive, it was not my intention to be. That said, I got the same feeling about your responses to other people and the topics of lock-down, opacity and vendor lock-in are dear to me, so I may have got a bit worked up.
This is a design opinion. I disagree with it. Minimalism is simply a design philosophy just like brutalism or complexity. The underlying mechanisms should be design agnostic.
>HTML on its own is a render target. CSS is a completely optional secondary display modifier that you put on top of that render target.
Sort of like turing completeness, HTML on its own is not "render" complete. There are many objectives that cannot be achieved with HTML alone. You must consider aspects within and outside of your "design philosophy" as the modern browser is intended to be a universal platform for multimedia applications. This is why HTML alone cannot be the render target.
Render targets are usually more fundamental with libraries built on top for more specific use cases. It would be better if the web browser world had pixel level render targets with HTML built on top as a library. This is how most graphical APIs work. Rather then what is now, HTML as the render target, and canvas as a child object of HTML.
This maintains "render completeness" and gives users the ability to use higher level DSLs like HTML + CSS or to (switch to)/write another library.
>This is why adblockers work, it's why stuff like Reader View works in Firefox. Because it turns out that forcing interfaces to be pure-text has substantial benefits for end-users. Try building something like a UI-level adblocker for a native app. You can't do it -- it's impossible.
while this is true I wouldn't center the design of a platform on whether or not ad blockers work for it. It is not central to the problem which is the creation of a universal platform that is versatile. Rather it is the implementer of the adblocker who must conform to the platform.