W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > May 2011

[Bug 12643] New: <video> change of fragment in media fragment URI consequences

From: <bugzilla@jessica.w3.org>
Date: Tue, 10 May 2011 10:10:57 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-12643-2486@http.www.w3.org/Bugs/Public/>

           Summary: <video> change of fragment in media fragment URI
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: silviapfeiffer1@gmail.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,

Over in bug 10723 we discussed about what should happen when browsers find a
media fragment URI in the @src of a media element.

We stumbled across the question of what browsers are supposed to do when the
@src is changed by script, but only the fragment of the URL changes.

Currently, it seems that even setting v.src=v.src triggers a full new run of
the source selection algorithm and with it all the associated network activity
and events.

We've solved this problem for HTML pages and fragment addressing in 

But we haven't solved it for media resources (or image resources for that

What should v.src=s.src do? What should a change from
http://example.com/video.ogv#t=20 to http://example.com/video.ogv#t=50 do?

I think just like it is preferable for HTML resources to not retrieve the
resource again, the same applies to media resources. v.src = v.src should
probably just seek to the beginning of the resource, and a change of the
fragment time should just do a change of the currentTime, too.

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 Tuesday, 10 May 2011 10:10:58 UTC

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