- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Sat, 17 Mar 2007 18:48:10 +0000
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