Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Our Pointless Pursuit Of Semantic Value

Update (November 12th 2011): Read a reply by Jeremy Keith1 to this article in which he strongly argues about the importance of pursuing semantic value and addresses issues discussed in the article as well as in the comments here on Smashing Magazine.

Disclaimer: This article is published in the Opinion column section in which we provide active members of the community with the opportunity to share their thoughts and ideas publicly. Do you agree with the author? Please leave a comment. And if you disagree, would you like to write a rebuttal or counter piece? Leave a comment, too, and we will get back to you! Thank you.

Meta-utopia is a world of reliable meta data. When poisoning the well confers benefits to the poisoners, the meta-waters get awfully toxic in short order.

Cory Doctorow2

Allow me to paint a picture:

  1. You are busy creating a website.
  2. You have a thought, “Oh, now I have to add an element.”
  3. Then another thought, “I feel so guilty adding a div. Div-itis is terrible, I hear.”
  4. Then, “I should use something else. The aside element might be appropriate.”
  5. Three searches and five articles later, you’re fairly confident that
    aside is not semantically correct.
  6. You decide on article, because at least it’s not a div.
  7. You’ve wasted 40 minutes, with no tangible benefit to show for it.

This Just Straight Up Sucks Link

This is not the first time this topic has been broached. In 2004, Andy Budd wrote on semantic purity versus semantic realism3.

If your biggest problem with HTML5 is the distinction between an aside and a blockquote4 or the right way to mark up addresses5, then you are not using HTML5 the way it was intended.

Mark-up structures content, but your choice of tags matters a lot less than we’ve been taught for a while. Let’s go through some of the reasons why.

The Web No Longer Consists Of Structured Content Link

In the golden days of the Web, Web pages were supposed to be repositories of information and meaning, nothing more. Today, the Web has content, but meaning is derived from users’ interactions with it.

XML, RDFA, Dublin Core and other structured specifications have very solid use cases, but those use cases do not account for the majority of interactions6 on the Web. Heck, no website really has the purity of semantic mark-up that such specifications demand. Mark Pilgrim writes about this7 much better than I do.

If you have content that demands semantic purity — such as a library database, a document that needs a table of contents, or an online book (i.e. anything for which semantic purity makes sense) — then by all means stick to the HTML5 outlining algorithm, and split hairs on which element should be an article and which a section. No customer-facing tool exists that takes advantage of this algorithm by producing a table of contents. No browser seems to exploit such tools either.

Is It Really Accessible? Link

If accessibility is your reason for using semantic mark-up, then understand that accessibility and semantic mark-up have very little correlation, due to the massive abuse of HTML mark-up on the Web. (I would love to link to Mark Pilgrim’s post on this, but it is dead, so this will have to do8.)

The b, strong, i and em tags are equivalent to the span tag as far as the specification is concerned9. And so are some of HTML5’s tags.

As stated on HTML5 Accessibility10, almost every new HTML5 element currently provides to assistive technology only as much semantic information as a div element. So, if you thought that using HTML5 elements would make your website more accessible, think again. (How much additional information do <figure> and <figcaption> bring? None11.)

The recent debate (or debacle?) on the <time> element12 is just more proof of the impermanence of the semantic meanings associated with elements.

Is It Really Searchable? Link

If SEO is your grand purpose for using semantic mark-up, then know that most search engines do not give more credence to a page just because of its mark-up. The only thing recommended in this SEO guide from Google13 is to use relevant headings and anchor links (other search engines work similarly). Your use of HTML5 elements or of strong or span tags will not affect how your content is read by them.

There is another way to provide rich data to search engines, and that is via micro-data14. In no way does this make your website rank better on search engines; it simply adds value to the search result15 when a relevant one is found for your website.

Is It Really Portable? Link

Another much-touted advantage of the semantic Web is data portability. Miraculously, all devices are supposed to understand the semantic mark-up used everywhere and be able to parse the information therein with no effort. Aryeh Gregor puts that myth to sleep16:

