DEV Community

Stop using so many divs! An intro to semantic HTML

Ken Bellows on March 24, 2019

Divs are played out We all love our <div> tags. They've been around for decades, and for decades they've been the go-to element wh...

Read full post

Oyebanji Jacob Mayowa • Mar 24 '19

Awesome post!

you have a dangling </div> in the last HTML code block. :)

Ken Bellows • Mar 24 '19

Oh no! 😫 Hahaha, thanks for pointing that out! Fixed it

PauGuillamon • Mar 24 '19

I agree with everyone, very nice and useful post! Especially for me, who I'm not a web developer but I sometimes do some side and personal projects that imply web development!

As a side note, there's still one extra </div> in the code sample in The whole shebang: <article> section ;)

Ken Bellows • Mar 24 '19

Thanks, fixed!

programmerabhi • Apr 5 '20

Which tag should I use to display the code?

Ken Bellows • Apr 6 '20 • Edited

For semantics purposes, use the <code> tag. For display purposes, to make it looks like code, it depends:

If it's an inline code snippet in the middle of a sentence, you can just use the <code> tag:
The <code>while(condition)</code> loop is useful for loops with an unknown number of iterations
If it's an independent block of code, possibly with multiple lines, and you don't need syntax highlighting, you can wrap your <code> tag in the "preformatted text" tag, <pre>:

Below is an example of a while loop used to walk a graph of nodes:
<pre><code>
const queue = [rootNode]
const prev = new Map()
const visited = new Set()
while (queue.length > 0)  {
  const node = queue.shift()
  for (const child of node.children) {
    if (visited.has(child)) {
      continue
    }
    visited.add(child)
    prev.set(child, node)
    queue.push(child)
  }
}
</code></pre>

If you are worried about syntax highlighting, you should still wrap the whole thing in a <code> tag, but you're probably going to want to bring in a library that does the very hard work of parsing and highlighting your code, like Prism or highlight.js.

Bottom line, though, no matter what extra stuff you're doing for display purposes, code should always be wrapped in a <code> tag.

Tygari • Mar 24 '19 • Edited

Great post.
I been doing this for over a year and love it.

I feel you should have given some mention to Custom Tags. They help so much in pushing this to the next level.

PS-- Content Indicators has a hanging < /div>

Ken Bellows • Mar 24 '19

Thanks, fixed!

By custom tags, do you mean custom elements? Those are a whole other ball of wax. They're part of the Web Components API, which requires JavaScript and a ton of extra domain knowledge. This article is just an introduction to an important feature of HTML5, and Web Components are not a part of HTML5, so that would fall pretty far outside the scope of this article.

To be honest, I'm pretty unfamiliar with custom elements myself, so I'm not the person to write that article. Sounds like you have some background, so maybe you are! I'd love to read it!

Tygari • Mar 26 '19

Yes custom elements are what I mean.

Though there is far more to it than I know or understand (for now). In it's simplest form you can just write a tag as < box>< /box> (or any word you choose) and be able to target that tag as you would any other.

JavaScript:
document.getElementsByTagName("box")

CSS:
box{display: none;}

All without understanding anything else of the API.

The greatest thing about a custom tag is it is blank.
No pre-attached css or code like 'p' or 'div' have. Your free to write without having to remember what has what attached.

I use this kind of coding extensibly in my Browser Game "EVO Idle". As well as some new Dynamics to manipulate information quickly and easily. (Be warned some are considered against the standard.)

Ken Bellows • Mar 26 '19

RIght, that's the thing. Those aren't so much "custom elements" as they are "nonstandard elements", because the browser doesn't understand them, and they don't have any functionality backing them. It is true that you can write arbitrary tags in your markup, and IIRC the browser treats them like <span>s by default (which is to say, as generic inline elements), but this isn't standard practice, and it's usually considered a bad idea.

A custom tag name indicates to other developers that there's something special about this tag, that it's a component or a proper Custom Element with some JS behind it or something, and it can be very confusing to read markup with lots of nonstandard elements that aren't backed by any other code, especially if they're mixed with actual components that are backed by code. So my recommendation is to instead use a standard element with a class="..." instead of a custom tag name. The only thing that changes in your selector is an extra . before what would have been the element name, and is now a class name.

Just my two cents, take it or leave it 😊

more-urgent-jest • Mar 26 '19

html.spec.whatwg.org/#custom-elements

Ken Bellows • Mar 26 '19 • Edited

Yep, that's a nice summary! They distinguish there between "non-standard elements", arbitrary tags that have not been added to the CustomElementRegistry, and "custom elements", which have:

Custom elements provide a way for authors to build their own fully-featured DOM elements. Although authors could always use non-standard elements in their documents, with application-specific behavior added after the fact by scripting or similar, such elements have historically been non-conforming and not very functional. By defining a custom element, authors can inform the parser how to properly construct an element and how elements of that class should react to changes.

(My emphasis added.)

The word "defining" is linked to the portion of the standard that describes how to define a custom element, which begins as follows:

Element definition is a process of adding a custom element definition to the CustomElementRegistry. This is accomplished by the define() method.

Tygari • Mar 29 '19

I disagree. If people wish to make assumptions about everything than it is their own fault for messing up.

A simple Google check will verify if a tag is standard or custom.

Using custom tags with or without javascript makes the document more readable. Which is the point you were making.

Not everything needs to be predefined.
If it were the language would never have evolved in the first place.

It is people pushing out of the standard practice that evolve the language.

If you wish to be confined by such limitations that is your choice.
I choose to evolve my coding style by trying new things and creating new concepts. Even in the face of the people's backward concepts of what is and is not proper coding.

