DEV Community

Christian Heilmann
Christian Heilmann

Posted on • Originally published at christianheilmann.com

6 2 1 2 1

Learning HTML is the best investment I ever did

One of the running jokes and/or discussion I am sick and tired of is people belittling HTML. Yes, HTML is not a programming language. No, HTML should not just be a compilation target. Learning HTML is a solid investment and not hard to do.

I am not alone in this, Wired had a piece on HTML being a programming language and even for RAG training HTML makes a lot more sense than text.

HTML structures our content, makes it easier to index and gives us tons of accessible and easy to use interface elements. And it is straight forward to learn. The syntax is clear and the rules are only a few. And yet, nobody seems to even bother to look those up.

In last week's Bytes newsletter there was a "spot the bug" challenge that looked like this:

<main>
  <form onsubmit="handleSubmit(event)">
    <fieldset>
      <label for="name">Name:</label>
      <input type="text" name="name" value="Tyler"  />
      <label for="age">Age:</label>
      <input type="number" name="age" value="33" />
      <button>Submit</button>
    </fieldset>

  <hr />

  <form onsubmit="handleSubmit(event)">
    <fieldset>
      <label for="company">Company:</label>
      <input type="text" name="company" value="ui.dev"  />
      <label for="employees">Employees:</label>
      <input type="number" name="employees" value="33" />
      <button>Submit</button>
    </fieldset>
  </form>

  <script>
    function handleSubmit(event) {
      event.preventDefault();
      const formData = new FormData(event.target);
      alert([...formData.entries()]);
    }
  </script>
</main>
Enter fullscreen mode Exit fullscreen mode

The bug described was that as the first form wasn't closed, the script got the wrong content. But there is so much more in this small amount of HTML that is wrong, it made me flinch.

Fieldsets need legends

It uses fieldsets without legends - why? The idea of a fieldset is to to group form elements and give that group a name. If you omit the name, all you did was paint a hard to style border around them.

Pointless labels

It uses labels, which is a happy surprise, but fails to connect them to the right form elements. For a label to describe a form element, you need the element to connect to an ID, not a name. A name attribute is not unique, instead it clusters form elements together. So, you could have a few elements with the same name, but you need to have an ID on each to connect it to the label. When the form gets submitted, the names become form data (or URL parameters), the IDs are there for HTML parser internal use. And more. IDs are the few multi-dimensional things on the web, as they can be accessed via the browser (hash at the end of the URL), they connect HTML elements together (a link pointing to it, or a label with for), they are easy to use in CSS and in DOM scripting. One weird thing is that every element with an ID also becomes a global JavaScript hook on the window. This is a convenience method of browsers, not a standard though.

A great example of this is a radio group. I hardly see those in use, but they are a great way to offer a "pick one of many" interface without needing any JavaScript.

Check this Codepen to see a radio group in action.


<fieldset>
    <legend>Record Label</legend>
    <p><input name="recordlabel" type="radio" value="Trojan" id="company1">
    <label for="company1">Trojan</label></p>
    <p><input name="recordlabel" type="radio" value="Epitaph" id="company2">
    <label for="company2">Epitaph</label></p>
    <p><input name="recordlabel" type="radio" value="Hellcat" id="company3">
    <label for="company3">Hellcat</label></p>
    <!-- … -->
</fieldset>
Enter fullscreen mode Exit fullscreen mode

Notice that the name of the ID can be random, but needs to be unique, whereas the name makes sense to be human readable. This is even part of the specification:

Identifiers are opaque strings. Particular meanings should not be derived from the value of the id attribute.

As an extra, activate the Toggle checkbox/radio button to see that simply by changing the type attribute of an HTML input, you can allow users to either submit one or several values. By using properly connected labels, we also allow users to click/tap/hit space on the whole text to select instead of having to hit the small radio control.

Demo showing the difference between radio buttons and checkboxes allowing for one or several choices

HTML was and is fun!