… +Manu Sporny said that semantic Web people had received feedback that out-of-band data was harder to keep in sync with content. I can attest that in MediaWiki’s case this isn’t true, though… The only times I can see where you’d want to use RDFa or microdata instead of separate RDF is if either you don’t have good enough page-generation tools, or you want the metadata to be consumed by specific known clients that only support inline metadata (e.g. search engines supporting or such). If the page is being processed by a script anyway, and if the script author has ready access to server-side tools that can extract the metadata into a separate RDF stream, then it’s normally going to be just as easy to publish as a separate stream as to publish inline. And it saves a lot of bloat on every page view.

What Now, Then? Link

  • There is no harm using div elements; you can continue using them instead of section and article. I think we should use the new elements to make your mark-up readable, not for any inherent semantic advantage. If you want to use HTML5 section and article tags to enhance some particular textual documentation for a future document reader, do it.
  • Tools exist today that take advantage of the nav, header and footer elements. NVDA now assigns implied semantics17 with these elements. The elements are straightforward to understand and use.
  • There is good support18 for ARIA landmarks in screen readers, but be careful19 when using them with HTML5 elements.
  • HTML5 has a host of new features20. I think we should learn about them, use them, give feedback. Make these features more robust and stable. Yes, most of these features require that you understand and write JavaScript and expose features that create a richer experience for your audience. If that task sounds formidable to you, then start learning how to code21, particularly JavaScript.

What do you think? Link

This article is published in the Opinion column section in which we provide active members of the community with the opportunity to share their thoughts and ideas publicly. Do you agree with the author? Please leave a comment. And if you disagree, would you like to write a rebuttal or counter piece? Leave a comment, too, and we will get back to you! Thank you.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook


