8 ms·

That page actually goes against your point of HTML as a singular render target. You need CSS or that entire page won't look right at all. The point isn't wheth

That page actually goes against your point of HTML as a singular render target. You need CSS or that entire page won't look right at all. 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.

danShumway 7y ago
> You need CSS or that entire page won't look right at all. 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.
- crimsonalucard 7y ago
  >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?" 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.

danShumway 7y ago

> You need CSS or that entire page won't look right at all. 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.

crimsonalucard 7y ago
>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?" 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.