[whatwg] Video proposals

H?kon Wium Lie wrote:

> On a mobile phone, it's expensive and slow to perform HEAD requests.

I can well believe that, but the question becomes: are the types
reported in the type attribute sufficiently reliable for mobile phone
purposes? i.e. can phone browsers safely ignore embedded content if its
HTML type attribute specifies a type they cannot play? And if so,
doesn't video need a type attribute, since different phones will support
different containers? And will type or even content-type be able to
solve that problem, since even if a phone pulls down a container it
supports, it might contain content in codecs it cannot play?

> Running personal spiders is out of the question. We should keep in
> mind that the specs we designs must be usable in many types of
> enviroments.

I absolutely agree (that's why I offered some information on the
behaviour of a text browser, and talked about how content types don't
really meet the needs of users with different abilities). I was just
addressing your particular use-case, which (if I understood it right,
perhaps I didn't) involved a content administrator moving content from
one place to another. I'd expect a content administrator proficient in
such migrations to able to run wget or a similar GUI tool.

Should we have attributes to indicate whether <video> content has
subtitles, captions, audio descriptions, and transcriptions embedded, so
that videos are only downloaded and played if they are in fact going to
be accessible to the user? Or to flag content that is NSFW, so UAs can
be configured to not play it? Or to point to higher quality but higher
bandwidth alternatives? Or maybe to indicate licencing, so that
authoring tools could throw up a warning if one tried to mix up or
deeplink to content with a restrictive licence. (I don't actually think
authoring tools should prevent one doing so, because authoring tools
aren't lawyers.) All of this is stuff one might very much wish to
know /before/ downloading the video. Particularly on the accessibility
front, when users with disabilities go through the palaver of
downloading and opening content which could be made accessible, but
hasn't been, it damages their faith in the relevant technology. PDF is a
common offender here (never mind failure to use tagging, what about
failing to OCR scanned text before output to PDF?); for the response of
one of the many disillusioned, read:

http://www.accessibilitynews.ca/acnews/editorials/geof.php#a42

--
Benjamin Hawkes-Lewis

Received on Saturday, 17 March 2007 11:48:10 UTC