Ken Bellows • Mar 30 '19 • Edited

Alright, please read what I have to say here in full. I need to say something that I feel is very important.

I fully respect that you have a different opinion from me on how best to write your markup. And I'm perfectly cool with that; you can write your HTML in whatever way you see fit, and I'll be happy to hear how it works for you, and what benefits you find in it. Genuinely, reading about alternative viewpoints on web development is one of my hobbies, and I almost always find something I like in every one I explore.

But please do not turn around and label my attempts to explain the existing standards and best practices of the web platform as "backwards concepts of what is and is not proper coding". Because these are not some arbitrary whims handed down from some oligarchic hierarchy of web gods. These are standards with a huge amount, literally decades, of research, community-wide debate, and iterative revisions behind them, and there are are very good reasons why they exist.

It honestly hurts to be accused of trying to "confine" and "limit" people from "trying new things and creating new concepts" simply because I'm explaining the background and advantages of the specs that are out there. My point was never that nonstandard tags are evil and you should feel bad for using them. But you started the conversation by suggesting that I should have promoted nonstandard elements as a good practice that "help[s] so much in pushing this to the next level." The fact that you said that nonstandard tags can build on the techniques that I discussed in my article tells me that I did a poor job of emphasizing the reasons why we use standardized semantic tags. Semantic tags are not primarily about improving code readability. If that was the case, there would have been no point in defining a spec for them; we could just standardize the use of arbitrary tag names and let common patterns develop within the community, like we have with CSS class names.

My point in this thread was to let you know that there is a very real difference between arbitrary nonstandard elements, which have no defined semantics or behavior and can't be used by assistive tech or web crawlers, and true custom elements, for which the developer has explicitly defined the behavior and semantics for the browser.

Because here's the thing: the semantic web isn't just a matter of preference or style or convenience. It has a huge direct impact on the lives of many, many users, those who rely on assistive technology, which in turn relies on the semantics it can parse from the text to help those users.

If you've never tried to use the web with a screen reader before, please do. I think every web developer needs to do this periodically in order to better understand how many of their users interact with the web, and how honestly horrible a lot of the web can be for users who rely on assistive tech. If your site is built with nonstandard elements with no defined semantics, then the best that a screenreader can do is read the text top-to-bottom, with no way to let the user easily navigate the page. But if you use the elements I talked about in this article, a screen-reader can add build an outline of the page to give to the user, and it makes it a hundred times easier to navigate the page.

And microdata specs like RDFa help fill in the rest of the semantics that aren't expressible in HTML alone. Seriously, browse a little through schema.org/docs/full.html and look at all the options. And that's all stuff that assistive tools can potentially utilize to give users more context about what the page represents. (And by the way, it can dramatically help your SEO on top of this.)

In my experience, there's a tragic lack of attention paid to semantics in web development training, and this knowledge gap actively hurts the users that actually need it. That's a big part of why I wrote this article. Using semantic HTML and microdata formats improves the lives of many people much more directly than you might expect. Nonstandard tags, unfortunately, don’t, and I worry they may redirect devs away from the standard methods that do because nonstandard tags require fewer characters and zero research.

Maybe I should have emphasized the a11y aspect of semantics more strongly in my article, and maybe I'll write a follow-up to do just that. But please, please don't think that I or anyone else is trying to enforce some arbitrary restrictions that stifle innovation by recommending that devs avoid nonstandard elements and use existing semantics frameworks instead. What I'm trying to do is help one of the most underserved and ignored groups of users on the web.

Jon Lauridsen • Apr 6 '19

This feels like a hugely under-appreciated comment, it’s a very good reply. I seriously think you can turn this comment into its own blog.

Ken Bellows • Apr 6 '19

Thanks 😊 I may do that

rhymes • Apr 14 '19

Please do :-)

Ken Bellows • Apr 28 '19

For posterity, since new people seem to keep finding this article and this comment thread, I did write that follow-up:

Why I care about the Semantic Web

Ken Bellows ・ Apr 22 '19 ・ 7 min read

#html #webdev #semantics #a11y

James Thomson • Mar 26 '19

Good article. It can be tricky when a design isn't at all related to the common news, blogs, etc. In those times I've found this flowchart pretty handy to help reason about semantics. html5doctor.com/downloads/h5d-sect...

Ken Bellows • Mar 26 '19 • Edited

Nice, that's an awesome chart! Haven't come across it before. Kinda surprised that <header> and <footer> don't show up anywhere

James Thomson • Apr 2 '19 • Edited

Perhaps a v2 is in order ;)

Edit: I just noticed the date on it is 2011-07-22, so yeah, a v2 really would be good.

ɥɔɐ⅂ ɐɥɔsɐS • Mar 27 '19

I'm completely agreeing using semantic HTML. Usually I'm always trying to use the sectioning elements.

But I'm observing that I'm still heavily using <div>s, inside of an <article> or <section>, especially when layouting with flexbox.

I tend to create a lot of wrapping <div>s, for grouping together some elements as one flex child.
(e.g. for using the margin-*: auto; trick altogether)

It kind of feels unsemantic, but then again, since these are only used for layouting, it seems to be ok.

How do other people feel about that?

Ken Bellows • Mar 27 '19

I have two feelings:

First and foremost, it's almost definitely fine! The point here isn't to totally get rid of <div>s, it's to stop using them in cases where they have some semantic meaning that's covered by another element. But generic containers with no semantics to them are exactly what <div>s are, so if they're just grouping things for styling purposes, not semantic purposes, you're all good!

