More Respect for HTML

Why do front-end developers neglect HTML?

A learning experience

Have you ever come to respect something/someone that you initially dismissed or blew off?

My wife and I became first-time homeowners a few years ago and were very excited to tinker and improve. Within that first year we painted the living room, replaced the kitchen faucet, re-acquainted with yard maintenance (don’t spend your money on a cheap reel-mower), and came to terms with gophers digging up our yard. Eventually we’d take on grander plans like planting citrus trees, putting solar on our roof, and replacing the windows. We had an air conditioning unit that we didn’t think much about, except that it kept our house cool during the 6 months of Southern California summer.

My respect for that A/C unit rose significantly during a July weekend when my wife and kids were away. It was one of those horrible 110-degree (fahrenheit) spells, with some humidity thrown in for good measure. The vents stopped blowing out cold air. The temperature inside the house rose. It took a few days to get the right technician to fix it with our home warranty, and in that time I came to appreciate the A/C unit much more as I holed up in a bedroom with a little wall unit.

My purpose, dear reader, is to advocate for more front-end developer respect for HTML. Take a moment and honestly answer these questions:

1. When was the last time you asked an HTML question in a candidate interview?
2. Do you know how to make a nested list with semantic HTML? A heading with links and dropdowns?
3. Could you code up a working, accessible form without looking anything up?

If your answers were as awkward as mine, perhaps you’ve overlooked and neglected HTML also.

With that awkward silence as a backdrop, let me clarify that I use overlook and neglect intentionally, as opposed to avoid or fear. I’d assume the average dev “fears” build tooling like Webpack, trying to avoid touching it unless absolutely necessary for fear of borking something or having to learn a slew of config options (“thank goodness there’s someone getting paid more than I am to take care of all that stuff”).

A typical developer’s attitude towards HTML seems to be more like “Don’t worry, I’ve got this”, like the time as a 16 year-old I took my coach’s sports car (with permission!) out for a spin, blithely overconfident, scraping on a speed bump and spraying gravel when accelerating.

Why front-end devs neglect HTML

Here’s why I think front-end developers tend to neglect HTML:

Doesn’t help you as much as programming languages do

As developers a lot of our time is spent doing things that will make our jobs simpler and more productive, like speeding up test runs or refactoring code. However, many of us struggle at doing (equally important) things that make users’ lives easier – things like performance and accessibility. I’d argue that creating semantic HTML doesn’t improve developer experience like writing great JavaScript does. Writing correct HTML is like shoveling your sidewalk after a snowstorm – schoolchildren will appreciate it, but it won’t benefit you personally as much (or as immediately) as picking up the toy in the hallway that you just stepped on.

Compounding the problem, browsers are pretty fault-tolerant of imperfect HTML. When was the last time your web app stopped working entirely due to some poorly-crafted HTML? Not to say it can’t happen, but you get my point…

Seen as low-level/entry-level

I think developers sometimes treat HTML like assembly language – something low-level enough that we shouldn’t have to bother with directly (“If only computers could take care of it for us!”). We do have Markdown, JSX, MDX, ERB, Haml, to name a few, but these don’t erase the need to understand and leverage HTML. That’s because the “consumer” of the outputted HTML isn’t some compiler or processor – it’s the browser, and search crawlers, and screen readers, and CSS, which directly influence the user experience.

Along the same lines, some might feel they’ve moved on from HTML, like it’s a beginner-level class that they’ve passed. They may have cut their programming teeth hand-writing HTML pages, copy-pasting markup all over the place, and are proud to graduate on to more sophisticated languages. But while they’ve “moved on”, the browser is still dependent on HTML, so one way or other that’s what you have to give it. You can level up in how you generate it or reuse it, but at the end of the day someone has to manage the markup and make sure it's accessible.

Trivialized as non-logical

I used to think that HTML was like learning to spell in English – light on rules and heavy on specific words with quirky exceptions. If I needed to write some markup for a component, I thought “google it and yer done”. But HTML does have rules and patterns.

What makes HTML hard?

Of course, it’s not all the developer’s fault. HTML works against the application-developer mindset in a couple of ways:

HTML was designed for documents, not for apps

At its heart, HTML is designed for documents, and it shows. Expressing rich text is straightforward, but when creating app-like interfaces, the choice of elements to use is less clear.

It’s the what, not the how

HTML straddles the line between structure and content. It defines the what of the page/app, not the how. Since developers typically handle the “how”, we feel less comfortable to define (or interpret) the “what”. Determining the structure of a page is one thing, but interpreting the content is another, especially since the raw content often comes from others, perhaps even from outside of the team.

Recent HTML learnings

Now that I’ve given my assumptions of why HTML is neglected/overlooked, I want to share some HTML learnings that have increased my respect. Lately I’ve spent more time working in our text editor, which forced me to deepen my understanding of HTML, which prompted me to write this article.

Categories of elements

Although technically not a distinction in HTML5, it’s helpful to separate elements into “block-level” and “inline”. Inline elements (like <span>s) can’t contain block-level elements. Block-level elements can usually include other block-level elements.

Element nesting

Divs and spans aren’t the only element you can nest inside themselves. You can have blockquotes inside blockquotes, and lists inside lists (as grandchildren of the outer list). You can also nest inline-level elements like <strong> and <em> (to indicate degrees of emphasis), for example.

Multiple tags can represent same content, but have different meaning

Content may visually look the same but have different meaning, and thus should be represented with a different HTML element. For example, <strong> and <b> both visually show as bold, but one is for importance and one is for visually standing out without importance. Similarly, <em> and <i> both visually show as italic, but one is for emphasis and one is not.

Browsers are tolerant, but have limits

Compared to other environments and languages, browsers are incredibly tolerant of HTML. There are exceptions, though – for example, if you put a block-level element inside a paragraph element, the paragraph will close itself off before the child block-level element, producing unexpected results.

Conclusion

Like it or not, HTML is who we’re stranded with on this desert island. It’s a taciturn companion, but it pulls its own weight and knows how to light a fire without matches. As app frameworks increasingly spread across the stack, our skills need to as well – including farther forward on the stack, to truly provide experiences fit for users.