Interesting stuff, certainly; there is without a doubt some utterly grotesque mark-up out there.
A couple of points:
Firstly, your aside about using rel=“tag” on links isn’t right. rel-tag has a more specific purpose than just any link to a tag page:
By adding rel=“tag” to a hyperlink, a page indicates that the destination of that hyperlink is an author-designated “tag” (or keyword/subject) for the current page [emphasis mine]
Therefore the list of tags following a blog post should be marked up with rel=“tag”, as they link to the page that aggregates all content for that tag. But a tag cloud is a summary of those tags; you’re not ‘tagging’ the current page, so those links shouldn’t have rel=“tag”. They’re just regular hyperlinks.
As for tag cloud mark-up, I agree completely with the analysis of existing mark-up. Technorati tried to be semantic but lost the plot a bit when they reached such deep nesting. That said, I’m not sure they’re completely wrong for using EM.
I think there are two distinct lines of thought for this. The first is that HTML does not have sufficient means to describe this cloud representation of tags and that therefore classes should be used on top of generic mark-up. The second is that HTML does not have sufficient means so we should use the closest matching mark-up we can find.
The nearest-match for tag clouds is EM and STRONG. In whatever context, the use of text size in a tag cloud is to emphasise one tag over another. The problem is that that only provides three levels of emphasis (none, EM, STRONG). For the project I’m working on at the moment I’m taking the ‘nearest match mark-up’ approach and have contrived a forth level with EM nested in STRONG.
Is nearest-match the way to go? I’m not sure. There are times when using nearest-match mark-up risks devaluing the semantics of the elements used (not dissimilar to TABLE being devalued for all its misuse in layout; could browser makers have done something amazingly cool with data tables had they only been used properly?). My feeling is that in the case of EM and STRONG in a tag cloud the devaluation is nil and so for me — in a situation where four size levels is sufficient in my cloud — I’d rather take some HTML semantics.
Ben Ward
Interesting stuff, certainly; there is without a doubt some utterly grotesque mark-up out there.
A couple of points:
Firstly, your aside about using rel=“tag” on links isn’t right. rel-tag has a more specific purpose than just any link to a tag page:
Therefore the list of tags following a blog post should be marked up with rel=“tag”, as they link to the page that aggregates all content for that tag. But a tag cloud is a summary of those tags; you’re not ‘tagging’ the current page, so those links shouldn’t have rel=“tag”. They’re just regular hyperlinks.
As for tag cloud mark-up, I agree completely with the analysis of existing mark-up. Technorati tried to be semantic but lost the plot a bit when they reached such deep nesting. That said, I’m not sure they’re completely wrong for using EM.
I think there are two distinct lines of thought for this. The first is that HTML does not have sufficient means to describe this cloud representation of tags and that therefore classes should be used on top of generic mark-up. The second is that HTML does not have sufficient means so we should use the closest matching mark-up we can find.
The nearest-match for tag clouds is EM and STRONG. In whatever context, the use of text size in a tag cloud is to emphasise one tag over another. The problem is that that only provides three levels of emphasis (none, EM, STRONG). For the project I’m working on at the moment I’m taking the ‘nearest match mark-up’ approach and have contrived a forth level with EM nested in STRONG.
Is nearest-match the way to go? I’m not sure. There are times when using nearest-match mark-up risks devaluing the semantics of the elements used (not dissimilar to TABLE being devalued for all its misuse in layout; could browser makers have done something amazingly cool with data tables had they only been used properly?). My feeling is that in the case of EM and STRONG in a tag cloud the devaluation is nil and so for me — in a situation where four size levels is sufficient in my cloud — I’d rather take some HTML semantics.