This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23492 - Linking to a page with a fragment identifier that causes a particular media element to be shown and to seek to a particular position
Summary: Linking to a page with a fragment identifier that causes a particular media e...
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 enhancement
Target Milestone: Needs Impl Interest
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
Depends on:
Reported: 2013-10-14 19:34 UTC by Ian 'Hixie' Hickson
Modified: 2014-09-30 16:35 UTC (History)
5 users (show)

See Also:


Description Ian 'Hixie' Hickson 2013-10-14 19:34:21 UTC
First described on Sat 24 Nov 2012 by Nils Dagsson Moskopp.

On Mon, Dec 17, 2012 at 4:37 PM, Ian Hickson <> wrote:
> You have a Web page with a single "major" <video> or <audio> element
> in it, e.g. the YouTube watch page, and you want to be able to link
> to that page with a fragment identifier that causes the video to
> start playing at a particular time, without any scripts involved.
> Also, from within a page, use a hyperlink to cause a media element
> to seek to a specific time, in response to user interaction, without
> any scripts involved.

On Tue, 18 Dec 2012, Nils Dagsson Moskopp wrote:
> I want to be able to link to a media element in the context of a
> particular page at a particular time via a URI. Starting playing is
> something that is already handled by the autoplay attribute, being
> able to link to an element at a particular time is the issue at
> hand.
> Since one can have multiple media elements on a page – for example,
> in a blog post – I find it important to be able to address a
> specific element, like
> <>. (A solution
> where the fragment addresses the element with parameters would
> preserve most current semantics. Would using the ampersand for
> parameters be web-compatible?)

On Tue, 18 Dec 2012, Nils Dagsson Moskopp wrote:

On Wed, 19 Dec 2012, Philip Jägenstedt wrote:
> Redefining/extending what the fragment component does for HTML is
> somewhat risky, so it really comes down to what exactly the
> processing should be.
> What should a browser do with a URL ending with #foo&t=10 if there
> is an element on the page with id="foo&t=10"? What about #foo&bar if
> there is an element with id="foo"? I would be surprised if treating
> #foo& the same as #foo were Web compatible...

More data at:
Comment 1 Ian 'Hixie' Hickson 2014-07-23 00:11:00 UTC
I'm tempted to say that we should just let this be a scripted thing. I mean it's similar to Kevin's Fragmentions, or to the old XPointer stuff. If we want to do this we should find some generic way to do it that isn't quite as heavy as XPointer and yet is going to be widely compatible with the Web, while still being extensible, so we don't have to keep fixing this for different contexts...
Comment 2 Philip Jägenstedt 2014-07-23 09:36:03 UTC
FWIW I agree, this is pretty easy to do with scripts. A built-in feature for this would only work if the media element has an id and is actually in the page at the time processing is defined to happen, which seems fairly brittle.
Comment 3 Ian 'Hixie' Hickson 2014-09-30 16:35:09 UTC
I'm going to say we should defer to scripts on this. There are so many complicated cases (how do you pick which video element, how do you make the URLs robust in the face of changing markup, how do you handle dynamically-created video elements, how do you handle preroll ads, etc) that depend on the specifics of each site, that I don't really see how we could do it.