Three things happen when you spend enough time staring at a website trying to understand why it looks wrong.

First, you begin to see the web differently. Where before you saw text and images and buttons and navigation menus, you start to see boxes. Everything is a box. Text is in a box. Images are in boxes. The navigation is a box containing smaller boxes. The entire page, from top to bottom, is a series of nested boxes, each one affecting the others like a particularly intricate arrangement of Russian dolls in which the dolls can argue about alignment.

Second, you develop a complicated relationship with the colour white. So much of web design involves white space, the empty gaps between elements that good designers use deliberately and bad designers either eliminate entirely (resulting in websites that feel like the visual equivalent of someone standing too close to you on the bus) or deploy so randomly that the page looks like it was formatted by someone sneezing on the keyboard. Our Adventurer had begun to notice white space everywhere: on websites, in books, on cereal boxes, in the gaps between sentences in birthday cards. White space had become personal.

Third, and most relevantly for the present chapter, you eventually arrive at the question that every person building a website must eventually answer: what, precisely, is a web page made of?

The answer is HTML.

And HTML, Our Adventurer was about to discover, is not just a technical specification. It is a language. A real one, with its own grammar and vocabulary and history and, like all languages, its own eccentric irregularities that made perfect sense in context and are now too embedded in everything to change.

The Language of the Web

HTML stands for HyperText Markup Language, which is the kind of name that tells you it was designed by engineers rather than marketers. HyperText is what they used to call text that had links in it, because the ability to click on words and go somewhere else was, in the early days of the web, genuinely extraordinary. Markup refers to the system of tags and symbols used to annotate the text. Language, well. Language is language.

Our Adventurer first understood what HTML actually was when looking at a piece of web page source code and noticing, for the first time, the tags.

Tags are the currency of HTML. They come in pairs, almost always. An opening tag looks like this: <p>. A closing tag looks like this: </p>. The p stands for paragraph. Everything between those two tags is treated as a paragraph. The browser reads the HTML, sees the tags, and knows what to do with the content.

There are tags for headings. <h1> through <h6>, where h1 is the biggest and most important heading and h6 is the smallest and theoretically least important, though in practice most websites use only h1 through h3 because by the time you are at h5 you are in very specific heading territory and the font is getting quite small.

There are tags for links: <a href="somewhere">, where the href attribute contains the address you want to go to. The “a” stands for “anchor,” which is another one of those early web names that made sense in 1994 and has simply been inherited by everyone since.

There are tags for images, for lists, for tables, for buttons, for forms. There are tags that mean “this is important” and tags that mean “this is a section” and tags that mean “this is navigation” and newer tags from something called HTML5 that have names like <article> and <aside> and <main>, which were invented specifically so that HTML could be more descriptive about what content is actually for, because before HTML5 everything was just <div>, which is a tag that means absolutely nothing except “here is a box, good luck.”

Our Adventurer found this fascinating in the way that learning a new alphabet is fascinating: there is a moment where the symbols stop looking like symbols and start looking like meaning, and that moment is quietly exhilarating.

The div: A Character Study

If HTML were a city, the <div> would be the city’s most common building material. Not the most interesting. Not the most purposeful. Just the one that is everywhere, in everything, holding the whole place up while meaning absolutely nothing specific.

The div is a generic container. It groups things together. It provides a box that CSS can then style and JavaScript can then manipulate. It has no intrinsic meaning and no default styling except that it is a block element, which means it takes up the full width available to it and forces the next thing onto a new line.

WordPress, Our Adventurer discovered when first viewing the source code of a WordPress-generated page, uses an absolutely extraordinary number of divs. They nest inside each other like the aforementioned Russian dolls, each with class names that are either very descriptive (like “wp-content” or “entry-header”) or entirely cryptic (like “wp-block-group__inner-container” which sounds like someone describing where they keep their existential doubts).

Understanding how WordPress structures its HTML was like being given a map to a building you have been living in without realising it has rooms you have never found. Suddenly the page was not just a visual thing but an architecture, a system of elements with relationships and hierarchies and purposes.

Our Adventurer began to read HTML the way you learn to read music: slowly at first, sounding out each tag, and then faster, and then finally in phrases and passages, understanding not just the individual notes but the structure they formed together.

The Great Semantic Revelation

The concept that changed everything, the one that made HTML click in a way that CSS never quite had, was semantics.

Semantic HTML is the practice of using elements that describe what content means, not just how it looks. The difference between using a <div> with a class called “navigation” and using the actual <nav> element. The difference between using a <span> with a class called “emphasis” and using the actual <em> element. The difference between wrapping your page’s main content in a <div id="main"> and using the actual <main> element.

Why does this matter? For three reasons that Our Adventurer found genuinely compelling.

First: screen readers. People who use the web with assistive technology, who are blind or have low vision or cannot use a mouse, rely on the semantic structure of HTML to navigate pages. A screen reader can jump between <nav> elements, or skip straight to the <main> content, or read out a list of all the headings on a page so the user can navigate to the section they want. If everything is just divs, the screen reader has no clues to work with.

