When HTML5 was released in 2014, developers were given a slew of new elements. Many of them are meant to serve as a replacement for the flavorless jello <div>, the inline <span>, and other elements whose names didn't convey much meaning.
Utilizing these elements to give our HTML as much meaning as possible is what it means to write "semantic HTML". Using semantic HTML results in the same appearance of our site in the browser, but it provides a lot of benefits to both users and developers.
Benefits of Semantic HTML
Increases Accessibility
Semantic elements help screen readers understand the context of the content on your site better; therefore communicate it to users more effectively. Search engines are also more effective when they have semantic tags to reference.
Dev Empathy
We've all seen that codebase with 14 nested <div> elements, and even with perfect indentation, it gets difficult to read. Using semantic elements, such as <nav>, <section>, <article>, and <footer> in place of the <div> element, when appropriate, can alleviate this. This will also make reading and updating the document easier for future-you. Another benefit for devs is when we need to style elements - instead of those 14 <div> elements that all need their own attribute, we now have different element names that we may not need to add as many attributes.
What Does it Look Like?
One of the two cards below was built with semantic HTML; one was not. Can you tell which is which?
The answer is - you shouldn't be able to tell by looking at the result in the browser. Semantic HTML should result in the same appearance; but the elements we use should communicate meaning to us, the devs, and technologies that read our code, in order to provide a better experience for all users.
Here's a screenshot of the code, side-by-side. See the full CodePens by clicking on the links below.
Find the CodePens here and here.
Note: There are many different ways the HTML could have been written for this card - all using semantic elements. This is by no means the best or only solution!
What About <div>s?
This does not mean you should never use a <div> again! Notice that, in the "Semantic? Yes" example, I chose to use a <div> to wrap the host details. I didn't want to communicate anything about the chunk of content, but needed the container to use FlexBox in my CSS. However, I chose to use an <article> element for the card itself, then a <section> to differentiate the rental info from the host info.
<div> elements probably do still have a place in your site. When you're not sure if you should be using a <div> or a more semantic element, ask yourself, "Are these elements grouped together because their content belongs together? Are they grouped together because I need a container for styling?" That can be a starting point for making that decision.
Your Challenge
After reading this you may be thinking "I already use some semantic HTML" - that's great! I encourage you to read through a project you're currently working on and assess your use of semantic HTML. If something sticks out to you, refactor it!
Wrap Up
Just like in anything else in programming, there is not one right way to write semantic HTML, but it's important we are thoughtful and constantly trying to make our applications more accessible to users and readable to other devs.
Check out MDN's page on Semantic Elements to learn about more of the elements available for your use!
Top comments (1)
I really enjoyed this post, mostly since I've come upon the same view lately.
Most elements in web development nowadays is simply
divs stuffed with mountains of classes, and it makes it very annoying to debug, read, or edit.Frontend frameworks aren't exactly helping the situation either; everything is a component and there's no need to use anything other than
divs, but it takes away from the accessibility and understanding of the code.However, I won't say I'm not guilty of this. Using
divs often seems easier than trying to decide whether to use asection,article, or whatever else, and has established itself as a generic element that can be used anywhere. But the downsides are clear, and many web developers (including myself) should strive to use the markup we're provided.