Second, with the above said, as kind of a side comment, if you're creating a lot of nested flex containers, you probably would be better served with a flatter HTML structure and CSS Grid for the layout. Grid is supported pretty solidly at this point, and it's usually not hard to create fallbacks for older browsers that still look perfectly fine (even if they don't exactly match the mockup) without adding any extra markup. If you haven't tried Grid yet, give it a shot, it'll blow your mind! (If you can't tell, I'm very excited about Grid, I wrote a couple article about how pumped I am haha, I recommend this one you wanna see the thing I love most)

Daniel Tonon • Apr 5 '19

I just wanted to chime in on the CSS Grid discussion.

If the only reason you aren't using CSS Grid yet is because IE11 needs to look identical; I wrote a whole series on how to write modern CSS Grid code that works perfectly in IE with no fallback styles.

css-tricks.com/css-grid-in-ie-debu...

PS. Great article, I'll definitely be recommending it to people.

ɥɔɐ⅂ ɐɥɔsɐS • Mar 28 '19

I'm more and more trying to use Grid, you're right it is mindblowing.

Right now I'm using it for overall page layout and flex for smaller sub items. I need to reconsider if nested flexboxes can be done with grid.

(I actually found my way to this article, via your Why we need CSS subgrid article. Great one, too!)

Sebastian-Nielsen • Mar 24 '19

Stop telling me what to do!

CrashedDummy • Mar 25 '19

Great post.
But something bugs me : multiple <section> in one <article> ?
When I learned HTML5 ~10 years ago, I was told the contrary, multiple <article> in one <section> (see alsacreations.com/xmedia/doc/origi...).
What is the best practice ?

Ken Bellows • Mar 25 '19

Well, you can do both, depending on the scope of the tags. For example, I might put a tweet in an <article>, and I might show multiple tweets in a single <section>. But typically, on a site like a blog where you have literal articles or other long-form text, you'd have one <article> that wraps the main text content of the document, and that <article> would contain multiple <section>s.

Let's look at the spec again.

<article>:

The article element represents a complete, or self-contained, composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication. This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.

html.spec.whatwg.org/multipage/sec...

<section>:

The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.
Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element.
The section element is not a generic container element. When an element is needed only for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element's contents would be listed explicitly in the document's outline.

html.spec.whatwg.org/multipage/sec...

So the idea that an <article> can contain multiple <section>s seems natural to me. And in fact, the spec itself shows a code example under the definition of <section> linked above where an <article> has multiple <section> elements within it.

CrashedDummy • Mar 25 '19

Thanks for answering !
It feels clearer now.

Last question, just to be sure I understand well, would it be correct to do the following :

<section itemscope itemtype="http://schema.org/Blog">
    <article itemscope itemtype="http://schema.org/BlogPosting">
        <--! header, sections, footer-->
    </article>

    <article itemscope itemtype="http://schema.org/BlogPosting">
        <--! header, sections, footer-->
    </article>
</section>

Ken Bellows • Mar 25 '19

I don't see why not! Two tangential comments though:

Each <section> should ideally have a heading tag (<h1>-<h6>) to identify the section. Remember that a <section> should be something you'd list in your table of contents, so what would you call that section? Though I recognize you might have skipped it for the sake of example code, and of course this has no effect on the main point
Your comment syntax is slightly wrong, it should be <!-- rather than <--!. But again, no effect on the main point

CrashedDummy • Mar 25 '19

Thanks again !
And :facepalm: for comment syntax X)

Drew Knab • Mar 25 '19 • Edited

Good article!

However, I have strong and complex feelings on this, being interested in the semantic web since 2003 and remember ardently following xhtml1.0 strict standards.

main: great, good.
header/footer: awesome, thanks
nav: oh wow how did we live through xhtml without it?
article/section/aside: wow, trash, wtf?

Article, section and aside are so vague that they semantically mean about the same thing as div. You still have to drop identifying classes on them to actually note what they are intended to contain.

Comments/assorted widgets/supplementary info can be articles, but also can be sections, but can also be asides or contain or be contained by any mixture of the above. I'm not saying div is the gold standard, but this is one area whatwg kinda dropped the ball. Semantically, it doesn't say what it is any more than div does.

I'm not alone here, either.

Ken Bellows • Mar 25 '19

That's a very interesting perspective, genuinely, and I'll have to think more about it.

But my initial reaction is that I think article and section at least have pretty clear meanings:

An <article> should be used only for a high-level portion of the document that is sufficiently independent that if it were plucked out of your page and dropped into another page, it would still make perfect sense, like a blog post or tweet.
A <section> is a block that doesn't meet the above independence criteria, because it only makes sense within the context of the surrounding content, but that you would list in your table of contents.

An <aside> is, admittedly, a bit more vague: is a "note" block in the middle of your text an "aside"? I often use phrases in my writing like "as an aside, ...", but I wouldn't put the proceeding paragraph in an <aside>. So maybe its name is a bit misleading. But I still think it serves an understandable purpose: if I never read the content within the aside, I shouldn't be confused about anything in the article, but the content in it should either enhance my understanding of the content (e.g., example 13 in the spec adds background info about a country that might help an unfamiliar reader) or give me additional functionality, like a sidebar with links or buttons.

I think this is sort of an inherent problem with trying to fit any rigid spec to human language: we want the spec to be written using words we understand, but human language is incredibly fluid and non-rigid, so there are bound to be confusing cases where its unclear which element to use, etc. But I still think there are clear black and white areas, even if there are lots of grays in between.

All that said, I'm interested to hear your feedback, and I'm very interested to read more about the problems people see with the spec; it should be helpful in explaining it better down the line. Thanks for pointing this out to me!

