Our Pointless Pursuit Of Semantic Value

Advertisement

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

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

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?

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?

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?

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 schema.org 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?

  • 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 JavaScript22.

What do you think?

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.

(al)

↑ Back to topShare on Twitter

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

    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: http://dev.w3.org/html5/spec/Overview.html#the-section-element

    0
  2. 2

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

    0
  3. 3

    If the link is dead, check if it is in the Internet Archive: http://www.archive.org/

    0
  4. 4

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

    0
    • 5

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

      0
      • 6

        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.

        0
        • 7

          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.

          0
  5. 9

    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.

    0
    • 10

      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.

      0
      • 11

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

        0
      • 12

        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.

        0
        • 13

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

          0
      • 15

        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.

        0
    • 16

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

      0
    • 17

      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.

      0
  6. 18

    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.

    0
    • 19

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

      0
      • 20

        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.

        0
      • 21

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

        0
  7. 22

    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.

    0
  8. 25

    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.

    0
  9. 26

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

    0
    • 27

      Fully agree with Jon.

      0
    • 28

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

      0
    • 29

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

      0
    • 30

      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.

      0
  10. 31

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

    0
  11. 32

    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.

    0
  12. 33

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

    0
  13. 34

    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.

    0
  14. 35

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

    http://mistermorris.tumblr.com/post/11692729680/the-rise-of-the-confused-machines

    0
  15. 36

    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.

    0
  16. 37

    “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

    0
  17. 38

    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.

    0
    • 39

      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.

      0
      • 40

        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

        0
      • 41

        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.

        0
      • 42

        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.

        http://www.w3.org/standards/semanticweb/
        http://semanticweb.org/wiki/Main_Page

        0
        • 43

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

          http://www.consortiuminfo.org/bulletins/semanticweb.php

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

          0
        • 44

          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.

          0
  18. 45

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

    0
  19. 46

    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.

    0
    • 47

      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.

      0
  20. 48

    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.

    0
  21. 49

    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?

    0
  22. 50

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

    0
  23. 52

    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.

    0
  24. 56

    Use the new elements to make your mark-up readable, not for any inherent semantic advantage.

    The flaw in the article surfaces in this sentence. To make the mark-up readable for whom? An user who is sighted and looking at the content through the filter of cascading style sheets? A blind user listening to the page through a screen reader? A developer who has inherited the markup and is trying to figure out WTF the previous developer’s intentions were? An algorithm contained within a program which parsing the page for use by another application? All of the above?

    The word “semantic” has as its root two Greek words “significant” and ”sign.” The WWW is the first publishing platform intended to be readable by both humans and machines. The fact that we haven’t built machines that can even begin take full use of the significant signs (HTML elements) shouldn’t stop us from hand wringing how to use them.

    I think the reason we have a Web which is now dominated by commonly held standards is that a few principled designers insisted on consistent open standards and spent time picking over the bones and calling browser developers to account.

    0
    • 57

      I do not see what the flaw is. Screen readers do not assign any new meaning to the new elements than divs as I mentioned in the post. The markup is readable for those who work with the markup basically the developers who are trying to scan the lines of markup to work with.

      These days I recommend people work with tools that compile to HTML rather than raw HTML itself.

      Your point that we have not built machines yet to understand significant signs exactly proves the point I am making. We have spent more than 15 years trying to make our content more ‘semantic’. And we have gone no where. There is a balance between using what is practical, having relevant tools and using a new element just because it is the most semantically pure one out there with no practical applicatons.

      0
      • 58

        Saying ‘we have gone no where’ undermines your own statement that header, footer, and nav are good because they are being put to use and easy to understand. If we truly havent gone anywhere, you wouldn’t have been able to say that. Heck, we wouldn’t be making a transition from HTML4.01 to HTML5 at all, right?

        0
        • 59

          Ankur, I think you’re missing Divya’s point. The reason that header, footer, and nav are good is because they’re readable and easy to maintain (from a developer standpoint).

          Her point in the article (and she’s right, so I have no idea why her comment above yours got so many down votes) is that machines don’t understand them, so from a machine-reading standpoint, they’re useless.

          But, on the other hand, markup that uses header, footer, and nav is more readable (by developers) than one that uses “div id=header”, etc. So, although there is some semantic value to using some new elements, that value doesn’t extend to machine-readability.

          0
      • 60

        “These days I recommend people work with tools that compile to HTML rather than raw HTML itself. ”

        Compile HTML? I’m a little confused to what you’re referring here, could you elaborate a little please?

        0
      • 62

        What tools would those be?

        >These days I recommend people work with tools that compile to HTML rather than raw HTML itself.<

        0
      • 63

        Try telling those in the bioinformatics and other crucial fields that semantic content has “gone nowhere.”

        0
  25. 64

    My friend @RyanButtrey just tweeted this http://html5doctor.com/wp-content/uploads/HTML5Doctor-sectioning-flowchart.png, it should solve the 40 min dilemma.

    0
  26. 66

    Amen! Unless you’re doing it for a hobby, building a website for a business has its priorities – benefiting the business. I think a relatively good developer (and I’ve had quite a few working for me over the past several years) knows how much and in what fashion to deviate from the so called *norm*. It’s not just about a 40 minute decision. Over the course of a project, there are several such decisions. That’s where experience plays an important role.

    Kudos Divya! Good article.

    0
  27. 67

    I remember having the following debate with a VP of Dev Engineering:

    Me: We should use CSS for layouts.
    VP: Why? Tables work and I understand them.
    Me: CSS is easier to maintain, and will reduce time spent fixing layouts.
    VP: But IE.x doesn’t fully support CSS.
    Me: IE will eventually catch up. In the meantime we can make it work.
    VP: I think we should just keep doing it the way we are. If IE comes around we’ll go with CSS.

    I left that job because I didn’t want to continue working with the methods of the last century. You say that assistive technology doesn’t get meaning from the new semantics, but that doesn’t mean they never will. Who’s to say that the work you do today won’t be around in 5 or 6 years when the clients can benefit from the semantics?

    Progress means moving forward. In this business, if you are standing still, you’re falling behind.

    0
    • 68

      This has nothing to do with tables vs layouts debate. Using div instead of a section or article does not make your code several times larger, more unreadable or unmaintainable and completely incomprehensible to all browsers or assistive technologies.

      0
      • 69

        You missed the point. You are making the same argument against semantic markup, that others used against CSS for layout. Namely, client (specifically IE back in 2001) support or the lack thereof. The spirit of your argument is that we shouldn’t bother with new technologies, because clients don’t take advantage of them. I disagree.

        If web designers like Doug Bowman hadn’t pushed the envelope at Wired, CSS layouts would have never been widely adapted. Don’t be so quick to dismiss the new just because it is unfamiliar.

        0
        • 70

          Except, much like others, you assume that tags like aside bring an advantage. Her argument also sounds like many of the arguments against XHTML. Whether or not you think the wrong side won that debate, the reality is that most “new technologies” fail, and pushing a failing one because the dogma seems right can be just as wrong.

          0
        • 71

          Yeh – she really did miss that point!

          I completely concur Mr Wong – I get where you’re at :)

          0
    • 72

      Where we need to be careful is progress for the sake of progress.

      If everything changes every 3 years and there is constantly a new cutting edge being shouted about from every conference venue then no front end developer will ever be unemployed.

      I remember not so many years ago front end developers going on about the importance of making content and layouts resizable cross-browser when clients didn’t handle this well natively. I wonder how many hours and client dollars were wasted chasing that trend which was ultimately made pointless by browser innovation and standardization.

      0
  28. 73

    I couldn’t agree more. To me, the most important thing is to make the code readable for future maintainers.

    0
    • 74

      And what do you think is more readable for future maintainers? A whole lot of divs and spans or actual semantic tags? Specially on the closing brackets…

      div
      div
      div
      … content …
      /div
      /div
      /div

      vs

      article
      footer
      p
      … content …
      /p
      /footer
      /article

      0
      • 75

        And if you read the article, she actually supports this exact use case. The question is, what are “actual semantic tags”?

        If I come in later, change content within a subsection, and the office debates whether it is now an aside or a section, we have not only introduced a net negative to our workflow and wasted time, but we are also demonstrating exactly how little the semantic difference matters.

        In other words, it is not all or nothing, with emphasis on the “it is not all.”

        0
  29. 76

    Back before the proliferation of HTML5 in 2004 Mike Davidson wrote a piece that pretty much nailed the “This Just Straight Up Sucks” part of your post. It’s about other frustrating things that existed in HTML4 and XHTML, but it could very well apply to HTML5 when discussing the new elements and the the ever-metamorphosing strict semantics behind them.

    However, I think just because the Web doesn’t completely abide by the semantics specified in the specifications doesn’t mean we shouldn’t strive to make our code as clean as possible or as semantic. My philosophy on Web design (and the philosophy of those who started the Web standards movement to begin with) is that the code should be as beautiful and efficient as the design. You can argue whether we’ve really progressed when you view the source of webpages that contain 60 different jquery libraries just to display stupid eyecandy, but that’s for another discussion. There’s nothing wrong with striving for perfection. That desire for perfection has gotten us to where we are now.

    0
    • 77

      “That desire for perfection has gotten us to where we are now.” — I love that.

      I think part of the problem people (myself included) are having with adopting all of these new semantic elements lies in the fact that when they view the source, they actually expect to see divism. And when they see something else, they regard it as a sort of hipsterism — or showing off.

      I deal more with interactions, so I don’t get to spend as much time as I’d like on semantic markup, unfortunately. I’d really like to be able to fully grasp it and use elements with confidence.

      0
  30. 78

    What about future proofing for browsers and screen readers that don’t yet but eventually will support the questioned HTML5 specs? Are we supposed to just change everything when they eventually do? This is a backwards way of looking at semantics. That’s like saying don’t use CSS3 because only *some browsers support certain features..

    0
  31. 79

    This articles reminded me this article http://www.viget.com/inspire/html5-elements-irresponsible-choice-right-now/ though it’s bit different.

    0
  32. 80

    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.

    0
  33. 81

    Many times I feel like giving up and long for using XML with XSL transforms where I can create pages as I wish but supply to search engines and other data gathering apps RDF or microdata that they understand. Trying to create a standard for human understanding has proven to be very difficult so far.

    0
  34. 82

    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.

    0
  35. 83

    Sigh. This is the kind of article that will be used by people to further polarise their views. “I knew I shouldn’t bother trying to learn the new HTML5 tags” and so on.

    I don’t think this is the intention of the article, but it will be the outcome.

    This echoes of “why you shouldn’t bother with test-driven development” with quality arguments such as “it takes longer”.

    0
    • 84

      I think a balance can be found. Let’s use HTML5 but not get so carried away that nothing works in IE7. But at the same time, let’s not just and everything to death without a second thought. I’m hopeful.

      0
    • 85

      Vitaly Friedman (editor-in-chief of Smashing Magazine)

      November 12, 2011 6:24 am

      I sincerely apologize for any confusion the original article might have caused. The style and tone of this opinion piece is different compared to other articles published here at Smashing Magazine. We could have done a better job at polishing its “edges” making the original intention of the article clearer. Divya does raise some valid points and concerns and I believe that it has been our editorial mistake that we haven’t set the right tone and style for it. We will do our best to prevent such mistakes from happening do a better editing job in the future.

      0
      • 86

        Regardless of whether some, or many, people do not agree with the article, I find it worrying that the Editor in Chief promises to “prevent this in the future” and “polishing” the article a bit more next time. That’s censorship bollocks: Are we supposed to publish and read only articles we agree on? That’s not how the world advances you know. Unless the earth is flat or something.

        0
      • 87

        Or hire authors that don’t write with a confusing style.

        0
  36. 88

    Derek Featherstone

    November 11, 2011 9:26 am

    Regarding the accessibility side of things and the fact that many of the semantics of HTML5 aren’t currently supported — that may be the case now, but that won’t be the case forever. Browsers and assistive technology will get to the point where these new HTML5 elements such as figure and figcaption, nav, aside, article, header, footer, etc will have meaning and be more useful than a semantically neutral div.

    0
    • 89

      Precisely. And that’s what being Future Friendly is all about. It’s not about the now, it’s about thinking intelligently about the future. If we’d have done that to begin with, we might have avoided the whole tables and spacer gifs and IE dominance era.

      0
  37. 90

    Hi Divya,

    When I saw the title of this article in a tweet this morning, I thought it was about the use of classes and IDs, but it’s not (somebody needs to write a piece about that though). Ignoring semantics when choosing class and ID names is something I can understand, but HTML elements (not tags)… I don’t think so ;-)

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

    As others pointed out already, learning something through the process is not a waste of time (far from it).

    Screen readers do not assign any new meaning to the new elements than divs as I mentioned in the post.

    Not yet! But that will change and who wants to write his code twice?
    I think we should not write markup and css according to browser support, but to specs? Let’s take vendor prefixes as an example, authors include the non-prefix version even though they know that no UA use it yet. But it causes no harm and it is future proof.

    It is because screen-readers do not make any difference between article and div that we should use the former. Using div is of no benefit today, and will be of no benefit tomorrow.

    The way I see things is that – ultimately – content should be marked up the same regardless of who authors a document.

    0
  38. 92

    So, basically, what you’re saying is that the whole foundation of HTML is pointless. Heck, the name itself is pointless. There’s no value on marking something as an article if you can use div, right? … And that’s a markup language how?

    You see, the whole point of using semantically correct elements (and to create Hypertext MARKUP Language in the first place) is to give meaning to an otherwise meaningless bunch of text and objects. Separating things from their most basic forms (paragraphs, emphasized text, ordered list, etc.) to more organized groupings (articles, sections, navigation blocks), markup languages (like HTML) are here to specify exactly what each thing is. That is what a markup language is all about. Advicing people not to mind what element to mark their content with while using a markup language is… well, bad advice.

    Yes, there might not be tools that actually take advantage of these; and yes, it is a pain to think over what element you use; but using them will make the web a better, easier to work (and interact, which according to you is what gives content all it’s semantic value) and most importantly, a more organized place.

    Someday there will be software that actually takes advantage of these technologies. That indexes content accordingly to their markup text.That increases accessibility and makes it easier for people with a disability. What we need to get there? Start doing things right.

    0
    • 93

      Exactly. Imagine what a mess we’d be in if the only tags were div, span, a, table, and img. Everything else is just a derivative of those, right? Who needs paragraphs anyway!?

      0
    • 94

      “markup languages (like HTML) are here to specify exactly what each thing is”

      I’m sceptical of HTML5′s role in the future of the semantic web. Elements like “aside” and “article” only vaguely define the content on a page but in order for mark-up to be useful for machines, it needs a level of semantics that HTML doesn’t offer. This is where micro-formats should come in. If you are concerned with making your content accessible to machines, you need to structure the content specifically for those machines.

      Screen readers will probably, eventually benefit from the new HTML elements so I don’t think that making the decision to use them is useless. But the end consumers of that content are still human. And humans don’t require the same level of detail that a machine does.

      Whenever I hear talk of search engines eventually using HTML5 elements as a guide to indexing web pages, I think of the old meta-keyword element and how easily that was gamed. If search engines don’t even trust developers to use heading elements (H1, H2) appropriately, why would they trust them to properly use “article” and “header”?

      The developer needs to know their audience and make realistic assumptions about how their site will be used over the course of its lifetime. It’s important to build sites with an eye to the future but it’s more important to future-proof the storage/organization of the website data, not the mark-up. If the site is built well, it shouldn’t be so difficult to change the mark-up down the road as technologies and demands change.

      0
    • 95

      Markup will eventually evolve by those who use it.
      Just throwing that out there.

      Much like language. It evolved by those who use it.

      0
  39. 96

    Just want to say that I’m enjoying the debate here. I read this and tweeted about it ( http://goo.gl/PbHak ) before diving into the comments.

    On a high level, I still agree that we shouldn’t get carried away so much to throw semantics out the window and waste time without learning or GTD. But there are several points that I initially missed in these comments. Good stuff!

    ( Time to refresh the page )

    0
  40. 97

    The chicken and the egg.

    Without applications to interpret new semantic markup said markup is futile? Only for the present – having a little foresight and trust in your collegues at Opera (and elsewhere) those applications will emerge.

    Very scary read from someone working at a browser vendor (known for championing standards) I think :/

    0
  41. 100

    THANK G0D SOMEONE FINALLY SAID THIS!

    I have been saying this for years: my job is to please the client, not the browser.

    I know my job is to make the site look good and do it efficiently and do it in a way that is accessible to other developers and bots, etc… but if I end up having to do something in a non-purist, non-semantic, or even {gasp} hacky way, I am probably going to do it.

    Of course I will try to avoid these, but if I have to or it just makes more sense in a particular situation, I will do it.

    0
    • 101

      How pleased will your client be in a few years when his/her site is now a jumble of meaningless s and browsers, search engines, his golf course buddy, etc are all looking through source code for semantic tags?

      0
  42. 102

    Do we feel the same way about non-semantic classes as we do ID’s?

    I presume most of us are using some kind of framework for faster workflow, but ending up with ‘grid-8′, ‘grid-4′…. etc throughout our code….

    Are we then to refigure this after ‘prototyping’ is complete or is this making it to our final code? I love Zurb’s Foundation, but I’ve noticed alot of this boilerplate code still remains in some of their finished product… Is this Ok?

    I personally think yes. If semantics are that important I propose we need an extra attribute for markup… Something we can use purely for layout and styling without the fear of semantic value…!?

    Thoughts?

    0
    • 103

      What semantic value does a class name have? Nothing beyond what it means to the developer looking at it. If you have a small site with limited templates then semantic names are more readable and allow an easier redesign. On the other hand, if you have a large site with hundreds of different layouts, semantic names are nothing but a big headache, because you’ll never be able to redesign just be tweaking your CSS. In that case it’s better to allow developers to lay out a new page with some well-understood presentational grid classes than it is to write hundreds of lines of custom “semantic” declarations that bloat your CSS.

      In short, intelligent application of CSS is context dependent. The best opinions on the matter come from hard-won experience, but even that experience is not universal. The best you can do is understand different approaches (OO-CSS etc) and figure out which applies best to your situation. No single pundit’s word should be taken as gospel.

      0
      • 104

        Hey Gabe :)

        Well, we need to nuance your response a bit further and talk about class names and CSS related to layout *separately* from class names and CSS related to content style.

        For layout, I think your comment is correct. However, for style, I think semantic class names are very valuable. And I do not think it was your intent to imply that CSS class names and semantic class names never have value.

        Allow me to use examples to illustrate my point.

        Imagine a P tag that is conveying some very important information, and the old design called for a red background and yellow text. If that P’s class name is “redAndYellow” then this class name is presentational and NOT semantic. However, if this P’s class name is “important” instead, then we would call it semantic. One can definitely imagine a radical redesign of this site where this semantic class name “important” will end up being much more helpful than “redAndYellow.” We can simply change the CSS in one spot, and be done! No need to rename all those classes in the HTML.

        However, if we’re talking about columns or boxes, and which cells of a grid they occupy, or whether they are in left/right order or top/bottom order, or whether parts of an article violate columns in special ways for purely aesthetic reasons (e.g. push/pull classes popular with grid CSS frameworks) … then yeah, the class “grid-4 push-1″ makes a lot of sense… because the only reason these classes are being applied is for the purpose of changing layout, not for imparting a semantic hook for styling. And when you redesign, your layout will be totally different.

        0
  43. 105

    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.

    0
  44. 106

    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.

    0
  45. 107

    <sarcasm>This is great! I always thought semantic markup was for suckers.</sarcasm>

    0
  46. 110

    My biggest issue with semantic HTML is that the new tags are mostly aimed at a particular domain — documents (pages in a blog, CMS, news sites, etc.), not applications. Most of the web apps I work on have no content in them that aligns particularly well with the concepts of “article”, “section”, “blockquote” etc…

    To use some real web apps as examples, would Gmail markup be improved by making the tag which contains an email post an “article” instead of a “div”? Or Twitter making individual tweets “blockquote” instead of “div”? What would the proper semantic markup be for a typical github page (e.g. https://github.com/joelarson4/Thunder) which appear to be largely “ul” and “li” currently — is that the best fit or is there even a best fit? I’m not sure…

    I can see how for example WordPress or CNN.com might do well to go deeply semantic; I’m not convinced the current tag set is a great fit for all applications though…

    0
    • 111

      You just posted that so you could promote Thunder.js…. it worked I’m watching it on Github, awesome script!

      Oh and I agree, article and section aren’t enough if we are going to go down this semantic road.

      The micro-data from schema.org seems to be better suited.

      0
  47. 112

    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.

    0
  48. 113

    Oh you guys, she’s just biased because her name is DIV-ya ;-)

    0
  49. 115

    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.

    0
  50. 116

    I have never read such a piece of mis-information and wrong-headedness in all my life.

    Semantics are absolutely critical to Assistive Technology users and the fact that *currently* the browsers have parked their effort to get this properly implemented, in favor of getting some fancy CSS3 animation thingy working better is a real shame. To be fair, Firefox (with David Bolter and Marco Zehe) have been working hard and in concert with NVDA to improve this. Where’s Opera in all of that? http://www.paciellogroup.com/blog/2011/10/opera-doesnt-work-with-screen-readers-does-it-matter/

    Web Developers: don’t believe this rubbish – it is the opinion of one, slightly mis-informed young lady who has failed to really understand what she is advocating. Unless of course you are content to crank out mediocre web code that “looks pretty” but has all the finesse of a box of sledge-hammers, and is virtually meaningless to many end-users. Your mother would be proud.

    Divya, you are just plain wrong.

    0
  51. 122

    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.

    0
  52. 123

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

    0
  53. 124

    HTML evolved to address the existing behaviours of people who were creating stuff. Hence HTML5. Loathe as I am to use the phrase, due to possible anatomically painful retribution by Jeff Croft (http://bit.ly/tUO5YF), it was ‘paving the cowpaths’. So use divs to get good work delivered if that’s what it takes. HTML will evolve again as long as we keep creating. We’re still in the infancy stage of the web. We should always remember that.

    0
  54. 125

    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.

    0
  55. 126

    There is value to carefully crafted code, but the elegance of the code should not overshadow other goals. I have seen developers obsess over semantic markup while overlooking user experience flaws. Semantic code is only one component of the work necessary to deliver quality to all browsers (bots, screen readers, printers, desktops, small screen devices, etc…).

    0
  56. 128

    Wayne’s thoughtful comment above makes the human case for well considered semantic markup.

    0
  57. 129

    I worry that this article will encourage people who don’t think tag choice matters in the slightest, when in fact (as you stated in your article) there are some tags that DO matter very much.

    It is important to note that the web is and was meant to be open and accessible (in the generic sense of that word). It is supposed to be easy for people 9 to 99 to publish things on the web, regardless of their background. And I’d never have it any other way.

    That said, if you are in the business of writing markup professionally, then I think you would be severely remiss to not understand and use HTML tags as semantically as possible.

    Is it worth it to argue about a particular choice to use an em vs a strong vs a span? Probably not. But, overall, I think as professionals we all need to agree that semantics are something we should always consider.

    0
    • 130

      Amen, this is the message the article gets to. Not semantics are useless but its not worth worrying over minute detail on.

      0
  58. 131

    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.

    0
  59. 132

    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.

    0
  60. 133

    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.

    0
  61. 134

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

    0
  62. 135

    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.

    0
  63. 136

    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.

    http://dbushell.com/2011/11/11/in-favour-of-semantics/

    0
  64. 137

    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.

    0
  65. 138

    It’s a mixture of both sometimes (to me). It really depends on the time I can invest or not. Sometimes I also see when I am reviewing the code, that there might be an extra div, etc.

    0
  66. 139

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

    0
  67. 140

    Afterall…. it is just a case of semantics. It will pass.

    0
  68. 141

    I dont use the semantic tag because I don’t know yet how to use it.
    Then, after reading a lot about in my spare time about aside tag, I started to use it, later on, after reading about nav tag and understand how to use it, I started to use it on my web. Step by step

    0
  69. 142

    I have a feeling you misunderstand the words “provides the same amount of semantic information to AT as a div element.” and make a bad conclusion from it.

    What is means is that there is no additional information about the contents from the tag alone (in the way that, for example, ul, ol and dl tags contain information about the contents of the lists). An example of this would be article tags providing information about the author, but there’s no such information to be found in those new items.

    However, that does not mean that the information inferred from the tag name is useless – because it’s not! It’s easy to imagine assistive technology that allows you to “skip to next article”, for example.

    0
  70. 143

    full disclosure first of all: I also work at Opera, in the same team as Divya in fact…but this comment is, as this article as well, personal opinion…

    I’ve always been a pragmatist when it comes to markup. Heck, I still fondly remember the heated arguments back in early 2000s about whether one element or another, or a specific combination, was the “one true way(tm)” to semantically mark up a particular piece of content. Is a navigation really an unordered list of links, or should it be an ordered list, or even a nested list of nested lists…I’ve seen such arguments go around and around. My advice has been, and always will be: try to mark stuff up with what feels like the most appropriate elements, try to follow best practice advice, but don’t bust trying to find the absolute perfect structure, as in many cases it may simply not exist – real-world content is more complex than what can be captured with the relatively limited amount of markup lego blocks available.

    And strangely, that seems to be the point of this article, as the conclusion doesn’t seem too dissimilar to what I’d often talk about. However, the spurious strawman argument about the 40 minutes wasted, the overly confrontational, aggressive or forcedly controversial tone of the ensuing rant against the strawman, and some – in my mind – strangely misguided “no tool makes use of it anyway, so don’t bother” attitude, seem to bury the probably quite valid point (don’t overthink your semantic markup, be pragmatic) in an incongruent heap of smug and angry sideswipes at those who dare be so silly as to want to waste time on semantics. Sure, some myths need to be busted, but not this way…far too unilateral and mocking in tone.

    IMHO, of course.

    See you back at the office on monday? :)

    0
    • 144

      I agree about the tone of some of the posts. It’s too bad because I think discussions like these are very healthy for the community.
      Wrong, right, who cares as long as we get something out of the thread?

      So thanks Divya for daring to speak your mind and bravo for handling the whole thing so well.

      0
  71. 145

    I feel like it is a responsibility as developers to learn, master, then implement. As in, find out what the best practices are, learn how/when to use them properly, then make them apart of your coding arsenal. You shouldn’t use something if you don’t know how to use it properly obviously, but you should have the willingness to learn and grow. I do get what the article is getting at, though I ultimately disagree in the end. :)

    0
  72. 146

    HTML5 semantics is just pretty, and that’s enough for me.

    Really, styling a “header” instead of a “div class=’this_is_a_header’ ” just makes life so much easier.

    Of course, obsessive adherence is useless. If my section was supposed to be an aside, the next developer isn’t going to be saying “What? What the heck was this guy doing?”

    0
  73. 147

    I think this article should be considered harmful because it might encourage less experienced web developers to actually follow your advice.

    Meaningful HTML (article, hx, aside, section, header, footer, nav) helps screen readers, search engines, colleagues who work on your code, and other non-visual browsers to determine what is content, what is a sidebar, what is a menu, etc.

    These elements also help users of screen readers heavily, who rely on shortcuts to jump to different section on your site, e.g. the header, footer, first article on the page, the next fieldset, etc.

    If you spend 40 minutes on thinking what element to use, something else is really the problem. Using div’s is not going to help.

    0
  74. 148

    I’m afraid I have to agree with Patrick’s comment when he says that the confrontational tone and strawman arguments at the start of the article make it hard to get to the real message.

    But if you can get past the blustery tone and get to the kernel of the article, it’s a fairly straightforward message: don’t get too hung up on semantics to the detriment of other important facets of web development.

    The specific example of divs and sectioning content is troublesome though. There is a difference between a div and a section or article (or aside or nav). I don’t just mean the semantic difference (a div conveys no meaning about the contained content whereas a section element is specifically for enclosing *thematically-related* content). There are also practical differences.

    A section element will have an effect on the generated outline for a document (a div will not). The new outline algorithm in HTML5 will make life a lot easier for future assistive technology and searchbots (as other people have mentioned) but it already has practical effects today in some browsers in their default styling.

    Download the HTML document I’ve thrown up at https://gist.github.com/1360458 and open it in the latest version of Safari, Chrome or Firefox. You’ll notice that the same element (h1) will have different styling depending on whether it is within a div or within a section element (thanks to -moz-any and -webkit-any CSS declarations in the browser’s default stylesheets).

    So that’s one illustration of the practical difference between div and section.

    Now with that said, I somewhat concur with the conclusion of “when in doubt, just use a div”. I see far too many documents where every div has been swapped out for a section or an article or a nav or an aside. But my reason for coming to that conclusion is the polar opposite of Divya’s reasoning. Whereas Divya is saying there is effectively no difference between using a div and using sectioning content, the opposite is the case: it makes a big difference to the document’s outline. So if you use a section or article or aside or nav without realising the consequences, the results could be much worse than if you had simply used a div.

    I also agree that there’s a balance to be struck in the native semantics of HTML. In many ways its power comes from the fact that it is a limited–but universally understood by browsers–set of semantics. If we had an element for every possible type of content, the language would be useless. Personally, I’m not convinced that we need a section element *and* an article element: the semantics of those two elements are so close as to be practically identical.

    And that’s the reason why right now is *exactly* the time for web developers to be thinking about semantics. The specification is still being put together and our voice matters. If we want to have well-considered semantic elements in the language, we need to take the time to consider the effects of every new element that could potentially be used to structure our content.

    So I will continue to stop and think when it comes to choosing elements and class names just as much as I would sweat the details of visual design or the punctation in my copy or the coding style of my JavaScript.

    0
  75. 149

    Same warning than Patrick H. Lauke.

    I have argued the topic with Divya already in a Norwegian wood (tune the song) a few months ago. The social contract of markup is the meaning we convey to other *people* (not the browser).

    Reading the comments and answers from Divya to commenters, I have a growing feeling that this article has nothing to do with semantics markup, Web, etc. Re-title the article “Our Pointless Pursuit of Perfection” and you have a perfect article for a self-help web site applying to any kind of topic. Basically something which is working for everything and then has little values.

    Suggestion : next article should focus on what you can do more than on our common flaws. I know some people who would debate about colors and pixels for a long time except of meaningful interactions or accessible content. :)

    0
  76. 150

    I think @Divya’s points are too dismissive. I think you want to strive for making things better. Build more semantically correct wherever possible, learn what is most appropriate and try to use it. And yes, it takes time – and is probably inconvenient. I think in terms of progressively moving forward because out in the “rubber meets the road” world there are lots of people who are doing it wrong and don’t care. Sparing over who is doing it perfectly and who is not is the lesser concern. The bigger issue is if we are not trying to move forward – are we not moving backwards?

    I hope you don’t mind, but I posted a link to this article on the LinkedIn Web Standards group http://tinyurl.com/d86tmlt

    0
  77. 151

    Huh? How hard choosing the proper element is? I find myself really entertained by doing it. And hell no, it doesn’t take 40 minutes. I spend one minute or less. Maybe if you’re just learning the new HTML5 elements it may take that long.

    Come on, darling. If you have the chance to use semantic value why avoiding this?

    Site navigations links? Wrap them in a `nav` element. Completely independent content? Use `article`. Any large group of related content could go in a `section` and if there is a piece of elements related to that content but not required in order to understand it, `aside` then.

    You mentioned that `header` and `footer` are worth using. Where in the world do you think they go? Inside a `section` or an `article`.

    0
  78. 152

    Vitaly Friedman (editor-in-chief of Smashing Magazine)

    November 12, 2011 6:13 am

    Update: Thank you for your constructive feedback and meaningful comments. You can also read a reply by Jeremy Keith to this article here on Smashing Magazine 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.

    0
  79. 153

    I swear people are getting lazier and lazier every day. Just write semantic code and make life easier for the rest of us, stop being selfish and show some pride in your work. We do crap like this for the same reason we build pattern libraries. To make it efficient for other authors / developers to hand off work / knowledge. We are having a hard enough time teaching people to have a bit more pride in their craft and here you go looking for perceived inefficiencies just to get your name out there….

    0
  80. 154

    I can kind of see Divya’s point. While I know it was not her original intent, I have always been bothered by the “semantic purists” and their strict calls for absolute separation of content and presentation. Much of my issue with these views has to do with web design and development being my own personal hobby and making sense to me has been more important than anything else.

    That’s not to say that I haven’t attempted to use best practices, but one example of this “disconnect” has been definition lists. Some of the excellent books I’ve read (Cederholm) have championed their use because of their unique ‘structure’, while others (Budd) say they should be limited to their more “semantic” origins.

    Of course, HTML5 has changed these to “description lists”. Great, but therein lies a problem. One area were I may have wasted 40 minutes of time is reading up on the new “time” element in HTML5. It sounded like a perfect replacement for all my instances of “p class=date”.

    That is, until Mr Hickson of the WHATWG decided to pull it. But apparently the W3C is going to keep it, so who knows…And the redefinition of the “cite” element in HTML5, which Jeremy Keith called “just plain wrong,” is another example. What else is going to change in this living standard between now and 2022? I have a somewhat hard time accepting the “accessibility tools will be on board soon” argument with a markup standard landscape in such flux.

    0
  81. 155

    Making Divya’s point even more confusing, view source on her blog http://nimbupani.com/ She’s using article, section, header, nav, etc.. but tells us, “don’t bother.”

    *div class=joke* Maybe she’s trying to keep the good stuff for herself. *div*

    0
  82. 156

    I agree with Divya, however I’d take it a step further. I fundamentally believe that computers should adapt to us, and not the other way round.

    As technology advances exponentially, it shouldn’t be too long until computers are fluent in discerning natural human samantics and language, eliminating the need for markup as we know it.

    This process has already been achieved to some extent by voice command interpretation technologies such Siri. Even apps such as Fantastical understand natural human commands for setting meetings, dates and times etc. Kind of makes micro-format date/time structure look old-school and robotic, kind of like comparing MS-DOS to OSX.

    0
  83. 157

    I’m a beginner when it comes to web development, not that I lack interest in the subject, just because it’s not my daily work activities. I started playing around with HTML, CSS, JS prior to HTML5 standards started being adopted by browsers and a lot of things that have happened in the web show that web development community has matured, the gathering on people around common issues on Web Development and in providing answers for them, makes a pleasure to be involved in building a part of internet.
    I rely on standards sense to help me to decide why/when/how to apply a certain technology, so they need to have a syntax and semantic meaning behind it, one that also makes possible to me and others to sit down and have discussions on it’s issues so that solutions can continue to be pursued.
    Taking HTML as an example, if there are debatable questions around the need of certain tags then they shouldn’t be considered as part of the standards right now. I heard once Douglas Crockford saying like the standards aren’t suppose to include all that the language represents but the critical few ‘rules’ that allow the language can expresses itself without jeopardize the user liberty, and I agree with him. As an example, divs are today used and abused as HTML tags but hasn’t header, footer, nav, aside, etc, brought an easier way to build HTML and HTML, CSS and JS interact? If a tag doesn’t easily demonstrates it’s value, it will certainly be a source of all type of issues and for me this means that it needs more work to be considered part of a standard.
    Web developers need to have into account a lot of forces while doing their job, but don’t mix pragmatism, personal taste or particular case necessity to what should be in a standard (having a syntax and semantic well defined). Standards are the cement that makes possible all sorts of buildings in internet and it’s worth having good cement so that we fill confident in approaching from walls to sky scrapers.

    Thanks for keep promoting the internet and don’t forget that we are all learners here. RM

    0
  84. 158

    Coming to this a bit late, but as you quote HTML5 Accessibility which I develop, thought I would chip in.

    The figure and figcaption elements currently have no semantic meaning. This is partly because the semantics are not defined in accessibility APIs and partly because the available role semantics and labelling relationships have not been implemented yet in browser yet. There is active work going on to change that. I wrote a post about it. At TPAC last week we discussed the addition of a figure role in ARIA 1.1. There is also moves afoot to add a figure role to the iAccessible2 API, and Firefox are making progress on the implementation of the labelling relationship for figcaption/figure and role implementation for figcaption.

    So the semantic story for HTML5 is not bleak, it just requires cultivation from implementors and developers.

    0
  85. 159

    The big problem with this article is that is bases most (if not all) of its arguments on the current state of the web. For an industry that relies so much on “paving the cow paths”, we often find ourselves in a “do first, see the results later” situation. If search engines don’t pay much attention to our semantics, it’s because we’re doing a crap job right now. Giving up is not really an option if you ask me.

    Taking your aside example, the tag should prove invaluable when machines are programmed to decide when and if they should display secondary content. If you just use divs everywhere, there is no way to know whether a piece of content is primary or secondary (and can be dropped if needed). What programs do this now? None really (that I know of), but the main reason is because most people either don’t use the tag or abuse the tag. So rather than tell people to stop thinking about semantics, we should urge them to learn do their job properly.

    0
  86. 160

    While I don’t agree with everything that you have said in this article, I have found it invaluable in helping solidify my own views on the subject.

    Print documents and research papers have had definite structures and conventions for a long time. A paragraph has meaning, as do headings, figures, quotes etc. We need to retain these things – without them then text can just become a mass of words. Lets remember that HTML and the web came about as a way of sharing research data between academic and research institutions, and the semantic meaning of the text is really important.

    I also agree that we shouldn’t get too hung up on whether we are overusing DIVs and SPANs – these are layout elements, but the argument that STRONG and EM not having any more semantic value that DIV and SPAN is flawed. These DO have meaning – the convey the authors intent and meaning. Also, just because screen readers don’t handle the new HTML5 tags at the moment doesn’t mean that they won’t.

    0
  87. 161

    “Interaction” elements and codes within a page are just metadata of the content, web standards should strive to isolate them from the content. This is exactly what jQuery tries to do: isolating an element’s behavior out of the element itself, just like what CSS does regarding attributes; the presentation attributes actually.
    Take a look to the source code of this page:
    http://richstyle.org/
    Thanks to jQuery, you will not find any “interaction instruction” in this page at all, not even a single event in the whole HTML code. Just empty classes in a “nav” element.

    0
  88. 162

    Honestly I see one big advantage of actually using all those HTML5 elements:

    If building a complex site, it will ease CSS markup a lot!
    You’ll be able to reduce the use of classes and IDs, and build better context-dependent styles. And if you do so, see to it, that you use these elements in a semantically correct way. Otherwise, I’m still using mostly xHTML markup

    0
  89. 163

    Sorry Hixie, I’m not going to spend hours reading about semantic elements just so your employer’s search engine can bastardise my content even more than it already does.

    Boycott semantic markup!

    0
  90. 164

    Thank you for being honest, for saying what many of us have thought, but dared not say. It’s refreshing.

    0
  91. 165

    Semantic richness and value is only valuable in context to the content.

    As algorithms and quality raters become better at deciphering what is quality, it becomes less important to be semantically rich.

    You can game the system with temporary benefits but in the end, content quality will determine its value. Social media shares, higher click through rates, etc. is the best indicator.

    0
  92. 166

    I think people need to turn their heads more towards http://schema.org and http://ogp.me/. These are the ‘steroid mark-up’ standards that will highly impact on your content in search engines and social media sites.

    0
  93. 167

    Well said! Thank you.

    0
  94. 168

    This Post is ,in fact , one of the shittiest arguments i’ve ever read on the web . Your points are too narrow and silly. you are just talking about today’s implementation of HTML5 semantics .
    But I truly believe that developers should try html5 semantics today , thats how the conversation happens , thats how we all can help making the living standerd better

    I actually do not use non-prefixed these days because syntax changes so often and it would not be future-proof.

    Huh ” so often” ? I can’t believe you work for Opera .

    0
  95. 169

    who the hell cares if the mark up is perfect or not. as long as the site works and google can crawl it correctly then it’s fine.

    0
  96. 170

    The use of the new elements like header, footer, section, article, aside take a webpage from being interpretive to a universal structure that is understandable by everyone.

    div id=”myopinionsucks”
    div id=”whydotheyletmewrite”
    div id=”whydidoperahigheryou”
    h2 this is a great article /h2
    /div
    /div
    /div

    Is like looking at newspaper, you see alot of blocks with headings that are 100% interpretive,

    section
    article
    header
    h2 This article is by who? /h2
    /header
    p sounds like someone has a case of the mondays /p
    /article
    footer
    by me
    /footer
    /section

    Is like looking at a encyclopedia, where you can understand the structure of the information and Google does take this into account (regardless of what you think you know, they created the new tags.) It also means less markup for alot of us that understand how the cascade works and use it to our advantage. So go ahead and keep it up with the div and id game, but when your ready to advance the web instead of hold it back… html5 will be there waiting with forgiving arms.

    0
  97. 171

    Thank you for this article, it made my day.
    Don’t waste time on semantics, do it simple and concentrate on the content.

    0
  98. 172

    The future of the web should be a semantic web. There are a lot of benefits of doing semantic content instead of “just content”. We are far away from a perfectly semantic web, but the new html5 tags are a first step in the right direction. The big advantage of having semantic pages is that they are “machine readable”, which means that a machine knows how to treat the data it just found. If you want a truly semantic website you should use microdata and follow the schema.org conventions. The reward you will perhaps get are rich snippets in google search results. We should try to use the new semantic tools we get today, so that we can find out what works and what not, to make something better for tomorrow.

    I also think the web could benefit from the semantics, because today the web is “just” a huge amount of websites, sometimes interacting using apis. If you look at the huge amount of apis that get created every day, one thing you will often see are apis that allow you to retrieve content from a website, similar to an rss feed but filtered using some parameters. Apis are maybe usefull to inject new content in a website. I think semantic websites will help webmasters to create connections between websites that were not possible before and get rid of a lot of apis used today. Informations on the web should be free, semantics can help us here. If you want to use mining you need to have structured content. Today you have to use the twitter api to display your posts in a widget on your blog, in the future you could be able to run screen scraping tools that retrieves all the posts you made around the web and displays them on your blog.

    0
  99. 173

    So styling article is better then styling div id=”article”? Well, I have four sections tagged “article” in my page and those are supposed to styled differently. Yet, I have to use article id=”primary” article id=”secondary” and so on …

    IT IS BETTER!

    0
  100. 174

    I know I am very late, maybe, the author change his mind about it.

    I think the article miss the point in the beginning. In the 7 steps of the “picture” it shows.

    If you want to use html5 semantic tagging you have to learned first. Am I wrong on this?
    If you are going to use a div and you don’t know to use aside, or article is because you didn’t bother to learn HTML5 tagging. If you don’t do this you’ll lose the 40 minutes of digging in internet, that’s true, but don’t blame the semantic tagging, blame yourself of not having invest the enought time to know the semantic tags.

    This article, remains me to the time that people defends tables against divs, because they don’t know css, and get confuse with the tags.

    0
  101. 175

    You hit the nail on the head!

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top