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

[Ryan King]

On Jul 14, 2005, at 8:35 AM, Dimitri Glazkov wrote:

>> 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.

I think *they* (whoever these imaginary people are) are smart enough  
to figure things out.

I think *they* know what a date is, what a time is, what a person is.

> The problem of free-wheeling instructions is that
> they aren't any good for those who can only follow cookbooks.

Right, so we need cookbooks? I'm certain that all of the formats  
could use more examples, even though they come with some examples and  
link to examples /in the wild/.

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

Education in semantic markup and web standards will certainly help.  
But, even without understanding these broad principles, people can  
still "cookbook it," esp. with hcard and hcalendar.

> For instance, in some cases, using tables would be perfectly valid
> semantic markup to display addresses.

right.

> There is nothing in hCard that
> prevents trs from serving as containers, and tds serving as
> properties.

Yes. I think upcoming.org is doing this with hcalendar.

> 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?

Many. :)

-ryan