Pursuing Semantic Value

Advertisement

Disclaimer: This post by Jeremy Keith is one1 of2 the3 many4 reactions5 to our recent article6 on the pursuit of semantic value by Divya Manian. Both articles are 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.

Divya Manian, one of the super-smart web warriors behind HTML5 Boilerplate, has published an article called Our Pointless Pursuit Of Semantic Value7.

I’m afraid I have to agree with Patrick’s comment8 when he says that the abrasive title, 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. Divya clarifies this in a comment9:

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

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 mentioned in the comments) 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/136045810 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 collective 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.

(vf)

Footnotes

  1. 1 http://adactio.com/journal/4999/
  2. 2 http://dbushell.com/2011/11/11/in-favour-of-semantics/
  3. 3 http://twitter.com/#!/phuunet/status/135132232590426112
  4. 4 http://www.stuffandnonsense.co.uk/blog/about/our_pointless_pursuit_of_semantic_value
  5. 5 http://twitter.com/#!/jcroft/status/135038999965347840
  6. 6 http://coding.smashingmagazine.com/2011/11/11/our-pointless-pursuit-of-semantic-value/
  7. 7 http://coding.smashingmagazine.com/2011/11/11/our-pointless-pursuit-of-semantic-value/comment-page-1/
  8. 8 http://coding.smashingmagazine.com/2011/11/11/our-pointless-pursuit-of-semantic-value/comment-page-1/#comment-554393
  9. 9 http://coding.smashingmagazine.com/2011/11/11/our-pointless-pursuit-of-semantic-value/comment-page-1/#comment-554372
  10. 10 https://gist.github.com/1360458

↑ Back to topShare on Twitter

Jeremy Keith is a Web developer and author living and working in Brighton, England.

Advertising

