[uf-new] img alt content (was:hAudio implemented on Bitmunk (with one snag))

[Tantek Ç elik]

On 7/9/07 7:51 PM, "Manu Sporny" <msporny at digitalbazaar.com> wrote:

> Tantek Çelik wrote:
>> 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.
> 
> Doesn't doing this go against the HTML 4.01 specification? You aren't
> supposed to have anything in the 'alt' attribute of the image tag that
> isn't pertinent:
> 
> http://www.w3.org/TR/html4/struct/objects.html#h-13.8

Many publishers go against many aspects of the HTML 4.01 specification yes,
not in the least by publishing invalid content.


>> I've added this to the hCard FAQ as well:
>> 
>> http://microformats.org/wiki/hcard-faq#Why_is_IMG_alt_not_being_picked_up
> 
> The above link states:
> 
> "In addition all too often there is "garbage" (or just extra unwanted
> text) in alt attributes for a variety of publisher reasons, and that
> extraneous text would pollute otherwise clean property values in
> numerous existing sites."
> 
> I couldn't find a reference to the analysis that lead to this
> conclusion?

We didn't capture it at the time unfortunately, and we're being more
thorough now.  We did actually try it the other way first (including all
nested "alternative" content) and found it worked worse across a variety of
existing real world sites, not just 1-2 examples but LOTS.


> What constitutes "garbage"?

In this case things like duplicated text, text for chrome/UI etc.

> What reasons would a publisher
> have to do this? If they're doing this, aren't they quite blatantly
> violating the HTML 4.01 and XHTML 1.0 specification?

Not necessarily.


> The link stated above also says:
> 
> "Finally, it is simpler and more predictable for publishers if they know
> that for images and other such URL related elements (a, object, etc.)
> that whether they are specifying a URL property (like "email", "photo",
> "url", etc.) or a text property (like "fn", "nickname", etc.) in either
> case directly specifying the property on the element is the way to do it."
> 
> If we were to adopt this approach, I don't see how we could ever get the
> following chunk of HTML working for hAudio:
> 
> <a rel="sample" href="/samples/sneaking_sally.mp3">
>  <img src="sample.png" alt="Sample Sneaking Sally" />
> </a>
> 
> Sample, as defined by hAudio is:
> 
> rel-sample. optional. sample file/stream using rel-design-pattern with
>                     'sample' as the mf-rel-value.
> 
> Rel-patterns are only available on links... thus the "move the URL
> property such that it is specified directly" approach doesn't work for
> any Microformat that uses the rel-design-pattern.

rel does not apply to <img> therefore this is not a problem.

Tantek