Microformats Would Benefit from a Pseudo-Namespace

Post from September 13, 2007 (↻ June 5, 2021), filed under Web Development.

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 dictating class names cause unnecessary problems that could be avoided by using a “pseudo-namespace.”

The idea behind pseudo-namespaces is not new, and they already mean an aid in large projects as part of a defensive web development strategy. They basically mean to add a prefix to ID or class names in order to create more efficient style sheets, preserve meaning, and save flexibility.

For microformats, running around not using something like pseudo-namespaces means problems that should be judged critical in the long run:

Currently, Microformats Limit “Regular” Web Development

The hCard microformat alone theoretically 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 clear limitation: Once an author settles for a microformat, imprudent use and, above all, formatting of certain classes eventually becomes a problem.

Example: Use of a photo class. It usually may 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 unacceptable.

A general or microformat specific prefix could help: mf-photo, for example, leaves authors all room to use names they wish; at least it reduces the likelihood that there are any conflicts. It means a “win/win”—not only will it become simpler to add microformats to projects, but also could the microformats community go on inventing even more formats.

Currently, 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 safely used anymore since occupied by microformats on our site?”

This is a question nobody should be forced to ask. Microformats may be hip and cool, but it’s not their job to constrain web development and to make work harder. This is a strict point of view, but seen probabilistically, microformat development might 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 stay independent. And still 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.

Currently, Microformats Introduce Unnecessary Layout Risks

The larger the project and the more decorators, designers, or developers involved, the greater the likelihood that there are unforeseen display problems when maintaining and extending the project. In practice this appears to prove as a fact. Microformats currently, unnecessarily increase this likelihood as illustrated above, just due to the fact that they require developers who are aware of the constraints imposed by microformats. This is superfluous.

❧ The argument had to ignore the history of certain microformats, like hCard’s intentional and far-reaching congruence with vCard. It’s biased towards pseudo-namespaces, which must not mean the only solution. For some, the mentioned problems might still appear abstract; 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 practice 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 revisions and several printouts, I’m still not happy. On the other hand, I’m wildly 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 some microformats sympathizers don’t 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 probably helps to explain why there’s an increased 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 voluntarily choose, and thus it’s at least questionable whether the microformats community can assume something like “consensus on semantics.”
Concepts like namespaces do make it easier to create new microformats. With namespaces, there’s only a very low chance that there are ever any conflicts even when the project uses millions of pages, thousands of IDs/classes, and hundreds of web developers. People might be more eager to use microformats.

About Me

I’m Jens Oliver Meiert, and I’m an engineering manager and author. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.

If you have questions or suggestions about what I write, please leave a comment (if available) or a message.

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 “namespace” consideration in upcoming microformats.

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.

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

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

Well, 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 usual styling for that element within microformat context.

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

Uh, I didn’t propose to add more class names—instead, they should just be modified.
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.

Have a look at the most popular posts, possibly including:

Looking for a way to comment? Comments have been disabled, unfortunately.