[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.