Our Pointless Pursuit Of Semantic Value (opens in new tab)

The link to the IRC logs in that piece was fascinating. To see Mark Pilgrim - who was always at the pragmatic end of things when it came to the accessibility debate - recanting many of the positions he takes in 'Dive into Accessibility' tells you how little of the things that we've been promised for years have actually amounted to anything.

Don't believe anyone who tells you anything about markup best practice until they can point you to a shipping user-agent that will make use of it and introduce you to a living human being who will experience some tangible benefit.

Frankly, this couldn't be more wrong. Every website in that list has plenty of semantic structure that is lost in the HTML.

- Facebook, Twitter, Linkedin and Wordpress (not to mention HN) has plenty of structure that could be surfaced by SIOC[1].

- Wikipedia is the king - see DBpedia[2].

- Amazon (and to a lesser extent, eBay) are a perfect fit for Good Relations[3], which is already used by Very Big websites to provide value to customers.

The problem with this post is that reduces the Semantic Structure movement to HTML5. Yes, HTML5 semantic tags may not be worth it, but there's much more to the semantic web technologies than that.

[1]: http://sioc-project.org/ [2]: http://dbpedia.org/ [3]: http://www.heppnetz.de/projects/goodrelations/

It makes it more readable because you can quickly see the differences in elements instead of just seeing <div> everywhere. It also simplifies and cleans up CSS a bit as you can define more base element styles and then extend them with classes and IDs.

Yes, debating whether to mark up your forms using UL or OL or LABEL or SPAN or DIV or DL or TABLE or ... is a total waste of time. That doesn't tell us anything about the usefulness of machine-readable linked data, though. The two subjects have nothing in common except a relatively unusual adjective.

It's like going back to the early 1980s and blogging about how computer graphics suck so you shouldn't be wasting your time looking into them.

To me this article is a very good rebuttal to a lot of the arguments that people were throwing around at that time. However these days things are different...

The emergence of WHATWG and the unification of the HTML5 standard and a recommitment by the W3C towards on-the-ground pragmatism have really changed the standards world. HTML5 to me is a breath of fresh air. When I read about the new elements I see that they are directly addressing real world issues, and I see that browsers seem to be picking them up pretty quickly. I don't see a lot of bloat or pointless ceremony like XHTML 2.0, and there is always an eye towards backwards compatibility.

Given these developments, I'd say the effort to understand and utilize HTML5 appropriately is a good investment even if there are no material benefits for a particular tag at this point in time. I don't see it as the huge time sink the author makes out, but rather as something I spend a couple hours a month doing as part of my regular job. It's not about obsessing over things, but just having an ambient awareness of what tags are there and how to use them so that my work is of higher quality and reaps whatever future rewards come down the pipe without extra effort.

I used to promote the idea of having parallel .rdf files, for example, index.rdf with the same base URL as index.html, etc. but with RDFa life is good enough. I still like my old idea however, but without this being a standard or at least a common practice it is not of much value.

I haven't seen a div tag in years. Unless your market is other designers do what your customers will pay for rather than whatever is in vogue. I wonder what fashionable designers would think about a site like HN still using tables.

Actually, I quite agree. The days of being able to make sense of web pages via markup are gone. It was a good goal once, but the effort has failed. Time to move on and find a better accessibility solution.

It's all about readability and, call it crazy, but I think markup and code are like poetry. Imagine trying to have universal semantics for poetry...it seems dumb, right? But general practices make sense and general types of structure are good for different things.

Code and markup should be looked at the same way. This article, to me, did a great job reminding us of that.