Recently, I started writing a lot about web development. I started with an article on the history of the Web and then I went to HTML and CSS. For those articles, I went quite deep: even developing since 1995, I started reading about all HTML tags, even the most obscure ones, as well as all CSS rules, the concept behind them and the whole context around their creation.
At some point, things “clicked” on my mind. So far, as most developers with mild OCD (or every developer, period) I have been a defender of the “separation of concerns” (SoC) that happened as a consequence of CSS creation. Before, HTML was everything a person should know to create a page. After, though, HTML was repurposed to be “semantic”, with tags suited to delimit content, and CSS should take care of the presentation.
As I said, before this made sense to me, mostly because it was something that sounds like an organisation method, and I like that (as programmers usually do). Going deeper into both of the aforementioned articles, though, I started to question my position to the point I saw myself switching sides. Not only SoC started to seem like an ill-conceived idea but CSS itself was also a bad one, at least in the way it was created.
All made sense then when I remembered about all the trouble I always had to organise CSS, especially before I started using scoped rules or CSS-in-JS.
I wrote about the issues with both on two very long articles, that I do not recommend that you dive into unless you have some time and patience. To save you some of both, I will try my best to summarise them.
The issues with HTML and CSS
HTML was created in 1989 and last modified in 2008, which is a galactic era ago in web time. To force a semantic approach (to separate the concerns) HTML has got too many new tags, all without any new functionality, just there for (subtle) semantic differentiation, while deprecating all-time favourites like b and i (only to introduce identical semantic doppelgangers like strong and em).
As this made HTML get too convoluted and open to interpretation, most people never got these subtleties right and, although Google enforced semantics at some point, now it mimics what humans do and prioritises content that is visible to humans over how tags are done.
The fact that the gazillion aria-* attributes are also too many and too confusing make for problematic accessibility and the screen readers are also coming up with ways to just read the page as humans would do, without relying on the code underneath.
In 1994 the Web had mostly small websites and there was no scripting language around yet. With that in mind and some goodwill towards over-engineering, CSS was invented to tackle the challenge of a new Web full of visually rich websites.
The idea was nice, but the outcome, well… Maybe because the Web was totally static at the time and JS had not even been born, its concept works like practically nothing on programming, with a bizarre way to feature inheritance and a selector-oriented approach that makes even small websites harder to organise, and medium to big projects totally impractical without helper tools.
CSS selectors were possibly created to be accessible for non-developers but they failed at it, which is pretty obvious given how convoluted the CSS concept is. Before CSS, non-developers often used plain HTML to create websites but, after that, tools like FrontPage and Dreamweaver became the only possible way.
When used without scoping, the style sheet can be so fragile to maintain and organise that a laughable command called !important was created to constantly remind us how messy things are in CSS, by design.
Actually, not only !important reminds us of this but also things that do not make a lot of sense in its original concept like scoping and even native CSS variables.
No wonder why Bootstrap and other layout frameworks are so successful: they keep web devs a bit more distant from CSS. Tailwind and other CSS tools go even further and make explicit their desire to bypass the failed “separation of concerns”.
Our up-to-date legacy
In most languages and development environments, although there are always frameworks available to be chosen as helpers, one can usually do fine without them. No situation is like what we get in web development: having a framework and a Web bundler is an absolute must to have something manageable on a professional setup.
Unlike any other language or environment, even Node.js (which is based on the same JavaScript that powers the Web) one has to use frameworks and bundlers to “fix” HTML and CSS: both can be diluted into the modern web dev stack when “recreated” by many different tools, that extend their functionality artificially and output a mash of the “legacy” original markups, in their original unmaintainable forms.
There is something wrong with the Web when you notice that, currently, the absolute majority of all web devs only develop with a stack that keeps them as far as possible from plain HTML/CSS. I wonder what web development beginners must think when they are told we have to generate this “legacy” code with dummy static assets for the web when working with modern tools like React, Vue, Emotion, SASS, as well as with JavaScript, a language that, if it is not the best all-around, is still pretty capable.
Finding the reasons
Ok, but, if we make a “code contortionism” to work our way around both plain HTML and plain CSS, which are old and outdated forms of development with major issues, why do we keep them?
What is preventing the Web from stepping into the future?
Well, the answer can date back to the time when developers struggled harder than today to develop websites and web apps because the major browsers at the time, Netscape Navigator and Internet Explorer, had very different ways of render pages, different APIs and they even did not want developers to detect them to make things harder (confusing user-agents are from that time).
In that context, it was a major victory when browser vendors finally got together and agreed on a base for future browser development. That base included the standards of HTML and CSS from the time, which evolved to be HTML5 and CSS3.
After those, which came a long time ago, neither HTML nor CSS had any new versions and the general guidelines are for them to never have. In practical terms, HTML is frozen in time since 2008 and the CSS concept is not set to change too, with it just getting new small updates like new rules and units (although people will constantly push for the concept-breaking @apply and other similar things, just because that is what makes sense to them).
What the future brings
I am not very optimistic about deeper changes in this situation, I’m afraid. Even if the changes could be made in an optional non-breaking way, the important browsers are mostly owned by corporate giants with little interest to implement changes too big in a unilateral fashion, not to mention that only Chrome would have the power (that is usually reserved for the dominating browser) to actually drive for changes that others may follow.
Chrome (and all other major browsers, for that matter) relies too much on its super-optimised engine that was crafted for years to deal with the messy stack HTML + CSS + JS, and remaking that engine for some new and revamped standards would make for a massive cost. Despite that cost and, while browsers’ engines are very well optimised for the mess, ditching the mess would allow for a much faster and more efficient Web.
However, as the web dev scene is currently not being subject to a lot of protests because of the issues I bring here, massive change is unlikely to happen soon. Small improvements like Houdini will make things a bit more interesting but things will not proceed much further from there.
Nevertheless, now we have another big factor called WebAssembly.
This marvelous potential game-changer makes it possible for people to develop websites (mostly) without JS, although today it is still being discovered, so to speak. In the event of a massive migration of web devs to Rust or other languages supported in WebAssembly, people may perhaps want to develop ways to bypass completely the DOM (by extension, most of HTML and CSS) and with this movement, some actual changes on the “mainstream” layout engines driven by the DOM could arrive (in this case, too late probably).
In any case, I would have two requests that I judge as easy ones and I would love to see at least one of them implemented. They would demand less effort from the browser vendors and would be, in my opinion, interesting steps towards a Web in sync with the reality of 2021.
My immediate wishlist
The first one would be to allow for a JavaScript file to be the entry point for Web apps/sites. It looks secondary but the entry point of web apps is a key concept.
This would not only be the end of the dummy index.html files that are good for almost nothing on a modern single-page app, but it also opens the path for web apps 100% built on code which, if not a panacea for all its issues, at least makes the Web foundations conceptually more cohesive, especially from the perspective of a beginner or an amateur. They (and we) would be free to use React with JSX and Emotion, or Vue with templates and scoped styles, for example, without the underlying entry code.
Also, I would love to see HTML semantic tags being ditched and deprecated, which would require even less effort from browser vendors, as they do not bear any functionality. These tags were never used right and as a consequence, both SEO and screen readers are moving on from them as I said above. They are there only as cognitive load, representing dumb costs on web app/site development. HTML is a very good way to represent a tree-like structure as a web page, but the overall lack of correct compliance to semantics shows it should be way simpler.
Conclusion
Web development, despite its immense popularity, is troubled by the amount of time it has been around with the same foundations, created for situations that either happened only too long ago or never happened at all. HTML and CSS should be reassessed, so they don’t need to be avoided and kept hidden like a shameful secret as they are today, neither they would drive people to bypass them completely, should this be made possible by WebAssembly.
This is not to be seen as an empty criticism towards browser vendors or the W3C people or whoever has a say on our Web but, rather, a cry for humility, whose goal is to help turn web development into something that would be more sensible and require fewer tools and less processing to achieve the same.