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