- From: <bugzilla@jessica.w3.org>
- Date: Tue, 10 May 2011 10:31:13 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12643 Philip Jägenstedt <philipj@opera.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |philipj@opera.com --- Comment #1 from Philip Jägenstedt <philipj@opera.com> 2011-05-10 10:31:12 UTC --- "What's the use case?" When navigating directly to a media resource, I can see the argument that changing the fragment component can be used to trim down the fragment by testing successively smaller ranges. Are there other cases? Is it critical in this situation that the video is never reloaded or has its state reset? The time to decode and seek to a certain point in a file is rather small even without this optimization. For <video> elements in an HTML document, the utility of dynamically changing the fragment is less obvious. Does it side-step the resource selection algorithm? Does it cause currentTime to change? More generally, it seems like a very cumbersome interface for whatever it is it should achieve. If you have <source> elements, you'd have to change the src attribute on all of them and then call load(). Should that side-step the resource selection algorithm and how? IMO it might be easier to work with if there were IDL attributes startTime and endTime, or if a fragment implicitly creates a cue range with pauseOnExit set which could then be manipulated by scripts. But, without a clear understanding of the use cases I'm just guessing... -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Tuesday, 10 May 2011 10:31:15 UTC