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

[Ryan King]

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

yup.

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

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

--
Ryan King
ryan at technorati.com