I have worked on the website for several years both professionally and in side projects. One day I pondered the fact that all my web development training had come by myself making websites. In most cases, I have a specific problem with Google how to solve it and learn something new in the process.

I wondered what was missing because I never learned HTML holistically. Forget CSS and JavaScript. I’m just talking about raw HTML. It may seem silly to go back to such a basic element of web development after a decent experience, but with skills, it’s easy to become confident just because you know enough to do a few useful things.

So I decided to learn HTML again and find my own unknown unknown.


Due to the context, I made my first website in high school for the project. We learned HTML and embedding an HTML paragraph felt magical. But I didn’t touch on network development again until college. I made a light news aggregate called Daily Lore which is still running (cabinet the original version).

Since then, I have worked on two websites professionally, on one non-profit website personal websiteand a few small websites for side projects like Make a README.

Introduction to HTML5

I don’t consider myself an expert in web development based on this very experience, but I certainly had a lot more knowledge than a typical Coursera student Introduction to HTML5 course. I started the course expecting to know a lot of content already because it was designed for beginners with no programming background.

When I went through the material, I actually already knew a lot about it, but it was still a good recreation especially for two points: the importance of using semantic elements and where to think about accessibility.

I’ve always had a bad habit of using generics <div> elements to do what is needed, and not semantic elements that represent specific content, such as header and footer elements.

Accessibility was also something I had never thoroughly considered. I knew the pictures should be alt descriptions, and that was it. One of the key points of the course is that the use of appropriate semantic elements is important to ensure easier access to the site.

For example, people using screen readers can jump around title elements (<h1> through <h6>), so it is important to use them and make sure they are in the right order. It is wrong to use them only to enlarge text, because their real purpose is to define the structure of the content. They are like a table of contents.

Instead of titles, we can use <p> elements and change font sizes with CSS to create an identical-looking website, but it would be less semantic and less accessible. There is more to web development than making websites look the way we want them to. It is important to make content mean what we also want.

Accessibility is not just about improving the performance of websites with screen readers. We should think about font size, font style, and color contrast for people with visual impairment or color blindness. We need to keep in mind that people with hearing impairments may have a harder time recognizing that audio or video is being played. We should make tab navigation work well for people who rely primarily on the keyboard, perhaps because they have difficulty using the mouse. When we add animations, we need to avoid ones that make it difficult to actually use the website, such as animations that change the layout of the page in the middle of the interaction. And we should think about when a page is overloaded with too much information or too many elements, making it difficult for people to understand things or how the website is actually used.

Accessibility is easy to forget, 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 healing one often means healing everyone else.

Reading documents

I have friend who is probably the only person I know who has read everything NFL rulebook (The 2020 version is 87 pages). Watching football with him was fun because he was so good at understanding the nuances of the game and the weird situations. I thought HTML had a similar opportunity for me.

The exact equivalent would have been to read HTML standard for each HTML element, but I decided to read MDN documentation for each element, because MDN has a lot of information about browser compatibility and how to use the elements in practice. I read the whole page of each element, took notes, and did Anki cards from the bits I wanted to commit to memory.

There were many obsolete elements that I just read through, and I didn’t bother to take notes on them, but dozens of standardized elements and attributes were completely new to me.

I wasn’t going to come out of this experience as a master of HTML, and I still have to apply what I’ve learned (also on this website), but I find it helpful to just be aware of what’s available. Although I don’t remember all the details of using a picture I know it exists now, and I can always look for details later during implementation. It’s a categorical difference that you are not aware of it at all and use the usual <img> in all cases because I don’t know better.


When I read the documentation, some things were of particular interest to me, and I had some observations:

address the element is for contacts in general, not just physical mailing addresses.

definition the element represents the term to be defined and not the definition itself.

There are a number ruby elements used primarily to display pronunciations of East Asian characters.

to follow the element provides a standard way to embed timed text tracks for video and audio. I had never heard WebVTT (Web Video Text Tracks) format previously.

map the element appears to be an anachronism, especially given that it is not responsive.

information the element provides a machine-readable translation of the content. It looks like it could help scratch the screen, which some websites like LinkedIn has been actively trying to block.

There is subtlety in making the right choices strong against in against i against u against b against make.

There are a few elements that seem unnecessary. legend element describes the title of a field set element, Isolated on white element describes the title of a table element and picture element describes the title of a picture element. I don’t know why one element couldn’t work for all three because the meaning was derived from the main element.

The future of HTML

As I read through the documentation, it constantly made me think about the question of how HTML should evolve. Browsers are getting more and more functionality to the extent that they are more than operating systems. There is even an experimental one API for connecting Bluetooth devices.

Wikipedia is the perfect website for what HTML was originally designed for: mostly static documents linked through hyperlinks. But now we use a browser to deliver a full application, for example Figma, a design tool that efficiently executes C ++ code in a browser by compiling it into WebAssembly.

HTML has added a few elements and attributes that allow interactivity without JavaScript. For example detail the element creates a widget that can be switched between open and closed mode.

But as your usage evolves, it’s hard to rely solely on what HTML offers. For example, Bootstrapprogress bar does not use HTML progress element.

We do not use HTML5 element to ensure that you can stack progress bars, animate them, and place text stickers on top of them.

Another example is table element. Clean HTML tables can be quite sophisticated in terms of data display, but there is no built-in support for interactive functions such as sorting, filtering, and paging.

Browser support also becomes a problem as the element becomes more advanced. income element is one of the most complex elements because it supports so many combinations of input types and attributes. In theory, you can use it to collect the date and time easily using date-local type. But not all browsers support it, and there are differences in how it works between those that support it.

Some elements are also difficult to format, such as choose element. So website developers may want to rely on standard features instead of using the library or implementing the feature themselves, but then they have to make sure that it doesn’t work well in certain browsers or stylistic inconsistencies with the rest of the site.

I am eager to see Network components becomes more popular and offers a good solution to these problems. If this happens, the situation may become similar to programming languages, where different languages ​​take different positions on the question of how much functionality should be included in a standard library (HTML) so that the community has a greater or lesser tendency to trust third-party libraries (network components).

Network components seem to be picking up somewhat. GitHub has began to use themand they publish the components to WebComponents.org.


With HTML development, it was easy to feel confident after several years of web development. Still, I found a lot of value in coming back to learn it in a more rigorous way. I’ve learned about the many improvements I can make to my websites where I work, and I have a better view of HTML code and how it’s evolving. While I think learning by doing is still very effective in my opinion, this experience has made me want to go back and learn other things with a bottom-up approach.



Please enter your comment!
Please enter your name here