W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > December 2010

[Bug 10723] support for media fragment URIs in relevant HTML5 elements

From: <bugzilla@jessica.w3.org>
Date: Thu, 16 Dec 2010 01:16:43 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PT2SZ-0008MZ-Ie@jessica.w3.org>

--- Comment #10 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2010-12-16 01:16:41 UTC ---
(In reply to comment #9)
> Please only file one issue per bug. What one issue is this bug raising?

It seems that dealing with media fragment URIs has implications for several
parts of the spec. The one issue is of course how to support media fragment
URIs. But maybe we should now split it into several bugs now that the full set
of consequences are being listed?

My suggestion of first focus for this bug would be on what consequences the use
of temporal media fragment URIs in a <video/audio @src> or <source @src>
attribute has.

Here are the consequences:
1. When a temporal media fragment URL is used in a video/audio element (e.g.
http://ex.com/video.ogv#t=10,20), the media resource will start playing from
fragment start time (10 in the example) and pause at end time (20 in the
example) unless a @loop attribute is specified in which case the UA will repeat
the fragment. If the user or JS interacts with the timeline of the media
resource and jumps to a temporal location outside the fragment, the fragment
context is broken and the full resource is regarded again, in particular a
@loop will loop over the full resource again.

2. If the @controls attribute is given and a temporal media fragment URI is
loaded, there is a need to introduce markers on the controls for the fragment,
see e.g. http://www.youtube.com/watch?v=LfRRYp6mnu0 for an example

Do you want me to open new bugs for the other issues?

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, 16 December 2010 01:16:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:35 UTC