[uf-discuss] RFC: Proposal for general purpose microformat

[Dr. Ernie Prabhakar]

Hi Abramo,

On Dec 2, 2005, at 2:50 PM, Abramo Bagnara wrote:

> Dr. Ernie Prabhakar ha scritto:
>> That is an interesting question.  I know that Rohit has been asking
>> that same question.  The conventional answer is that microformat
>> classes *are* in fact the same classes you'd be using for normal CSS
>> styling, so there's no need to call them out -- and besides,   
>> namespaces
>> tend to confuse mere mortals.
>
> I've deliberately quoted "namespace": a simple prefix is enough.

Believe me, I understand.  Still, even telling people to do "@name"  
or "-description" is a little odd.

> As an example consider that a web page might already use class
> "description" for its own purpose. Suppose now that he'd like to add
> hCalendar encapsulation: how he can easily represent differently the
> hCalendar content and the others?
>
> He has some alternative:
>
> 1) don't use the "description" class outside hCalendar data (??? to  
> use
> hCalendar means to be forced to not use any rfc2445 names as class  
> name?)
>
> 2) use selectors like:
> .vevent .description { }

The microformat recommendation would clearly be the latter.

> but what about if .vevent area is rather large and inside that he
> already use some classes clashing with rfc2445? And what about if  
> vevent
> internal data is stored outside .vevent area?

This is one of those hypotheticals that we'd love to see a concrete  
use case to justify.  The general microformat rule is to NOT pollute  
the 80% case merely to make the corner cases possible, which I think  
is a rational approach.

> You should only solve the problem of how to instruct stylesheet about
> *where* it can find the role param value in xhtml page... And then you
> should be sure that with this policy you're not excluding *any*  
> sensible
> layout.
>
> You've an hard work, my friend... :-)

Au contraire -- as already noted, *we* are _not_ trying to solve the  
most general case of "any sensible layout", for that very  
reason. :-)  If people have unique needs that aren't solved by a  
general-purpose microformat, then we wish them well but don't feel  
compelled to convert them to our camp.

Now, it *is* certainly possible that an existing definition doesn't  
pass the 80% test, and in fact 40%+ of common uses require something  
different than what we are doing.  But that's why we stress prior  
research before forming a microformat, to ensure we cover the bulk of  
the target audience.   Yes, that means we leave other potential usage  
patterns on the table; if you think you're smart enough to figure out  
a general-purpose solution that will be broadly adopted, by all means  
-- go for it!  Most of us here have decided we're not that smart, so  
we'll be content with something more modest. :-)

Best,
Ernie P.