Aoibhe Wilson 🇨🇭 • Mar 26 '19

I think part of the issue we run into is that the human language being used to describe this is specifically the language of print layouts like newspapers or magazines. That language was far more known back in the late 90's early 00's but more and more developers are going to be seeing this through web-first eyes.

Your explanations are spot-on though. Even with aside, while we might see it as vague in its contents, you nailed the purpose.

Ken Bellows • Mar 26 '19

Thanks! And yeah, I agree, the farther we get from the days of mostly-print-media, the less obvious the metaphors become.

I also think with <aside> specifically there are sort of two competing metaphors: the "sidebar" layout element, and the semantic "aside", for tangential info. These are really two very different things, but the spec currently allows for both, which is confusing. As I understand it from some googling, the spec initially only allowed for the semantic usage, and did not recommend using <aside> for sidebars with content unrelated to the main content, like navigation links, etc. But the spec was later amended because of common confusion and the perceived need for a sidebar element to explicitly allow both usages. I'm unsure how I feel about that move.

ALF2000 • Apr 3 '19 • Edited

I enjoyed this refresher and I agree there's more to markup than divs. With that said, the current crop of available HTML tags are a little confining. They seem biased towards newsy, bloggy, content-heavy sites (section, article, header, footer, p, aside etc). It would be great if there were a few tags aimed at web applications - tags like controlbar, preview, settings, livecontent, and user etc. I often find myself trying to map the meaning of some "thing" I'm working on to the nearest-matching standard tag. In the absence of more semantically appropriate choices, this all-to-often turns out to be a div.

Ken Bellows • Apr 3 '19 • Edited

That's a pretty good point, and one that a lot of people have discussed in the last couple of years.

As for most of the semantic tags being biased toward content-heavy sites, I'd say you're like 75% right. Tags like <p>, <aside>, and <article> are pretty specifically defined in terms of representing that kind of content. But some of the others, like <header>, <footer>, and <section>, while arguably still defined with content-heavy applications in mind, are IMHO still pretty useful for web applications if you focus on the idea of an "outline" for your site, and how that impacts accessibility in particular. Assistive tech like screen readers uses elements like these to build an outline of the parts of the page for the user, so you could still have the main interactive regions wrapped in sections, with <h1>-<h6> tags to label them, and <header>s and <footer>s where they make sense, though those are probably rarer, especially <footer>.

As for introducing new elements that are more focused on web applications, I have three thoughts.

First, I think this would be much more difficult than it might seem at first glance. How to structure and divide up the parts of a web application is pretty controversial even within a single team, let alone trying to standardize semantic markup for the whole industry. There actually have been some discussions about this, and several proposed (and even partially implemented) elements have been retracted; see <menu>, for example.

Second, there already is a way to do this, though it's not quite as clean as semantic elements: the Roles Model, which uses the role="" attribute to define pretty specifically what elements in the page are for, and it has a pretty large selection of "widget roles" that are super useful within web apps. I also expect it would be 100x easier to add a new role than a new semantic element.

Third, there is also another approach that's been floating around for a few years now and gaining some steam that will allow the community to develop and share these elements, maybe create some community de facto standards, without waiting on the W3C for it: Custom Elements. They aren't just for widgets: you can register custom elements to play semantic roles as well, if you want, and define some amount of semantics and behaviors for them. I haven't played with them too much, but have heard good things from those who have.

As a final note, I just saw a super interesting thread on Twitter on a very closely related subject, then switched to Dev and saw your comment in my notifications. This is the first tweet of several, and I recommend clicking through and reading the whole thread.

Florens Verschelde

@fvsch

So I kinda share this sentiment, but as a UI dev I also have a hunch that it's a bit uninformed and too optimistic about the cost of defining and building complex & stylable standard UI components. Even native ecosystems, with far fewer platforms to support, are pretty bad at it. twitter.com/tjholowaychuk/…

19:34 PM - 03 Apr 2019

TJ Holowaychuk 🙃 @tjholowaychuk
1.3mb of React UI components for regular things like popovers, tooltips, auto-complete etc, maybe the browsers can focus on things like this that we actually need instead `try{}catch{}` without an error 😉

0 2

ALF2000 • Apr 3 '19

Thanks for your response. Of course you are right about all of it, but roles and custom elements seem a little verbose, if not downright complicated for app design and scaffolding. HTML tags are so basic by comparison - you can write and read and understand them immediately. I'm not saying the web needs to be simple - heaven knows it's not, but there is something to be said for brevity when it can be had. In my HTML fantasy, there would be just a handful of common, handy tags for web applications and I would be universally heralded and financially rewarded for my contribution to humanity.

Ken Bellows • Apr 4 '19

Well that's the awesome thing about custom elements, once they're written, they are just HTML tags. The idea with them is to pass them around like any other library. So hey, give it a try, write that fantasy set of web app tags, share them around and get your fame!

Ben Halpern • Mar 24 '19

Fab post

John R. D'Orazio • Mar 24 '19

Isn't it kind of redundant to use a 'header' tag just wrap an 'h1' tag? Seems to me to clutter up the dom structure...

Ken Bellows • Mar 25 '19

That's certainly true, and in many cases you don't need it. You can definitely just put the <h1> (or <h2>, ...) tag on its own, and AFAIK that works just as well for screen readers, SEO, etc. But the advantage of a <header> is being able to group other things like inline icons, section anchor 🔗links, etc., and I find myself going back and adding those later often enough that I have just made a habit of using a <header> wrapper almost all the time. But with that said, it's a very YMMV situation, so feel free to skip the <header> if you feel confident you don't need more than the <h1>, there's nothing wrong with that semantically 😊

