Jens Oliver Meiert

Microformats Would Benefit From a Namespace

Published on Sep 13, 2007 (updated Jun 19, 2024), filed under (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:

Update (September 17, 2007)

Another discussion snippet just sent for clarification:

About Me

Jens Oliver Meiert, on November 9, 2024.

I’m Jens (long: Jens Oliver Meiert), and I’m a web developer, manager, and author. I’ve worked as a technical lead and engineering manager for small and large enterprises, 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.)