Re: unifying alternate content across embedded content element types (was Comments on IRC log)

[Subject changed to that of an earlier thread, which seems a better
description]

At 09:09 +1000 UTC, on 2007-07-27, Lachlan Hunt wrote:

[...]

> <video src="/movie">
>    <a href="/movie">Download the video</a>
> </video>
>
> The content of the video element is fallback for those that don't
> support the video element.  It doesn't make the video itself accessible.
>   The video should, ideally, be made accessible by providing, for
> example, captions and audio descriptions embedded in the file itself.

You've claimed before that that would be ideal, but would you mind explaining
what exactly would be ideal about it? Because I don't see it.

I do see that in *some specific cases* it would be ideal. If your hearing is
bad, or you're in a situation where having the sound loud enough to hear the
video would bother other people, video with captions would be nicer fallback
then (marked up) text. But when you can't see, or your browsing environment
doesn't provide the video's required bandwidth or CPU, or you're an indexing
bot, downloading the video and reading the captions isn't much of an option.

Add to that the authoring burden. Having to provide the same video in
different formats, all with their own mechanism to add captions, seems likely
more work and more expensive than providing a (marked up) textual alternative.

Lastly, what guarantee or even strong evidence is there that [1] the authors
of video formats will in fact provide such fallback mechanisms and [2] web
publishers will (be able to) make use of those? It would have to be pretty
strong evidence for this group to not bother providing a more generic
fallback mechanism.

Again, I can see why in certain specific cases a fallback within the file
format can be ideal, but I don't see how it can be considered ideal for the
Web as a whole -- which I got the impression is what HTML5 is about.

> If you also wanted to provide an alternative for users that don't
> support the video format, then that would require a different approach.
>   Perhaps the video could be provided in multiple formats, or perhaps
> some kind of textual alternative that describes both the dialog and
> action in the video.  The textual alternative may also be useful for
> users who are both deaf and blind, for whom captions and audio
> descriptions are both ineffective.

Right. So the textual equivalent is the only one that'll work for all users.
yet as I understand it, <video> as currently specced doesn't provide authors
with the means to mark that text up as the <video>'s equivalent.

> My point is, addressing different needs for different users sometimes
> requires different approaches.  There is not always going to be a single
> solution for everyone.

Doesn't (marked up) text work for every user in every browsing environment?
If so, it would make sense to spec HTML such that textual equivalents can be
provided for all non-textual media. Authors can still offer video in
different formats, and with things like captions if a given format allows for
that. But the only thing that'l work for all users is (marked up) text.


Btw, at <http://krijnhoetmer.nl/irc-logs/whatwg/20070701#l-225> you said:

> I really do not get the whole <picture> idea. It provides nothing more than
> <object> does

As explained, what it provides over <object> is that <object> is broken in IE
and therefore no option to authors. And as long as Chris Wilson continues his
silence, there is no reason to expect he'll ever fix IE. A new element, not
burdened with the history of <object>, <image> and <img> would seem to stand
a better chance then. (Personally I'd prefer <object>, provided the spec
would be made author-understandable, but I don't see the Web's IE-dependancy
change substantially any time soon.)

Does that help get the <picture>? ;)

> , and has absolutely no browser support

I heard that argument before and would really appreciate an explanation -- I
honestly don't see how it can be considered an argument. How does "<picture>
has no browser support" mean anything? "<p>" had no browser support either,
until browsers started supporting it. Browsers have no <canvas> support until
they start supporting it.


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

Received on Friday, 27 July 2007 02:05:04 UTC