Aoibhe Wilson 🇨🇭 • Mar 26 '19

If you think of a magazine or newspaper article it makes more sense. Things like a byline, publication date, subtitle, those are all still part of the header for that article. You would want to group them semantically.

Isa Levine • Mar 24 '19

thanks for writing this! i'm just starting out with html and i totally thought the convention was to throw divs in everywhere--glad to have these other options, especially early on!

Reinier Kaper • May 2 '19

This is certainly a lot better than just divs and spans, however there are also some quirks with HTML5's section elements.

Section and Aside bring some nasty-ness to the outline for example.

Using more than one h1 (like in your example) is also generally discouraged for accessibility, even though the spec seems to encourage it.

I usually don't include a heading in the nav (even though the outline wants it), and only use 1 h1 element on the page at all times (literally the main heading on the page, the rest gets an h2/h3/etc where it makes hierarchical sense).

So in your example I would change the 2nd h1 to h2 and all the h2 to h3 for a somewhat nicer outline.

Other than that, I really encourage writing more semantic markup in general. There's a ton of useful tags out there that are way better than your styling hooks (div/span)!

Ken Bellows • May 2 '19 • Edited

Thanks for the context! I'll readily admit that I'm no expert on the outline algorithm, but I will say that the rumors I've heard suggest that an updated outline algorithm is beginning to be implemented in a few browsers, and the updated algorithm prefers a new <h1> within each sectioning context, e.g. within each <section>, <article>, etc. But even so, it's not the predominate algorithm in the wild right now, so fair point, one <h1> per page.

How do you examine the generated outline for a page, as perceived by assistive tech? Are there good tools out there to help with this?

Reinier Kaper • May 2 '19

Hey Ken!

Yeah the spec calls for a new outline in each section, so multiple H1's are technically allowed, but assistive technologies and (as much as I hate this argument) SEO don't always line up with the spec. So for now it's safer to go the 1 H1 route.

Usually I use W3C's validator (validator.w3.org/nu) with the outline option checked to test for at least the basics.

Then there's some other tools (like the "Siteimprove Accessibility Checker" plugin for Chrome) that help a bunch as well (but they focus less on semantics and more on pure a11y).

Ken Bellows • May 8 '19

It's true that if you don't specify a tag type, Emmet defaults to <div>, but it can produce whatever kind of tags you want. And in fact, it's often very few changes, since we often use stuff like id="header" or class="header" where we should just use tags, e.g. <header>. So with regards to Emmet, instead of this:

#main>.main-header+(.content>.content-header+.section*3+.content-footer)+.main-footer

which expands to:

<div id="main">
  <div class="main-header"></div>
  <div class="content">
    <div class="content-header"></div>
    <div class="section"></div>
    <div class="section"></div>
    <div class="section"></div>
    <div class="content-footer"></div>
  </div>
  <div class="main-footer"></div>
</div>

you can use the semantic tag names along with any custom classes you want, if you feel you need them:

main>header.main-header+(article>header.content-header+section*3+footer.content-footer)+footer.main-footer

which expands to:

<main>
  <header class="main-header"></header>
  <article>
    <header class="content-header"></header>
    <section></section>
    <section></section>
    <section></section>
    <footer class="content-footer"></footer>
  </article>
  <footer class="main-footer"></footer>
</main>

Did you have other concerns about using semantic tags with Emmet?

Zac Heisey • Mar 25 '19

Hey Ken, nice article! Glad to see more devs advocating for alternatives to "div soup." I wrote an article along these same lines earlier this year, which also got some solid responses: medium.com/web-dev-basics/7-altern...

BaltimoreDevs Represent ✊

Ken Bellows • Mar 25 '19

Wow, I wrote almost exactly the same article! Sorry for unintentionally ripping you off, haha!

Zac Heisey • Mar 25 '19

No way man, your article was great! It delved into other areas of semantic HTML that I didn't touch on. There's plenty of room for multiple "stop using so many divs" articles, at least until more developers get the message ;)

hajikelist • Mar 26 '19

I didn't think I would like this as much as I do. Pretty awesome stuff actually. The main tag example you mentioned does have it's drawbacks since you'd have to identify and group collections of main tags in order to iterate through them in any meaningful way. Perhaps not as semantically beneficial, since one would usually do something along those lines with div tags anyway; div#home, div#page-1, etc...
To use the main tag properly it should be used like void main in C++, there can be only one!

Ken Bellows • Mar 26 '19

