[whatwg] Apple Proposal for Timed Media Elements

[Robert Sayre]

On 3/21/07, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Mar 21, 2007, at 6:16 PM, Ian Hickson wrote:
>
> >   Starting with simple features, and adding features based on demand
> >   rather than just checking off features for parity with other
> > development
> >   environments leads to a more streamlined API that is easier to use.
> >
> >   How should we approach this?

My two cents: we should put off events and other API pieces that
address editing applications. It is possible to write web versions of
things like iMovie and SoundEdit in Flash right now, but I don't think
it is realistic to capture that stuff in a first effort. We should
focus on playback and consumption for v1. So my question for any
proposal right now would be: "why is the feature needed for something
analogous to a VCR or YouTube screen?"

>
> >   For <audio> in general, there's been very little demand for <audio>
> >   other than from people suggesting that it makes abstract logical
> > sense

I disagree. It's been pointed out by multiple people that <video> will
be used for audio. That could be quite likely if the page authors
wants to send ogg vorbis audio.

>
> > * What's the use case for hasAudio or hasVideo? Wouldn't the author
> > know
> >   ahead of time whether the content has audio or video?
>
> That depends. If you are displaying one fixed piece of media, then
> sure. If you are displaying general user-selectable content...

This reasoning seems sound to me. In general, I am weary of proposals
that require control over both sides of the wire to be effective.

> We have included a mechanism for static fallback based on container
> type and codec, so that it's possible to choose the best video format
> for a client even if user agent codec support varies.

What existing markup leads us to believe this will be an effective
method for content negotiation?

--

Robert Sayre