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.
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
