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: Sun, 10 Apr 2011 08:32:10 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Q8q42-0005zX-Ld@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12426

--- Comment #13 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-04-10 08:32:07 UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> > The use case for looping over a fragment are no worse than the use cases for
> > looping over the complete video. I'm not a fan of that attribute myself, but it
> > exists, it has an effect on video elements and it needs to show the expected
> > effect when the resource is limited to a fragment, too, which should be looping
> > over the fragment rather than the full video.
> 
> Not supporting it is nevertheless a valid option, just like the spec was just
> updated to not support looping for synchronized resources.

If we find more and more use cases where we disallow @loop, we might as well
completely remove it. You can always do the looping through JavaScript with
direct setting of currentTime.


> The only non-annoying use case for gapless looping that I know of is background
> music for games, and I don't think that MF is really helping that use case.

Depends on how that music is given - if it's a fragment that needs looping,
then it is a use case. But I don't even see @loop giving any advantage over
setting currentTime in script - it won't be more gapless IIUC.

-- 
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 Sunday, 10 April 2011 08:32:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:08 UTC