Menu Search
Jump to the content X X
Smashing Conf New York

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 New York, 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 New York

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 New York, on June 14–15, 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 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.)

  2. 2

    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.

  3. 3

    “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

  4. 4

    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.

  5. 5

    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.

  6. 6

    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.

  7. 7

    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.

  8. 8

    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.

  9. 9

    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.

  10. 10

    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.

  11. 11

    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.

  12. 12

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

  13. 13

    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.

  14. 14

    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:

  15. 15

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

  16. 16

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

  17. 17

    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.

  18. 18

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

    • 19

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

      • 20

        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.

        • 21

          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.

  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.

  21. 36

    I’m sorry Divyia but you’re completely on the wrong here.

    Of course you shouldn’t spend hours nitpicking over what is the correct element (that should be a one-off thing anyway after your learn enough of the specification).

    But to say that “accessibility and semantic mark-up have very little correlation” is reckless. Do you test your pages with screen readers? We do, and it’s not pretty when you have a bunch of div tags wrapping everything. It’s like going back to table layouts, without the tables. Using the correct elements, attributes and structure makes a world of difference in accessibility.

    It will also make your pages more robust – you don’t know what technology will look like in 10 (or 2) years, so you better do your best to make your markup clear and understandable now. That’s why we have a specification to conform to. This attitude of “fuck it, everyone is doing it wrong so I will do it too” only does harm to our own future.

  22. 37

    My summary of the response.

    Divya: “Semantics, never proven to be valuable at an excessive level of detail”

    — “Semantics can’t be used at all?!! You’re crazy.”

    Do what feels right, but concentrate on adding value, rather than speaking obtusely about which tag is right.

  23. 38

    So what you’re saying is forget HTML and its new tags; use what you want, the way you want to use it. Sounds like the kind of developer I’d want on my team.

  24. 41

    I think the point is that in the long run semantics is about what is being used. HTML5 has added elements based on id’s and tags that were commonly used and removed elements and attributes that either didn’t work or were abused.
    The same will apply to the future. The success of any semantic element or construct depends on how we use it today. Assistive technology should not be used as a base for comparison since it isn’t “cutting edge”; it will only use what works, not what might work.

    As web designers and/or developers we are expected to know the tools that we work with. In that sense wasting time on choosing the right element is a lame excuse for not having read and understood the specs. But that does not mean that the specs have an answer for all practical problems. In the end the semantics of any element is based on how it is commonly used in the real world, not by how it is defined on paper.
    But that does not reelease us from our responsibilities as designers/developers, nor does it mean we should ignore the spec as a guideline. So in all I must disagree.

  25. 42


    November 11, 2011 3:22 pm

    Screw it, I’m going back to tables. :)

  26. 43

    “You’ve wasted 40 minutes, with no tangible benefit to show for it.”
    – on the other hand, you do now understand the difference between the div, article and aside elements, which means that you are now 40 minutes better educated as a developer, which should add long-term value to both you and your application.

    As with a lot of development, you should always make the decision about the balance between time-to-market and long-term maintainability based on business need rather than on the developer’s desire for “purity” or their unwillingness to improve their skills, or on some arbitrary deadline or schedule set by a middle manager somewhere.

    • 44

      Fully agree with Jon.

    • 45

      or equally you just wasted my time when i was reading this :D (The blog post i mean)

    • 46

      I think, the point was that there is no business or any other kind of value (it’s actually more efficient for the website to use old markup – no need for shims, classes already are faster for hooks than element selectors) that you gain from these 40 minutes. The knowledge about the difference in outlining algorithm is fragile as it’s a subject for debates.

      Of course having interest and will to go find out how things work is important, but perhaps you’d better spend this time learning JavaScript, new Web Platform APIs etc.).

    • 47

      Agree. Also, outside of front end development, I find it a lot easier to manage the dynamic content I create in PHP or whatever if I can do it with items such as article, aside and section. Those tags help to keep my thoughts organized on how the output should be styled when I am creating it. It also gives me a heck of a lot more variety in calling out DOMs with JavaScript if i want to have effect an object with the class of foo inside an article only. Rather than having to have DIV’s with extra classes on them. It makes for a lot cleaner code. In my opinion of course…

      Plus, if I am being honest, I think that those tags look cooler in my code and I like the idea of it. Sure, DIV’s work fine, and I still use them, but I sure do like the ability to use modern HTML elements and the bottom line for me is that once I started using them I had no desire to go back. Ultimately, do what works best for you. For me, the new HTML standards work fantastic and the more semantic my code is, the more compliments I get on it from the people I hand it off to.

  27. 48

    Rudolph Gottesheim

    November 11, 2011 6:49 am

    I get what you’re saying. And basically, I agree with you. But this article should not be on SM because many (if not most) people will get it the wrong way and say “Smashing Mag says it’s ok to flush all semantics down the toilet, so I’ll just use span and div for everything.”

    I’d love you to clarify that a bit (At the top of the article! Many people just read the first few paragraphs) since this is way too dangerous in its current state.

  28. 49

    Although I want to be able to see Divya’s point of view in this article, I find myself struggling.

    To me, semantic markup is about striving to achieve clean, well-formed, meaningful code that will (some day) hopefully be understood by browsers in a much bigger way.

    My biggest issue with this article is that it downplays the importance of code conformance and the idea that we should strive to write code that is easily maintainable by others.

    I consider myself fanatic in the way that I code. I always strive to write clean, semantic code whenever possible. I believe as a result of this, my code is much easier for others to pick up, understand and work with.

    I have worked with many developers who don’t understand the value of semantics and this is evident in the quality of their code. I believe developers should obsess over appropriate tag usage and placement – how else does one ensure a sense of quality when coding? It’s the lazy, nonchalant attitude of the semantic naysayers that promotes divitis.

    We should all be working towards one common goal – To write code that is or can be understood by browsers to some degree (either now or in the future). If we don’t make the effort to achieve code conformance now, it’ll be a long way off before the ‘semantic web’ dream is achieved.

  29. 50

    I wrote a response on my blog but I may as well copy/paste it here in the interest on discussion:

    The true value of a website is its content.

    Data — until semantics and presentation turn it into information. If that is true we can therefore infer that semantics reign supreme in front-end website production.

    The thing is, not all content is created equally. There needs to be a pragmatic interpretation of how content is represented. For most users of a web browser its all about what is visible. For those using screen readers it’s all about what is audible.

    We have multiple layers of content, and multiple presentations of the same content. We have semantic information that can be aggregated from HTML alone and visual content that offers support for visual users (which make up the majority of users, but not everyone). The visual style applied with CSS often changes content into a different form. For example, it can change a simple hyperlink into a visual button with a graphical icon. This icon has little value in the raw HTML where a link will suffice. We can also provide multiple versions of the same content, e.g. a video or animation with an alternative description, or better yet, a more thorough written transcript. In this case both versions of the content can be marked up in HTML.

    The whole reason for HTML semantics is to supply meaning in one specific regard when the content is accessed in its rawest state. It’s an accessible baseline. We can use CSS or JavaScript to enhance that content in presentation — a second level.

    There is nothing wrong with being a purist in terms of HTML semantics. That’s commendable. That’s future proofing your content, which is why I strongly disagree with the notions suggested in this article. You just have to realise that semantic HTML is just the first layer of accessible content.

    Website design is moving more and more towards visual, interactive presentation of content. That makes the accessible semantic HTML layer all the more important.

  30. 51

    Today you can take a *single* HTML file and develop a rich interactive website with visual effects, animations, and structured content. This can be consumed by a *huge* array of form factors, from touch devices nested in our pockets, all the way up to 10-foot experiences hanging in our living rooms. They can be navigated by using your finger, a mouse, even a strange input device you’ve never seen. There are blind people using our websites, there are quadriplegics navigating our websites with nothing more than eye movements and mouth pressure.

    It’s absolutely astounding, and exhilarating to realize the impact standards have had. During our day-jobs it can get frustrating that IE sucks, or a colleague challenged your usage of article, or you had to support some archaic edge-case. It will never be perfect, we live in an imperfect world. But collectively the web design world is pushing forward.

    I guarantee some some futuristic device will come along and add an entirely new dimension to our work that none of us will be prepared for. But that’s why we do this, right? And if we make standards important, we continue to make our work valuable.The pursuit of semantic value isn’t entirely measurable, but that doesn’t make it pointless.

    P.S If you’re spending more than 2 minuets figuring out whether to use article or section, I would just argue that you aren’t being productive.

  31. 52

    This is why I like to let the pros discuss and decide later on. Respecting the experts

  32. 53

    I’ve been struggling with this of late. I wrote this recently which is related

  33. 54

    Thank you!

    I use new elements like nav, header and footer because they make sense structurally. I use article where a li would not be appropriate, but other than that… the whole mess that surrounds the _semantic_ aspect of the new elements keeps me from even trying to use them.

    Because, yes, it does take 40 minutes to look things up.

  34. 55

    Agree. “Choose tools over philosophy” Chris Williams JSConf. “We need to start realizing that these are tool and treating them as such”

  35. 56

    Matt Tortolani

    November 11, 2011 7:29 am

    Didn’t expect this from someone at Opera.

    It really doesn’t take a lot of effort to learn the semantics behind each element. If you spend 40mins reading blog posts to decide what element you need to use on a regular basis you need to read a fucking book.

    • 57

      This post expresses my opinion Matt Tortolani. We at Opera do have very divergent views on this topic. This by no means represents an opinion of the collective at Opera.

      • 58

        Matt Tortolani

        November 11, 2011 8:44 am

        I totally agree with you for tight deadline situations. But, to me, it just seems lazy not to make the effort with these new elements.

        Once you’ve read a decent book/blog posts on the subject and actually understood it, your set

      • 59

        Matt Tortolani

        November 11, 2011 8:45 am

        I totally agree with you for tight deadline situations. But, to me, it just seems lazy not to make the effort with these new elements when you can.

        Once you’ve read a decent book/blog posts on the subject and actually understood it, your set.

      • 60

        But at least, someone at Opera should know that the benefits of Semantic Web are beyond a single tag or how lazy we are to learn the specs. Semantic Web is about the future of the Web and how new devices will read or code and understand it. Probably it is not happening now but it is better to build a future proof applications.

        As Web Developers we should be responsible to keep up with he technologies that we are suppose to be working with. For example, do you still use crazy DHTML from the 90’s? I believe no because you took your time to learn the best practices and now it is not recommended. The same will happen with HTML5.

        • 61

          Structural or “semantic” HTML markup has nothing to do with the Semantic Web (capital S, capital W):

          “TBL: It’s not about people encoding web pages; it’s about applications generating machine-readable data on an entirely different scale […] using the initial W3C Semantic Web standards for description (RDF) and ontologies (OWL). ”

          The Semantic Web (capital S, capital W) might be the future of the Web, but given it has – rather notoriously – failed to take off despite a decade of work by W3C, the assumption that it is the future could perhaps be best described as “brave”.

        • 62

          I think that you’re missing the fact that many of your fellow web developers disagree that the semantic web, as currently envisioned, is the future. You might disagree with us, yes, but that does not mean that we haven’t been following along. We just think that it is the wrong direction.

  36. 63

    Seriously, thank you for this! you have freed some dark corners of my daily mindset.

  37. 64

    I have to disagree here. If the reason for not using the appropriate markup is because “everyone else and their dog who are building websites doesn’t do it”, then we are missing the point. It is because we are professionals. Simply stating that the semantics of the web are broken and irrelevant feels a little like “I’m taking my ball and going home.” We should be building a web that makes the best use of semantics for future uses.

    What about blog aggregators that sniff websites for to look for interesting content, or browsers that start integrating content into the native app for better usability.

    Sure, it may take some time to learn the appropriate uses for new elements, but isn’t that our job? We work in a field that is constantly changing, and if we all decided that we were simply going to ignore those advances, we would still be using IE6.

    There are probably cases where the time saved ‘might’ be worth it (not sure about that). But I don’t feel that, as a general rule, we should abandon the structure of the web for poorly marked-up documents.

    • 65

      Except that this assumes, a priori, that the “semantic” markup in the current HTML5 spec is superior in some Platonic way. Some code readability (and, in turn, maintainability) benefits I can buy, but other than that, the “structure of the web” you mention is only hypothetical and contingent on a movement that isn’t materializing.

      Writing markup for software that no one will write is *not* a worthwhile use of time, and I see that eventuality just as likely (or more) than the one you envision.

  38. 66

    As long as it’s being added in a standards-compliant way, there is no reason to avoid adding semantic richness to content. It’s not being used *today*? So what?

  39. 67

    This article is right, but for all the wrong reasons.
    I’m just glad that the authors name isn’t Tableya.

  40. 69

    inadf, rjfsnsl nx pjd yt zsijwxyfsi jfhm tymjw. ny’x ymj xthnfq htsywfhy ns gjybjjs tzw nijfx. dtz fwj rncnsl uwthjxxnsl fsi rjfsnsl. vznyj xfi.


↑ Back to top