On 14/03/2008, Sarven Capadisli <[EMAIL PROTECTED]> wrote: > @title value in <abbr> is not hidden data. The user is able to hover > the element and get to the information. The @title value is used as an > alternative or replacement of <abbr> textContent. This is not the case > in <input type="hidden">.
Point taken. But the data is still "hidden" in the sense that most users don't tend to hover their cursor over every word to see if there is more information about each word. It is still possible to let the title attribute fall out of sync with the "human" content. And likewise it's just as easy to abuse as "properly hidden" data: <abbr style="border: none; cursor: default;" title="20010101" class="dtfrom">Free</abbr> <abbr style="border: none; cursor: default;" title="29991231" class="dtfrom">stuff!</abbr> > It is important to keep the data paired, a) human readable > date/timestamp within context, b) human readable standardised > date/timestamp. <abbr> is "good enough" for this or at least the most > semantic candidate with minimal negative impact. Screen readers may > have a problem with it only because of the way they are configured to > treat the data. The information inside <abbr> is independent from how > it will be interpret or treated by any UA for that matter. > > e.g. <p>I will see you <abbr title="2008-03-21" class="dtstamp">next > week</abbr></p> It's a good example above, but let's be honest: the real reason we have the ISO dates in microformats like hCalendar is so that dates are machine-readable. If it were possible to reliably parse something like <span class="dtfrom">next Thursday at sundown</span> then we wouldn't be having this discussion. Using <abbr> is a decent semantic compromise in many circumstances. But screen readers are not doing anything wrong by interpreting the data the way they do (they are very much following the spec, and the semantics). It's the stretching of the semantics by microformats that unwittingly caused the issue; it's not right to expect screen readers to address the issue by changing the way they interpret the data. I have been convinced, so far, that using hidden input elements as a "blanket solution" for machine-readable data is indeed a bad idea. The title of my original email is therefore somewhat inadequate. However, I maintain that in specific circumstances where we have data that is *meant* for machine-readability and that has adverse effects on human readability then we should consider using a hidden input field. -- Nelson Menezes [EMAIL PROTECTED] _______________________________________________ microformats-new mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-new
