[Bug 12425] User interface of temporal media fragment URI in @src of video element

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

--- Comment #7 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-04-07 22:16:53 UTC ---
(In reply to comment #5)
> We do want browsers to be compatible with each other, though. So we need to add
> the specific means in which fragments are exposed when a @controls attribute is
> given for audio or video. A browser isn't a random stand-alone media player,
> but exhibits a behaviour that needs to be compatible across browsers.

Why isn't there a need for compatibility between browsers and (at least some)
non-browsers?  Clearly some implementations might have entirely different
needs, but that's why there's such a thing as a "SHOULD" requirement
<http://tools.ietf.org/html/rfc2119>.  Alternatively, the media fragment spec
could explain how it's expected to work in browsers and browser-like
implementations, without requiring that behavior of other implementations. 
HTML5 does this in its Rendering section.

In particular, I'd expect the same URL to be interpreted in essentially the
same way if I open it in a dedicated movie player (that supports opening URLs)
and if I open it in a browser tab.  If the browser starts at the fragment start
time and the movie player doesn't, for instance, I'd regard the movie player as
broken.

(In reply to comment #6)
> Aryeh, your use case is dealt with at
> http://www.w3.org/TR/media-frags/#media-fragment-display (in the Media Fragment
> spec). Don't you have the answer of your question there?

What HTML-specific requirements are needed in addition to those requirements?

-- 
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, 7 April 2011 22:16:56 UTC