Tantek said:
1. Not backwards compatible with existing microformatted non-abbr
elements.
and
Here is a simple (theoretical) example (hReview fragment)
<span class="rating" title="Three means fair">3</span>
Yes, but the proposal is to limit the title-design-pattern to
*specific* classes
As James said:
Any element, but only on specific Microformat classes, each of
which has expected RegEx-matchable values. DTSTART, DTEND,
DURATION, RDATE, RRULE expect values defined in RFC 2445. TYPE and
GEO expect values defined in RFC 2426. This would eliminate the
ambiguity of title-or-contents.
These kind of rules already exist in microformats. Take the url value
in hCard, for example. Parsers look for the value in the href
attribute, not between the tags. In that case there is a simple rule
for parsers to obey. By restricting the title-design-pattern to a
limited number of values, we can provide equally straightforward
rules for parsers.
Now... there's also the issue of multiple class names and how parsers
should handle the situation with one of the classes that James lists
*plus* another class.
Here's an example from a (theoretical) vevent:
<span class="dtstart summary" title="2007-05-01">May Day</span>
According to the proposed title-design-pattern, the value for dtstart
is extracted from the title attribute while the value of summary is
extracted from between the tags.
dtstart: 2007-05-01
summary: May Day
Limiting the title-design-pattern to specific classes like this would
counter the second argument:
2. Too big of a change.
In a way, what's being proposed here is an inverted version of
Tantek's suggestion:
If on the other hand, you were to simply extend the abbr-title
pattern to
*one* other element (rather than *all* non-abbr elements), then the
additional damage would be less than were you to extend it to all
elements.
Rather than limit the title-design-pattern to one (other) element, it
makes more sense to me to limit the number of scenarios where the
title-design-pattern applies at all (specifically: datetime and geo
information).
Defining a specific element to use feels restrictive to me. We've
already run into plenty of trouble with the abbr element from people,
quite fairly, questioning the semantic appropriateness. For me, one
of the great strengths of microformats is that they generally don't
mandate what elements should be used.
There's already a misconception out there that microformats "demand"
the use of superfluous divs and spans (a misconception probably
derived from the examples and specs and something I hope to address
with some tutorials at some stage). If we introduce a design pattern
that mandates the use of a specific element, I feel that might place
an unnecessary burden on publishers.
I realise that introducing the title-design-pattern for a limited
number of classes introduces a burden for parsers but I'm okay with
that. :-)
Most importantly, the existing practice of encoding datetime and geo
information in the title attribute of an abbr element is entirely
compatible with the proposed title-design-pattern (restricted to
these specific classes).
To give an example of why I wouldn't want to be restricted to a
specific element (and again, this is purely theoretical so take it
with a huge pinch of salt), I might want to publish:
<h1 class="dtstart summary" title="2007-05-01">May Day</h1>
Rather than being forced to nest elements:
<h1 class="summary"><span class="dtstart" title="2007-05-01">May Day</
span></h1>
or:
<h1><span class="dtstart title="2007-05-01"><span class="summary">May
Day</span></span></h1>
Now, with all that said...
If we were to find an existing HTML element that was semantically
suited to encoding datetime and/or geo information *and* didn't cause
problems with assistive technology, then I would jump all over it and
agree wholeheartedly that the title-design-pattern should be
restricted to that particular element. But I don't believe such an
element exists.
In the absence of such an element, I'm in favour of allowing this
pattern on any element. But I'm well aware of the problem:
The other point that has been made that the title attribute on HTML4
elements in general (excluding abbr, acronym) is meant for the
author to
provide "advisory information about the element".
Semantically, we're somewhat screwed. We're damned if we use the abbr
element (stretching the definition of abbreviation and causing
problems for screen readers) and we're damned if we use any other
element (abusing the title attribute to hold information that is not
advisory information).
So the problem becomes one of damage control.
Tantek's proposed damage limitation is to open up the abbr-design-
pattern to just one other element.
James and I want to open up the pattern to any element but limit the
damage by restricting the number of classes the pattern applies to.
But if the consensus is that Tantek's proposed damage limitation
makes the most sense, I will quite happily go along with that.
Bye,
Jeremy
--
Jeremy Keith
a d a c t i o
http://adactio.com/
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
