6 ms·

It’s a bad render target, and it’s only half the story. It’s html + css that’s the render target. Separation of concerns happens because the render target is a

It’s a bad render target, and it’s only half the story. It’s html + css that’s the render target. Separation of concerns happens because the render target is a over complicated mess. So separate the good parts out of the mess as much as possible but the mess is still there.

danShumway 7y ago
95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX. Of course HTML for interfaces is more complicated than something like canvas, because it forces you to think about your UX on a deeper level than "this component should be on the left". The point of HTML is that it forces you to build a universal interface that works for everyone -- it forces you to sit down and build a human-digestible, pure-text tree that communicates your current application state to users. 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. 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.
- crimsonalucard 7y ago
  >95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX. 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.
  - danShumway 7y ago
    This is not a design opinion to me. Unless your application state can be represented as pure text, it can not be efficiently conveyed to blind users. So we force you to do that. > 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.
    - crimsonalucard 7y ago
      >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: https://neal.fun/deep-sea/ https://neal.fun/deep-sea/ 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"
int_19h 7y ago
I wonder if perhaps we need to revive FOP...

danShumway 7y ago

95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX. Of course HTML for interfaces is more complicated than something like canvas, because it forces you to think about your UX on a deeper level than "this component should be on the left". The point of HTML is that it forces you to build a universal interface that works for everyone -- it forces you to sit down and build a human-digestible, pure-text tree that communicates your current application state to users. 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. 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.

crimsonalucard 7y ago
>95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX. 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.
- danShumway 7y ago
  This is not a design opinion to me. Unless your application state can be represented as pure text, it can not be efficiently conveyed to blind users. So we force you to do that. > 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.
  - crimsonalucard 7y ago
    >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: https://neal.fun/deep-sea/ https://neal.fun/deep-sea/ 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"

int_19h 7y ago

I wonder if perhaps we need to revive FOP...