- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 26 Aug 2010 00:47:40 +1000
On Tue, Aug 24, 2010 at 7:43 PM, Philip J?genstedt <philipj at opera.com>wrote: > On Tue, 24 Aug 2010 10:24:35 +0200, Ian Hickson <ian at hixie.ch> wrote: > > > Given that, it wouldn't be a big problem to let modification of src >>> attributes on source elements trigger resource selection, you won't get >>> the 3-2-1 problem I mentioned earlier. >>> >> >> I don't really understand what use case this would solve. >> > > Neither do I, I'm just saying that it's easy to do if necessary. I was running through all the properties that can possibly be changed in JavaScript and checking which effects they have in all browsers, i.e. what events they call etc. I wasn't aware that authors are discouraged from changing @src on <source>. On Tue, Aug 24, 2010 at 6:24 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Sat, 24 Jul 2010, Silvia Pfeiffer wrote: > > > > There is definitely a spec bug, because different locations of the spec > > say diverging things. > > For the record, when the spec contradicts itself, and one part is > normative (such as the algorithm here) and another is non-normative (such > as the definitions here) then always assume the normative part is wrong. I > often forget to update the non-normative parts. > You mean: the normative part is right, I assume? Thanks for this clarification - I was indeed unaware of the history of changes. On Mon, 26 Jul 2010, Silvia Pfeiffer wrote: > > > > I now wonder about the intention of play() (and also of pause()). As I > > understood it, they are both meant to reload the media resource if > > @currentSrc has changed, similar to what load() is supposed to do. > > I do not believe that has ever been the intent. > Both descriptions of play() and pause() have a "loading the media resource" in them. media . play<http://www.whatwg.org/specs/web-apps/current-work/complete.html#dom-media-play> () Sets the paused<http://www.whatwg.org/specs/web-apps/current-work/complete.html#dom-media-paused>attribute to false, loading the media resource<http://www.whatwg.org/specs/web-apps/current-work/complete.html#media-resource>and beginning playback if necessary. If the playback had ended, will restart it from the start. media . pause<http://www.whatwg.org/specs/web-apps/current-work/complete.html#dom-media-pause> () Sets the paused<http://www.whatwg.org/specs/web-apps/current-work/complete.html#dom-media-paused>attribute to true, loading the media resource<http://www.whatwg.org/specs/web-apps/current-work/complete.html#media-resource>if necessary. I assumed that if the @currentSrc had changed, that would trigger loading the new media resource, too. If that is not the intention, maybe the non-normative description should point out that it only triggers loading the media resource when the @src attribute is being set for the very first time. Though, to be honest, I don't really see a difference between setting @src through JavaScript for the first time (which IIUC also has a NETWORK_EMPTY state) and re-setting it again a subsequent time - IMHO both should consistently either include the media resource loading or exclude it. On Tue, 27 Jul 2010, Silvia Pfeiffer wrote: > > > > Sure, but this is only a snippet of an actual application. If, e.g., you > > want to step through a list of videos (maybe an automated playlist) > > using script and you need to provide at least two different formats with > > <source>, you'd want to run this algorithm frequently. > > Just have a bunch of <video>s in the markup, and when one ends, hide it > and show the next one. Don't start dynamically manipulating <source> > elements, that's just asking for pain. > > If you really must do it all using script, just use canPlayType and the > <video src=""> attribute, don't mess around with <source>. > Thanks for adding that advice. I think it's important to point that out. Cheers, Silvia. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100826/86839cc3/attachment.htm>
Received on Wednesday, 25 August 2010 07:47:40 UTC