HTML is - dare I say it - fun to me. The reason is that I started a long time ago. Building my first web site instead of creating things with Visual Basic or C builder was amazing. HTML appeared to me all powerful. I didn't have to spend any money, install and understand a development environment. All it needed was an index.html file and writing the code using a text editor that came with the OS. I went to htmlhelp.com and downloaded the HTML spec as a zip and put it on a floppy to look things up. I was only online at work, my home internet connection came a lot later.

Unforgiving browsers

In the early days, making HTML mistakes was a problem as browsers would punish you for it. Netscape would not render tables that weren't closed. And back then tables was the only way to create complex layouts. This was a bad use of HTML as it was non-semantic, but we had nothing else.

Later, when CSS became a thing there was still a lot of interference of HTML in the final product. Whitespace should not make a difference in HTML but it caused a lot of extra space in table cells and with images. The best advice I would give to designers back then that banged their head on the desk was to validate their HTML. The HTML Validator became my power tool to fixing issues for clients.

These days, HTML gathers less interest as with the HTML5 parser, things became a lot more lenient.

A lack of HTML interest and respect

As browsers bend over backwards to fix broken HTML, developers stopped caring about it. If it doesn't break the build, it's less important than getting those JavaScript packages bundled. But this, to me, is lazy development. Why rely on a platform to fix bugs that we could avoid if we put in a tiny bit of effort?

HTML has some exciting new features for us in 2025. A single element could replace a whole component library. Sure, the component might give us more predictable styling and more control. But it also is one more dependency, and could be a security, performance and maintenance issue. An issue we can't fix as we don't control it.

No matter how you create things for the web, the end product will be HTML. Either HTML generated on the server or with JavaScript. With AI search bots not rendering JavaScript yet maybe this is a good time to re-learn what HTML can do for you. It has not let me down in over 25 years, whereas lots of other "magical solutions" did.

Sentry blog image

How I fixed 20 seconds of lag for every user in just 20 minutes.

Our AI agent was running 10-20 seconds slower than it should, impacting both our own developers and our early adopters. See how I used Sentry Profiling to fix it in record time.

Read more

Top comments (4)

Collapse
 
martyhimmel profile image
Martin Himmel

I'm 100% behind this. HTML is where I got my start with web development in 2004. At the time, I was playing a lot of Diablo 2. One night, I was looking for some info on the game and after looking at a few sites thought it would be fun to learn how to build websites. Looked up some HTML tutorials and built some terrible looking table based layouts, but had a blast doing it. Nothing but HTML - I didn't even know about CSS at the time.

Nowadays, I look forward to when newer HTML tags get baseline adoption across browsers so I can reduce code and/or rip out some library and go with the built-in option. For example, the dialog option has been a great asset in a re-design project I've been working on. Build out the dialog, call .showModal() on it, and call it a day. Replaced an entire library with a couple lines of code that way.

Collapse
 
xwero profile image
david duymelinck • Edited

I don't understand why xhtml didn't make it as the standard when they updated HTML4.
Even script languages like PHP added typing as a language feature. So while most languages became stricter, HTML became looser.

I think people care less about form inputs because HTML inputs are hidden most of the time to create shiny, dynamic inputs like a toggle button or a select with search.
Languages always go in a slower pace than the demand. But they are evolving. The sad thing is that too many people are in a framework-lock in, which makes them blind for those evolutions.

I don't think only-html AI crawlers are a long term solution for people to care about correct HTML.
Search engine crawlers can index javascript rendered websites. I think the same will happen with AI crawlers when too many websites are rendered with javascript.

I'm happy to see the javascript community is moving to the html-first mindset. I think it is weird the term has to exist to make people aware of their behaviour.
But if it helps to convince people, I'm all for it!

Collapse
 
peshale_07 profile image
Peshal Bhardwaj

HTML and CSS are always ignored by developers. Good HTML knowledge is great to get.

Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more

👋 Kindness is contagious

Immerse yourself in a wealth of knowledge with this piece, supported by the inclusive DEV Community—every developer, no matter where they are in their journey, is invited to contribute to our collective wisdom.

A simple “thank you” goes a long way—express your gratitude below in the comments!

Gathering insights enriches our journey on DEV and fortifies our community ties. Did you find this article valuable? Taking a moment to thank the author can have a significant impact.

Okay