[tabtab]

Web UI "standards" are a friggen mess. We really need to rethink it all. For one, if we had a standard state-ful GUI markup language, we wouldn't need to reinvent so many common GUI widgets and idioms using bloated libraries based on JS + DOM.

Second, if web standards allowed true absolute positioning of vectors (as an option), then the layout engines could reside on servers, allowing us to choose a layout engine that best fits domain and need.

Note that while existing web standards do have some coordinate based features, they are too inconsistent to reply upon. If they were any good, we wouldn't need PDF viewers.

[eyelidlessness]

My goodness a coordinates based layout system would be an enormous step backwards. We’d be back to `m.` subdomains and horizontal scrolling as the norm.

The CSS layout standards are certainly not all ideal for my preferences. But the adaptability they afford in fluid layout is far better for real end users than any kind of absolute layout predetermined on a server.

We’ve reached a point I can use most of the web on my phone without compromise and I’d hate to lose that for some development convenience.

[tabtab]

I don't think you understand. The layout engine could be on the server, not "non existent". (Although one could program directly with coordinates if they wanted.) Coordinate based vectors allows the layout engine to be on the server, so that we are not stuck with a one-size-fits all layout engine.

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

And what's good for public site phone use may not be the right tool for internal CRUD applications. I don't recommend Google make an email client with the additions I suggest, for example. The existing standards are fine for light-input consumer sites, but lousy for productivity-oriented CRUD. I'm not saying get rid of existing standards.

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