Firas Durri: Enthusiast

Some concepts are composed of such obscure scholastics that I find myself right at home among discussions fussing about them. Like ‘Semantics in Markup of Ranked Tag Lists’. Let’s talk about machine intelligence as it relates to a strange graphical representation of social software’s edgy reinvention of keywords!

Joe Clark said that Technorati’s tag box could use semantically better markup than inline style attributes specifying font-size. “Self-evidently, a tag collection of this sort is an unordered list with an assumed default size that is modified by big and smallâ€?. I’d cursorily agreed, because I’m sympathetic to the argument that semantics are sometimes forced into inappropriate uses—the <i> tag is not completely replaceable with with the <em> tag.

So when Matt linked to Joe Clark’s post I chimed in with a rationale for using <big>, saying that it’s a more appropriate element than <em> in this context. Joe Clark’s update has a good point, that the essense of weighted lists is presentational anyway, hence the core of their meaning is the dimension: big and small.

However, as Tantek says, <big> and <small> are about “fonts and nothing more”. So when he updated Technorati’s tag box in response, he used nested <em>s. But I agree with a commentor over at Matt’s—dave— when he states that nested <em>s benefit neither man nor machine.

Dimitri Glazkov articulates the abstract problem in a comment at Anne Van Kesteren’s:

What you are dealing [with] here is attempting to express two dimensions of relationships (alphabetical + importance) for a set of items using one dimension (serialized presentation of content, aka markup). If we learned anything from the math classes in college, you can’t express N dimensions using N-1 dimension without sacrificing some integrity and having to resort to “assumed” relationships, which are expressed by an additional semantical structure. [...]

HTML/CSS doctrine itself does not provide a clear pattern on how to handle these situations, and thus the interpretations of the Bible begin, with all the semantic sophistry that always accompanies them.

There are two ordered lists here: a list of keywords sorted alphabetically, and a list of keywords sorted by popularity. The on-screen representation shows one as the linearized display of elements (top-to-bottom, left-to-right for English), and the other as the rendered dimension of these elements (larger means more significant.) HTML lists specify just one order (or maybe they should have a sort="alphabetical" attribute—then the tags can be marked up as a list ordered by popularity.)

So, turning off the CSS on Tantek’s implementation loses the tag popularity information, and Joe Clark’s suggestion mixes semantics and presentation. I’d go for the former, but a pox on both houses, I say; dave had the suggestion of using a table with term and popularity columns. It does change the meaning of the weighted list, turning it into a table instead, but that sort of thing degrades excellently. Intruiged by his suggestion that table rows can be displayed inline to recreate the tag-box style, and because putting the tags in a table and using class attributes on the rows allows the popularity to be conveyed by other ways than term size—colour intensity, for example, or a bar chart—I made a demo.

Tags CSS Demo

Behaves well in Firefox (yay for Gecko), kinda works in Opera, and completely fails in IE. This can probably be worked around, though, because IE fails more because of the selectors than because of the properties. A sprinkling of class and id attributes should take care of that.

Ultimately, I don’t expect this to be much of a problem, because as soon as one veers into bar graph and pie chart chart territory, it becomes clear that such representations of data are best displayed in graphic formats like jpeg or svg. Charts are fundamentally visual, and the only way to make them accessible, or otherwise readable as text, is to summarize the trends they convey.

Incidentally, Dimitri is right about the ‘semantic sophistry’ these discussions entail. Tantek’s aside on the HTML spec’s “abuse of a <dl>/<dd>” reminded me of my being irked by this part of the spec:

Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words.

Well, that’s hardly a definition list, now is it? It’s not a set of key-value pairs either, because the keys aren’t unique; each speaker may have hundreds of different interjections in the overall dialogue, as in a play. What’s required is a way to specify a list where one element can be paired with the next, loosely associated for whatever purpose the document author wishes—definition lists are just one example.

But none of this really matters. Neither a ‘definition list’ nor the ‘meaning’ of nofollow matter outside of an English-speaking context. I wonder whether 50 years from now these discussions will be archaic, because markup will have become as democratized as language, where the only ‘proper’ way of saying something is the way everyone else understands it. On the other hand, the 90s HTML mess was begotten of just such a democratization, and the following contemporary mindset holds quite contrary beliefs. There will always be company for those fond of obsessing over slight pedantic vagaries.

Related: Tim Bray on markup and meaning: “I think that this whole area of thought is what over in the W3C TAG we refer to as a “rat-holeâ€?. I.e., something you can vanish down never to re-appear, or at least a place where you can waste a lot of time scurrying along twisty little passages. [...] [W]e shouldn’t try to kid ourselves that meaning is inherent in those pointy bracketsâ€?.