- From: Mihai Sucan <mihai.sucan@gmail.com>
- Date: Fri, 19 Oct 2007 13:08:22 +0300
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: public-html <public-html@w3.org>
Hello Ian! Thanks for the reply. Le Fri, 19 Oct 2007 04:50:38 +0300, Ian Hickson <ian@hixie.ch> a écrit: > (By the way, in general, I recommend not bothering to report editorial > mistakes at this point. Let's worry about making the actual rules correct > and unambiguous before we worry about the spelling and grammar!) Ok, then I'll skip reporting editorial mistakes from now on. > On Sun, 5 Aug 2007, Mihai Sucan wrote: > >> 1. Looking at the 3.14.9.2. "Location of the media resource" section [2] >> one can read: >> >> "*The src content attribute* on media elements gives the address of the >> video to show." >> >> I think the topic is wrong and confusing. This "error" is repeated in >> the entire spec. >> >> I have read 1.4. "Terminology" section [8] and I still think this should >> be changed. The section does a good job in explaining what a "content >> attribute" is, but when reading the spec, it's still confusing. >> >> I would suggest using "markup attribute" or "element attribute" instead >> of "content attribute". > > It's not a markup attribute (you can add it to the DOM dynamically). > > The term "element attribute" ends up being really confusing, especially > when you have attributes named element, and elements named attribute, and > other such weirdnesses, as we've ended up with in XBL. I'd like the term > to be consistent through the specs I edit. > > I'm leaving it as is for now, but I think the issue has been mentioned > before and will likely be addressed separately again later. Fair enough. >> 14. The DOM event "volumechange" should not be fired when a media >> element is muted/unmuted. >> >> Currently the spec says this: >> >> "Whenever either the muted or volume attributes are changed, after any >> running scripts have finished executing, the user agent must fire a >> simple event called volumechange at the media element." >> >> Actually, the volume itself does not change when the media is >> muted/unmuted. >> >> The UA should fire a simple event called "mutetoggle" when the media is >> muted/unmuted. > > Having two events seems like overkill for this. I was suggesting to only fire a simple event called "mutetoggle" when the media is muted/unmuted - no "volumechange" event. The "volumechange" event should only be fired when the volume actually changes. >> 16. I suggest adding the "playing" DOM attribute which tells if the >> media element is actively playing. >> >> [...] >> >> "The playing DOM attribute represents whether the media element is >> actively playing or not. The attribute must initially be false." > > I actually agree with this, but there has been some pushback before. What > do people think? Should we add this feature? It would be easy. Pushback for something so obvious? Why? What can someone argue against the playing DOM attribute? >> 17. The spec is missing the definition of a scriptable way to abort the >> loading of the media element. > > Just remove the <source> elements and src="" attribute, and call load() > again. That's not an ideal solution. If I remove all the <source> elements and the src attribute, I have to re-add them once I want to play the media again. >> In the 3.14.9.4. "Loading the media resource" section [3] we can read: >> >> "If a media element whose networkState has the value EMPTY is inserted >> into a document, user agents must implicitly invoke the load() method on >> the media element as soon as all other scripts have finished executing. >> Any exceptions raised must be ignored." >> >> The networkState has the value EMPTY as default. This means that media >> resources are automatically loaded on document load. >> >> I suggest that autoplay also controls "autoload". That means if autoplay >> is false, then the media is not loaded when the document is loaded, only >> when play() is called. If autoplay is true, then the media is loaded and >> played automatically when the document is loaded, just like now. >> >> If this is the behaviour defined in the current spec, then, please try >> to make it clear that media elements do not load on document load, >> unless autoplay is set to true. > > If you don't want it to autoload, just don't set the source yet. This is not an ideal solution. In a document where the author doesn't want to use any scripting, he would simply add the media elements, with the associated <source> elements. As an author, I would expect I can enable/disable automatic media downloading and automatic media playback, without any scripting. >> 19. The spec does not define a way to stop media playback. >> >> Currently, pause() is different from what stop() is in media players. >> >> I agree stop() can be implemented by Web applications *but* this is a >> simple native function that should be available by default (compare with >> cue points, which are great, but seem rather complex for a first >> definition of the media element). > > What's the use case? Test case: open xmms/winamp/amarok/gmplayer/totem or some other media player and try the pause/stop buttons. I think you agree, it's obvious tons of online media player GUIs which will use the API defined by this spec will implement the stop() method. For that matter, they'll most likely implement their own half-working "playing" DOM property. What I am asking for is to include the common methods and properties - avoiding the need for authors to implement crappy solutions. For the same matter I want a method for fullscreen() video ... but that's another story (more complex). Regards, -- Mihai Sucan http://www.robodesign.ro
Received on Friday, 19 October 2007 10:08:36 UTC