Microformats Would Benefit from a Pseudo-Namespace

Jens Meiert, September 13, 2007 / March 25, 2008.

This entry is filed under Web Development.

Microformats (simple, open data formats) become more and more popular, yet 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 certain semantics, and save flexibility.

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

Current microformats unnecessarily 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 yet commendable names for other uses. This means a clear limitation: Once an author settles for a microformat, unconcerned 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 basically “blocks” this class since the styling of photo is now restricted – it might affect the hCard presentation (this “might” is harmful 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 also inacceptable.

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

As the former point already shows, some microformats affect authoring by adding an unnecessary cognitive burden: “What class names cannot be safely used anymore since occupied by the microformats on our site?”

This is a question nobody should be forced to ask. Microformats may be cool, but it’s not their job to limit web development and to make work harder, and be it only by a tiny bit. This is a very strict point of view, but seen mathematically, the microformat development will theoretically result in blocking every name available, meaning that one day, there’s need to create class name whitelists for web authors (this is such a bold exaggeration that yet I need to laugh ).

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 stay totally free in the rest of the work.
There are unnecessary layout risks.

The larger the project and the more web decorators, designers, or developers involved, the greater the likelihood that there are unforeseen display problems when maintaining and extending the project. This is just a plain fact, independent of available measures. 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. Again, this is just superfluous.

The entire reasoning needed to ignore the history of certain microformats, like hCard’s intentional and far-reaching congruence with vCard. It’s biased towards pseudo-namespaces anyway; clearly, they must not mean the only solution. And yet for some, the mentioned problems might be too abstract; but, you probably don’t need more details when you agree that it’s advisable to avoid problems from scratch and by design.

However, 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 still ain’t very happy. On the other hand, I’m way too passionate about the subject. I’m looking forward to criticism, but also to friendly interpretation.

Update (September 14, 2007)

Both comments and discussion brought up two other aspects:

I understand that some microformats sympathizers don’t feel very well in having a set of class names like for example, concerning 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:

Concerning HTML, current web dev practice still focuses more on styling, while microformats focus more on semantics (basically great). This difference in focus probably also helps in explaining why there’s certain increased probability of conflicts, yet especially when adding microformats to large projects.
Predefining class names is neat, but statements like “some elements should use this or that name” aren’t lightweight. vCard, for example (though special), surely uses some names that few authors would otherwise voluntarily choose, and thus it’s at least “questionable” if the microformats community can really assume something like “consensus on semantics” then.
Concepts like namespaces will make it easier to add microformats in about any scenario. With namespaces, there’s basically a very low chance that there are any conflicts at all even when the project uses millions of pages, thousands of IDs/classes, and hundreds of web developers. People might be more eager to add microformats.

Enjoy the most popular posts, probably including:

Comments

On September 13, 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, 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, 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, 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, 1:14 CEST, Jens Meiert said:

The first thing you need to realize is that microformats are already widely published

Yes, that’s why I’d especially 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 anyway, 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, 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, 17:10 CEST, Jens 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 due to attempted flaming.)
On April 23, 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, 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.

Jens Meiert