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.
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.
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
<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.
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.
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!
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.
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!
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!