Microformats Would Benefit From a Namespace
Published on Sep 13, 2007 (updated Jun 19, 2024), filed under development, html, css, maintainability (feed). (Share this on Mastodon or Bluesky?)
This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.
Microformats (“simple, open data formats”) become more and more popular, accelerated by the questionable success of the nofollow microformat. However, those of them that mandate class names cause problems that could be avoided by using a “pseudo-namespace.”
The idea behind namespaces is not new, and they already mean an aid in large projects as part of a defensive development strategy. They basically mean to add a prefix to ID and class names in order to create more efficient style sheets, preserve meaning, and ensure flexibility.
For microformats, not using something like namespaces means problems that will turn critical in the long run:
Right Now, Microformats Limit “Regular” Web Development
The hCard microformat alone blocks more than 20 class names, use of hCalendar blocks 3, at least, and other microformats also require class names that might be legitimate names for other uses. This means a limitation: Once an author settles for a microformat, use and, above all, formatting of certain classes can become a problem.
Example: Use of a photo class. It can usually be used at will, but when using hCard, hCard “blocks” this class since the styling of photo is now restricted—it might affect the hCard presentation (this “might” is problematic enough). It is not an option to, say, format .photo { padding: 1em; }, only to add .vcard .photo { padding: 0; }. Any other enforced modification of selectors means a limitation, too, as in .section-that-contains-no-microformat .photo. This is inelegant, inefficient, and shouldn’t be acceptable.
A general or microformat-specific prefix would mitigate this: mf-photo, for example, leaves authors all room to use names they wish; at least it reduces the likelihood that there are conflicts. It means a “win/win”—not only will it become simpler to add microformats to projects, but could the microformats community also go on creating more formats.
Right Now, Microformats Cause Unnecessary Cognitive Load
As the former point shows, some microformats affect authoring by adding an unnecessary cognitive burden: “What class names cannot be used safely anymore, because they’re occupied by microformats?”
This is a question nobody should be forced to ask. Microformats may be cool, but it’s not their job to constrain web development and to make work harder. This is a strict point of view, but theoretically, development of microformats could result in blocking every name available; meaning that one day, there’s need to create class name whitelists for web authors (this is probably an exaggeration).
But hopefully, the point is clear: The uncontrolled spreading of microformat class names isn’t trivial and has a clear impact on everyday work, as soon as people want to use microformats but also like to stay independent. A simple thing like a prefix might help, so that anyone can use microformats and at the same time be unconstrained when it comes to other code.
Right Now, Microformats Introduce Unnecessary Layout Risks
For the reasons already mentioned, the larger the project and the more decorators, designers, and developers involved, the greater the likelihood that there are unforeseen display problems maintaining and expanding the respective project. Microformats currently require developers to be aware of the constraints imposed by microformats. This is, again, avoidable.
❧ The argument had to ignore the history of certain microformats, like hCard’s intentional congruence with vCard. It’s biased towards namespaces, as these must not mean the only solution. For some, the mentioned problems might appear abstract and distant; in that case I hope that there’s agreement that it’s useful to look for solutions that avoid problems by design.
I ask the microformats community to reconsider current naming practices at least not to amplify the mentioned problems. In the long run, microformats should not stand in their own way.
Curiously, this is one of the most challenging articles I’ve ever written. Even now, after about 20 reviews and revisions, I’m still not happy. On the other hand, I’m passionate about the subject. I’m looking forward to your thoughts.
Update (September 14, 2007)
Both comments and discussion brought up two other aspects:
I understand that microformats sympathizers do not feel good about having a set of class names like, as with hCard,
uf-vcard,uf-fn,uf-org,uf-adr,uf-region, and so on. I can’t say that I love it, either, but this is what would help.There’s a consequence that’s been left out before. I may cite my mail to Ryan from Technorati:
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” [microformat] design to require CSS modifications then.
Update (September 17, 2007)
Another discussion snippet just sent for clarification:
Regarding HTML, current web dev practice focuses mostly on styling, while microformats focus more on semantics. This difference in focus should underscore why there’s an increasing probability of conflicts, especially when adding microformats to large projects.
Predefining class names isn’t trivial. vCard, for example, uses names that few authors would typically choose, and thus it’s at least questionable whether the microformats community can assume something like “consensus on semantics.”
I venture that namespaces do make it easier to create new microformats. With namespaces, there’s a very low chance that there are ever any conflicts even when the project in question uses millions of pages, thousands of IDs and classes, and hundreds of web developers. People might actually be more eager to use microformats.
About Me
I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve been working as a technical lead and engineering manager for companies you’ve never heard of and companies you use every day, I’m an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for O’Reilly and Frontend Dogma.
I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)