[microformats-discuss] In need of an explainer: How "soft" is "too soft'?

[Dimitri Glazkov]

>From what I can see MFs are about qualifying markup elements with
attributes (class, rel, and even title), and leaving most markup
decisions up to the developer. There are design principles
(http://microformats.org/wiki/semantic-xhtml-design-principles), but
they don't seem directly consequential to the use of specific
elements. For instance, hCard's container could be a div, a span, or
even an address element -- the hCard spec does not specify that
explicitly. Naturally, some semantics can not be expressed with any
element -- references to external resources still need to be in their
corresponding XHTML form, be that a or img elements.

I can see the value in this "soft" approach, where you don't impose
specific markup requriements on a markup developer. As the MF mission
states correctly, microformats are not about "boiling the ocean".

However, it seems this approach has a drawback: it requires the
implementor of a MF to be knowledgeable in semantics, and most Web app
developers aren't. The problem of free-wheeling instructions is that
they aren't any good for those who can only follow cookbooks.

What could be done to make this more approachable by the average Joe
developer? Is this just basic semantic markup education?

For instance, in some cases, using tables would be perfectly valid
semantic markup to display addresses. There is nothing in hCard that
prevents trs from serving as containers, and tds serving as
properties. What bothers me is that this jump is not easily made
(tables are bad! spans are good! rah-rah!), and will either cause the
developer to abandon using microformats for a particular application,
or make decisions like switching to spans/divs or, worse yet,
embedding additional spans/divs into the tables, to make this work.

Any thoughts on this?

:DG<