Our Pointless Pursuit Of Semantic Value(coding.smashingmagazine.com)
coding.smashingmagazine.com
Our Pointless Pursuit Of Semantic Value
http://coding.smashingmagazine.com/2011/11/11/our-pointless-pursuit-of-semantic-value/
28 comments
God, no. Please don't help to spread this horseshit.
Here are the user agents that make use of it:
- ChromeVox: https://chrome.google.com/webstore/detail/kgejglhpjiefppelpm...
- NVDA: http://www.nvda-project.org/
- Window-Eyes: http://www.gwmicro.com/window-eyes/
- VoiceOver: http://www.apple.com/accessibility/voiceover/
- JAWS: http://www.freedomscientific.com/products/fs/jaws-product-pa...
- Orca: http://live.gnome.org/Orca/
And two dozen others. And here a few living human beings that benefit from it:
http://www.youtube.com/watch?v=Mwoe7OjIxpw, http://www.youtube.com/watch?v=pntGp00HHr8, http://www.youtube.com/watch?v=dAw0SIkXm1o, http://www.youtube.com/watch?v=ZBzSXIEusoU, http://www.youtube.com/watch?v=-zSTJwIULYU, http://www.youtube.com/watch?v=6_TFHqIHBqM
285 million people are visually impaired in the world. Putting aside the SEO, meta-data and other discussions, I think this is a pretty meaningful argument in favor of doing it right.
Here are the user agents that make use of it:
- ChromeVox: https://chrome.google.com/webstore/detail/kgejglhpjiefppelpm...
- NVDA: http://www.nvda-project.org/
- Window-Eyes: http://www.gwmicro.com/window-eyes/
- VoiceOver: http://www.apple.com/accessibility/voiceover/
- JAWS: http://www.freedomscientific.com/products/fs/jaws-product-pa...
- Orca: http://live.gnome.org/Orca/
And two dozen others. And here a few living human beings that benefit from it:
http://www.youtube.com/watch?v=Mwoe7OjIxpw, http://www.youtube.com/watch?v=pntGp00HHr8, http://www.youtube.com/watch?v=dAw0SIkXm1o, http://www.youtube.com/watch?v=ZBzSXIEusoU, http://www.youtube.com/watch?v=-zSTJwIULYU, http://www.youtube.com/watch?v=6_TFHqIHBqM
285 million people are visually impaired in the world. Putting aside the SEO, meta-data and other discussions, I think this is a pretty meaningful argument in favor of doing it right.
You (and I to a certain extent) need to be more specific. You've provided a list of screen readers. What I was really trying to say was "when someone argues that a particular markup or technique has benefits, then they need to demonstrate a real user with a real need who will benefit using shipping technology".
So we would need to pick a particular point of contention and then we can argue the toss.
So we would need to pick a particular point of contention and then we can argue the toss.
PS If you read the Mark Pilgrim IRC logs he caricatured the response he often found when criticising any aspect of accessibility best-practise as "OMG!!! YOU HATE BLIND PEOPLE!!!". It's an effective way of shutting down debate and doesn't help anyone.
until they can point you to a shipping user-agent that will make use of it
Chicken and egg can be a problem. Someone could very well be saying "there's no point in developing a browser which can understand semantically structured data since almost no website implements it".
Chicken and egg can be a problem. Someone could very well be saying "there's no point in developing a browser which can understand semantically structured data since almost no website implements it".
Yea, the sad thing is that, for example, back in the day Viola had built-in support for collapsible lists:
http://groups.google.com/group/alt.html/msg/ddc97911c2f9a6f4
http://groups.google.com/group/comp.infosystems.www.authorin...
http://groups.google.com/group/comp.infosystems.www.authorin...
http://groups.google.com/group/alt.html/msg/ddc97911c2f9a6f4
http://groups.google.com/group/comp.infosystems.www.authorin...
http://groups.google.com/group/comp.infosystems.www.authorin...
XML, RDFA, Dublin Core and other structured specifications have very solid use cases, but those use cases do not account for the majority of interactions on the Web.
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/
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/
[deleted]
Semantic markup is more than just accessibility for me. Even if it doesn't add semantic value to browsers, search engines, or screen readers, it's beneficial to me while developing.
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.
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.
The conflation of "semantic HTML" with "the semantic web" has done immeasurable harm to both causes.
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.
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.
Or, to put it another way, there are two different kinds of semantics in play; the semantics of a document (this is a title, this is a paragraph, ...), and the semantics of the subject of a document (this is the price of the item, this is how many we have left in stock, ...).
The costs and benefits of enhancing one are different and separate from the costs and benefits of enhancing the other.
The costs and benefits of enhancing one are different and separate from the costs and benefits of enhancing the other.
The fact that our current systems for giving semantic classifications to web content are insufficient does not mean that giving web content semantic meaning is a pointless idea.
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.
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.
I disagree and don't think that's the point of the article. The analogy you gave is a little hinky, too.
The main point here is that too much time is wasted on simple issues. While energy is heaved into whether or not <time> is a better tag than <data>, a lot of actual work and design could have been done.
The main point here is that too much time is wasted on simple issues. While energy is heaved into whether or not <time> is a better tag than <data>, a lot of actual work and design could have been done.
I work in a front-end only dev shop, and while we might have a few hour-long discussions on markup scattered around the year, there aren't enough elements in the spec to keep us busy for a day. The article is just exaggerating the "issue".
Hmm, I've been doing web development for over 15 years now, and I was one of the first to jump on the CSS bandwagon ca. 2000. Most of the hand-wringing semantic purity came from front-end people doing small sites or blog templates, and the high watermark was around '03. There was a long period of stagnation and XHTML dying on the vine while the world continued using IE6 interminably.
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.
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.
HTML5 is new enough that this has yet to be fully realized, but I'm hoping that the semantic labels help in getting content creators to think more non-linearly. For developers (and perhaps, print layout people), it's an accepted fact that the web is not just a sequential ordering of text with the occasional image. I suspect it's been harder for others to break away from that when all they see is divs.
I have had RDF market on some of my sites for about 10 years, but was not happy with available notations until RDFa which I like.
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 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.
With a decent web framework, creating a template which generates RDF from the same data source should be reasonably easy, if you know what ontologies you're targeting.
But yeah, having RDFa, there's no much point in that; clients should be able to parse the triples from it too.
But yeah, having RDFa, there's no much point in that; clients should be able to parse the triples from it too.
Or you could just use haml and .notation
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.
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.
Semantic language has it's limits and rightfully so. The point of communication (sometimes) is to add something new. New things by definition have no pre-defined category. Therefore some content can only be described by inventing something. It's a moving target. I guess some attempt is a good thing like having a <title> tag, but it will never be perfect and if some day it is perfect then we are a dead species. I sincerely hope that most data continues to defy description.
Slanted and biased. I mean, just look at the author's name :)
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.
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.
But they aren't, they're just starting!
For example, search on Google for "Hearty Vegetable Lasagna Recipe". The way Google is able to recognize the review score, preparation time and number of calories of the recipe was extracting from the semantically tagged markup.
Now search for "Inception". See how Google recognized the review score, the director and the cast? Again, all from semantically tagged markup.
It's not over - it's only now beginning. But HTML5's new "semantic elements" are not the answer. RDFa, Microformats, Microdata - that's the real future.
For example, search on Google for "Hearty Vegetable Lasagna Recipe". The way Google is able to recognize the review score, preparation time and number of calories of the recipe was extracting from the semantically tagged markup.
Now search for "Inception". See how Google recognized the review score, the director and the cast? Again, all from semantically tagged markup.
It's not over - it's only now beginning. But HTML5's new "semantic elements" are not the answer. RDFa, Microformats, Microdata - that's the real future.
I think there are some generally "semantic" things that are just good practice, like using logical classnames, keeping markup and styles separate, using the right list type for the task, etc. but I completely agree with the article.
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.
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.
I thought Best Buy was seeing increased revenue from adopting RDFa?
Anyone else think it's kinda funny the author's name is Divya?
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.