5 ms·

All that said, there’s still no way to just make a layout and it be compatible with all screens. You still have to do mobile, tablet, pc modes. (And there’s eno

by wruza 3y ago

All that said, there’s still no way to just make a layout and it be compatible with all screens. You still have to do mobile, tablet, pc modes. (And there’s enough sites that are pc-only or mobile-only.) You still have to make 2-3 layouts, but in one source. Well, what’s the argument against gp’s point again? Sorry, but this statusquoism and rationales that essentially change nothing drive me mad sometimes.

danShumway 3y ago
The web and CSS make it reasonably feasible to support most of those layouts well with at most 2-3 layouts in one source. My point is that it is impossible to get the same level of results doing fully device-specific and domain-specific languages without considerably more work -- more work than would ever be undertaken by the majority of people building for the web today. If you want an indie web, if you want websites that aren't just built by corporations and professional development teams, HTML and CSS is what enables those indie websites to exist and to work across every device you own. The proposal of using interface-specific languages and abstractions wouldn't work. Doesn't work, in fact, when you look the places where it's being attempted as a UI strategy. Like democracy, universal design abstractions such as CSS are the worst way to design interfaces that work in the real world for real users across diverse devices and configurations -- except for every other way. If we asked devs to actually use separate domain languages for mobile devices and desktop devices, the web would be a lot smaller and a lot more limited and a lot less flexible and a lot worse for end users.
- wruza 3y ago
  I don’t think our common ancestor in this subthread suggested separate languages for different screen sizes. Did they?
  - danShumway 3y ago
    > The problem with css is almost entirely self inflicted, though. Yes, layout is hard. Why make it harder by aiming for the model we now have? Specifically, why aim for one major model that will fit all pages? It's possible I interpreted that incorrectly? But if their problem is just making different layouts then I don't see what the issue is. CSS has breakpoints. You can already make different layouts for different screen sizes. You're not required to have one set of rules that apply to every page size. The only criticism that makes sense to me as a reading is that they don't want a common set of UI paradigms and language features that allow targeting multiple devices and they want a more specific language targeted at describing a subset of those interfaces -- because that's what CSS is. That's the only thing that CSS is, it's just a universal rules-based language. You can design different layouts for different page sizes, you can even on the serverside serve entirely separate HTML pages for mobile and desktop devices. The only issue I can think of left to complain about with CSS being too general is that CSS is a common language designed to be used in all of those situations instead of in only one of them. Did they mean that they wanted CSS to have separate terminology and paradigms and ways to tackle those problems built into the language? It does! And that's exactly what people complain about, that's exactly where the "why are their 5 ways to do this" complaints come from, they come from CSS having lots of different ways to achieve the same effects based on the individual unique needs of the specific interface being created. What's the alternative, have one way of doing everything for every interface? The original commenter I was replying to said that they didn't want that. They want multiple models for different formats, and CSS has that and lets you use them and target as many interfaces as you want, and there are ways to detect and serve different CSS and HTML based on device agents, and so... I don't know, if they don't want different languages, then what is the complaint?
    - taeric 3y ago
      I wasn't necessarily proposing separate languages. I don't see the benefit in having a single source, though. The vast majority of designs do not need to have every single element recalculated at the client. To that end, I confess I would encourage leaning more heavily into absolute positioning of elements than most places go with. Is what I did for stuff such as https://taeric.github.io/cube-permutations-1.html https://taeric.github.io/cube-permutations-1.html, and seems to work just fine. I remember I did something similar on the job once, and the next developer came in and was against the idea of using absolute positioning. The rewrite did not go well. :( My push is the "model" for what a page is showing should be dominated by concerns of what the page is showing. It should, ideally, not be too heavily influenced by how you want to write the styling for it. We rebelled against using tables for styling years ago. Nowadays, we shrug at the number of divs necessary.
      - danShumway 3y ago
        So, I would push back against this as a design pattern, but I do want to re-emphasize, if you really want to absolute-position all of your divs, and if you want to serve even completely separate HTML for different devices -- you can. That is a thing that CSS allows. Flexbox, responsive design -- it's all optional. There is going to be a sense when you use CSS that way that you are swimming against the grain, and that's on purpose because it's important that the instinctive default way that new designers think about the web is in those responsive terms. But even if the web pushes you in that direction a bit, it's not a requirement -- you can still design interfaces the way you're talking about, and you can heavily use breakpoints and you can have different layouts depending on the situation. One thing that I see websites do fairly often (which I don't think is great practice but I'm throwing it out as a common practice and I understand why people do it) is literally have two versions of their menus for mobile and desktop in the same interface in the same DOM tree and just throw a "display: none" on one of them depending on the width of the screen. So it's not even necessarily that you have to serve different HTML, you can have different versions of components even on a completely static website with no JS that swap out seamlessly depending on the user's device size.
sfn42 3y ago
You can just make one layout that works totally fine on all screens. Problem is you're basically just making a mobile layout and scaling it up so it'll be shit on larger screens
- danShumway 3y ago
  Heavy, heavy disagree. Tiny example, but just because it's on my mind that I need to rewrite it soon: https://danshumway.com/resume https://danshumway.com/resume. This is almost per-pixel identical to the resume layout that I used to have laid out in a normal editor exclusively for PDF and print, but without making a single concession with my normal print layout, it also seamlessly collapses into single columns perfectly fine on mobile devices, doesn't require Javascript, and the entire layout is ~160 lines of CSS. And to be clear, this is bad CSS. This is not CSS I'm proud of, this is CSS I wrote ages ago that I'm going to be tackling very differently whenever I get around to rewriting the resume. But it's still perfectly reasonable to have document layouts that feel like normal print layouts that collapse down well on mobile devices. And sure, this is a trivial example, but I think the same principles scale up. I don't believe that applications are different. Most application UIs can be represented as trees, and trees are well-suited for multiple-column layouts and collapsing rules based on width. That many sites work on mobile and don't scale up is a result of developers designing primarily for small screens and not thinking about large screens at all. Even here, this resume should handle wider screens better, it doesn't take enough advantage of available width. But the other thing about the web compared to native is that with native toolkits if a developer designs for mobile and then doesn't think about desktop, the app just doesn't work on desktop at all and you can't use it. On the web, if a developer designs for mobile and doesn't think about desktop, at least the interface is still usable on desktop. And vice-versa: there are desktop interfaces on the web that are miserable on mobile devices. But they work. None of the alternatives that people are proposing have that advantage.
  - sfn42 3y ago
    I don't really see how this disagrees with me at all. Yeah, you can make a layout what "works" on all sizes, I said that. For something trivial it can even be great on all sizes. But a more complex website like let's say amazon.com is much better with thought-out styling for different widths.

by wruza 3y ago

danShumway 3y ago

The web and CSS make it reasonably feasible to support most of those layouts well with at most 2-3 layouts in one source. My point is that it is impossible to get the same level of results doing fully device-specific and domain-specific languages without considerably more work -- more work than would ever be undertaken by the majority of people building for the web today. If you want an indie web, if you want websites that aren't just built by corporations and professional development teams, HTML and CSS is what enables those indie websites to exist and to work across every device you own. The proposal of using interface-specific languages and abstractions wouldn't work. Doesn't work, in fact, when you look the places where it's being attempted as a UI strategy. Like democracy, universal design abstractions such as CSS are the worst way to design interfaces that work in the real world for real users across diverse devices and configurations -- except for every other way. If we asked devs to actually use separate domain languages for mobile devices and desktop devices, the web would be a lot smaller and a lot more limited and a lot less flexible and a lot worse for end users.

wruza 3y ago
I don’t think our common ancestor in this subthread suggested separate languages for different screen sizes. Did they?
- danShumway 3y ago
  > The problem with css is almost entirely self inflicted, though. Yes, layout is hard. Why make it harder by aiming for the model we now have? Specifically, why aim for one major model that will fit all pages? It's possible I interpreted that incorrectly? But if their problem is just making different layouts then I don't see what the issue is. CSS has breakpoints. You can already make different layouts for different screen sizes. You're not required to have one set of rules that apply to every page size. The only criticism that makes sense to me as a reading is that they don't want a common set of UI paradigms and language features that allow targeting multiple devices and they want a more specific language targeted at describing a subset of those interfaces -- because that's what CSS is. That's the only thing that CSS is, it's just a universal rules-based language. You can design different layouts for different page sizes, you can even on the serverside serve entirely separate HTML pages for mobile and desktop devices. The only issue I can think of left to complain about with CSS being too general is that CSS is a common language designed to be used in all of those situations instead of in only one of them. Did they mean that they wanted CSS to have separate terminology and paradigms and ways to tackle those problems built into the language? It does! And that's exactly what people complain about, that's exactly where the "why are their 5 ways to do this" complaints come from, they come from CSS having lots of different ways to achieve the same effects based on the individual unique needs of the specific interface being created. What's the alternative, have one way of doing everything for every interface? The original commenter I was replying to said that they didn't want that. They want multiple models for different formats, and CSS has that and lets you use them and target as many interfaces as you want, and there are ways to detect and serve different CSS and HTML based on device agents, and so... I don't know, if they don't want different languages, then what is the complaint?
  - taeric 3y ago
    I wasn't necessarily proposing separate languages. I don't see the benefit in having a single source, though. The vast majority of designs do not need to have every single element recalculated at the client. To that end, I confess I would encourage leaning more heavily into absolute positioning of elements than most places go with. Is what I did for stuff such as https://taeric.github.io/cube-permutations-1.html https://taeric.github.io/cube-permutations-1.html, and seems to work just fine. I remember I did something similar on the job once, and the next developer came in and was against the idea of using absolute positioning. The rewrite did not go well. :( My push is the "model" for what a page is showing should be dominated by concerns of what the page is showing. It should, ideally, not be too heavily influenced by how you want to write the styling for it. We rebelled against using tables for styling years ago. Nowadays, we shrug at the number of divs necessary.
    - danShumway 3y ago
      So, I would push back against this as a design pattern, but I do want to re-emphasize, if you really want to absolute-position all of your divs, and if you want to serve even completely separate HTML for different devices -- you can. That is a thing that CSS allows. Flexbox, responsive design -- it's all optional. There is going to be a sense when you use CSS that way that you are swimming against the grain, and that's on purpose because it's important that the instinctive default way that new designers think about the web is in those responsive terms. But even if the web pushes you in that direction a bit, it's not a requirement -- you can still design interfaces the way you're talking about, and you can heavily use breakpoints and you can have different layouts depending on the situation. One thing that I see websites do fairly often (which I don't think is great practice but I'm throwing it out as a common practice and I understand why people do it) is literally have two versions of their menus for mobile and desktop in the same interface in the same DOM tree and just throw a "display: none" on one of them depending on the width of the screen. So it's not even necessarily that you have to serve different HTML, you can have different versions of components even on a completely static website with no JS that swap out seamlessly depending on the user's device size.

sfn42 3y ago

You can just make one layout that works totally fine on all screens. Problem is you're basically just making a mobile layout and scaling it up so it'll be shit on larger screens

danShumway 3y ago
Heavy, heavy disagree. Tiny example, but just because it's on my mind that I need to rewrite it soon: https://danshumway.com/resume https://danshumway.com/resume. This is almost per-pixel identical to the resume layout that I used to have laid out in a normal editor exclusively for PDF and print, but without making a single concession with my normal print layout, it also seamlessly collapses into single columns perfectly fine on mobile devices, doesn't require Javascript, and the entire layout is ~160 lines of CSS. And to be clear, this is bad CSS. This is not CSS I'm proud of, this is CSS I wrote ages ago that I'm going to be tackling very differently whenever I get around to rewriting the resume. But it's still perfectly reasonable to have document layouts that feel like normal print layouts that collapse down well on mobile devices. And sure, this is a trivial example, but I think the same principles scale up. I don't believe that applications are different. Most application UIs can be represented as trees, and trees are well-suited for multiple-column layouts and collapsing rules based on width. That many sites work on mobile and don't scale up is a result of developers designing primarily for small screens and not thinking about large screens at all. Even here, this resume should handle wider screens better, it doesn't take enough advantage of available width. But the other thing about the web compared to native is that with native toolkits if a developer designs for mobile and then doesn't think about desktop, the app just doesn't work on desktop at all and you can't use it. On the web, if a developer designs for mobile and doesn't think about desktop, at least the interface is still usable on desktop. And vice-versa: there are desktop interfaces on the web that are miserable on mobile devices. But they work. None of the alternatives that people are proposing have that advantage.
- sfn42 3y ago
  I don't really see how this disagrees with me at all. Yeah, you can make a layout what "works" on all sizes, I said that. For something trivial it can even be great on all sizes. But a more complex website like let's say amazon.com is much better with thought-out styling for different widths.