> If CSS was designed the way it is just to satisfy the constraints of 1996, then maybe that gives us permission 20 years later to do things a little differently.
Yeah, just like we can choose which side of the road to drive on or pick any arbitrary character encoding for an 8-bit byte.
Driving on one side of the road offers no obvious benefits compared to driving on the other side of the road whereas getting rid of HTML and CSS offers obvious benefits and is long overdue.
Everybody talks about replacing CSS, yet nobody comes up with a feasible solution.
Layouting is hard. Very hard.
I mean, there's a reason why ooxml or docx are so similar to CSS, and why PDF is so broken that it's a candy store for exploits.
Both object and functional oriented replacements always have led to a lot of redundancy compared to their compiled CSS equivalents. And usually you cannot model layouts as flexible as with CSS' different flow models.
Everybody that says CSS can be replaced with something simple usually hasn't even thought of print stylesheets, media queries, or why the box model and flow model got so complicated.
The spec authors had very good reasons to make changes to the CSS spec(s).
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.
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.
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.
> Driving on one side of the road offers no obvious benefits compared to driving on the other side
If that were true, then why did Sweden go to the trouble to change in 1967?
The fact that they did so, and that doing so was to improve interoperability with neighboring systems, might give you some clue why getting rid of CSS and HTML requires more than mere 'obvious benefits' to justify it.
You’re being deliberately obtuse. Driving on some side of the road offers no benefit, other than historical concerns arising from one’s neighbors decisions, and likewise with CSS. I’m sure you were aware of this and I’m not sure why you bothered to raise such a pedantic and worthless point.
My experience is that people who tend to disparage web tech don't have much experience building clients in general, so they think building web clients is hard and annoying because it's the web without realizing it's because it's a client.
"My experience is that people who tend to disparage web tech don't have much experience building clients in general"
My mom should be able to build great frontends for Web software, but currently the technology requires her to know much more than she knows. As you say, she "don't have much experience building clients in general." Therefore it's important that we get rid of HTML, CSS, and Javascript.
This is an old debate, but to repeat the highlights:
The benefit would be the productivity gained from specialization. The work could be moved away from computer programmers. Beginners would find beginning as easy as building a HyperCard stack, and specialist UI/UX experts (not computer programmers) could be put in charge of advanced frontends.
The same argument that was made for Web Assembly also applies to the frontend: we now know what we need as a general compilation layer for frontend descriptive languages, things we did not know in 1996 when HTML/CSS/Javascript were coming together.
The crucial thing is to have the kind of serialization formats that software can write, thus opening the door to a version of Dreamweaver that actually works. In other words, something like Adobe InDesign would then be the correct way to create all frontends. I wrote about this in detail here:
HyperCard, Dreamweaver, InDesign, Photoshop, Flash and Illustrator do not use a markup language internally. As with Web Assembly, it's important we have the right primitive that we can compile to. There are configuration languages that can make it easy for beginners to hand edit a frontend, and in my article I mention the configs that Ruby On Rails, Symfony (PHP), and Django (Python) offer to generate simple CRUD interfaces, and I mention that these configs could be much more powerful if they had the correct primitive to compile against, rather rendering to HTML/CSS.
Aside from all that, I would raise the more urgent question for our industry, why did it seem like such an urgent task, all through the 1980s, 1990s, and early 00s, to create visual software that would make it easy for beginners to create software, and yet now this is no longer a priority? Is there some reason why we are moving away from the era when "Empower the masses to create software" seemed like an important goal for the industry?
You can't version control whatever binary format InDesign uses. Markup languages benefit from precision, readability from an editor, easy integration with other tools.
HTML and CSS have been evolving for over two decades (now maybe faster than ever) and have been battle tested by nearly 2 billion websites.
It seems crazy to me to think that we should throw it all out and do something new. I suspect contributing to the improvement of the existing spec is a much more pragmatic endeavor.
Yeah, just like we can choose which side of the road to drive on or pick any arbitrary character encoding for an 8-bit byte.