Re: unifying alternate content across embedded content element types

At 13:10 +1000 UTC, on 2007-07-14, Ben Boyle wrote:

> On 7/14/07, Robert Burns <rob@robburns.com> wrote:

[...]

>> If anyone else has a suggestion for the log-jam, please join inn the
>> conversation.
>
> I'll try ... note this thread is about unifying alternate content
> across embedded media. This is clearly not a shared opinion as we have
> had many posts from people who think images should be managed
> differently from video/audio and again from object/embed.

My impression is that everybody who has spoken on the subject of unification
of an alternates mechanism agrees that it would be good. The disagreements
seem to me to be over [1] how to achieve that, and [2] what it's worth.

To me it seems obvious that the content of non-empty elements is the ideal
mechanism, because it provides
- one mechanism that allows for both short and long alternates
- one mechanism that allows for alternates in different media
- rich markup of alternates
- already the case, in HTML 4, for <object> and <iframe>, and in practice for
<embed>
- fulfills the Degrade Gracefully and (disputed) Visible Metadata vs.
Metadata Anywhere Design Principles.

The odd one out is the non-empty <img>. The *only* thing (but a big thing) it
has going for it that it is used a *lot*.

So it makes complete sense to me to try to find a solution to fix <img>
(unlikely), or offer authors a decent alternative (like <picture>, or
<object>), and it makes no sense at all to me to port @alt to other elements.
Because:
- all the above
- adding @alt to already existing elements wouldn't work in pre-HTML5 UAs, so
backwards compatibility would be broken
- how should a UA to handle <object alt="short alternate">short
alternate</object>? (which authors would want to do to not break backwards
compatibility).

(That leaves <video>, <audio> and <canvas>, but I haven't looked at the HTML5
spec enough to say much useful about them, exept that it seems to me they
should be defined to allow for alternates just like <object> does. Not doing
so would kill any chance at ever reaching unification, and thus HTML5 would
make authoring accessible sites even harder. (And I again use the word
"accessible" in the meaning of the average dictionary ;)))

All the above seemed so obvious to me that I didn't spell it all out earlier.
But perhaps it isn't that obvious and perhaps that contributed to Robert and
I not understanding each other. Hopefully this helps.

[...]

[HTML5 draft]

> - context can be enhanced through figure, section, article, aside,
> etc. and (more explicitly) figure/legend associates a caption with the
> img.

Yes, those are great improvements in HTML5. But context !=
alternates/equivalents/fallback. Context is context, and is exactly the
same/exactly as useful for whichever equivalent the user happens to access.

[...]

> Representing myself as an author, here's what I want in HTML 5: [...]

Agreed on all.


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Saturday, 14 July 2007 23:12:08 UTC