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 05:40:40 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QkUx6-0001S2-PA@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333

--- Comment #5 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-07-23 05:40:39 UTC ---
(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.

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?

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.

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

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.

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

-- 
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 05:40:42 UTC

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