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

[Bug 13333] audio, video (and source) elements require param children or equivalent

From: <bugzilla@jessica.w3.org>
Date: Sat, 23 Jul 2011 06:55:40 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QkW7g-0004rw-1V@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333

--- Comment #7 from Glenn Adams <glenn@skynav.com> 2011-07-23 06:55:38 UTC ---
inline for a couple of comments on specific examples

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > > Also not that swf or sliverlight files are much more than just audio or video
> > > > > resources and can thus not be used in audio and video elements. So, those
> > > > > examples are not really valid.
> > > > 
> > > > Oh? Why not? There is nothing in the definition of audio or video that preclude
> > > > its use. There are no restrictions placed by HTML5 on the media type referenced
> > > > by these elements. Since swf and silverlight can represent audio and video
> > > > content,
> > > 
> > > I don't know enough about silverlight to comment, but I do know that swf does
> > > not represent audio or video content. Instead, it represents a player that can
> > > play back audio or video content. That is very different.
> > 
> > If you don't like the swf example, then substitute flv and the nothing else
> > changes.
> 
> Actually, a lot changes. flv is indeed a video resource format, even though it
> is not registered as a mime type at
> http://www.iana.org/assignments/media-types/video/index.html (which I am
> actually quite surprised about). It is usually video/x-flv, while swf has
> application/x-shockwave-flash and anything can be in a swf - it doesn't have to
> be video.
> 
> When substituting flv, your params don't make much sense any more IMO.
> 
> "quality" is something that is subjective and probably only provides a label
> for a specific website that says that if it has several quality levels
> available, then choose the "high" one (whichever that is). Thus, this parameter
> can be replaced by data-quality.

not if the agent intended to interpret this parameter is the UA itself, that
is, if the prohibition on UA interpretation of data-* is to be maintained

> As for "allowfullscreen": that is a restriction to the functionality of the Web
> browser that the Web server does not need to even be told about for retrieval
> of the resource. There is currently no means to stop a user from watching a
> video fullscreen when the browser has such functionality. And why should there
> be?

this is a directive provided by the content author to be interpreted by the UA;
the UA is defined (and published) with semantics for allowfullscreen; because
the intended recipient of this directive is the UA itself, then it can't use
data-*  if the prohibition on UA interpretation of data-* is to be maintained

> As for the drm key: that is definitely something only between the Web page and
> the Web server, so a data-drmkey attribute would be sufficient.

not if the agent intended to interpret this parameter is the UA itself, that
is, if the prohibition on UA interpretation of data-* is to be maintained 

> The "windowless" parameter is not relevant for the Web context.

yes it is if the agent intended to interpret this parameter is the UA itself,
that is, if the prohibition on UA interpretation of data-* is to be maintained

> And the choice of protocol to use for retrieval of a resource on the Web is
> given in a URL and not in a parameter.

DLNA connection manager parameters are not co-extensive with the URL protocol
(scheme) field, so the value of the src attribute is not sufficient; in this
case, a DLNA enabled user agent intended to interpret this parameter;

> I haven't seen a parameter yet that requires a "param" attribute.

that's because you don't seem to recognize that each and every one of this
examples requires specific UA interpretation and responses to the parameter;

such responses are not expected to be define in HTML5, but in external
standards/specifications (or as private agreements); however, a standard
mechanism for authoring and interchanging such parameters between the content
author / server and the UA *is* required;

the fact that param is widely used with video/audio resources via object is
sufficient proof that an equivalent mechanism is needed on video/audio

-- 
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 Saturday, 23 July 2011 06:55:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:14 UTC