What I Learned by Relearning HTML
I’ve worked on websites for several years, both professionally and for side projects. One day, I reflected on the fact that all of my web development education had come from actually making websites. In most cases, I’d have a specific problem, Google how to solve it, and learn something new in the process.
So I decided to relearn HTML and discover my unknown unknowns.
For context, I made my first website in middle school for a class project. We learned basic HTML, and embedding a MP3 song felt like magic. But I didn’t touch web development again until college. I made a lightweight news aggregator called The Daily Lore that’s still running (I preserved the original version).
I don’t consider myself to be a web development expert based on just that experience, but I surely had far more knowledge than the typical student for Coursera’s Introduction to HTML5 course. I started the course expecting to know a lot of the content already, since it was designed for complete beginners with no programming backgrounds.
As I went through the material, I did in fact know a lot of it already, but it was still a good refresher for two points in particular: the importance of using semantic elements and what to think about in terms of accessibility.
Accessibility was also something I had never considered in depth. I knew that
images should have
alt descriptions, and that was about it. One of the
course’s key points is that using the appropriate semantic elements is important
to making a site more accessible.
For example, people who use screen readers can jump around using
<h6>), so it’s important to use them and make sure
they’re in the correct order. It’s wrong to use them only to make text bigger
because their real purpose is to define the structure of the content. They’re
like a table of contents.
Instead of headings, we could use
<p> elements and alter their font sizes with
CSS to create a website that looks identical, but it’d be less semantic and less
accessible. There is more to web development than making websites look the way
we want. It’s important to make the content mean what we want as well.
Accessibility isn’t just about improving how websites work with screen readers. We should think about font size, font style, and color contrast for people who have visual impairments or color blindness. We should consider that people who have hearing loss may have a harder time recognizing that audio or video is playing. We should make tab navigation work well for people who rely primarily on the keyboard, perhaps because they have a difficult time using a mouse. When we add animations, we should take care to avoid ones that make it more difficult for someone to actually use the website, such as animations that change the page layout in the middle of interactions. And we should consider when a page is overloaded with too much information or too many elements, making it hard for people to understand things or how to actually use the website.
It’s easy to forget about accessibility, but we should strive to make websites work well for as many people as possible. Accessibility also goes hand in hand with usability and search engine optimization. The course points out that improving one frequently means improving all the others.
I have a friend who is probably the only person I know who has read the entire NFL rulebook (the 2020 version is 87 pages long). Watching football with him was fun because he was so good at understanding nuances to the game and weird situations. I figured there was a similar opportunity for me with HTML.
The strict equivalent would have been to read the HTML standard for every HTML element, but I decided to read the MDN documentation for every element instead since MDN has a lot of information about browser compatibility and using elements in practice. I read the entire page for each element, took notes, and made Anki cards for the bits that I wanted to commit to memory.
There were many deprecated elements that I only skimmed through, and I didn’t bother to take notes for those, but dozens of standardized elements and attributes were totally new to me.
I didn’t intend to come out of this experience as a master of HTML, and I still
have to apply what I’ve learned (including to this website), but I find it
useful just to be aware of what is available. Even though I can’t recall all the
details about using a
element, I know it exists now, and I can always look up the details later during
implementation. It’s a categorical difference from not being aware of it at all
and using a plain
<img> for all cases because I don’t know any better.
As I read the documentation, some things were particularly interesting to me, and I had some observations.
The address element is for contact information in general, not just physical mailing addresses.
The definition element represents the term that is being defined, rather than the definition itself.
There is a whole set of ruby elements that are primarily used to show the pronunciations of East Asian characters.
The map element seems like an anachronism, especially considering that it isn’t responsive.
There are a few elements that seem redundant. The legend element represents a caption for a fieldset element, the caption element represents a caption for a table element, and the figcaption element represents a caption for a figure element. I don’t know why one element couldn’t do the job for all three, since the meaning could be derived from the parent element.
As I read through the documentation, it kept making me consider the question of how HTML should evolve. Browsers keep gaining more and more functionality, to the point that they are becoming more like operating systems. There’s even an experimental API for connecting to Bluetooth devices.
Wikipedia is the perfect website for what HTML was originally designed for: mostly static documents that are connected through hyperlinks. But now we use the browser to deliver full on applications, like Figma, which is a design tool that effectively runs C++ code in the browser by compiling it to WebAssembly.
We don’t use the HTML5 <progress> element, ensuring you can stack progress bars, animate them, and place text labels over them.
Another example is the table element. Pure HTML tables can be pretty sophisticated in terms of displaying data, but there’s no built-in support for interactive functionality like sorting, filtering, and pagination.
Browser support also becomes an issue when an element does become more advanced. The input element is one of the most complex elements because it supports so many combinations of input types and attributes. In theory, you could use it to easily collect a date and a time, using the datetime-local type. But not all browsers support it, and there is variation in how it works even among those that do.
Some elements are also difficult to style, such as the select element. So website developers may want to rely on standard functionality instead of using a library or implementing a feature themselves, but then they have to worry about it not working well in certain browsers or stylistic inconsistency with the rest of the website.
I’m eager to see if Web Components become more popular and provide a good solution to these problems. If they do, the situation could become similar to programming languages, where different languages take difference stances on the question of how much functionality should be included in the standard library (HTML) so that the community has a lesser or greater tendency to rely on third party libraries (Web Components).
It was easy to feel confident with HTML after doing web development for several years. Yet I found plenty of value in going back to learn it in a more rigorous manner. I learned about many improvements I can make to the websites I work on, and I have a better big picture view of HTML and how it might develop. While I still think learning by doing is highly effective, this experience has made me want to go back and relearn other things with a bottom up approach.