[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.
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.
More information about the microformats-discuss
mailing list