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
htmlspan class=titleNot 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
