When John Allsopp was working on his tagcloud effort, I started documenting some of the syntaxes you had done (though didn’t get very far). I did, however, come up with my own proposals.
Essentially it occurred to me that we’re working with two constraints (among others): (1) to be semantically meaningful in the source code such that it’s machine parseable but not human-offensive and (2) to reflect the relative tag weight in the visual, “graph” display (after all, a tag “cloud” is really just a visualization of data, like a pie chart).
In order to do this without being verbose in markup, while maintaining semantics, and while also allowing for default renderings to make sense in graph sense (think about a tagcloud on a cell phone browser — i.e. without styles applied), I realized that all this nonsense that we’re really looking at an ordered list and that presentation is not necessary is completely false. Indeed it is the rendering of the data that makes tagclouds useful — as a summary of the relationships between multiple items in a set. Additionally, to presume that tagclouds only refer to popularity (as opposed to prevalence or frequency) is also a terrible mistake: piecharts don’t only refer to how much apple strudel one can eat!
Anyway, I choose a path that would be both semantically accurate, somewhat condensed and universally accessible. It can be improved, surely, but I think the combination of em, strong, big and small tags can be rather flexible at expressing thie graphed data.
In any case, I’d love to see folks revisit their proposals given the constraints I’ve discussed above.
Chris Messina
When John Allsopp was working on his tagcloud effort, I started documenting some of the syntaxes you had done (though didn’t get very far). I did, however, come up with my own proposals.
Essentially it occurred to me that we’re working with two constraints (among others): (1) to be semantically meaningful in the source code such that it’s machine parseable but not human-offensive and (2) to reflect the relative tag weight in the visual, “graph” display (after all, a tag “cloud” is really just a visualization of data, like a pie chart).
In order to do this without being verbose in markup, while maintaining semantics, and while also allowing for default renderings to make sense in graph sense (think about a tagcloud on a cell phone browser — i.e. without styles applied), I realized that all this nonsense that we’re really looking at an ordered list and that presentation is not necessary is completely false. Indeed it is the rendering of the data that makes tagclouds useful — as a summary of the relationships between multiple items in a set. Additionally, to presume that tagclouds only refer to popularity (as opposed to prevalence or frequency) is also a terrible mistake: piecharts don’t only refer to how much apple strudel one can eat!
Anyway, I choose a path that would be both semantically accurate, somewhat condensed and universally accessible. It can be improved, surely, but I think the combination of em, strong, big and small tags can be rather flexible at expressing thie graphed data.
In any case, I’d love to see folks revisit their proposals given the constraints I’ve discussed above.