Layouting is hard only from a css perspective. We used TFrames and tAligns in delphi, we used (sane!) boxing in gtk, we used apple's constraint system. Entire operating systems and business packs were built exclusively on these for decades. And nothing was as hard as making damn css work on three devices without an explicit role or two to manage that.

Alternative is a king. Leave your css if you like it, but please make it an intermediate layer, not final, and allow more sane primitives on which people could build their ui. People are sick and tired of translating geometric ui layout to allegedly-text layout, when there is not a single character of text until fifteenth level of divs.

Edit: it is not "css as format" that is broken, if that was not clear. Broken is a set of primitives under "display" property.

Any given layout is pretty easy to work. The problem is the sheer number of form factors, flexible resizing, and rendering methods (as you mentioned, print vs AMOLED vs monitors) that make designers and engineers cry.

When I talk to designers, they love love love paper for many reasons, but one of them is the total control they have over the medium and the fact that they only have to deal with one fixed form factor at a time.

Maybe instead of having stylesheets for print and media queries, different versions are just written for each?

I've wondered this about a11y in HTML too. Instead of trying to torment the browser into understanding how a11y should work with a bunch of ARIA properties, what if a simple alternative was offered which was easier to understand for a11y but not for 'normal' users?

ARIA properties are really just the escape hatch. For the most part, people shouldn't be using them except to fill in gaps.

Semantic HTML is the simple alternative. And the reason HTML has worked for accessibility overall is because it forces developers to use the accessible interface.

Compare that with image/video captions/descriptions, where most devs just don't do it. If you have a programming setup where the accessible and visual parts of your interface are two separate things, then by and large you will usually only get software with a visual interface.

The terminal is another good example of this. It turns out that forcing developers to code an interface that can reduce to pure text has some advantages for accessibility, extensibility, and portability.

Those suggestions would probably be better if everyone building a website had infinite man power. But in the real world adoption is going to suffer if you have to make a separate document for web, print, a11y, etc. Then someone will say "Why don't we have a unified markup language that we can use to produce each of these documents for us?" And then XSLT will be invented. And what a mess we've made.

But if people are already putting in extra effort to get these features working in their unified markup language, then it isn't different (from the perspective of effort) to write separate versions. In fact, it might be easier, because at that point you're working in a language custom designed for the task at hand, not trying to shoe horn a spoken-word UI into a visual UI language.

Regarding accessibility: Isn't this the intention of the Accessibility Object Model?

> 'normal' users

Don't say this. The quotes don't make it any better - this is like outright discrimination to consider that people who need a well designed website are not normal. Every user of your product is a "normal user".

Remember that people's ability doesn't exist at two extremes - Just take eyesight. It is just a fact that people's eyesight starts to deteriorate, especially as you get older. This is incredibly normal, and just because you've gotten a bit older and can't see like a 12 year old doesn't mean you deserve a segregated web experience.

normal: the usual, average, or typical state or condition.

And there's a reason why both GTK and QT use CSS.

Gtk does use css, but not for the purpose of layout. Their layout rests on the same good, understandable and no-bullshit primitives (GtkContainer subtree) as before the time css-like theming was introduced. Gtk css solved a problem of theme engines (clearlooks, redmond, etc) which had to be done at low-level and thus were less easy to create or modify.

What I honestly didn't understand is why CSS and HTML don't have ui specific namespaces by default that could offer alternatives to div elements that would not be influenced by user agent stylesheets.

I think this was the primary idea behind xhtml back then (when looking at xforms et al) but somehow got lost into some weird hacks to make everything "somehow" run on IE.

Now we have ui and semantics in the same namespace (section, aside, dialog, main, article, footer, header et al) and everybody is just more confused. How should I use dialog, for example? No matter how code turns out, it's always a crappy JS based solution.

To be honest, I love the idea of web components, but I hate that there's no JS free deserialization from html to dom possible.

If you create a solution to advance the semantics of SGML, it's an architecture fail to implement it without the semantic aspects HTML and CSS were designed for.