[eyelidlessness]

> I don't think you understand. The layout engine could be on the server, not "non existent".

Oh, I do understand which is why the thing in your quotes isn't something I said. Layout on the server means you're laying out without the context of my device or viewport, and certainly without any change of context like if I switch to dark mode or prefers-reduced-motion, or if my data access changes.

> And what's wrong with the "m." standard as an option? For some jobs it's the right tool.

Instead of getting overly principled about it... one of the reasons it went away was because the heuristics that determined what even is mobile were becoming increasingly wrong. And like I said this resulted in a bunch of ridiculous horizontal scrolling for lots of users.

[tabtab]

Re: "Layout on the server means you're laying out without the context of my device or viewport"

Why are you making that assumption? A device can either send its screen size to the server, or a size preference category if it wants to hide details: watch, phone, tablet, laptop, desktop, workstation. (And user should be able to switch the preference manually.)

Re: "And like I said this resulted in a bunch of ridiculous horizontal scrolling for lots of users."

Without seeing a specific scenario, I cannot comment on possible solutions or standard adjustment proposals. Sometimes people throw the baby out with the bathwater even the baby was fine.

[eyelidlessness]

> Why are you making that assumption? A device can either send its screen size to the server, or a size preference category if it wants to hide details

And what happens when I rotate my device? Or resize my window? Or switch to dark mode? Another request to the server to redraw? What happens when an unknown class of device is encountered? What happens when your assumptions about a known class of device aren’t future proof?

Look I agree that the CSS layout APIs aren’t as good as they could be. But I really don’t think making them less flexible is the solution. If anything they’re not flexible enough (for example many kinds of layout are still very difficult to achieve with dynamic content, even with grid). But what would improve the APIs in my opinion is to design them with common idioms as primitives. Grid has somewhat embraced that by allowing template areas to be named arbitrarily. But the underlying APIs are sprawling and hard to understand even with close attention to the docs/spec.

[tabtab]

> And what happens when I rotate my device? Or resize my window? ... or switch to night mode.

It tells the server and the server re-renders the page. It's a bit slower than client-side adjustments, but worth it for the extra power and control. I don't do those actions very often, do you? The existing tools screw those up anyhow.

> But I really don’t think making them less flexible is the solution. If anything they’re not flexible enough

That makes the client even more bloated, meaning more client version variation and bugs. That exacerbates the problem. By shifting the burden to the server, the client can be simpler and thus less buggy, and the server can pick the best layout engine for the domain instead of being stuck with the client's one-size-fits-all mistake.

[dbbk]

I really don't think you have thought this through.

[tabtab]

I have. Throw specifics at me. Bring it on! I've been in many debates like this before, and my suggestion is skeptic-tested.