[wruza]

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]

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]

I don’t think our common ancestor in this subthread suggested separate languages for different screen sizes. Did they?

[danShumway]

> 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]

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, 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]

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.

[taeric]

I don't want to absolutely position all divs. But if I have one that I want to be always to the left taking up a knowable amount of space, I don't see the benefit in trying to make flow based choices so that that works out.

And fair that flexbox and such are probably fine for a lot of that, nowadays. Amusingly closer to the layout managers of early Java development days. Most of my learning was pre that. Which is why I do stress that I agree that CSS is perfectly workable.

The only real problem I see, is that sometimes the different layouts do require either slightly different markup for parenting/flex choices to work out in different layouts, or they require hilariously non-obvious markup that will work with both. Amusingly, XSLT days worked well in that aim, as you could keep the base markup only the content, but then use a stylesheet to add/remove things as necessary for display. Alas, that went nowhere.

[sfn42]

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]

Heavy, heavy disagree. Tiny example, but just because it's on my mind that I need to rewrite it soon: 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]

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.

[danShumway]

> is much better with thought-out styling for different widths.

When people talk about responsive design, we don't mean that you shouldn't be thinking about styling for different widths. We mean that what you come up with is a singular design that responds to changes in screen size and font size, whether that's using breakpoints, wrapping, hiding and showing elements, or a combination of all of these things -- as opposed to building a completely separate interface that the user can only access through a separate URL or application (if it's even available on their device in the first place).

Yeah, you'll get bad interfaces if you only think about one screen size, but responsive design is explicitly about not only thinking about one screen size.

Amazon is maybe a bad example here; their site doesn't implement great responsive design as far as I can tell. Scale down a window too far on Desktop and the site just throws a horizontal scrollbar at you. This is despite the fact that Amazon absolutely could collapse down into a single-column view. I disagree that Amazon's interface is so complicated that it needs a full browser width, it's a vertical list of horizontally floating elements, it's a great candidate for wrapping listings and for collapsing down the menus based on a breakpoint.

But I'm left sort of feeling like we're talking past each other. I agree that you should think about multiple sizes. I don't see what that has to do with whether or not CSS is well-suited for building interfaces, I would argue that CSS makes it easier to think about multiple screen sizes when building interfaces. I think that's CSS's strength as opposed to static layout tools that lack the expressiveness to describe what you want to happen when a column gets too narrow or to set things like margins based on text size instead of pixels or on and on. Those tools are all really useful when building interfaces that actually adapt to different settings/resolutions.

[sfn42]

I agree that we're talking past each other. I completely agree with everything you've said here.