Right, and typically that's the idea. The only case where I can imagine wanting multiple <main> elements is as a short-term measure to basically preload some content in a <main hidden>, then show it and hide the other simultaneously, and delete the old one. As a variation, in a situation where you're moving through pages sequentially (chapters in an online book, for example), I could imagine keeping the previous and next both loaded in <main hidden>s, but more than that seems like a bad idea (though I'm open to counter examples)

Vincent Milum Jr • Apr 4 '19

The primary reason I feel in love with these tags (and more in HTML5) is actually because of CSS. The styling becomes SO much easier and cleaner to read, too! Plus doing query selectors from JS as well.

Ken Bellows • Apr 4 '19 • Edited

Oh man, absolutely!

#main-content .blog-post .blog-section .section-header h1 { /*...*/ }

vs.

main article section header h1 { /*...*/ }

ofek3103 • May 25 '19

Is using these tags also has an advantage on the CSS side? I mean, keeping CSS as less specific as possible (Class has a higher specificity than element).

I'd also like to know if there's any replacement to

in HTML 5? (In case the "container" is a white rectangle inside a black screen)

Ken Bellows • May 25 '19

I definitely prefer selectors like main article header h1 over #main-content .post-body .post-header h1, just for readability's sake if nothing else, but I'm not super worried about specificity issues personally. It probably is preferable to keep your specificity low when possible.

I think the HTML element you typed got filtered out; can you ask your second question again with backticks around the element?

ofek3103 • May 26 '19

<div class=container> The element is a white rectangle centered in the middle of the page.

Ken Bellows • May 26 '19

So, the semantic elements introduced in HTML5 are all about conveying the structure of the data. Purely stylistic elements, like containers that only exist to help make the CSS work the way you want, don't have any semantics to represent, so a plain
old <div> really is the correct choice there, no replacement necessary.

Stephen Irving • Jan 6 '20 • Edited

A better approach is to use microformats over RDFa for semantically marking up content. It is more modern, easier to learn, and less verbose to write.

From the link:

"Microformats2 is an update to microformats that provides a simpler way of annotating HTML structured syntax & vocabularies than previous approaches of using RDFa and microdata which require learning new attributes."

Ken Bellows • Jan 7 '20

Wow, absolutely! I hadn't come across microformats specifically in my research, but it looks pretty powerful and straightforward. Do you know anything about technologies that recognize and utilize them, whether a11y assistants or search engines or anything else?

Scott Hannen • Apr 23 '19

This was excellent. I haven't been doing as much web development lately so this was a great reintroduction to stuff I haven't gotten to use. It reminds me of 15-20 years ago learning HTML for the first time.

$.02 on unregistered custom elements: I'm sure they have a place, but I'd exhaust every other option first and then consider using a div with a class. There's a place for creativity and a place for standards, and something that both people and software must read and understand is a better fit for standards.

bcbz-vssms-com • Apr 3 '19

Thanks for this.

Would you wrap your "cheesy content" inside any kind of element, or just have it as text alongside ?

(<header&rt;)

Ken Bellows • Apr 3 '19

In my example above, which is meant to be a mass-text article, I'd probably put the prose into <p> tags to mark the paragraphs. But you don't necessarily have to, you certainly could just put your text inline there, though I'd only recommend that if it's a single paragraph worth of text. HTML doesn't respect line breaks in the source, so if you don't use <p> or some other container styled with margins to separate your paragraphs, you will literally end up producing a huge block of text
like my text wall illustration.

bcbz-vssms-com • Apr 4 '19

Thanks.

I think sometimes I add extra divs because I feel there should be some kind of hierarchical "parity"(?) with elements, e.g.:

<section>
<header>
<h2>Part 1: Variety is spicy</h2>
</header>
<div class="not-header">
<p></p>
<p></p>
</div>
</section>

Do you think there's any value to that? If so, is there a better element than div here? Or should I just get over myself?

Ken Bellows • Apr 4 '19 • Edited

There's nothing semantically wrong with an extra <div>. I probably should have made clearer in the article, <div>s aren't bad, and there's nothing wrong with using them, just as long as the correct semantic elements are used where their semantics apply. The sort of <div> you're describing doesn't have any semantics to it anyway, so a <div> works fine if you prefer it, and can be useful for layout purposes as well.

By the way, another thing I probably should have made clear in the article is that <header> is not strictly necessary if the only thing inside it is a heading (<h1>-<h6>). It's useful for grouping things, like a heading, an icon, and a section anchor link, and it might be useful for styling purposes, but if you don't need those things, you could just do this:

<section>
  <h2>Part 1: Variety is spicy</h2>
  <p><!-- some cheesy content --></p>
  <p><!-- more cheesy content --></p>
</section>

That might give you the consistent feel without needing the extra <div>, if you're worried about it.

Any of the three options is fine: <header> + <p>s, <header> + <div>, <h2> + <p>s.

bcbz-vssms-com • Apr 4 '19

Yes, I like <h2> <p> <p> better, thanks.

(& I think you meant to write divs are "NOT bad" above)

Cheers

Ken Bellows • Apr 4 '19

Ha, I sure did 😂 Thanks! Fixed for posterity

Bryan Cole • Dec 5 '19

Hi Ken. This article was really great. I'm super new to HTML/CSS (less then a week!) and I found it really informative and easy to read. I'm currently taking Le Wagons Full-Stack Web Developer program. (Part time!)

The only confusing part for me about the article is how to write the CSS code to style these new sections. Maybe a quick primer or best practices link for for CSS styling based on this HTML?

For example... if you styled the h1 tag would that cover the h1 tag in and ?

And if you wanted to do the h1 tag in main only you it would be something like .main .article .header . h1? Does this add a lot of complexity to the CSS code?

Thanks!

Ken Bellows • Dec 5 '19 • Edited

Hey Bryan! Great questions, very fundamental to understand how CSS interacts with HTML. I won't be able to fully answer in a comment, because you've really struck at the heart of CSS selectors and how they work and I really recommend going through a full CSS tutorial for that, but I'll try to cover the main points.

The most important thing to remember is that CSS selectors are greedy, in a technical sense, meaning that they try to grab as much as they can. Anything that could possibly fit within the definition of a selector will. So if you write this block of CSS:

h1 {
  color: red;
}

then every <h1> tag on the whole page will be turned red, except where you define other blocks with more specific selectors that override the color, such as:

main h1 {
  color: blue;
}

This is a core term to know in CSS: specificity. Emma Wedekind wrote a great article going over it, which I highly recommend: CSS Specificity. But the basic idea is this: More specific selectors are stronger. main h1 beats h1 because it's more specific. h1 says, "modify all <h1> tags"; main h1 says, "modify all <h1> tags within <main>". More specific, so stronger. (Emma's article covers the details on exactly how specificity is determined for a selector, so check that out.)

