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.

---

Reply via email

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.

---

Originally posted as Why it's good for users that HTML, CSS and JS are separate languages on Hidde's blog.

Reply via email

For accessibility purposes, you could think of headings as a table of contents. But what if there are headings without contents?

On a web page, a heading (h1, h2, h3 etc) signposts ‘a section about X starts here’. Heading names are section names, in that sense. If, in a banana bread recipe, one heading says ‘Ingredients’, and the other says ‘Method’, expectations are set about what can be found where. Under the first heading, we’ll expect what goes into the banana bread, under the second we’ll expect some steps to follow.

The issue

Now, a problem I saw on a website recently: headings with no content. The issue wasn’t empty hx elements, it was that there was no content between these elements and the next. This can happen when the heading element was picked merely for its looks, rather than as a way to indicate that there is some content—and what kind of content.

<h1>Banana bread</h1>
<h2>It's tasty</h2>
<!-- nothing -->
<h2>It's healthy</h2>
<!-- nothing -->
<h2>It can be anyway</h2>

On a site with beautiful heading styles, this could look great, but structurally it is unhelpful, because when someone navigates to one of these h2’s, they find nothing.

It could also constitute a failure of WCAG 1.3.1: Info and relationships, because you’re basically claiming a structural relationship when there isn’t one.

So, the two questions to ask for headings:

• useful description: does this clearly say what kind of content I can find underneath?
• content: is there any content available underneath?

In the example above, only the h1 meets the criterion of being something we would want to navigate to. The bits underneath are more of a list of unique selling points. Something like this would be better in this context:

<h1>Banana bread</h1>
<ul>
  <li>It's tasty</li>
  <li>It's healthy</li>
</ul>

Note: the problem is not multiple headings as such, it’s multiple headings of the same level, that have no non heading content that they are a description for.

In summary

When you use a heading element, you set the expectation of content—always have content between headings of the same level.

---

Reply via email

For accessibility purposes, you could think of headings as a table of contents. But what if there are headings without contents?

On a web page, a heading (h1, h2, h3 etc) signposts ‘a section about X starts here’. Heading names are section names, in that sense. If, in a banana bread recipe, one heading says ‘Ingredients’, and the other says ‘Method’, expectations are set about what can be found where. Under the first heading, we’ll expect what goes into the banana bread, under the second we’ll expect some steps to follow.

The issue

Now, a problem I saw on a website recently: headings with no content. The issue wasn’t empty hx elements, it was that there was no content between these elements and the next. This can happen when the heading element was picked merely for its looks, rather than as a way to indicate that there is some content—and what kind of content.

<h1>Banana bread</h1>
<h2>It's tasty</h2>
<!-- nothing -->
<h2>It's healthy</h2>
<!-- nothing -->
<h2>It can be anyway</h2>

On a site with beautiful heading styles, this could look great, but structurally it is unhelpful, because when someone navigates to one of these h2 ’s, they find nothing.

It could also constitute a failure of WCAG 1.3.1: Info and relationships, because you’re basically claiming a structural relationship when there isn’t one.

So, the two questions to ask for headings:

• useful description: does this clearly say what kind of content I can find underneath?
• content: is there any content available underneath?

In the example above, only the h1 meets the criterion of being something we would want to navigate to. The bits underneath are more of a list of unique selling points. Something like this would be better in this context:

<h1>Banana bread</h1>
<ul>
  <li>It's tasty</li>
  <li>It's healthy</li>
</ul>

Note: the problem is not multiple headings as such, it’s multiple headings of the same level, that have no non heading content that they are a description for.

In summary

When you use a heading element, you set the expectation of content—always have content between headings of the same level.

---

Originally posted as When there is no content between headings on Hidde's blog.

Reply via email

Last year, I published Equality, a reading list. I’ve continued to read about equality, so here’s a second reading list, with even more recommended reads.

As with the previous list, I am no expert. The books in this list helped improve my understanding of a number of different inequalities and how they intersect. I hope they can help you, too!

Two notes:

1. The word “equality” may have been poorly chosen on my part, and equity may be a better thing to strive for. Equality is the concept of treating everyone the same. Equity recognises not everyone has the same needs. It strives to treat people differently based on specific needs. Both want to promote fairness, so there’s that.
2. A major misconception about racism is that it consists of tangible and objectively verifiable acts committed by mean people. Like a bar tender who refuses to serve [insert race] people. Pretty much all of the books in this list clarify that racism is often none of those things. They explain it as a system, demonstrated by ‘lived experiences’ of the people affected by it, often invisible to others. It commonly involves nice or well-intended people. Any given person may be more racist than they think. All of this makes the subject hard to talk about it for people, as all people have different experiences

Without further ado, these are the recommendations, I hope there’s something in it for you.

“Not racist” is not enough

