The HTML I Wish I Had (pt. 2)

HTML Should Be For People

Any innovation should be for people. The end result should be human happiness. The driving goal percentage of the population affected toward happiness. This is how maximum good can be accomplished.

Most people believe it is reasonable for an organization to have a scope of population whom the responsiblility of "toward happiness" applies. While at my company we refute the claim, we can continue to examine HTML with that idea in mind.

In the context of HTML, the percentage of population affected is a lot. The technical term for this may even be considered "the inhabited earth." Any living user of the internet receives downstream decisions of WHATWG, the working group which defines HTML.

That working group did no justice for the human audience in the decision for semantic elements. It does nothing for the human readers. It makes the experience more wordy, complicated, and by the DevEx tradition of classifying coginitive load as undesirable, these additional elements make the experience worse.

I expect to hear a thought which goes, "But, but... accessibility!" I'll be clear. Accessibility is not optional, it is a requirement. I expect to hear that contending thought because a good HTML Developer has that in mind. Yet here is the pill to swallow: Semantic elements do nothing for accessibility. A Screen Reader (a screen reader is simply a web scraper) may implement some understanding of the elements, but it may not! Further, it's 2024, and there is no standardization in this regard. Moreover, the algorithms of what to do with the information must necessarily vary between developers, and the information of what the human reader wants to know about the page must also vary!

Semantic elements were only a step toward complication for the benefit of very few. WHATWG started as a company of "major" players in the internet biz, and it's clear their priorities were skewed. It is valuable technology for companies who's business model is web scraping, not for accessibility, but for content aggregation (i.e. search engines).

HTML should be for people. Human experience and the betterment in that area (generally, not financially), should be the goal of any major innovation with the effective reach of HTML. Instead we got technology to answer the question "How can this subsection be characterized?"

Better stated, it's a Secret Answer because no living thing reads the answer to that question. A business entity is not a living thing. A web scraper is not a living thing. Only a software writer is aware it's there, and as stated, the effect of this addition to the spec is an increase of cognitive load and worsening of experience.

Great 🙂

This is Part 2 of a 3-part series.

• Sept. 25: The HTML Innovation
• Sept. 27: HTML Should Be For People
• Sept 28: HTML For People

Leave a message with how you'd make HTML Better for Experience!

If you're interested in making Hypertext Applications for the purpose of Human Happiness, come to the party at Salvation! Salvation Company, where We Are Saved. Oh, and I hear the author of that HTML Handbook is a member at I'm sure there is a sharable manuscript in the member library!