To answer your specific cases:

Yes, an h1 selector applies to every <h1> on the page. Though remember that any properties can be overridden in specific cases by more specific selectors.

You're mostly correct about styling that specific <h1>, but remember that .main is not the same as main: the dot prefix refers to HTML classes, so if you used the selector .article, that would not match <article>, but would match <div class="article">. The better way to style the <h1> in this case:

  <main>
    <article>
      <header>
        <h1>Title!</h1>
      </header>
    </article>
  </main>

would be like this:

  main article header h1 {
    font-size: 36px;
  }

Hope that helps! As for best practices, that's an even bigger question, and there are a thousand different opinions out there. To be honest, I wouldn't worry about best practices and conventions for now; focus on learning how CSS itself actually works at a deep level before you get into the subjective stuff.

Hope this helps!

Vijay Jangid • May 16 '19 • Edited

Great share! I think I get the point you are trying to make here.. just not easy to read/understand/compile for the developer... but also for other developers, automated testing tools, softwares that parse html, accisibility tools. (Humans and Machines).

I would highly recommend fellow readers to not just read the article, but also the 100+ comments down here. You will find a lot more views, perspectives, clarifications and reasoning.

On a side note, I remember writing comments in markup for
 ... 
which may be ommited or minimized to a great extent if semantic tags are used.

Thanks again for your research and sharing the knowledge :)

Colin Kiama • Mar 25 '19

Thanks for this. Was about to go crazy with divs for my site but now my CSS is show much easier to understand than if I carried on using divs for everything. Great article!

Tõnu Trubetsky • Mar 25 '19 • Edited

Great and informative article! While using this kind of structure I sometimes struggled with adding css on these elements because depending on the design I would need to style sections or main elements etc. But I've researched that some of those elements shouldn't really be styled directly so then I would have to wrap a section over a div? Or what would be the best practice while thinking of styling all these different html5 elements?

Ken Bellows • Mar 25 '19

Hm, I'm not sure what you mean. Do you have a specific example? I haven't heard of anyone saying you shouldn't style a <main> or a <section> directly

NM Labs • Mar 24 '19

Nice. Make it more readable and clearly.

Jan Wedel • Mar 24 '19

Great article! Will replace all divs in my personal blog by semantic Tags ASAP! 👍

Ken Bellows • May 22 '19

As in Software as a Service? It's fine, I certainly use plenty of SaaS products myself on a daily basis. Or did you mean SASS, the CSS preprocessor? I like SASS a lot. Or did you mean something else completely?

Madza • Apr 23 '19 • Edited

jade / pug?

Ken Bellows • Apr 23 '19

Not super familiar myself, only ever brushed up against either of them, but afaic, use whatever language you want, as long as the output is semantic HTML. It's not about cleaner markup, it's about accessible markup. I just wrote a whole article about that, actually, as a follow up to this one: Why I care about the Semantic Web

Rudson Augustin • Mar 24 '19

This was beyond informative!
Thank you!

Sunfire • Jun 16 '19

Nice breakdown! I've been using some for a while now, but others I barely knew. Thanks for sharing!

Mohamad Ashraful Islam • Mar 25 '19

As always like before i was thinking about div is good instead of anything. thanks man!!

Wes • Mar 24 '19

This is beautiful 😍😍🤩🤩. I’m converting my apps to use semantic html from now on. Soooo much more readable and accessible. #html #javascript

Mihail Malo • Mar 24 '19 • Edited

#hashtag

snydez • Apr 5 '19

wow! so later the css use directly the tag instead of the class?

Ken Bellows • Apr 5 '19

Yeah! IMHO, it's better to use more generic selectors in your CSS as often as you can, because it makes them easier to override later. Being too specific with selectors is what leads people to slapping !important everywhere, because they're having a hard time overriding those super-specific selectors.

Oleksii Trypolskyi • Jun 18 '19

Many thanks for the article! Good job!

Uddesh • Mar 24 '19

Great post.

Paramanantham Harrison • Apr 22 '19

Thanks for doing this series man. Keep doing the good work.

Meir Gabay • Feb 20 '21

Superb!!! Thank you! It feels like writing HTML is like writing in MarkDown, which is easier (in my opinion).

Jonathan Silvestri • Apr 23 '19

I am definitely saving this as I'm going to dive in to accessibility work very soon. Thank you!

Andrew Bone • Mar 27 '19

Seems this article really struck a chord, well done 🙂

Fellipe Geraldo Pereira Botelho • Jun 12 '19

Awesome post dude!

mludovici • Sep 16 '22

I didnt know you could put header and footer inside an . Why is that? And what other semantic elements follow that pattern and what are the effects of it?

Ken Bellows • Sep 20 '22

Hi! I'd be happy to answer your question but it looks like you typed a tag at one point and it got filtered out. Put a header and footer inside what?

mludovici • Sep 20 '22

oh sorry, I meant inside an "article" tag... it seems that tag works like some kind of isolated block independent from its html around it?

Ken Bellows • Sep 20 '22

Gotcha! So the <header> and <footer> tags are semantic ways of marking a header and footer of any segment of the page that needs one. <header> is definitely used way more frequently. Any body of text large enough that you'd want to break it into sections can be written with <section> tags and use a <header> to wrap the section heading, especially if you want to add something other than just a heading at the top of each section (like a section link to add a # section to the URL, a "back to top" link, an icon, anything like that).

