Write HTML Like It's 1999

2019-06-06

I am sure it's safe to say that most developers love to use the latest and greatest web tools available. Helpful resources such as preprocessors, template engines, syntax formatters - you name it - can all make a developer's life easier. Unfortunately, this sometimes comes at a cost: the HTML structure.

This is why I try my best to write HTML as if I'm stuck with the constraints of the 90s (within reason). What does this mean exactly? It means that tables are coded with table elements. Navigations are coded with nav and ordered/unordered list-items. Form inputs are not set with display: none and replaced with custom containers. You know, semantic HTML.

To be clear, I'm not advocating for creating projects that look like they belong in the 1990s. I would just prefer developers / designers be more conscious of their HTML skeleton.

Bad HTML practices

Let's do a very simple breakdown of some of the more common HTML no-nos:

• Using span or div elements for navigations or list components
• Implementing custom div layouts for forms while removing items like select or radio
• Creating tables built out of custom div elements
• Over-nesting elements or making overly complex depth to simple components
• Content being heavily reliant on JavaScript "injection"

Good HTML practices

So what should you do in place of these bad HTML implementations?

• Use proper nav, ul and ol for navigations or list components
• Style form elements directly this is already supported in browsers
• Build tables using table element structure (mind-blowing, I know!)
• Keep element hierarchy as slim and top level as possible
• Avoid injecting any content via JavaScript (I understand this is difficult for certain apps, but try to minimize this as much as possible)

My basic "structure" test

I've found a pretty simple starting point for testing the bones of a website by using the following single line of CSS:

* {
    border: 2px dotted black;
}

This property simply outlines all elements on the current page in a dotted border. By placing a border on every HTML element you can instantly see how overly complex or ugly your structure might be under the hood.

"Thanks, Captain Obvious!"

I know, this stuff is pretty basic. The point of this post isn't to tell you (developers) something brand new or mind-blowing, but instead should inspire you to keep things simple.

Don't forget that there is always someone new into the world of design and development. Hopefully this post steers others towards keeping HTML code semantic and clean.

Update to this article

Since this post received so much more attention than I ever expected, I've decided to touch on a few small points brought up in the comments.

1. What is the benefit of semantic HTML? - Accessibility. Programs like screen readers are built around the foundation of proper HTML hierarchy. I highly recommend testing all your projects with a screen reader - it will open your eyes to a lot of issues users with disabilities suffer through.

2. Tables not being responsive - This simply isn't true. It is much more semantic to layout your tables as you would normally, then for mobile devices you can target specific inner elements and alter them with flexbox etc. (You can see responsive tables in action here)

3. Instead of the CSS one-liner, simply use Firefox debugger - Fair point. Firefox is great!