Note: Our rating-system has caused errors, so it's disabled at the moment. It will be back the moment the problem has been resolved. We're very sorry. Happy Holidays!

  1. 1

    Many people misunderstood divya’s article. This one cleared everything.

    • 2

      I think it’s less a misunderstanding of the original article, and more that the original article was unnecessarily obtuse and confrontational

      • 3

        I don’t think the original article was obtuse or confrontational. The basic premise was just wrong. I don’t need 40 minutes to hunt down the semantic meaning of a tag. I know all of them already. I’m a web developer.

        Staying on top of the latest HTML5 elements can be a greater challenge, but if you’re a developer, it’s your job to know it. If you don’t know it, but consider 40 minutes to learn it a waste of time, I don’t want you on my team.

        I know people who call themselves web developers who don’t even realize multiple ‘tbody’ elements in a table are valid or know the purpose of a ‘label’ element’s ‘for’ attribute. I suppose I can call myself a tour de france cyclist because I know how to ride a bicycle, eh? :-D

  2. 4

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

    November 12, 2011 6:36 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.

    • 5

      You should not apologize for divya’s article. it was her thought in a form of article. There is nothing wrong to discuss things.

      What do you think?”

      was stated at the end of the article

      • 6

        There is no reason to apologize. Divya’s article was spot on. Her article was not just a random negative blast, it was informative and had supporting points. There NEEDS to be this controversy with HTML5. Most readers misunderstood the true message she was conveying in her article in the first place.

      • 7

        I fully agree. In fact, I almost feel sorry for Divya to have Vitaly apologize for the way she wrote her article.

        It was published in the OPINION column was it not?

    • 8

      @Vitaly

      This is the second one where a follow-up had to be published. It’s got to be tough managing this beast of a site, so I wish you luck in keeping the quality of the posts (even if they are “opinion”) up to par with the rest of the content you guys produce.

    • 9

      Neither Divya’s article nor your editorial instinct has any problem, your apology is not needed at all. If someone can’t tell the difference between fact and opinion, that’s his/her own problem. I think Smashing Mag should have more articles like Divya’s and not to be intimidated by anyone.

    • 10

      Please don’t start polishing the edges of the opinion pieces, at least ones of this nature. A few rough edges never killed anyone.

  3. 11

    It’s a sad day for freedom of speech. The problem i have with what SM just did here is that, in the name of (rightfully or wrongfully called) best practices, one cannot have his own mind about something, and can not express it the way he sees fit.

    I want Smashing magazine to publish breaking, conflictual articles. I want to take into account other way of thinking than mine. I want to question what I take for granted.

    Reading cheesy articles doesn’t help me (and hopefully the community) to make choices in an informed manner, nor to build tomorrow standards. So please SM, don’t ask people to forgive an editorial choice. You did it because you know deep inside that it was right.

    Oh, by the way… I’m on the semantic side of HTML.

    • 12

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

      November 12, 2011 7:51 am

      Alessandro, I respectfully disagree. The problem as I see it was that the tone of the article was a bit too aggressive compared to the common expectations that the readers of Smashing Magazine are used to when they come to Smashing Magazine. I do believe that it was the right decision to publish the article; I just feel that we haven’t done a good job at helping the author better promote her ideas and thoughts to our audience and the Web design community in general.

      Publishing the article was the right editorial choice in my opinion. The editing, however, could have been better. And this is what I have apologized for.

      • 13

        Hans Christian Reinl

        November 12, 2011 3:03 pm

        I think it’s ok how Divya wrote the article as the article is published in the Opinion Column. Furthermore the discussion that is going on now is great and shows how much the community cares about things that are published on SmashingMag.

        • 14

          The problem with dismissing the tone because it was in the opinion column is that when the article shows up in the main feed, there’s no indication that the article is an opinion. Even reading the article, there is no obvious indication that I’m reading someones opinion (unless all opinions end with “What do you think?”). After 10 minutes of searching the site, I finally found the opinion column, an area I didn’t even know existed.

          I come to Smashing to catch up on the latest and greatest movements in web design. Up until this point, I thought everything published was from the Who’s-Who in the web community and they had the best suggestions for enhancing our industry, and seeing an Opera employee speak seemed pretty credible. Then I thought, “so wait? Have I been wasting my time learning this stuff?”

          Perhaps it’s a sheepish way of thinking, but I’ve got so many other things to worry about in my day-to-day then to question if a good industry resource is trying to get me to think about my stance on a topic.

      • 15

        It’s better to provoke a reaction then to react to provocation. The article’s gotten a lot of comments, no doubt more then this one will ever see.

      • 16

        The apology is unnecessary and a bit pedantic. It’s an opinion piece, not a research paper. The people the article was written for don’t need hand-holding in figuring that out. If the article offended you, it wasn’t meant for you.

        It’s good to engage your readership, but don’t pander to them.

        • 17

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

          November 15, 2011 12:08 am

          Smashing Magazine has a responsibility for the community to support, provide and encourage best design and coding practices. From the feedback we’ve received to the original post, it looked like many developers, especially newcomers to the industry, misunderstood the intention of the article. Since it was published on Smashing Magazine, they didn’t understand that it was an “opinion piece” which was supposed to raise a discussion rather than make a bold statement for everybody to follow. We’ve received some emails from readers who claimed that we helped them to understand that they should forget about the “obsessive HTML5/HTML semantics which nobody needs anyway”.

          To be honest, I don’t feel that such reactions are healthy for the community or the professionalism in our industry.

          • 18

            Although I understand where you’re coming from, it feels as though you’re marginalizing the opinion of one of your writers. For me, that’s worse than the possible negative effect Divya’s article might have the on reader’s view of Smashing Magazine as a whole.

          • 19

            Without controversy in our conversations how will we ever really know the best practices? The conversation wouldn’t be very interesting if it was all one-sided.

  4. 20

    When I read the original article, these are the things that came to mind too. Knowing Divvya is not “just some webdesigner” makes it even harder to really grasp where she’s going with her article.

    There’s imho, indeed non-valid info in there, as Jeremy points out e.g. the “just use a div when in doubt” etc.. that the real message “don’t get too hung up on semantics” gets lost in it..

    Maybe best to put a link to this article in the original one or anything..

    The article from Divvya is not SmashingMagazine-level imho, no matter her qualifications or “personal view”.. The fact that a lot of people didn’t read into the message says a lot. Also a lot of people read SM and take everything as “best practice”. That should also be taken into account when publishing articles like these..

    • 21

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

      November 12, 2011 7:52 am

      Yes, agree! Actually, this is why Divya’s article was published in the “Opinion Column” section. It was very unfortunate, however, that we haven’t added a clear and visible disclaimer in the very beginning of the original article at the moment when it was published but a bit later.

      • 22

        Vitaly, Just an observation, but I had no idea you even had an “Opinion Column” section until you mentioned it. I read via RSS and either I didn’t see it, or else there is nothing to say as such in the feed. I agree that a clear and visible disclaimer is needed, but I would also say that strong, controversial opinion pieces are essential and shouldn’t be shied away from. We should always question the status quo even if the end result is merely a confirmation of what we already know. In this case, the discussion has been valuable. It’s just a shame so many decided it was more fun to attack Divya personally rather than addressing her argument. Thank goodness we do have some level-headed, intelligent souls in this here web industry who cooled the flames.

        • 23

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

          November 15, 2011 12:10 am

          Paul, I agree! We just need to make sure that such articles are clearly highlighted as “Opinion Pieces”. Of course we will continue publishing them in the future, but we will make sure that they are clearly marked as such.

          Thanks for your reply!

  5. 24

    As many others, I was initially misguided with Divya’s original intention. After re-reading it a few times, I got it; and it’s a great message.

    I’m very glad you’ve posted a response that clears things out so well. In the end, you’re the one source for many newcomers to learn and embrace ideas and best practices. An easily misguiding article could’ve been very bad to the community.

  6. 25

    Jeremy,

    Your Gist example was very helpful for me in terms of clarifying these new semantic distinctions. I’m still a little fuzzy on two central aspects of HTML5. First, the distinction between certain tags, such as section v. article, sometimes seems a bit subtle to me. (Am I being obtuse? I hope not.) Secondly, I still have little understanding of **how browsers render these tags differently.** Your example was especially helpful on the second point.

  7. 26

    First, I’d like to say that I’m happy that two intelligent voices in the industry have put forth their views on this issue. This is great to see, and I hope more influential developers and writers use Smashing Magazine to reach a wider audience for important messages and (I hope) friendly debates like this.

    Jeremy, I have a lot of respect for you and in no way should anything I say below imply that I don’t appreciate the contributions you’ve made to web development over the past decade. If it wasn’t for you, I’d know nothing about Ajax. So I do appreciate all that you’ve done and how you’ve helped folks like myself and others grow and evolve as web professionals.

    But my compliments will probably end there. :)

    Am I the only one that feels that Divya’s article was not confrontational? What exactly was confrontational about it? The title represented precisely the theme that she developed. Yes, it goes contrary to traditional views on semantics. But if it’s true, then it’s a necessary confrontation, and so that shouldn’t be viewed as a detriment to its value. Of all people, I’m surprised you would be taken aback by a strong opinion — especially if it has supporting evidence (assuming it does, of course, which is still unclear).

    In your article, you go on to point out a “practical difference” between div and section — the different default styling in some new browsers. Well, I definitely see a “difference”. But how exactly is this “practical”? Is this really going to help web developers solve some problem that they now face? Or is this “practical” difference just a figment of our imagination?

    Don’t get me wrong here; I’m not saying there is no value. I just don’t see it at the moment. So what is the value of a default styling that will, due to the common use of resets and normalizers, never be seen by any user or developer? Are assistive devices impacted by this difference? If so, then why didn’t you point this out here? If not, then aren’t you just begging the question?

    You said:

    The specification is still being put together and our collective 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.

    What are the “effects” that you speak of? You’re telling us to help pave the cowpaths (which is good), but what will the end result be?

    In her article, Divya says that semantics and accessibility have very little correlation. She links to a page that clearly proves this is true in the case of the new HTML5 semantic elements. Almost all of them have the same semantic value as divs.

    Is this going to change in the future? If it does change, then what will the effect be? If we pave a cowpath that leads to a clear purpose for “article” and a clear other purpose for “aside”, how will that benefit us? If your answer is “it’s more semantic”, then, again, I have to say that you’re begging the question. What does this semantic difference amount to in practical terms? What will screen readers do with these elements in the future that they aren’t able to do today with regular divs?

    Personally, I don’t think Divya was confrontational at all. I was shocked to see so many people make that claim. She put forth an argument and she supported it with evidence. I guess people like yourself, Andy Clarke, and other long-time proponents of semantics took it that way because of how clearly it flies in the face of what you’ve invested in for so many years.

    But it’s sad that, with a few small exceptions, everyone basically just said you’re wrong without providing much explanation as to why she’s wrong.

    Again, I’m not saying she is right, and that the pursuit of semantics is worthless. But it would be nice to see some of the opposers of that piece provide clear evidence that currently semantics do help us, and in the future will help us, solve real problems. Otherwise, in line with the feeling I get from reading this response of yours, I think we’re just back at square one, asking ourselves: What is the point of spending so much time debating the use of semantic tags in HTML5?

    • 27

      So you’re saying “show me a practical difference between div and section.” I show you how those elements will render their contents differently in browsers shipping today. Then you basically say “that doesn’t count—show me another difference.”

      You finish by writing “I’m not saying she is right, and that the pursuit of semantics is worthless.” …If you think that’s what Divya was saying, you completely misunderstood what she wrote (or you’re deliberately applying a reductio ad absurdum).

      Also, in answer to many of the questions you ask (which you probably intended to be rhetorical) about assistive technology and other user-agents, there is a big difference between the answers “no” and “no yet.”

      Try to make an effort to think beyond today.

      • 28

        Jeremy,

        The title of Divya’s article is “Our Pointless Pursuit of Semantic Value”. When I said “she was right” I was referring to her main point which is in reference to the squabbles on trying to find the value of an “article” vs. a “section” and similar debates. I was generalizing in my statement (so I apologize for that), in line with the title of her piece. I know she supports the fact that semantics do have some value.

        Oh and you’re right, it is important that we think beyond today. But with regards to semantics, haven’t we been doing that for about 15 years with very little to show for it? :)

  8. 29

    When talking about 4 sources on the one topic, why is it acceptable to link one word per link in that sentence for each of the 4 sources where that link text is completely ambiguous (ie “one of the many reactions”)?

    I’ve noticed this trend across a few blogs, particularly from people who should know better.

    Is this not particularly important when talking about an article on better practice?

  9. 31

    Thank goodness for Jeremy Keith.

  10. 32

    Coming to this a bit late, but as Divya quoted 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 (Firefox bug) 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 further cultivation from implementors and developers.

  11. 33

    I just wanted to thank both of the authors Jeremy Keith, and Divya Manian for taking the time to write their articles for us to read and reflect on. I am new to Web design and have just recently started writing HTML5. To my own frustration, I also struggled with many of the same issues that Divya explains in the beginning of her article directly after “Allow me to paint a picture:”, as I try to keep my coding as semantically correct as possible. So after reading countless articles in the past few weeks with one “extreme” view of using practically no div elements and another saying to write the same structure as you did previous to HTML5 and just name the divs ids and classes as header, footer etc. and change them later on; I think I have now found the middle starting ground (personally) between the two “extremes” in order to code forward into this exciting world of HTML5.

  12. 34

    Hello everybody. Good discussion this. Personally I don’t think there was anything wrong with the tone of the original article. In my view: If somebody writes ‘Kill all internet explorer 6 users’ and provides good points why it’s a horrible browser..we will all smile and raise our thumbs…it’s not really being negative, it’s suggesting there’s better or OTHER ways to do things… it’s the same here I believe; just with a more contemporary topic that most of us still are discovering now (amazing how many claim to be experts already while the full potential of html 5 is just being opened up to us all)

    My experience is there will always be upsides and downsides to every method applied – kinda like with the Flash/HTML 5 battle right now; you find people who say Flash is THE tool, others claim HTML5 is the unavoidable future, some claim they can go hand in hand etc. in the end , when the customer is happy and the end-result of your work is something you can be proud of…everybody’s right.

    The whole argument about preparing sites for future, from my experience with customers, is pointless – we all know changing ‘header’ into a ‘div name’ or vice versa, should one method prove better, takes like….10 secs? And besides…will those customers who dont have html5 tricks in their site now, really mind that in 5 yrs? when over 50% of them is not using the website they wanted anymore, anyway? Yes this is a fast changing business…with any luck your customer will come back for many updates in future- there IS NO golden rule of doing it right for eternity imho

    I would like to end with a question somebody who’s got more code experience than me (shudn’t be hard – I am a basic front-end designer) ;

    I’ve been working on responsive website design since recently,
    and have found that my content is placed on the page very differently now as before because I need to keep in mind how (in what order) it’s displayed on mobile screens too. (iow – an image with a text div next to it might show in unwanted order in mobile screen) ,

    And reading this discussion I wonder how this affects responsive design?
    Esp. with ‘mobile only’ tags etc. isn’t the whole ‘name of the element’ a pointless tool anyway? And doesn’t that put us back to having to name ‘div’s anyway because otherwise the order of document becomes more unclear?

    Just asking- not stating this or that is better…just curious:)

    Thanks to smashing magazine and all the smart people contributing for colouring up my creative workday always! Keep it up

  13. 35

    H1
    This new article was a boring waste of time, the prior article in question was brilliant.

    Aside From that… drum roll please.

    I couldn’t get through the first paragraph of this drab attempt at rebuking, So I can’t tell you how I felt about this one.

  14. 39

    Good day! I could have sworn I’ve been to this blog before but after browsing through some of the post I realized it’s new to me. Anyways, I’m definitely glad I found it and I’ll be bookmarking and checking back often!

  15. 40

    Jeremy is winning.

  16. 41

    I disagree with Jeremy on several points. I must be one of the few people who have wasted hours/days/weeks of their lives trying to understand sectioning and outlining in the HTML5 spec for my HTML5 book (http://itsninja.com/html5book/), so when I say I disagree, please know it’s with some research under my belt!

    Jeremy says, “A section element will have an effect on the generated outline for a document (a div will not).”

    This is true.

    “The new outline algorithm in HTML5 will make life a lot easier for future assistive technology and searchbots (as other people mentioned in the comments)”

    This is not.

    “but it already has practical effects today in some browsers in their default styling.”

    “Practical” is perhaps in the eye of the beholder ;)

    The HTML5 outlining algorithm is/was dead on arrival, due to the poor way the spec documents outlining, and the way it has been written about in the community. For example, the classic 2007 article on HTML5 semantics (http://www.alistapart.com/articles/previewofhtml5) with the image of a typical layout, which is rehashed here (by SM editorial, I imagine), fundamentally miscommunicates the intent of the elements as described in the already muddy spec. (For example, header and footer look like sectioning elements, they aren’t; articles can appear all over the place; ditto sections, etc; it looks like a visual replacement for current uses, it’s not (it’s for sectioning); no one understand sectioning; etc, etc.)

    The fact that this misunderstood layout became the de-facto understanding for the many books and blog posts that have come since is really quite unfortunate (such is the power of an image!), as the net result is the new elements have been implemented poorly by the community (as Jeremy notes) with absolutely zero thought to outlining. Therefore there is, and will be, a long trail of broken outlines that make an attempt to use them programatically, at least in a way that is recognizable in the spec, pretty much moot. Similar promises were made with XHTML; similar failures occurred.

    But it gets worse. We need to also factor in that we need two separate outlines — one for AT that exists today, which uses headings for the outlines — and a theoretical may-be-used-in-the-future-but-probably-not outline, which is incredibly messy.

    Then factor in that, contrary to Jeremy’s suggestion, search engines are never going to use these outlines (why would they? They’re a mess. Can we please put this age-old SEO myth to bed?) and they seem even more pointless.

    So, while Jeremy is right in pointing out the technical difference between a div and a section, as to practical differences, will the “new outline algorithm in HTML5 will make life a lot easier for future assistive technology and searchbots”? The answer is no and no.

    Jeremy also rightly warns against haphazardly using section (or sectioning elements) without understanding the consequences. But that’s what everybody is already doing en masse, rendering their one main benefit (outlining) useless. It’s a sad state of affairs.

    Jeremy says “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 collective voice matters.”

    Ah, but the joke is on us. Our collective voice matters to Hickson (the HTML5 editor)? In what way?

    Our voice didn’t matter at the start — I did the research, and Hickson said that he (and perhaps some others) threw the new elements into the spec in 2004, prior to *any* research (that came after) or consultation. Comments he has made in recent years make it clear he sees them as purely stylistic choices — he seems to have long forgotten outlining, even though it’s described (somewhat obtusely) in his own spec. The idea that “our collective voice matters” now is just false optimism. The recent time element debacle is a case in point.

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

    The new elements aren’t well considered in any way, shape or form. That’s why the situation is such a mess – they appear to have been thrown into the spec after Hickson jotted them down on a whiteboard (literally, that’s what’s in the WHATWG archives), and from that poor specification has sprung even worse implementations by the community which don’t match the spec in any recognizable way. It’s a double failure. Not that it matters much now — according to my correspondence with Hickson, the ship has sailed on these elements, and apart from adding, or subtracting, or adding and then subtracting the odd peripheral element here or there, the door is closed.

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

    Spending time to stop and think about how best to use half-baked, functionally pointless elements is not time well spent; Divya was right on the money there.

    Jeremy, a quick plea if I may: honestly I think as an (the?) authoritative voice on the use and nuances of markup, you owe it to the community to better communicate the messy realities of the spec. This wide-eyed optimism about a deeply flawed process and resulting spec leads average, garden-variety web designers (such as myself) to believe everything is just super with the spec, but having spent many hours rifling through the WHATWG mailing list archives, studying the spec, and reading the books (including your own) & blogs on the topic, the impression the community is getting is really quite detached from the reality of the HTML5 spec as document, a process, and an implementation.

    As far as markup is concerned, HTML5 is a mess, plain and simple, and the less time designers and developers waste contemplating the new elements, the better.

    • 42

      Luke,

      You argue that the popular ALA HTML5 layout diagram (http://www.alistapart.com/articles/previewofhtml5) “fundamentally miscommunicates the intent of the elements as described in the already muddy spec.” If that’s true, then I and a heap of others are in trouble. Books I’ve read so far about HTML5 explain layouts, sectioning, and tags more or less in the same way that article does. I’m rather upset to hear that the hard work I’ve put into understanding HTML5 has resulted in “a long trail of broken outlines.” Have I unwittingly been authoring broken outlines? [Banging head against wall now.]

      This raises a few important questions:

      1) What resources are available that can teach us the proper use of the new HTML5 tags? Or is everything so messy at this point that there is no correct use yet?
      2) If HTML5 markup is such a mess right now, then why use it at all? Shouldn’t we just keep using XHTML until the dust settles?

      • 43

        Hey John,

        Go easy on the wall ;) The correct way to write HTML5 outlines (and use the new elements) is pretty wonkish stuff, and is communicated very poorly in the spec, so I don’t think you’re alone :) It took me several rewrites to feel like I’ve finally nailed it, and I despaired at the thought of anyone who wasn’t writing a book on the topic actually understanding the nuances of outlining with the new elements (and issues such as a lack of backwards compatibility).

        On your questions:
        1) I don’t intend this as self promotion, but I ended up writing a couple of chapters on these issues for my forthcoming book simply because I couldn’t find anyone who had accurately described what the spec actually specifies. I’d like to get some feedback on them so I’ll tweet you if you’d like a look.
        2) Why use the new elements at all? Yeah, I wouldn’t. They actually blow up the page for a very small percentage of users too, which is another issue that hasn’t been given much airtime either. There are new, interesting things you can use though for accessibility (ARIA landmarks). XHTML is a conceptual dead-end too though.

  17. 44

    Semantic meaning always has value. A book, research paper or article all have a definite structure and this is readily apparent in print so why should it not in the web? My concern in has been with HTML (as appears to for many) is the use of DIVs and SPANs, but after reading these articles it becomes readily apparent that these should be considered just as ‘layout control characters’ just as are present in PostScript or LaTeX.

    I also agree that we have to take care not to create too many elements – there are a set of common semantic elements available to us that have been used for centuries so why create more?

  18. 45

    Stating the obvious: Semantics are not just about accessibility, accessibility is not just about assistive technology. But semantic information (name, role, states and properties) carried by HTML elements and attributes is integral to making content on the web accessible, especially for those who rely upon assistive technology to access and interact with web content.
    Historically and currently accessibility support for HTML features in browsers lags behind other facets of feature implementation, and unfortunately accessibility support is not taken into account when browsers announce support for a feature. Which is why we get claims about HTML5 structural elements being implemented in browsers. What is actually meant , pretty much, is that visual styling has been implemented.

    Where there are clearly defined semantics already available via
    acccessibility APIs
    for new HTML5 features, it is easy for browsers to implement the support and no excuse for AT to not understand and convey the appropriate information to users.
    The accessibility implementation and semantics of particular HTML5 elements is still being worked out. This is mostly due to the semantics, from an accessibility support perspective, not being well specified or specified at all in the HTML5 specification. The HTML to accessibility API implementation guide is intended to help with this, but it is still in early development.

    For example, the hgroup element is a mess. Why? because it is an element in search of a cowpath. As currently specified it does not provide a useful semantic to assistive technology users, in fact it does the opposite, it removes potential information about subheadings/subtitles/taglines etc, by forcing implementors to collapse the subheading semantics into the parent heading. That is why hgroup is at risk in the W3C HTML5 specification, with 5 detailed proposals to either abolish or replace it.

    Another example is the header element from discussions with browser and AT implementors, it is considered that the header element does not add much value as it does not provide anything that currently available semantics does not. To understand why, it is useful understand the ways in which screen readers can expose HTML element information to users. As a consequence it may well not be implemented in browsers or AT.

    In regards to the outline algorithm, Jeremy states “The new outline algorithm in HTML5 will make life a lot easier for future assistive technology” which suggests that he is not aware of the implementation of the outline algorithm in JAWS 12/13, unfortunately the current implementation can actually undermine users ability to navigate and understand document structure. Note, also it does not take hgroup into account.

    For a long time, the refrain from certain quarters has been, screen readers don’t support feature X its been in HTMLX for ages, F#@King screen reader vendors. They are an easy target. Part of what HTML5Acessibility was set up to do was draw attention to the browser vendors role in providing accessibility support. I suggest that browser implementation is an integral aspect of HTML accessibility support, without it there is not chance of robust, interoperable access to web content for AT users. Take a look at the debacle with longdesc, AT for the most part cannot be relied upon, and should not need to be relied upon to implement accessibility features, without the browsers doing their part.

    sidenote: HTML5 is still a work in progress, but it’s at a stage now where significant changes must not be handed down from upon high, the community must have the opportunity to be involved in affecting change. Involvement in the W3C HTML working group provides that opportunity, get involved!

  19. 46

    The irony of all this is that the original meaning of ‘DIV’ in HTML 3.2 was ‘document division’.

    i.e. pretty much synonymous with ‘section’, and unlike HTML 5’s “The div element represents nothing at all”.

  20. 47

    I should also add that my comments are specifically about HTML5’s new elements, not all semantic information per se — adding ARIA landmarks is obviously a good thing.

    However, I think it’s worth highlighting the HTML5 editor’s own view of the new HTML5 elements, as contained in this 2009 exchange with Bruce Lawson: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html

    Lawson: “After all, I know of no user agents that can use time, section, footer, datagrid etc but we mostly expect there to be soon.”

    Hickson: “I don’t. Most of the new elements are just meant to make styling easier, so that we don’t have to use classes.”

    That’s straight from the HTML5 my-way-or-the-highway editor’s mouth. No mention of outlining; no mention of accessibility; no expectation they’ll be used at all, which is contrary to Hickson’s own spec. It’s good to see the work being done trying to rangle some value out of these elements for AT at least (and thanks for all your hard work documenting this Steve F), and good luck to anyone who tries to create a logical, backwards-compatible document outline, but these things don’t make the situation any less of a rather dire mess.

  21. 48

    Thanks Jeremy for raising a practical example. This discussion is a tough one as much of HTML5 has clear semantics (nav/header/footer), but then parts have underdeveloped semantic meaning or add confusion to authors.

    Jeremy’s gist is a great example, in fact, of a poor time investment in semantics. It ascribes value to the new method of document outlining, which recently sees different styling for h1’s depending on section nesting. Recent browsers do indeed style the h1’s different; but if you actually structure your document as such, you do it to the detriment of your screenreader users: they will either get these h1’s all as top level headlines or a mishmash of heading nesting levels that don’t match any expected behavior (As an aside, this is completely unrelated but if anyone’s curious what CSS it takes to make that new h1 styling work across browsers… feast your eyes on this beauty)

    Additionally, <hgroup> is on the chopping block and is not supported by JAWS. Suffice it to say, Now is not a smart time to invest your time understanding the unwieldy document outlining algorithm. Luke’s comment above digs in deeper to the messy semantic state of the outlining algorithm.

    The practicalities of making accessible web content are messy, but important. The fact that we seem to spend more time on div vs article vs. section than on learning ARIA is a crime. (Furthermore, learning ARIA isn’t complete unless you’re listening to the results in a screenreader.)

    My recommendation: follow the work of Steve Faulkner and Jason Kiss. These two guys are publishing the only data that illuminates what’s actually happening at the AT level in response to our work. Steve’s comment on this post does a solid job of unraveling this complex topic by showing all the many layers involved: specs, editors, authoring experience, aria, browser impl, screenreader compliance.

    Also if you’d like to investigate what’s happening under the covers, I recommend:

    HTML to Platform Accessibility APIs Implementation Guide – Understand how HTML elements and attributes map to accessibility APIs
    HTML5, ARIA Roles, and Screen Readers in March 2011 – Implementation of HTML5 elements in screenreaders isn’t perfect yet.
    HTML5 and the myth of WAI-ARIA redundance – Will HTML5 make the use of WAI-ARIA in HTML redundant? Definitely not.
    JAWS Support for ARIA – Originally published by Freedom Scientific as a MS Word document. *facepalm*
    html5accessibility.com – Also from Steve Faulkner; this research is hugely comprehensive and backs up the examples Divya provided
    delicious.com/paul.irish/aria – My own bookmarks on semantics, aria and accessibility.

    In summary, I think it’s best to ground our efforts in pursuing semantic value by identifying precisely what the results will be. A fair rule of thumb: when it comes to semantics, if it’s confusing enough for you to ask a question about it, chances are the answer won’t make a realistic difference. Let’s build incredible stuff on this impressive platform and avoid getting mired in semantic inconsequentialities. There’s also room for more author engagement and screen-reader involvement in the standards process regarding these issues; but that’s a large topic I’ll have to save for another day.

    • 49

      I have a concern…
      Authors seem to make less and less distinction between AT and Accessibility.
      I’ve always been against the negative text-indent technique that hides text from screen, but exposes it to screen reader users; and for the same reason, I think we need to warn people about their use of ARIA.
      ARIA is not meant to give authors a free pass. For example, the use of the latest role="img" technique (<div role="img" aria-label="blabla"></div>) demonstrates that developers narrowed their view and are losing (or ignoring?) the big picture.
      Imho, providing content or alternative content to screen-reader users is not the same as writing quality documents. We should think of our audience as a whole, AT is part of the picture, but there is more to it… Much more!

    • 50

      Paul, to play devil’s advocate a bit, you write:

      “This discussion is a tough one as much of HTML5 has clear semantics (nav/header/footer)”

      I wonder if the definition of these really is so clear, specifically the nav element. As defined in the spec (http://dev.w3.org/html5/spec/Overview.html#the-nav-element):

      “The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.”

      The definition implies that it would be semantically acceptable to surround a few links that were listed serially mid-paragraph in a nav element. Additionally, it seems to forbid the use of a nav element to surround a grouping of buttons that controlled the playback of a slides or other nested content, because it implies moving within or leaving the current context.

      I bring this up not to be pedantic about the specification and/or literally reading it versus interpreting it. But therein lies the crux of what is so difficult to define: all specifications will be interpreted, adapted, bastardized, upheld, pushed and pulled.

      It is difficult to argue that there are “clear semantics” but perhaps easier to argue that there are practical, commonly accepted semantics, which folks are welcome to augment, contribute to, or otherwise play with as our industry continues to evolve.

      (PS: I agree with your entire message though — specifically your last paragraph — despite seemingly disregarding it above!)

    • 51

      Great comment Paul, just one small thing: even the “clear” semantics aren’t really – nav may be, but most people assume header and footer are *overall* header and footer, but they aren’t necessarily (as you’re probably aware). According to the spec they can appear in any/every section, so, to use the sepc’s example, every comment on a blog post could be an article, and every comment can have a header/footer (see: http://www.whatwg.org/specs/web-apps/current-work/#the-article-element ).

      This (*gets back on soapbox*) is perhaps the biggest problem with the elements – they have seemingly intuitive names, Hickson tells everyone they’re just to replace what we’re already doing, Jeremy says HTML5 is paving cowpaths, but the actual definition in the spec is neither – it’s not intuitive, or a reflection of common practice.

      Therefore no one is going to be able to do much with these elements programatically, because who do you follow – the spec (header/footer non-sections everywhere), or the very different actual usage (one header ‘section’/one footer ‘section’)? It’s a shame.

  22. 52

    Does anyone know if agents such as Instapaper, Read It Later and Readability take into account the semantics of the elements in question here? I see quite a few examples where these services get the parsing wrong and I’ve often wondered whether improving the semantics and structure of the markup would improve the likelihood of it being parsed correctly. Not only that, but surely the new elements would enrich the capabilities of these services so that they are better able to format asides, captions, sections, and so on?

  23. 53

    By definition, semantics is “relating to meaning in language or logic.” This implies that we, and our activities, are *adding meaning* to something we are presenting, whether by adding descriptors, relating content to other content, deepening contextuality or countless other approaches to enriching the content presented.

    It is central to any discussion of semantics, and the value created by semantically augmenting content, that we are discussing content itself. Semantics as an academic pursuit is indeed a frustrating one because it allows us ultimate freedom at the same time it promises to provide a concise method for describing something to a fresh observer. This — the notion that meaning is within the word, not layered on by context and experience — is the intrinsic difficulty with language that philosophers, linguists, psychologists, writers and like-minded individuals have grappled with since we began communicating. [aside] Just look at how we collectively debate the meaning of “responsive.” [/aside]

    When it comes to technology, specifically the tools we use in developing interfaces, there are so many ways to add semantic clarity to our subjects. As a result, there are perhaps too many layers competing for our attention when we discuss semantics — browser capabilities, what technology one’s site uses, alternatives for the visually impaired, the way meaning changes based on the device consuming the content, etc. — to allow for a discussion that is considerate of all the circumstances, while being directly applicable to those participating in the discussion, as well as the larger, arguably more important stakeholder, those that will ultimately consume our content.

    I’ll stop being academic and get specific. While it may be appropriate for a blog or magazine to wrap it’s posts in an article tag (based on a socially agreed upon definition of article), it is perhaps not semantically accurate to say that the abstracts of of those articles in a list should be surrounded in an article tag. So,
    1) we could propose and flesh out an abstract tag for this purpose
    2) we could create a class or other attribute that adds meaning
    3) we could use a div in the list instead and use attributes to clarify
    4) we could use divs everywhere and use attributes on all of them to lend meaning

    The point is, all of these strategies rely upon some modicum (usually much more than that) of agreement as to the meaning of the device in use. For something like a magazine story or encyclopedia entry article makes great practical sense. For a presentation of slides that a user can navigate in place, what is the appropriate entity? Video? Audio? Article? Probably none of these. It may be that one person thinks of it as a series of figures with a nav all in one article, while another thinks of it as a series of divs containing further markup all wrapped in a container div. Should we create slide and slidedeck tags? Maybe?

    As Jeremy implores, if you feel passionate about what is present or absent, speak up and become active, and I’m sure that Divya vehemently agrees. If at the end of the day the result doesn’t meet your needs, there are many ways to work with what we’ve got, all of which have pros and cons and none of which are more right or wrong, but you really can’t complain for having not taken action when you had a chance.

  24. 54

    Another reason why the web is where it is today, too many people arguing over pointless crap and bashing personal opinion’s.

  25. 55

    From Ryan Dahl, creator of Node.js:

    The amount of complexity I’m willing to tolerate is proportional to the size of the problem being solved.

    Although Ryan was talking about software in general, I think that quote is appropriate to the whole semantics issue.

  26. 56

    for me the semantic value for instance, when constructing a language translation tool, such as a compiler it .

  27. 57

    Thanks Paul

  28. 58

    http://www.onderhond.com/blog/work/in-defense-of-semantic-value

    My take on the current discussion in blog form. The bottom line:
    “Semantics matter. If not today, then hopefully tomorrow. And if not tomorrow, you know who to blame.”

  29. 59

    You have raised such a good points. I would apply these on my websites as well. I really like the way of writing too. Thanks

  30. 60

    Would you say this piece was a nice section, or a nice article? ;-)

  31. 61

    Another benefit of using semantic html5 elements properly that people seem not to mention particularly often: makes very generic css rules much more intuitive especially when using advanced operators like ‘>’

  32. 62

    The length of these comments are ironically emblematic of the problem. : )

  33. 63

    Haven’t you learned your lesson yet Divya? People are trying to knock you down a peg or two because you are deluded about your own abilities and the extent of you knowledge. Being so naive and new to the game, you couldn’t possibly know enough to see the big picture of this issue.

    I’ll let you in on a secret. Just because a few kids and “web rockstars” tell you that you’re smart and use your hopeless open source projects doesn’t mean you should get ahead of yourself. Typically the ones that will call your bluff will be the least vocal people right up until you go too far, get too smug and arrogant and fabricate glaring errors and logical fallacies.

    I know it seems all new and revolutionary to you but you’re not the DHH of web semantics yet. You have to earn that respect. It may feel good when a few clueless kids naively mistake you for a genius but you’re not so wise that your word is gospel yet.

    When your opinion actually holds some weight, you won’t have to be so smug and self-absorbed in delivering it.

  34. 65

    I’m still not entirely convinced on converting from divs to semantic coding. At it’s core, semantic coding is supposed to make your mark-up more logical by adding meaningful descriptions to tags. That’s it. I don’t care what other purposes you want to make up for it. Semantic more or less means to “make meaningful” and if that is not the point of semantic coding then it’s misleading everyone by being called that.

    Other issues arise from the fact that I am not entirely obsessed with how my code looks. I still like to make my code look neat and tidy for the benefit of any other designers (or myself) reading it but otherwise, the tags I use and how I use them don’t matter much to me as long as the page looks how I want it to in all major browsers.

    Semantic coding and web standards used to mean quite a lot to me but over the years I’ve learnt that in the “real world”, these concepts have no practical use. Professional developers do not design for themselves, they design for their clients who in-turn want a website that works for them and their users. Your clients don’t care if the website follows proper web standards or uses semantic coding. They probably don’t even know what these are, nor do they care.

    At the end of the day, the end user, your client, only cares about one thing: That the website works. So make it work. Stop wasting so much time learning about new practices when your old ones have worked for over 10 years and are still working. If you use semantic coding automatically now then good for you, but that doesn’t make your client happier, does it?

↑ Back to top