Divya Manian is a web opener for Opera Software in Seattle. She made the jump from developing device drivers for Motorola phones to designing websites and has not looked back since. She takes her duties as an Open Web vigilante seriously which has resulted in collaborative projects such as HTML5 Boilerplate.

  1. 1

    I’ve been waiting to read something like this for ages! The whole time thing seemed like a complete waste of energy to me.

  2. 2

    I totally agree ! I have had the “Screw you guys, I’m using divs”-feeling quite a few times now already.

    • 3

      I’ve not just had the feeling – I’ve been doing it since the beginning. I just saw no real benefit.

      • 4

        Dennis Jenders (@djenders)

        November 14, 2011 8:00 am

        Wow, I am surprised at how many folks agreed with this. As a digital strategist, and former front-end developer, there are many reasons we want to encourage the use of semantic tags.

        One of the primary reasons? The ability to have you content better organized and likely indexed appropriately, pulled into news readers and tablet applications like Instapaper, as well as the benefits to the organization.

        And if you are a news resource there is absolutely no reason for NOT using this markup. We live in an era where the more semantic data the better. Structure and especially micro-formats should be tools every developer uses going forward.

        This is a ridiculous opinion article. It just appears the purpose of publishing it is so lazy developers can agree and have something to link to so they can explain their feelings.

        • 5

          It’s not ridiculous, and we are not being lazy.

          There are still companies that require developers to support back to ie6.

          I know it might sound shocking, and it is getting better, but what about ie7? or ie8? These browsers certainly don’t understand html5. While more advanced browers such as safari, firefox, and chrome support html5, it is still shotty for Internet Explorer.

          I do agree that we should start using these elements, and I fully support anyone who uses html5, but html4/xhtml1 are the current standards, and practically all browsers/devices support them.

  3. 7

    I guess I waste about a couple of seconds to choose the right tag (including article, section, aside and div), I really don’t think that should be an issue!

    Of course, if you *do* waste 40 minutes to pick it up I fully agree, go with div. Or (better, IMHO) learn how to pick the right one in 2 seconds.

    (I know, there may be ambiguous cases… but 99% of the times the choice is pretty straightforward.)

  4. 8

    I really don’t see this as a semantics issue. If your argument is that there is no benefit in identifying the type of content with an appropriate tag, then you are just plain lazy…

    All of your arguments for no benefits in accessibility and portability (which are basically the same thing) are very weak and one sided. Sure, we can use object or embed or iframe to post videos to our blogs (if we feel like it), but why wouldn’t we spend 40 minutes to research the use of the video tag to provide native support to the users? Are there not significant benefits to it?

    We are on the same page regarding the SEO / microdata, good job there.

  5. 9

    “You’ve wasted 40 minutes, with no tangible benefit to show for it.”

    If you will use your 40 minutes wisely to read good links. it will be useful in current and future project. You will have to invest the time to understand the use and importance of new tags once.

    And do you mean that we should not use new tags until HTML 5 reach to final recommendation. and how we can know that which element can be removed later and which not, I cannot use DIV just because of this reason. And even any elements get changed I will do Find and Replace to replace later.

    I think Semantic coding is also good to show our content in RSS readers

  6. 10

    Interesting points but I’m not sure I agree particularly. The argument that using a ‘div’ avoids 40 minutes of soul searching deciding between ‘aside’ and ‘article’ seems a bit over the top to me, you could argue that naming anything with meaning is a waste of time as you should just call them div1, div2 etc.
    Using the same argument, why learn anything new when you are ‘unsure’ about it, why not just stick with what you know?

    I agree with some of the comments here which mention that anything which keeps meaning to the code from a development point of view is a benefit. Finding appropriate sections in code is easier and quicker if you automatically know that the CSS you want will be under ‘header { }’ rather than some random name the dev before you used.

    Using specific elements can enforce default implementations such as ‘this is a block level element, this isn’t’ which again can be overrridden, but do imply that a certain element should be used in a certain way and give developers some hints that particular hierarchies should be avoided.

    I would also argue that using specific elements rather than generic ones allows more specific rulesets to be applied to them and therefore give more consistent behaviour accross browsers. You can go some way to insisting that particular elements have certain properties, ‘img’ tags with ‘alt’ attributes for example and whilst not always obeyed, it does provide a framework for ensuring a bare minimum in the code which browsers encounter.

  7. 11

    Correct me if I am wrong, but in your opinion it is better to accept the status quo than to challenge it? There is much that *can* be gained from a more semantic web, if we all accept that this would never happen then you are right, but I am not willing to accept that at face value.

  8. 12

    Today, the Web has content, but meaning is derived from users’ interactions with it.

    And I might have completely misunderstood your point, because I read your post in random order and perhaps misunderstood some of the responses to be part of what you said and vice versa.

    But as meaning is derived from my interaction with the content, then I think that my assessment that you’re backward-thinking and shortsighted is on target.

    I think others might have said this, but it bears repeating: Coding your website, and especially web apps, for what assistive technology supports today would be like being Steve Jobs in 1975 and deciding that, since everyone is still using IBM Selectrics to produce information, there is no point in playing around with circuit boards in the garage, so you’ll just go back to your schoolwork and make sure you get that degree.

    Build for the future. It will be here before you know it.

  9. 13

    Bernardo Presser

    November 11, 2011 10:49 am

    Maybe you should check out Tim Berners-Lee talk on TED about the future of the web. Very inspiring.

    When I’m “wasting” 40 minutes trying to find the right tag to wrap my information, I’m not thinking about TODAY’S web. I’m thinking about it’s future, when bits of data can be found, matched and combined, thus creating a richer content for those seeking information. Sure, this does not apply to every website out there, but as designers and developers is our role to try and organize in the best way possible the mess of data of today’s web.

    The great thing about advances like HTML5 is not that we can write more semantical code for future developers to use. We can write content for future technologies and user behaviors.

  10. 14

    I couldn’t disagree more.

    Re: spending 40 minutes looking up the best practice for using , yes that can be the case in 2011 when we’re still learning how to use HTML. But in due time we will become used to it. You don’t spend time wondering whether to use a or a , do you? No, because you’ve done it a million times and you’ve built an intuition.

    Re: accessibility, SEO, and whether machines care — it’s a chicken/egg problem. A screen reader, for example, can’t rely on the new HTML5 elements *yet* because they’re not in wide enough use. It has to assume you’ve coded it the old way, with tons of meaningless s. But eventually if we all use the elements properly and come to a consensus about their usage, it will be a real boon for machines attempting to interpret our structure. If you just keep using s it will never get better.

    Then there’s the issue of what will become of your code. Suppose it’s 2023 and some new markup language Foo has supplanted HTML and you’re looking to convert your documents. If you used all plain s, Foo will have no idea what you meant to convey. But if you used s and s and so on, Foo will have a pretty good feel for your intended structure. And of course there are also other coders who take over your work, or someone looking to improve your site with a new script, who will have quite a headache wading through div after div, each one looking the same.

    Last but not least, there’s something to be said for doing things the right way. It’s likely that good semantics written now will pay off later. But even if they’re not, it does feel good to know you’ve done your job correctly and didn’t just lazily re-use what you already knew instead of learning something new.

  11. 15

    There are a few issues with the logic of the piece:

    The two questions attempting to disarm the benefits of the new semantic elements aim at pitting what search engines and accessibility-assisting technologies are *currently* doing, versus what they will be doing in the near-future. Just because the accessibility-assisting technologies don’t differentiate between article and div doesn’t mean that they will never do this.

    Also, the argument about pleasing the client: there are many dimensions to this. Another developer may pick up the code (in your company or another) and more-well-defined semantics will help them learn your markup structure. The trade of is: getting the project done today verses “doing it right” – allowing your team to continue to please the client over time.

    Moreover, the whole spirit of this article is that at the conclusion of the 40 minutes, you’ve wasted time, and have nothing *apparently* to show for it… What about the pride gained from mastering another dimension of your craft? What about the satisfaction from a job-well-done? What about knowing that your product will stand up to the scrutiny of “view-source:” and other colleagues’ peering eyes!? Surely the intangibles matter…

    Learning the new elements should be *at most* one-week worth of learning and practice.

  12. 16

    Divya, I really do agree about the fact that semantic markup, at this point, doesn’t have a boatload of advantages. For me… it comes down to one thing: if I have a choice between using divs for everything and using new elements that hint at context and importance of my page content, then why NOT? If the advantages are negligible as you say, then I would much rather opt for the route that allows me to write code that I can more easily read through as a developer AND will potentially put my code ahead of the game once we start to see increased use for parsing semantic HTML5 elements.

  13. 17

    Regarding your comments on accessibility, the fact that (currently) many new HTML5 elements only provide the same semantic information as a DIV does not at all mean that this will be the case forever. Would you use the same flawed logic to argue we shouldn’t be wasting our time with any of the new form input types, either? Many new form inputs aren’t well supported by most browsers. Do you suggest that we shouldn’t use them? That’s just plain silly. Just as browser vendors are working towards better support of HTML5, so are assistive technology vendors.

  14. 18

    True, you may waste 20 minutes (40 seems a bit much for simply browsing google results) the first time, but next times you’ll know what to use (which is why I keep research like that for my allocated 20% R&D time that I force myself to take every week to stay up to date).

  15. 19

    As I read this article with my custom user style sheet, that made it visible to me, I thought, “What a narrow view of semantic markup”. Author, you worry too much.

    I find , and a convenience. There is a little too much worry about purity here and too little worry about the underlying purpose.

    Make no mistake, semantics are core to solving accessibility. Prior to the introduction of semantics to the GUI many programmers were just shut out. These were people, including me (visually impaired since birth), who had adapted to the command line interface and were accomplished in computer science. With the GUI we suddenly found that we could not use a computer anymore. Many great programmers came together and created the accessibility API’s that translated the graphical mess into semantic markers that could be transcribed into language based interfaces. Some of those people were involved in writing WAI ARIA.

    Accessibility is about translation of perceptual and operational interfaces into alternative medias. It is translation, and hence requires semantic preservation. The more semantically deterministic the interface is, the more accessible it is.

    The fact that assistive technologies employ heuristics to get around ambiguous encodings does not mean that assistive technology prefers ambiguity or that AT can overcome all ambiguous data. A deterministic interface really is necessary for realistic accessibility.

    Worrying too much about whether you use an or an misses the point. Both convey the concept that presentation is changing to convey subtle change in meaning. Both trigger assistive technology to flag this change in a media appropriate way. The vs is a great example. If you really have an article then is better than , but it is no deal breaker. still says, “I want you to think of this content as a group”.

    I think you need to relax. Semantics are very important to people with disabilities. The point is to do your best, and don’t call a an because you have some kludged up reason to do it. But, don’t worry about honest disagreement.

    It is always easier to translate language defined semantics than author defined semantics. That is why the element level communicates much more deterministic information than the attribute level. There are many good heuristics, and many unofficial conversions, but these cannot protect against periodic false translation in an alternative media setting. Only language defined semantics can guarantee against false translation. So, use language semantics as much as possible, and get creative when the simple approach fails. And, don’t worry about it excessively. If you minimize neutral semantics, most AT can function.

    In the scope of HTML the and are good things. They provide containers that let us define semantics that exceed the base language. They always will be necessary, with HTML 5, HTML 6, … HTML forever. Use semantic elements when you’re pretty certain and semantically neutral containers when you are in doubt. That will be enough. The semantically neutral container will still send a useful flag to the AT.

    Wayne E Dick PhD
    Professor Emeritus
    Computer Entineering and Computer Science
    California State University, Long Beach, CA.

  16. 20

    Similar to article regarding its semantic use and validity is section. I’ve seen it used in a variety of different situations just because it’s HTML5 or because they didn’t know what they were doing. Anyway, at this point is not even a question of semantic validity, it’s more a question of reading the docs and not making it up: as it turns out the HTML5 draft specifies that section is not a replacement for div nor a more loose alternative to article:

  17. 21

    If the link is dead, check if it is in the Internet Archive:

  18. 22

    James Williamson

    November 11, 2011 2:28 pm

    Divya, I have a huge amount of respect for you, and appreciate your many contributions towards making the web a better place, but I disagree with you here. I appreciate the fact that you’ve forced the discussion on semantics away from the utopian dream of “the semantic wonderland” to focus on “what we gain from it at the present.” For the most part I agree with your take on what it’s worth at the moment. However, I disagree with it in regards to the future benefits we’ll gain from semantically-crafted sites. The improvements in Internet Explorer are a direct result of web designers and developers embracing standards and adopting browsers that did the same. Imagine the mess we’d be in right now if Netscape and IE had been allowed to continue dictate which markup and features to use.

    Dismissing the value of semantic tags by pointing out the poorly defined nature of article, aside, and section is, in my opinion, short sighted. Yes, many of the new tags in HTML5 seem to be very “blog-focused” (what, no comment tag?), and the fact that even Bruce Lawson seems to be confused by when to use an article .vs a section doesn’t mean that the overall vision of a more semantic markup language is invalid. I’m not surprised that browsers and search engines haven’t made a huge effort to take advantage of the new structural elements. The HTML5 outline algorithm continues to evolve, and as you correctly pointed out with the time debacle, the dust hasn’t quite settled on what, exactly, everything means.

    That doesn’t mean, however, that it’s always going to be this way. Most of the focus in this discussion has been on current and probable future support of semantic tags by browsers. However, in the very near future browsers, as we understand them now, will not be the primary means of accessing web content. It’s easy to imagine devices in the future that aren’t interested in the full content of my page, but only on seeing if I have specific content for specific needs. By giving new devices consistently structured code with additional semantics, we make it easier for those types of devices to be developed and implemented. In fact, if the main argument against this is that the necessary semantics doesn’t exist for this to happen, then the fault likes with the specification, not the designers or developers.

    By embracing semantics and micro-formats, and encouraging and educating others about their use, I hope to be a part of the movement towards a web that has richer meaning and increased capabilities for the user.

  19. 23

    Interesting points raised but not sure if I fully agree with what you’re saying.

    If you are making websites that you don’t mind having no real structure then yes, why worry about semantics; but semantics are core to structure IMHO. When it comes to styling a site, making sure elements, classes and IDs are semantically correct we can style the page accordingly (minus the use of names that describe style). It allows the web to be more open with data allowing people to plug into that for what ever their needs; so if the element is used then developers can plug into that data easily for what ever reason (such as a calendar plugin for Firefox that grabs dates from a site and adds it to your iCal cannot be achieve so easily if we have a with no real semantic name).

    There shouldn’t be any time wasted sussing out if something should be A or B (possibly C) as it is counter productive, but a good developer should understand their structure and the purpose of each item thus knows what is the semantically correct element to use.

    • 24

      Classes and IDs are definitely not harbingers of semantic information. They are there to enable you to style your content or manipulate them but not to provide information about them. That should be done using microdata. The problem with understanding the meaning of new elements is that the meanings change frequently (e.g. time, or b or cite). You cant assume something and claim that to be valid forever.

      • 25

        I’m not sure. I see the HTML markup as a whole, so elements such as and do carry the same weight as class=”additional” and id=”main”.

        The main thing is, I believe, we should structure a document as if there is no style (to separate content from style), that means we do need to take semantics into consideration as a whole as it does help us, so if there is a element that suites our needs better than a class/ID then it’s probably better to use that. It also creates a certain amount of standardisation (which has it’s own points and counter-points in web).

        HTML5 is still in development so I see your point about it not being valid forever, but a site should try and grow with the web, so if elements become invalid then we should alter them to the valid attribute. If we stick to what is current at our disposal then surely we are becoming more reactive than proactive and thus not trying to engage things forward?

        Not trying to say your wrong, I just see things differently :)

      • 26

        Divya, HTML5 is still in development. It’s *likely* to change. That’s what the process is about. If you want stability, use an existing standard. Once the HTML5 standard is set, then those meanings will not change, just as they haven’t in existing standards. That’s the whole point of a standard.

        • 27

          Perhaps you haven’t heard yet — according to WHATWG (who took over HTML while W3C were busy with their XML crusade and foisting XHTML on us), there is no “HTML5”. They’ve said HTML will be a “living standard”; that is, it’s not going to be versioned at all, and it will constantly change as browsers do. If your argument is that it’s not “set” yet, then hang it up now, cause it *never will be*.

      • 29

        Identifiers and classes should *only* provide information to content by referencing its relevance. It should and never be descriptive of the style/design. This is why we don’t use “clearfix” as a class.

        The pursuit of semantic value is the pursuit of longevity.

    • 30

      I think you are conflating a sematically queryable website that can reveal data *about* its content with the semantic structuring that is interpreted in browsing. Read about SPARQL – if you know about that then i may be wrong ;)

    • 31

      With elements having multiple purposes within the specification though, how can you be sure you are actually using the most semantically correct element?

      My biggest argument to not using HTML5 is support for screen readers. We are going to have to support two different document outlines if we adopt HTML5 which is quite a big ask considering how HTML5 envisions how users markup heading elements going forward.

  20. 32

    I’d say more meaningful code is easier for a another developer to pick up and maintain. I’m sure we’ve also come across DIV soup numerous times and have been left scratching our header, wondering what DIV is what.

    More semantic elements also give is the opportunity to make our code a little more succinct. For example, using an article tag instead of a div.article not only makes your HTML a little more streamlined but also helps keep your CSS a little tidier.

    I think the real issue is the ambiguity surrounding some of the new elements, which Divya has quite rightly pointed out.

    • 33

      There is also efficiency – if you dig through the codes of websites where performance is critical you will see that they mostly use short class names to hook CSS and JavaScript – that’s because referring by element selectors is slower. Of course it wont make huge difference for a little landing page, but in a web app it’s going to be an important point (also, “div” is shorter than “article” => less bytes, faster download).

      • 34

        Misha – using shorter tag names used to have an effect in the 90’s – but with gzip/deflate compression you’re talking about four extra bytes in the compression table.

      • 35

        Oh don’t bother closing br tags either saves some bytes.


↑ Back to top