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

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

From: <bugzilla@jessica.w3.org>
Date: Thu, 07 Apr 2011 01:34:54 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Q7e7a-0002OW-0p@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12425

--- Comment #5 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-04-07 01:34:52 UTC ---
(In reply to comment #4)
> Any UI expectations for media fragments that apply to <video>/<audio> should
> also apply to viewing the media file in its own tab, or indeed retrieving a
> media file from a URL using a non-browser UA -- right?  Why is the HTML spec
> the right place to put this sort of thing?
> 
> I just opened the default movie player on Ubuntu and immediately found an "Open
> Location..." option that would let me view media from a URL.  The authors of
> that application presumably would have no reason to care about HTML or <video>,
> only about the semantics of media fragments.  Why should they have to look in
> the HTML spec to find out how they're expected to display URLs with media
> fragments?  This should be in the media fragment spec.

There are recommendations specified in the media fragment spec and that's all
that such a spec can do, since players may have different approaches to dealing
with the fragments.

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.

-- 
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 01:34:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 April 2011 01:34:58 GMT