On Sep 13, 2007, at 12:59 PM, [EMAIL PROTECTED] 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.

also,

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.





_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

Reply via email to