Microformats Would Benefit From a Namespace

Published on September 13, 2007 (↻ June 19, 2024), filed under Development (RSS feed for all categories).

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 (great). 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

Jens Oliver Meiert, on November 9, 2024.

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, 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. (Please be critical, interpret charitably, and give feedback.)

Comments (Closed)

On September 13, 2007, 22:22 CEST, Chris Baker said:
Interesting. This has always been my main concern with Microformats. It will be interesting to see how the community reacts to this.

I wonder about even going as far as creating a pseudo-namespace metatag declaration in the header for parsing by automated tools.
On September 13, 2007, 22:24 CEST, André Luís said:
I believe everyone can understand what you mean, even with all the revisions. 😉 “uf-” seems like a good candidate for a microformats pseudo-namespace, btw.

I think we’re too far into the game to start re-writing every set of uf properties, though.

This is something that could be taken into consideration on future formats, but I think rewriting the existing ones is more than risky, it’s dangerous.

+1 for importance. This should be made a guideline to follow in the future. Let’s see what the good folks of uf-discuss have to say about this. 😉
On September 14, 2007, 0:20 CEST, Scott Reynen said:
The first thing you need to realize is that microformats are already widely published, and any changes that require updating all that publishing face an uphill battle. Beyond that, it seems your three points all boil down to microformats monopolizing class names. But they only do so within the context of relatively obscure root classes.

It is not an option to, say, format .photo { padding: 1em; }, only to add .vcard .photo { padding: 0; }

Why not? This works fine in my experience. Is it just too much work, or did this actually fail for you? I don’t see a significant difference between .vcard .photo and .vcard-photo.
On September 14, 2007, 0:27 CEST, Jeremy Keith said:
Microformats already have de-facto namespacing; the class of the root element of the microformat. The 20 classes from hcard that you mention can be used with impunity anywhere in your document. They are only parsed as hcard components when they are contained by an element with class=”vcard”. So if you’re worried about styling images with a class of “photo” within an hcard differently than those outside, just use specificity. That is far, far simpler than adding even more classes to every class name used by a microformat.
On September 14, 2007, 1:14 CEST, Jens Oliver Meiert said:
The first thing you need to realize is that microformats are already widely published

Yes, that’s why I’d welcome consideration for namespaces in upcoming microformats.

Why not? This works fine in my experience. Is it too much work, or did this actually fail for you? I don’t see a significant difference between .vcard .photo and .vcard-photo.

Well, I refer to the additional efforts. If there was mf-photo or uf-photo, one wouldn’t even need to think about, let alone change anything when photo was used.

Microformats already have de-facto namespacing; the class of the root element of the microformat.

Probably for microformat parsing, but not for CSS development. The microformat root means certain context, but it doesn’t give the freedom that the suggested namespaces offer.

The 20 classes from hcard that you mention can be used with impunity anywhere in your document.

That’s what I wanted to disprove with the photo class example. If any of these classes is used in another context—and current practice makes that more and more likely—where it is treated (presented) differently, problems arise, and be it “just” an additional rule to overwrite styling for that element within the microformat context.

That is far, far simpler than adding even more classes to every class name used by a microformat.

I didn’t propose to add more class names—instead, they should be prefixed.
On September 14, 2007, 13:59 CEST, André Luís said:
I don’t think you should disregard this topic just because it hasn’t bitten you in the rear, yet.

As far as my experience goes, I’ve never had any types of collision. And if I did, I think I overlooked it since specificity is your friend.

And I also like the position on semantic relevance. If it’s a photo, it’s a photo everywhere. If not, you just need to write your css carefully and that’s not just about microformats. If you write careless css code, you’ll bump into more problems than collision with uf. 😉

Still, keep this in the back of your head when spec-ing new formats… that shouldn’t hurt, should it?
On September 14, 2007, 17:10 CEST, Jens Oliver Meiert said:
Well, just because we who discuss here never had these problems doesn’t mean that they don’t exist. Problably symptomatic of theory 😉

(Some comments removed.)
On April 23, 2008, 21:24 CEST, Jordan Clark said:
PS: A handy resource that will help people avoid the class-name clash is the microformats document on existing classes.
On April 23, 2008, 21:24 CEST, Jordan Clark said:
Bang on. Don’t get me wrong, I think microformats are great, but one thing that concerned me was the “blocking” of classes, as you put it.

I had already used class names such as email, logo, and url etc. in different contexts, and I had no choice but to rename them. Seeing as my personal website is quite small*, it was not a big problem, but it would be for a lot of medium- to large-scale websites.
On February 16, 2009, 12:47 CET, Andy Mabbett said:
Twitter’s hCards on user profiles are broken, because they use class=”label”, within their hCard mark-up, but for marking up the text labels of fields, not for formatted addresses (e.g [span class=”label”]Name[/span]).

Improvements to the hCalendar microformats on Wikimedia Commons had to be rolled back, because class=”description” was already in use for an unrelated purpose.