On Thu, 01 Mar 2007 12:27:49 +0100, Benjamin Hawkes-Lewis
<[EMAIL PROTECTED]> wrote:
Opera has some internal expiremental builds with an implementation of a
<video> element.
Interesting. I just wanted to ask for a bit more detail on how this
works in practice and what it can be used for. How would this support
audio descriptions, captions, and subtitles? e.g. Can the captions be
displayed to match user preferences for fonts and so forth and exposed
to accessibility frameworks? Might it support any form of hyperfilm
(e.g. clicking on something in the film like one can click on parts of a
Flickr photograph, changing perspective etc) or is it intended only for
traditional linear video? (These capabilities look like potential
advantages of SMIL.)
Everything with regards to the <video> element what we currently support
is mentioned in the specification I attached (well, minus some bugs).
From an accessibility point of view (not to mention an interoperability
one), doesn't the draft spec need to mandate the inclusion of a
fallback?
I'm not sure what fallback has to do with interoperability. Mandating a
fallback would probably be good...
And what do play() pause() stop() etc do when video-playing is
unavailable and the fallback content is displayed instead?
Open issue. Maybe they should throw an INVALID_STATE_ERR or something.
The draft spec shows the addition of button elements by the content
producer. Would it be better from a usability and efficiency point of
view (both for authors and viewers) for UAs to generate the UI
themselves? (Or at least, since some interfaces might have more complex
and innovative functionality, to have the UA's own UI as default, and
allow a boolean attribute to disable the default generated interface?
e.g. customui="customui").
It doesn't seem wise to mandate a particular UI. User agents are free of
course to expose the functionality of play(), pause() and stop() in some
way, in my opinion.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
