On Sep 14, 2007, at 2:02 AM, Jens Meiert wrote:
The microformats community could happily go on with creating yet more names if these were at least neutralized with a prefix or suffix or whatever, while about everyone might change or extend sites just as he or she wants, not being forced to think about possible interactions with microformat elements.
I think it's actually better that publishers do think about possible interactions with microformat elements, and all other elements for that matter. Increased awareness of the implications made by markup is a good thing. It's the basis of semantic HTML. If someone doesn't want to think about how their markup will be interpretted, they're free to go on using <table> for non-tabular data and class="photo" for elements that aren't actually photos, but by doing so they miss out on the benefits of a shared vocabulary.
There's a reverse side, though: Several people might indeed want to style elements with the same class names the same way (assuming semantical agreement, this makes total sense). But, it still seems to mean better, more "unobtrusive" design to require CSS modifications /then/.
That doesn't make much sense to me. I think it makes sense that a given class, say "photo", should mean the same thing everywhere it's used. If you're using "photo" to mean something different from what it means in hCard, one of the two is using an odd definition of the term. Converging on single definitions for terms is a good way to ease communication, just as it is with natural language, hence we have dictionaries.
But even if we were to assume (charitably, I think) that the divide between publishers who want their hCard photos to behave/look different from all their other photos and those who want them to behave/look the same is roughly 50/50, the former half is still smaller because not everyone uses class="photo" outside hCard. Your namespace would require more work from *all* publishers, whether or not they actually have conflicting class names, whereas the current naming conventions only require more specific selectors in the (hopefully increasingly) rare cases where we don't all mean roughly the same thing with a given term.
It seems you're arguing for a mechanism to ease the continued fragmentation of HTML semantics, but I think the whole point of microformats is to standardize on shared meaning.
Peace, Scott _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
