- From: <bugzilla@jessica.w3.org>
- Date: Thu, 07 Apr 2011 00:41:03 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12426 --- Comment #6 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-04-07 00:41:03 UTC --- (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > This is one of the corner cases with MF that has had me wondering what to do as > > > > an implementor. Lacking strong use cases, I would prefer that the loop > > > > attribute has no effect when used together with MF, to reduce the amount of > > > > magical state. > > > > > > The strong use case is simply the replay. Someone has carefully defined a > > > temporal media fragment that illustrates a funny moment and wants to > > > bookmark/share it. The loop on this media fragment will be to play and replay > > > just this bit. For example, I just want to see the "trip over" of this rider in > > > the Tour de France: http://www.youtube.com/watch?v=XycqQr03ba8#t=4,15 > > > > Personal preferences vary of course, but I'd prefer pressing play again to > > replay the video, nothing is funny enough to loop indefinitely. However, the > > issue is then what happens when you press play after pausing at the end of the > > fragment range. What's the thinking on that? The user either wants to watch > > from the beginning of range or keep watching past the end of the range, neither > > is obviously the Right Thing�. > > > > In a way, things would be a lot simpler API- and UI-wise if a temporal range > > was more of a crop than a focus. That's not a great user experience though, so > > I digress... > > 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. s/loop/fragment/ - sorry > 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. -- 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 00:41:05 UTC