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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12643

           Summary: <video> change of fragment in media fragment URI
                    consequences
           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,
                    public-html@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 
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid

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

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 on the CC list for the bug.

Received on Tuesday, 10 May 2011 10:10:59 UTC