[uf-discuss] hAtom draft - class="title"

Benjamin Carlyle benjamincarlyle at optusnet.com.au
Sat Dec 31 01:58:02 PST 2005


On Thu, 2005-12-29 at 23:47 -0600, Ryan King wrote:
> ...I believe that context and specific rules on opacity are  
> sufficient for making thing unambiguous. Admittedly, with  
> microformats we tend to walk a fine line here, but its not without  
> reason- we're trying to optimize for publishers- which mainly  
> includes geeks who hand-write html in textareas and web developers/ 
> designers.

Is it your position that hAtom's title class can have a different
meaning to hCard's title, and that hAtom's summary class can have a
different meaning to hReview's summary class? Is it your position that
opacity will allow for classes to have different definitions depending
on scope?

Tantek, is this your position also? Does anyone need more time or more
direct discussion to consider the question?

If this is carried through, hAtom should be able to stay as it is and
may be ready for promotion and use as it currently exists. It may be
important to define which class names have a globally-understood meaning
and which have context-sensitive meaning. If this trajectory is carried
through, I would suggest that top-level microformat names such as
"vcard", "feed", rel="tag", and the like should all have immutable
definitions that cannot be used in other microformats. A parser looking
for vcards on a page should be able to find them even though they are
embedded in in hAtom "author" contexts.

Child elements of these top-level microformats could change in
definition according to context, including "summary" and "title".
Parsers could not go searching for them except within the appropriate
contexts. All parsers should recognise whatever the mfo class eventually
gets transformed into and not assume familiar class names within those
scopes are understandable, except for top-level microformats.

Would all of the experienced microformatters be happy with this

Benjamin Carlyle <benjamincarlyle at optusnet.com.au>

More information about the microformats-discuss mailing list