Ibram X. Kendi’s very popular “How to be an antiracist” is an extensive analysis of racism. It looks at history, culture, class, biology, ethnicity and more from an antiracist perspective. Antiracist, Kendi explains, is not the same as “not racist”. It’s not personal or about specific people either, it’s about working to dismantle a system. To be antiracist, says Kendi, is to act in ways that support antiracist policies (“policies that reduce racial inequity“). Almost every chapter starts with one or more definitions, often drawing clear distinctions. They help the reader identify what lacks in their thinking about the issues, and ensure a good understanding of the argument Kendi makes. To be antiracist, requires careful scrutiny of one’s own actions and ideas, something Kendi himself does, too. This is not something we can sit down and do one afternoon, the scrutiny should be an ongoing process. This book is the ideal guide to that process. Get the audiobook if you can, it’s great and author-narrated.

How to be an antiracist by Ibram X. Kendi. See also Brené Brown with Ibram X. Kendi (podcast)

Nice people

When you believe nice people cannot be racist, you don’t understand what racism is or how it operates, explains Austin Channing Brown in “I’m still here”. This belief in various shapes and forms, that are all harmful to the antiracist cause. There is what Channing Brown calls “relational defense’: “when people say they cannot possibly be racist, by appealing to the relationships of those who ‘know’ them”, or when they have black friends. Seems nice, but it puts the onus on the harmed. And there’s the concept of color blindness, which, again, seems nice, but it defeats the purpose if it is a blindness for racial injustice at the same time. Channing Brown’s perspective is that of a black Christian woman, and, like many of the other authors in this list, she shares generously from her own experiences and perspectives. Her treatment of the facade that diversity policy can be, is particularly well articulated. Again, I can recommend the author-narrated audiobook.

I’m still here by Austin Channing Brown. See also, Brené Brown again… Brené Brown with Austin Channing Brown (podcast)

Talking about racism

Talking about race can be uncomfortable, and can leave people with questions. “So you want to talk about race” very patiently and straightforwardly answers some of those. It treats important subjects like privilege (and what it means to “check your privilege”), microagressions, police brutality and cultural appropriation, and makes for a good entry-level book about anti-racism. This book is American, some themes might make less sense to people elsewhere (“on campus arrests” and lack of universal healthwcare come to mind). Like Kendi, Oluo is frank about her personal experiences, whether it is in examples of microagressions she experienced or tales of how she had to re-examine her own prejudice. I found this mixture of memoire and hand book very helpful.

So you want to talk about race by Ijeoma Oluo

Bananas

Pete Wu is a Dutch journalist and “second generation” Chinese. His mom calls him “banana”, yellow outside, white inside. As he wrote his book “De bananengeneratie” (The banana generation, Dutch only), he found this was the case for other Chinese-Dutch, too. The book has interesting reflections on discrimination and cliches, and crystal clear analysis of what it means to be Chinese-Dutch in The Netherlands. I previously read Sun Li’s excellent De zoetzure smaak van dromen, which covers some of those subjects, from a slightly different angle. De bananengeneratie also explains how being Chinese-Dutch intersects with being gay, as Wu describes his experiences in online dating (the phrase “no asians” is apparently common in the online Dutch gay scene).

De bananengeneratie by Pete Wu

The myth of “trickle-down”

Some say it will lead to more equality if minorities make it to the top. This idea of “trickle down” is questionable, shows Dawn Foster in her short book “Lean out”. Sheryl Sandberg may have successfully made it to the top, but her “journey” cannot simply be copied by others. Making it to the top shouldn’t be an aspiration of feminism anyway, explain the authors of “Feminism for the 99%”, as sexism often intersects with other problems, like poverty, and there are bigger problems to solve at the bottom.

Lean out by Dawn Foster and Feminism for the 99% by Cinzia Arruzza, Tithi Bhattacharya and Nancy Fraser

Winners take it all

Not to be confused with ABBA’s The winner takes it all. This is a good reminder that we should be extremely wary of people who say or pretend that they’ll save the world or make it more equal, especially if they’ve made large contributions to equality through their previous work. “Winners take all” makes fun of thought leaders and their conferences, explains what it means if philanthropists involve with politics and why “win win” without friction is a pipe dream.

Winners take all: the elite charade of changing the world by Anand Giridharadas

Such a fun age and Little fires

Novels are a really good way to better understand racist dynamics, so I want to end this list with two of my favourite reads this year, “Such a fun age”, by Kiley Reid, beautifully shows how good intentions cannot prevent bad impact, by exploring racial inequality from two points of view, a rich white woman and a single black twenty-something. “Little fires everywhere”, by Celeste Ng, takes place in Shaker Heights, a suburb of Cleveland Ohio, where everything is planned, including careers, as if there is no privilege, and everyone is colour blind, as if there is no racial tensions. This is also a tale about motherhood, identity, and social status, the comedy is top notch and the characters are fantastic. This was also turned into a tv series on Hulu.

Such a fun age by Kiley Reid and Little fires everywhere by Celeste Ng.

---

Reply via email