Second: search engines. Google and its friends read HTML. They look at the structure. They give weight to content inside <h1> tags. They understand that the content inside <article> is the main content and the content inside <aside> is supporting material. Good semantic HTML helps search engines understand your page, which helps people find it.

Third: it just makes sense. Writing HTML that means what it says is the same satisfaction as writing a sentence that says exactly what you mean. It is precision. It is craft.

Our Adventurer rewrote the blog’s HTML structure, ensuring every heading was a proper heading element, every list was a proper list element, the navigation was a proper nav, the footer was a proper footer, and the main article content was wrapped in an <article> element because it was, self-evidently, an article.

It looked, to the user, exactly the same as before.

But it was better. Underneath. In the bones.

Our Adventurer found this deeply satisfying in a way that was difficult to explain to non-developers, which was, at this point in the adventure, everyone Our Adventurer knew.

The Battle of the Forms

Having understood the broad landscape of HTML, Our Adventurer now encountered its most treacherous territory: forms.

HTML forms are the things that let users input data. Contact forms. Search boxes. Login forms. Subscription forms. They are everywhere on the web and they are, deceptively, quite complicated to build properly.

The HTML for a basic form looks approachable:

<form action="/submit" method="post">
  <label for="name">Name:</label>
  <input type="text" id="name" name="name">
  <button type="submit">Send</button>
</form>

Simple. Readable. Understandable. Our Adventurer typed this into an HTML block on the WordPress site, saved, and looked at the result.

The form was there. It was a box with a label and an input and a button. It was, by any objective measure, a form.

The button, when clicked, did absolutely nothing.

This is where HTML’s philosophical limits became apparent. HTML structures things. HTML describes things. HTML does not make things happen. Things happening, events and interactions and data being processed, requires JavaScript, which was not yet in Our Adventurer’s arsenal. For now, though, a contact form plugin handled all the complicated bits: the processing, the email sending, the spam protection.

The form worked.

No custom JavaScript required.

This felt like a victory, but also, Our Adventurer could not entirely shake the feeling that using a plugin was in some sense cheating. This is a feeling, Our Adventurer would later learn, that is both universal among web developers and largely baseless, because the entire profession is built on not reinventing wheels. Nobody builds their own compiler from first principles before writing a program. Well. Almost nobody.

The Table That Would Not Behave

There is a particular battle in the HTML wars that has been fought since the very earliest days of web development, and that battle is about tables.

HTML tables were originally designed for exactly what their name suggests: displaying tabular data. Things like spreadsheets, comparison charts, schedules, anything that logically exists in rows and columns. The HTML structure is logical:

<table>
  <thead>
    <tr>
      <th>Thing</th>
      <th>How Good It Is</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Beans on Toast</td>
      <td>Excellent</td>
    </tr>
  </tbody>
</table>

Clean. Sensible. thead for the header row. tbody for the data rows. tr for each row. th for header cells. td for data cells.

Our Adventurer was building a comparison table of different WordPress hosting providers, with columns for price, speed, support quality, and overall rating.

The table looked fine on a desktop browser.

On a phone, it was a disaster. The five columns refused to fit in the narrow mobile screen and simply overflowed to the right, the rightmost columns invisible unless you scrolled horizontally, which nobody wants to do on a web page, horizontal scrolling being one of those interface decisions that feels like being told the only way to read this book is sideways.

Making tables responsive turned out to be one of CSS’s less elegant challenges. Our Adventurer spent an afternoon on various approaches before settling on a smooth horizontal scroll wrapper: the table scrolled horizontally on mobile, but with a subtle visual indicator that more content was available to the right and proper touch support. Not perfect, but honest about its limitations.

Our Adventurer called it a draw with the table.

The Revelation of the View Source

One of Our Adventurer’s most productive habits during this period was something so simple it almost felt like cheating: looking at the source code of websites that looked good.

Modern browsers make this easy. Right-click anywhere on a page. Click “View Page Source.” Suddenly you can see the entire HTML structure, all of it, the full skeleton of the page you have been looking at, the tags and attributes and classes and IDs that make the page what it is.

Our Adventurer became an avid reader of other people’s HTML in the same way a young chef might eat in the best restaurants not just for pleasure but for education, noticing the technique behind the flavour. There were websites with beautiful HTML, clean and semantic and carefully indented, the work of people who cared about the structure as much as the appearance. There were websites with HTML that was a catastrophic mess of nested divs and inline styles and attributes that appeared to have been generated by a machine without human oversight, which they often had been.

The blog a friend had used to build the successful mug business was examined carefully. The HTML was solid. Good heading hierarchy. Proper image alt text (which Our Adventurer had not yet implemented and immediately added to the to-do list). Sensible class names.

Our Adventurer took notes.

The notebook was now almost full. A new one had been purchased, this time a proper A5 lined notebook bought with the deliberate intention of using it for WordPress learning and not, under any circumstances, meal planning.

The Accessibility Awakening

Something happened around this point in Our Adventurer’s HTML education that was, in retrospect, one of the most important shifts in the whole adventure: an encounter with accessibility.

It started with an alt attribute.

