- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 29 Oct 2007 04:02:07 +0000 (UTC)
- To: Mihai Sucan <mihai.sucan@gmail.com>
- Cc: public-html <public-html@w3.org>
On Sat, 27 Oct 2007, Mihai Sucan wrote: > > > > > > Pushback for something so obvious? Why? What can someone argue > > > against the playing DOM attribute? > > > > We want to avoid feature creep, with more API surface area than > > absolutely necessary. Right now we have quite a tight (albeit large) > > API, with very little redundancy. > > I wouldn't call this feature belonging to the "feature creep" category. Well, like I said, I originally included something like this (a boolean to tell if time was advancing ot not), but got pushback... You can work it out from the available attributes, so not having this isn't a complete blocker, it's just a lack of redundancy in the API. > Cue points are "feature creep". It's interesting they made it into the > first version of the API - this could suggest to me there's corporate > interest in cue points (?). Not necessarily corporate -- but there has been a lot of interest in cue points / ranges, yes. > > Yes. But what's the use case? Why would you abort loading? > > Asking why would you abort loading of media elements is like asking why > would a download manager abort file downloads, or why any other software > application would ever abort any file download, for any possible > purpose. Not really. It's clear that the _user_ should be able to abort downloads, and indeed he already can. But why would the Web page author start a download just to cancel it? > As a user, I don't like I can't abort/stop loading videos on YouTube, > Dailymotion, Stage6 and other similar sites. This is not the way > software media players work: when I play a file with mplayer over the > network, if I pause/stop playback, the player stops using my network > resources. I like that. I would like a similar "feature" in online media > players as well. Providing an API doesn't guarentee it'll be made available. I would recommend instead asking browser vendors to implement bandwidth limiting as the spec recommends; that way you have it available everywhere. > > True, we don't really have a good story on that end yet... What do > > people think? How should we address this? I hesitate to add yet more > > attributes... We could have auto=play auto=load instead of > > autoplay...? > > This issue is similar to the one above, and similar to the GUI controls > issue ("we want native controls by default" - me as well). > > Auto=play, auto=load, auto=none sounds good to me - auto=play being the > default. There has not been much support for this idea (you and I are basically the only ones who've even considered it recently, as far as I can tell). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 29 October 2007 04:02:17 UTC