W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > April 2011

[Bug 12426] Effect when @src of video element contains temporal media fragment URI and @loop

From: <bugzilla@jessica.w3.org>
Date: Thu, 07 Apr 2011 08:00:21 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Q7k8b-0000Kb-Q8@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12426

--- Comment #8 from Philip Jägenstedt <philipj@opera.com> 2011-04-07 08:00:20 UTC ---
(In reply to comment #7)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > In my mind, a loop goes over the given resource, which in this case is the
> > > fragment. As soon as the user interacts with the resource, however, we break
> > > out of the loop state. For example, if the user pauses at the end, then the
> > > next 'play' will continue. Or if the user seeks anywhere, then we revert to the
> > > full timeline.
> > 
> > I was talking about the case when playback pauses at the end of the fragment
> > range because it's the end, not because the user paused at that point.
> > 
> > Do you mean that *any* seeking, including within the fragment, should break the
> > state and cause it to behave as if no fragment was specified at all?
> 
> Yes, that would be my approach. OTOH, an explicit control of that state might
> be a good alternative.

Having an invisible state that gets broken by any user interaction would no
doubt confuse users, and having special UI to toggle that rather obscure state
also doesn't seem like a nice thing to subject users to. I think either option
is actually worse than not supporting loop at all.

-- 
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 Thursday, 7 April 2011 08:00:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 April 2011 08:00:24 GMT