An alt attribute on an image tag provides a text alternative for the image, for people who cannot see it. Screen readers read the alt text out loud. If the image fails to load, the alt text appears in its place. For search engines, alt text provides context about what an image shows.

Our Adventurer had been adding images to blog posts without alt text, because WordPress did not require it and the posts looked fine without it. But a commenter pointed out, kindly, that the images lacked alt text and this made the content inaccessible to some readers.

Our Adventurer felt genuinely bad about this. Not in a defensive way but in the way you feel bad when you realise you have been doing something thoughtlessly that affected people you did not consider. It was a perspective shift. The web, this thing Our Adventurer was learning to build, was used by everyone. Not just people who could see every image. Not just people who could use a mouse. Not just people on fast connections with large screens. Everyone.

And building for everyone, not just the most common case, was not just a legal consideration (though accessibility is indeed a legal requirement in many contexts) or a search engine optimisation tactic (though it helps). It was the right thing to do.

Every image on the blog now had alt text. Every decorative image had an empty alt attribute, which tells screen readers to skip the image because it contains no meaningful information. This is the correct approach and Our Adventurer learned about it from the Web Content Accessibility Guidelines, known as WCAG, a comprehensive document produced by the World Wide Web Consortium, genuinely and thoughtfully written by people who care deeply about making the web work for everyone.

Our Adventurer read significant portions of WCAG.

This is not something most beginning web developers do. It is, perhaps, a reflection of the particular kind of person Our Adventurer was: someone who, once interested in something, became very interested in it, interested enough to read the specifications, to understand the reasoning, to care about the craft rather than just the output.

HTML’s Peculiarities: A Love Letter to the Weird Bits

No account of learning HTML would be complete without acknowledging its peculiarities, the bits that make experienced web developers sigh softly and beginners stare at the screen with the expression of someone who has been confidently walking in what they thought was the right direction and has just realised they are in a completely different town.

There is the <b> tag versus the <strong> tag. Both make text bold. But <b> just means “bold visually” while <strong> means “this content is important,” which is a semantic distinction that matters to screen readers and search engines even though it looks identical on screen.

There is the <br> tag, which creates a line break, one of the famous void elements that have no closing counterpart because they contain no content. Remembering which elements are self-closing while everything else needs a matching closing tag is one of those tiny things you get wrong exactly once and then never again.

There is the peculiarity of white space in HTML, where multiple spaces and line breaks in the source code are collapsed into a single space in the rendered page, which means you can make your HTML as readable as you like with indentation and blank lines and it will not affect the appearance at all.

There is the wonderful chaos of the <head> element, the part of the HTML document that the user never sees but which contains metadata and linked stylesheets and script tags and favicons and open graph tags for social media and all manner of invisible information that tells browsers and bots and apps what the page is and what to do with it. The <head> is the back of the house in restaurant terms: the customer never sees it but everything they experience is determined by it.

Our Adventurer was, by now, spending at least an hour a day looking at things like this. HTML had been developed over thirty years by thousands of contributors, and the history of those contributions was visible in the language itself, in the things that made perfect sense and the things that were obviously vestigial, holdovers from a different era that persisted because the web never really breaks backwards compatibility. There are still websites from 1998 out there that need to work in modern browsers, and the people who maintain browser engines have, through some combination of heroism and stubbornness, kept them working.

This, Our Adventurer thought, was genuinely remarkable.

The First Truly Good Blog Post

In the sixth week of the adventure, Our Adventurer wrote a blog post that was, for the first time, actually good.

Not just present. Not just published. Good. Well-structured, with a proper heading hierarchy that guided the reader through the content. With images that had alt text. With a table that worked on mobile. With links that were descriptive. With paragraphs of a sensible length, neither the wall-of-text approach that exhausts readers nor the one-sentence-per-paragraph approach that feels like someone rattling out thoughts without ever developing any of them.

The post was called “Everything I Have Learned About HTML In Six Weeks, Including The Bit That Made Me Feel Genuinely Ashamed About Accessibility.”

It was shared by someone on a web development forum. Then by someone else. Then by a social media account with a reasonable following among web developers.

Twelve hundred people read it in the first week.

Not eleven thousand pounds. But twelve hundred people.

Our Adventurer stared at the analytics page with the same expression that had greeted a friend’s eleven thousand pounds: disbelief, then belief, then a peculiar sense of vertigo that comes from realising something you made has resonated with strangers.

In the comments, someone said: “You write about technical things like they are adventures. Keep going.”

Our Adventurer read this comment several times.

Then opened the notebook.

There were more enemies to face. PHP was coming. But tonight, the HTML was done, or at least done enough. The battle had been fought. The language had been learned, if not mastered. Never mastered, because there is always more to learn, always a new element or attribute or specification to understand.

But enough. For now, enough.

The chip shop downstairs was frying something fragrant. Our Adventurer made tea and looked at the analytics page one more time, twelve hundred people, and felt the particular quiet satisfaction of someone who had built something and watched it reach people it was never guaranteed to reach.

Tomorrow, PHP.

But tonight, tea.

The adventure, improbably and wonderfully, was working.