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

Ryan King ryan at technorati.com
Fri Dec 2 14:35:45 PST 2005

On Dec 2, 2005, at 1:54 PM, Abramo Bagnara wrote:

> Ryan King ha scritto:
>> On Dec 2, 2005, at 11:39 AM, Abramo Bagnara wrote:
>>> The benefits I see wrt current hCalendar are:
>>> - generality
>> This may be in opposition to the way we develop µF's. As the first µF
>> principle states: "solved a specific problem."
> I'd add: "better if *this* specific problem is solved in a general  
> way,
> without complex policies and hairy details".
>>> - simplicity and readability (without have to know the complex   
>>> rules of
>>> hCalendar describing where the data might be located)
>> IMHO, your rendition is no easier to read than hcalendar. Of course,
>> I'm very familiar with hcalendar, so I may be biased.
> I find very hard to remember which attributes and in which prioritary
> order are attempted to find the field content. In my proposal this is
> explicit and also permits to avoid the @headers mess extending its
> benefits to non tables (like in CSS oriented tables).
>>> - no overlapping with class name in use by consolidated css
>> True. However, you do realize that using colons in class names  
>> will  not
>> work well with css (with current useragents, at least, I'm not  sure
>> exactly where the spec is on this)?
> Good point: .xx:hover is indistinct from .xx:dtstart


> What about to choose a $prefix different from "xx:"?
> Can we reach an agreement that to use a "namespace" for microformats
> specific classes is a good thing?

Be careful, you might want to read the archives here.

>>>> Why not propose a fix to hcalendar, rather than starting from   
>>>> scratch?
>>> My proposal is exactly oriented toward this, to improve current
>>> hCalendar (as you can see the similarity between the two are much  
>>> many
>>> than the differences...)
>> It just seemed that you'd thrown out more than neccesary. Your stated
>> objective was to fixed the cases of encoding iCalendar parameters in
>> hcalendar (I think. I'm honestly not sure what part of the format
>> you're trying to fix.). Why not just focus on that part of the  
>> format?
> See the rationale above.
> I'd like you realize how many layout limitations impose current
> hCalendar way.

By layout, do you mean styling? Or markup? Because its not clear from  
your examples.

> I'll do a specific example, one of that I've found trying to add
> hCalendar tagging to my application output.
> Suppose that I want to group attendees by role.
> With hCalendar I'm forced to this abbr abuse:
> <div>
> <span class="header">Optional partecipants: </span>

Not to nitpick, but it'd be helpful if you didn't reinvent <h*>.

> <span class="attendee">
>   <abbr class="role" title="opt-participant"></abbr>

Ok, so you've found a place where its hard to follow the DRY principle.

>   <a class="cn" href="mailto:abramobagnara at tin.it">Abramo Bagnara</a>
> </span>,
> <span class="attendee">
>   <abbr class="role" title="opt-participant"></abbr>
>   <a class="cn" href="litabanelli at racine.ra.it">Licia Tabanelli</a>
> </span>
> </div
> while with my proposal I can do the following:
> <div>
> <span class="header">
> <abbr title="opt-participant">Optional partecipants</abbr>
> </span>:
> <span class="xx:attendee= xx:@role=../abbr/@title">
>   <a class="xx:@cn xx:=@href"  
> href="mailto:abramobagnara at tin.it">Abramo
> Bagnara</a>

Do you realize the tradeoff you make here? You can't write a CSS  
selector to style on "xx:attendee= xx:@role=../abbr/@title". This is  
a deal breaker for microformats. If you really want to reference  
another HTML element, why not use something more HTMLish, like and  

> </span>,
> <span class="xx:attendee= xx:@role=../abbr/@title">
>   <a class="xx:@cn xx:=@href" href="litabanelli at racine.ra.it">Licia
> Tabanelli</a>
> </span>
> </div>
> So leaving the needed layout freedom to web page designer.

Per my point above, you leave more markup freedom, but eliminate  
[CSS] styling freedom. A big negative in my book.


Ryan King
ryan at technorati.com

More information about the microformats-discuss mailing list