- From: <bugzilla@jessica.w3.org>
- Date: Thu, 07 Apr 2011 09:27:25 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12426 --- Comment #9 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-04-07 09:27:25 UTC --- (In reply to comment #8) > (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. Are you suggesting that when a @loop is given on a video for which a fragment is specified, we ignore @loop and just stop playing at the end of the fragment, no matter what? I don't think that meets the expectations of the developer. -- 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 09:27:30 UTC