[uf-new] Use of img in rel-* (with analyzed data)
joe at andrieu.net
Sun Jul 15 16:00:21 PDT 2007
Tantek Ç elik wrote (Sunday, July 15, 2007 2:58 PM)
> On 7/15/07 2:45 PM, "Manu Sporny" <msporny at digitalbazaar.com> wrote:
> > However, I ask again - why are we giving publishers the choice of
> > violating the HTML specification?
> That has never been demonstrated via an actual example with
> URL and citation of the clause in the spec with URL that is
> allegedly being violated, and reasoning applied to the actual
> example as such. It's only been asserted in hand-waving.
> > Of hiding data?
> No one is advocating that AFAIK.
> > Where are
> > the real world examples of why we need to provide that option?
> Manu, please check the other responses on this thread, there
> has already been at least one publisher that has responded
> and demonstrated as such.
I don't understand the use of examples in this debate.
If we were to examine contact information in the wild, we wouldn't suggest that class="title" is bad because nobody is using it or
because people use it outside of hcards. We aren't about to go scan every ALT value for semantic data; the suggestion, as I
understand it, is to allow ALT values as a source of data /within/ uFs.
The issue, imo, seems to be that /when authoring uFs/, can or should data be placed in alt tags so that authors can specify data
that otherwise might be burried in an image?
That becomes two questions.
1. Is it semantically valid within common HTML usage? Or put another way, images sometimes contain human readable data that are not
(easily) machine readable. Is the alt tag an appropriate way to specify that data in a machine-readable way?
2. Does it break existing uFs? And that means specifications and usage; Whether or not it breaks parsers is a different issue. In
this case, it may make sense to evaluate the use of IMG ALT tags within uFs to see if uF-using authors have adopted widespread
practices that would break. However, evaluating random selections of IMG tags doesn't really help us understand anything about
current uF usage and how this change to the spec might cause problems with existing uFs.
joe at switchbook.com
+1 (805) 705-8651
More information about the microformats-new