Is HTML code? Who cares?

If you’ve been lucky enough so far to have avoided the question ‘is HTML code?’, I dare you to nip over to the Internet and ask.

You'll almost certainly see a repetitive stream of pointless arguing over semantics:

You can’t call it coding, because it’s not programming.

But it’s done by people who code, so it’s coding.

It’s not code, because it doesn’t use logic …

It’s a designer thing … blah, blah …

… Blah, blah …

It isn't pretty reading.

Avoiding responsibility

What most of these conversations lack is a sense of responsibility. Stamped in-between all those pithy lines is the implicit statement: ”it’s not our job”.

And that, perhaps, is the fundamental problem with HTML. Often, nobody cares enough to take responsibility.

Should back-end developers care if they’re only spitting out the odd bit of markup, or relying on the framework to handle it?

Should front end devs care so long as it renders alright in the browser?

Should designers care if they can’t see it?

Should quality engineers care if everything they’re testing for works anyway? It’s just a few HTML advisory notices, right?

Should sales, accounts, marketing or investors care if nobody else seems to?

So, who actually cares?

The simple fact is: users care.

We’re all here to make software, right? (Or a website; it’s the same thing.)

And the sole purpose of software is to make our users’ lives easier? Or to please them? Or, just not make life harder?

By arguing over semantics and ignoring users, it’s easy to fail at our jobs.

Everyone who has a hand in making software should care as much about the quality of HTML in the product as they do any other part of it.

If users care, everyone else should too.

Why do users care?

Nice, clean, standards-compliant HTML will render a teeny bit quicker in the browser. Which is nice for everyone.

Call it a bonus.

But for a lot of users – like those who rely on the keyboard, or switch controls, or screen readers, or voice commands – properly-crafted HTML is a deal breaker. Without it, they might not be able to use your page or application at all. Not one bit.

They’ll just give up and go find your competitor.

Or perhaps they can kinda use it and persevere, or have no choice and have to endure. It’ll take them longer to complete their task. It’ll be hard work. It’ll be unpleasant. Frustrating. Annoying. They’re forced to suffer horribly through it. 

Or worse still, their only option is to lose independence and ask someone to do it for them.

I’m deliberately not dressing this up. This is the harsh reality of badly produced HTML. It ruins accessibility. It discriminates. It makes peoples’ lives worse.

That’s why it matters. That’s why users care.

Why are developers sniffy about HTML?

I often wonder if the sniffiness of some devs towards HTML is partly because of the titular question of whether or not it’s code. It makes it something other. It’s not proper. It also doesn’t seem to break easily. It can be abused and rarely fights back. It doesn’t command respect.

In reality, devs should take a large slice of the responsibility for writing HTML. They’re best placed to look after it. Even if we can only agree HTML vaguely resembles code, it’s often being produced by the much more complex high-brow programming that devs are willfully buried it. 

Why don’t designers understand it?

This isn’t just about developers, though. A worrying proportion of the designers I speak to admit they don’t really understand HTML. Which is a bit like finding an interior designer who has no idea how to apply paint. If designers don’t know even the basics of how their designs will be made, how can they be sure what they’re designing is feasible?

And, crucially, how is is possible to know if those designs will be accessible? Whether or not you call yourself a user experience designer, everything that’s designed affects the experience of a user. Designs have to consider all the ways someone might experience the product – visually or otherwise.

Conceptually, there’s no difference between a marker pen and a HTML code editor. If a designer understands HTML as much as to they do their pen, they can craft the different experiences they intend all their users to have.

Sadly, budding designers aren’t taught about HTML and accessibility. They’re expected to make things look pretty, or appeal to the majority of people. Tutors are often from different eras when these things rarely mattered. Recruiters and bosses have had eyes on purse strings elsewhere. Accessibility and proper markup haven’t, traditionally, been all that important.

None of these are valid excuses to continue this way. There’s too much at stake for users.

What does good HTML look (or sound) like?

HTML is like the wire on your headphones. There are infinite ways of tangling it up, but just one way of keeping it neat. They’ll produce a sound all ways, but only one way looks pleasing.

Just like your headphones, tidy, consistent and predictable HTML is going to be pleasing, accessible and a whole heap easier to maintain.

And, far from being low-brow or dismissable, HTML is rich and interesting. Every element has a clearly defined purpose. Each one comes with rules.

It’s the understanding of what should be used and when, and the careful application of that knowledge, that makes good HTML.

Start caring, start learning

It doesn’t matter if HTML is code or if it’s made out of feathers. It really doesn’t matter.

But for your users, and professional pride, it’s important you care about it – whatever the part you play in the software making process.

The intellectual curiosity that led us into our chosen careers in this wonderful industry should guide us all to learn about and appreciate the brilliance of HTML.

I’m not going to do a load of tutorials in this post. But if you’re looking for somewhere to start, just ask the Internet.