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

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

--- Comment #36 from Glenn Adams <glenn@skynav.com> 2011-07-29 00:17:25 UTC ---
(In reply to comment #33)
> (In reply to comment #32)
> > (In reply to comment #0)
> > > <audio>
> > >   <source src="audio.mp3">
> > >     <param name="dlna-res-protocolInfo" value="rtsp-rtp-udp:*:audio/mpeg:*">
> > >   </source>
> > >   <source src="audio.mp3">
> > >     <param name="dlna-res-protocolInfo"
> > > value="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3">
> > >   </source>
> > > </audio>
> > 
> > Why isn't this written as 
> > <audio>
> >   <source src="rtsp://something/audio.mp3">
> >   <source src="http://something/audio.mp3">
> > </audio>
> > ?
> > 
> > (In reply to comment #28)
> > > (In reply to comment #26)
> > > > (In reply to comment #24)
> > > > > Regarding actual implementations of DRM support in browsers, there is more than
> > > > > one browser that supports DRM of video/audio content, and which AT THE CURRENT
> > > > > TIME makes use of the param child on object to communicate DRM parameters.
> > > > 
> > > > What browsers are those?
> > > 
> > > I am referring to browsers currently deployed on Televisions, Set-Top Boxes,
> > > and Mobile Devices, particularly those that participate in the playback and
> > > sharing of DRM controlled video or audio content. There are a variety of
> > > standards/specifications that apply to such devices, such as those defined by
> > > DLNA and other industry associations.
> > 
> > I meant the names of the browsers.
> > 
> > Why does your DRM scheme require parameters to be supplied alongside the
> > DRM-obfuscated file? That is, why isn't it sufficient to treat the DRM wrapper
> > as a special kind of file format? Like this:
> > <audio>
> >   <source src="audio.drm" type="audio/industry-association-drm-wrapper">
> > </audio>
> > 
> > Anyway HTML5 is trying to be a spec for the Web--a royalty-free system where
> > multiple vendors can implement clients without asking permission from a DRM
> > proprietor. While it's possible to reuse Web specs in closed systems, I think
> > we shouldn't design HTML5 for closed systems, since that's a distraction that
> > takes attention and focus away from making the Web better. That is, I think we
> > shouldn't spend time adding closed system-motivated features.
> > 
> > More concretely, I don't want to disrupt the parsing of <source> (a void
> > element--for better or worse--in shipped Web browsers) in order to cater to
> > closed-system use cases.
> 
> 
> 
> I actually read this whole thread as a request for an attribute and not an
> element. I think it can be done better with an attribute without destroying the
> parsing of <source> as it is now. For example, it can be done as something
> like:

Absolutely not. I am not requesting an attribute.

> <audio>
>   <source src="audio.drm"
>           x-dlna-res-protocolInfo="httpget:*:audio/mpeg:DLNA.ORG_PN=MP3">
> </audio>
> 
> or
> 
> <audio>
>   <source src="audio.drm"
>           x-param="dlna-res-protocolInfo=httpget:*:audio/mpeg:DLNA.ORG_PN=MP3">
> </audio>

Both of these entail use of a non-standard mechanism for specifying additional
parameters. If object (and other facilities) have a standard mechanism for
specifying parameters, then video/audio should as well. Otherwise you should be
arguing for the removal of param from object, for the removal of features
argument from Window.open(), etc.

> In any case, I agree with Henry that we should neither destroy the parsing of
> <source> nor the openness of the HTML5 spec.

'destroy parsing'? what are you talking about? We are talking about a spec in
the early period of its implementation. There will be *many* technical changes
made before HTML5 and its relevant specs are final. Your presumption that there
should be no technical change at this early stage (before the first LC is even
finished) is not realistic.

'destroy openness'? really? give me a break...

G.

-- 
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 Friday, 29 July 2011 00:17:31 UTC