- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 13 Oct 2007 06:19:19 +0000 (UTC)
On Thu, 5 Apr 2007, Benjamin Hawkes-Lewis wrote: > > There are three things I'd hope to see from a <video> element: > > 1) Ease of use compared to <object> (A common API contributes to this, > and v2 might approach it with a default UI. Lack of agreement on a > baseline format is a major problem here.) We now have both an API and a default UI. I will address the baseline format issue in a separate thread. > 2) Experiments in hyperfilm. Could you elaborate on this? > 3) Better accessibility features than are provided by the current > <object> or <embed> + plugin architecture. > > Unless I've missed something. The Apple proposal does not discuss > accessibility. Where do closed captions, audio descriptions, signed > alternatives, subtitles, dubbing, and transcripts fit into the proposed > scheme? Any additional and alternative audio, timed text, and video tracks available in the movie files can be made available by the UA in response to user requests. Transcripts are useful for all users and can be made available using an ordinary hyperlink near the video. > Why is <video>'s fallback limited to inline content? How is inline > content supposed to be an equivalent alternative to a whole video? Why > shouldn't <video> contain a <dialog> as fallback, for example? This is now changed in the spec; the content model is anything that the parent element allows (roughly). > If audio container formats contain (for example) captions, how precisely > are users supposed to access them, given that the spec says: "If the > source is an MP3 file containing synchronized lyrics, for example, the > user agent must render only the audio and not the text." The actual spec did not copy this restriction from Apple's proposal. HTH, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 12 October 2007 23:19:19 UTC