[uf-new] img alt content (was:hAudio implemented on Bitmunk
(with one snag))
Tantek Ç elik
tantek at cs.stanford.edu
Mon Jul 9 12:36:54 PDT 2007
On 7/9/07 7:37 AM, "Scott Reynen" <scott at makedatamakesense.com> wrote:
> On Jul 9, 2007, at 8:14 AM, Andy Mabbett wrote:
>
>>> They only grab the image alt text if the
>>> microformat class is on the image itself. Here's a different example:
>>>
>>> <a class="fn url" href="http://www.yahoo.com"><img src="foo.jpg"
>>> alt="Mike Kaply"></a>
>>>
>>> I realize this is a little contrived, but you get the idea.
>>
>>> In this case, the fn is empty.
>>
>> My argument is that the fn should /not/ be empty; the "alt" attribute
>> contains the text equivalent of the image.
>
> I agree this matches the semantics of the alt attribute; however, I
> suspect few publishers are currently using this attribute
> appropriately, so I think we should do more research into the likely
> ramifications of such a change before making it.
This was deliberately rejected at the creation of hCard to give publishers
more control.
All too often there is "garbage" (or just extra unwanted text) in alt
attributes for a variety of publisher reasons.
Thus only if the publisher explicitly *wants* the text from the alt
attribute do they add the respective class value to get it.
I've added this to the hCard FAQ as well:
http://microformats.org/wiki/hcard-faq#Why_is_IMG_alt_not_being_picked_up
Tantek
More information about the microformats-new
mailing list