As for the purpose of the <article> tag, like I mentioned in my post, their purpose is to wrap a section of the page (usually primarily text, but not necessarily) that is important content and is relatively independent from the rest of the page. The way I like to think about it is this: would this still make sense on its own if it were plucked out of the host page and dropped into another page, without the context of the other page? If so, maybe it could be wrapped in an <article>.

Obviously a common use case is actual articles, e.g. news articles or blog posts. But another good example is Twitter. If you're on a laptop or desktop right now, open twitter.com in a new tab, right-click on a tweet and hit Inspect. You'll see that Twitter wraps each tweet in an <article> tag. That's because a tweet is an independent unit that makes sense if you pluck it out of the context of twitter.com specifically and drop it into another page, as often happens with embedded tweets in news articles.

Unfortunately that's where the semantic HTML stops for Twitter. The markup of a tweet is a perfect example of the div soup that made me want to write this article. I think a tweet is a perfect place to use semantic HTML. Something like this would be awesome:

<article>
  <aside>
    <img src="/user/profile-img.png" alt="@username's profile picture">
  </aside>
  <header>
    <a rel="author" href="/@username"><strong>User Display Name</strong> @username</a>
    <time datetime="2022-09-20 15:08">Sep 20</time>
    <button title="Open menu"><img src="/static/menu.png"></button>
    <menu hidden>
      <li>Not interested in this tweet</li>
      <li>Follow @username</li>
      ...
    </menu>
  </header>
  <p>Tweet content here!</p>
  <footer>
    <button title="Reply"><img src="/static/speech-bubble.png"> 10</button>
    <button title="Retweet"><img src="/static/retweet.png"> 3</button>
    <button title="Like"><img src="/static/heart.png"> 75</button>
    <button title="Share"><img src="/static/share.png"></button>
  </footer>
</article>

This probably isn't everything, some extra elements (maybe even divs!) might be needed for structural and styling purposes, but these days honestly not very much more.

Here's how my rough markup would map to a real tweet:

Hope that helps!

Pierre-Henry Soria ✨ • Mar 25 '19 • Edited

Good read Ken! Indeed, HTML5 is mainstream for the past 10 years, but all features of HTML5 aren't still used to its all potential... Always good to remind them! 😉 It's worth it 👍

Fernando D. Bozzo • Apr 24 '19

Excellent post! Many thanks! :D

Strahinja Babić • Mar 24 '19

Ahh so awesome :)
Will definitely try to put less divs in further projects :D

Peter Thompson • Apr 3 '19

Great write up Ken. I like the way you have replied to comments as well :)

Ken Bellows • Apr 3 '19

Thanks! The discussions are my favorite part 😁

Hassan Alizadeh • Apr 1 '19

Thanks for your great post.

I think the second include line should refers to footer.php instead of
<?php include 'header.php'; ?>

Ken Bellows • Apr 1 '19

You're right, fixed! Thanks, good catch!

Devsol • May 17 '19

Dope read! I am in the process of building my website from scratch b/c I want full control and found this post to be very helpful!

Paul Ngumii • Apr 5 '19

Interesting article, thank you

Chad Windham • Mar 25 '19

Well done. Fantastic job breaking down all this info in an easy to read manner, much appreciated!

Poul H. Hansen • Mar 25 '19

Lovely writeup!

patrikx3 • Apr 8 '19

I love DIV-s! So simple...

Hamid Semix • Mar 26 '19

Wonderful post indeed

Anand Kumar • Apr 6 '19

Couple of tags I was not aware of from the list given at the end. Great post. Thank you.

Nick • Aug 1 '19

😊

Kamal • Apr 29 '19

This is amazing, thanks!

Namstel • Mar 26 '19

Great post, thanks for this! I find myself using divs a lot and I really need to change my ways, this article will help me.

Ken Bellows • Mar 26 '19 • Edited

I hope it does! 😁Though I should say, <div>s are still okay for many purposes, arguably most of the time. I feel like I should write an addendum, with all the attention this post is getting, just to say, "It's fine to use <div>! #NotAllDivs are bad!" The main point is to avoid using a <div> in two cases:

When the contents of a block have a specific semantic meaning that has a designated HTML element (<address>, <nav>, <code>, <data>, etc.)
When you would add a block to your Table of Contents if you had one, in which case you should use <article> if the block is the root of an entire self-contained piece of content that can be understood on its own (a blog post, news article, forum post, Tweet, Instagram post, etc.), or a <section> if it's only a part of a larger document that wouldn't make sense on its own

If there's no appropriate semantic element, and the block isn't important enough for the TOC, then use a <div>! And if you want to convey more about the semantics than HTML explicitly supports, you can use RDFa or the itemtype attribute and related attribute with a schema.org schema to convey extra info.

Jacob Evans • Mar 26 '19

Very well done article. Really great points, I will probably reread the article again later. Thanks for the time and effort you put into this.

Itachi Uchiha • Mar 25 '19

Awesome! <3 Thanks Ken.

Riccardo Messineo • Mar 26 '19

Using this "new" tags, should we be anyhow concerned about compatibility?
Yes I am thinking about ie :)

Ken Bellows • Mar 26 '19 • Edited

Nope! All of the Semantic elements except for <main>, which was added later in the game, are recognized all the way back to IE9. And even if you're still supporting IE6 for some reason, the nice thing about HTML is that browsers are pretty forgiving, and they aren't going to error or anything if you use an unknown tag, though I believe the default display mode for an unknown tag is inline, so if you really are supporting very old browsers you may need to add this CSS

aside, article, footer, header, main, nav, section, .....(list all the semantic blocks you're using) {
    display: block;
}

This is included in most CSS reset files, which I strongly recommend if you're dealing with very old browsers, so you probably won't have to di this by hand anyhow.