[uf-discuss] Microformats Would Benefit From a Pseudo-Namespace

Ryan King ryan at technorati.com
Thu Sep 13 15:13:43 PDT 2007

On Sep 13, 2007, at 12:59 PM, fora at erde3.com wrote:

> Since it belongs here:
> http://meiert.com/en/blog/20070913/microformats-and-pseudo-namespaces/

I hope you don't think I'm being overly critical, I just think your  
reasoning is flawed in a few ways and doesn't line up with the  
experience many of us have had in working with microformats over the  
last few years.

To quote from the article:
> Current microformats unnecessarily limit “regular” web development.

This may be somewhat true, but your supporting assertions are not:

> The hCard microformat alone theoretically blocks more than 20 class  
> names
is true only if you qualify it with "when used in the context of an  
element that has the class name of 'vcard'".

This has no conflict with hCard:

> <!doctype html>
> <html><span class="title">Not a job title</span>
Again from the article:

> There is unnecessary cognitive load.
Since this relies on the previous point, I don't think its valid.  
Authors only need to worry about root class names conflicting and  
using conflicting names within elements that have root class names on  
them. It's no where as bad as you make it sound.


> This is a very strict point of view, but seen mathematically, the  
> microformat development will theoretically result in blocking every  
> name available,
is unfounded given the process [http://microformats.org/wiki/process]  
and ammounts to little more than FUD. Also, I'm not sure what you  
mean by "mathematically"? Do you mean, "assuming unabated growth of  
microformats, we will eventually run out class names to use"? If so,  
I think you're also assuming an infinite number of monkeys typing up  
random microformat specs (which use infinitely long class names 
(there's no limit on the length of class names)). Not only is this  
point practically wrong, but also wrong in theory.

> 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 larger the project, the more need there is for markup best  
practices, and microformats present a set or markup best practices  
which can be shared from one workplace to another, not just within  
individual projects. I think microformats are a benefit to large  
projects, not a hinderance. Also, I don't see how your supporting  
points have anything to do with the layout of microformats in  
particular, it seems to be relevant to all markup practices.

More information about the microformats-discuss mailing list