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:[EMAIL PROTECTED]">Abramo Bagnara</a>
</span>,
<span class="attendee">
<abbr class="role" title="opt-participant"></abbr>
<a class="cn" href="[EMAIL PROTECTED]">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:[EMAIL PROTECTED]"
href="mailto:[EMAIL PROTECTED]">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:[EMAIL PROTECTED]" href="[EMAIL PROTECTED]">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
[EMAIL PROTECTED]
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
