Why it's good for users that HTML, CSS and JS are separate languages

This week, somebody proposed to replace HTML, CSS and JavaScript with just one language, arguing “they heavily overlap each other”. They wrote the separation between structure, styles and interactivity is based on a “false premise“. I don’t think it is. In this post, we’ll look at why it is good for people that HTML, CSS and JS are separate languages.

I’m not here to make fun of the proposal, anyone is welcome to suggest ideas for the web platform. I do want to give an overview of why the current state of things works satisfactorily. Because, as journalist Zeynep Tefepkçi said (source):

If you have something wonderful, if you do not defend it, you will lose it.

On a sidenote: the separation between structure, style and interactivity goes all the way back to the web’s first proposal. At the start, there was only structure. The platform was for scientists to exchange documents. After the initial idea, a bunch of smart minds worked years on making the platform to what it is and what it is used for today. This still goes on. Find out more about web history in my talk On the origin of cascades (video), or Jeremy Keith and Remy Sharpe’s awesome How we built the World Wide Web in 5 days.

Some user needs

Users need structure separated out

The interesting thing about the web is that you never know who you’re building stuff for exactly. Even if you keep statistics. There are so many different users consuming web content. They all have different devices, OSes, screen sizes, default languages, assistive technologies, user preferences… Because of this huge variety, having the structure of web pages (or apps) expressed in a language that is just for structure is essential.

We need shared structure so that:

• screen reader users can navigate web pages by heading (see headings are tables of contents).
• people with an attention disorder can turn on reader mode
• people with motor impairments can use autofill (see Identify Input Purpose)
• people who want to read a foreign language page in their mother tongue can stick a URL into Google Translate

All of these users rely on us writing HTML (headings, semantic structure, autocomplete attributes, lang attributes, respectively). Would we want to break the web for those users? Or, if we use the JSON abstraction suggested in the aforementioned proposal, and generate DOM from that, would it be worth breaking the way developers are currently used to making accessible experiences? This stuff is hard to teach as it is.

Even if we would time travel back to the nineties and could invent the web from scratch, we’d still need to express semantics. Abstracting semantics to JSON may solve some problems and make some people’s life easier, but having seen some attempts to that, it usually removes the simplicity and flexibility that HTML offers.

Users need style separated out

Like it is important to have structure separated out, users also need us to have style as a separate thing.

We need style separated out, so that:

• people with low vision can use high contrast mode; a WebAIM survey showed 51.4% do (see also Melanie Richard’excellent The Tailored Web: Effectively Honoring Visual Preferences)
• people who only have a mobile device can access the same website, but on a smaller screen (responsive design worked, because CSS allowed HTML to be device-agnostic)
• people with dyslexia may want to override some styles use a dyslexia friendly typeface (see Dyslexic Fonts by Seren Davies)
• people who (can) only use their keyboard can turn on browser plugins that force focus outlines
• users of Twitter may want to use a custom style sheet to turn off the Trending panel (it me 🙄)

Users need interactivity separated out

Some users might even want (or have) interactivity separated out, for instance if the IT department of their organisation turned the feature off company-wide. Some users have JavaScript turned off manually. These days, neither are common at all, but there are still good reasons to think about what your website is without JavaScript, because JavaScript loss can happen accidentally.

We need interactivity separated out, because:

• some people use a browser with advanced tracking protection, like Safari or Firefox (see my post On the importance of testing with content blockers)
• some people may be on low bandwidth
• some people may use an old device or operating system for valid reasons
• some people may be going to your site while you’ve just deployed a script that breaks in some browsers, but you’ve not found out during testing, because it is obscure

As Jake Archibald said in 2012:

“We don’t have any non-JavaScript users” No, all your users are non-JS while they’re downloading your JS

That’s right, all your users are non-JS while they’re downloading your JS.

Existing abstractions

None of this is to say it can’t be useful to abstract some parts of the web stack, for some teams. People abstract HTML, CSS and JavaScript all the time. People happily separate concerns differently: not on a page level, but on a UI component level.

On the markup end of things, there are solutions like Sanity’s Portable Text that defines content in JSON, so that it can be reused across many different “channels”. This is a format for storing and transferring data, not for displaying it on a site. Because before you display it anywhere, you’d write a template to do that, in HTML. In a government project I worked on years ago, the team abstracted form fields to JSON before converting them to HTML. I currently work on a project where we use XSLT to specify some stuff before generating HTML.

For CSS there are extensions like Sass and Less, utility-first approaches like Tailwind and many methods to define CSS inside JavaScript component. From JSSS (from 1997) to CSS in JS today, there is lots to choose.

As for JavaScript: there are numerous abstractions that make some of the syntax of JavaScript easier (jQuery, in its time), that help developers write components with less boilerplate (like Svelte and Vue) and that help teams make less programmatically avoidable mistakes (TypeScript).

I don’t use any of these abstractions for this site, or most others I work on. Yet, many approaches are popular with teams building all sorts of websites. Choose any or no abstractions, whatever helps you serve the best HTML, CSS and JS to end users.

We’re very lucky that all of these abstract things that are themselves simple (ish) building stones: HTML, CSS and (to a different extent) JavaScript. With abstractions, individual teams and organisations can separate their concerns differently as they please, without changing the building blocks that web users rely on.

Could you benefit people in your abstractions? Maybe. The proposal mentions specific parameters for visual impairments and content that can trigger seizures. But it is better for users (including their privacy) to have such things in the main HTML and CSS, regardless of whether that was written by hand or outputted by some abstraction.

Conclusion

The separation between HTML, CSS and JavaScript as it currently is benefits web users. It does this in many ways that sometimes only become apparent after years (CSS was invented 25 years ago, when phones with browsers did not yet exist, but different media were already taken into account). It’s exciting to abstract parts of the web and remodel things for your own use case, but I can’t emphasise enough that the web is for people. Well written and well separated HTML and CSS is important to their experience of it.