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

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

--- Comment #27 from Glenn Adams <glenn@skynav.com> 2011-07-27 14:13:26 UTC ---
(In reply to comment #25)
> (In reply to comment #23)
> >
> > for HTML5 to be successful in a variety of device contexts (other than the
> > desktop), the spec must recognize the role of extensibility and the existence
> > of external specifications;
> 
> HTML is extensible by nature:
> http://dev.w3.org/html5/spec/Overview.html#extensibility .
> 
> 
> > the bug reported here is an enabling technology that facilitates use of
> > video/audio elements in the real world of devices that extends beyond the role
> > of the HTML5 spec itself;
> 
> What you are advocating is the introduction of vendor-specific proprietary user
> agent extensions hidden under the pretense of having a standard param
> attribute. Whichever way you bend this: you are not advocating an open and
> interoperable Web with your approach.
> 
> If you want to do what you are proposing to do, it really doesn't matter if we
> standardise anything here in HTML: you can already introduce new attributes on
> elements.
> 
> 
> > there are a number of other existing extensibility
> > mechanisms already in place in HTML5; as a result, your reluctance to recognize
> > the need for extensibility here is not entirely consistent with these facts;
> 
> None of your examples do the same as what you are proposing.
> 
> 
> > for example, in HTML5 and referenced specs we have:
> > 
> > (1) the 'args' argument on HTMLCanvasElement.getContext(...), by means of which
> > context specific or UA specific parameters may be provided to the Canvas
> > implementation;
> 
> > 
> > (2) the 'features' argument on Window.open(...), by means of which UA or
> > platform specific parameters may be provided to the UA/browser/client
> > implementation;
> > 
> > (3) the 'protocols' argument on WebSocket constructors, by means of which UA,
> > platform, or transport/protocol specific parameters may be provided to the
> > UA/browser/client implementation;
> 
> These are all parameters on function calls in JavaScript. If you wanted that,
> you'd ask for introduction of a new Video() constructor with a param argument.
> 
> 
> > (4) the existing use of param on object element;
> 
> This is exclusively used for plugins and no matter how hard you try to regard
> plugin and UA core code as the same - they are not. Plugins extend the
> functionality of the standardised Web with proprietary functionality.
> 
> 
> > (5) the use of namespace qualified attributes on the XHTML syntax of HTML5
> 
> Let's not go into an XHTML discussion when we are discussing HTML5.
> 
> So, I'm sorry, but I really think we're not doing the open Web a favor by
> introducing a hidden means for non-interoperable proprietary extensions.
> Content that would be published for such an extension would not play natively
> in all browsers. That we have such a situation today with codecs is unfortunate
> and should not be a mistake that we should continue to repeat.

you keep insisting that this mechanism is a vendor specific proposal, it is
definitely not; it is a proposal to enable other standards, whether proposed by
W3C or external organizations; it is to maintain consistency with current,
real, necessary practice;

you seem to be advocating an idealistic position that presumes that HTML5 will
a priori specify all useful/necessary features;

you have failed to offer a viable alternative to this proposal, all you have
offered either doesn't work or violates some prohibition or convention; just to
review, you have said:

* use data-*
* use non-standard attributes in HTML syntax
* use object
* use JS parameters to non-standard JS interfaces

to re-iterate why these don't work:

* use data-*

HTML5 prohibits this usage when UA is intended to interpret values

* use non-standard attributes in HTML syntax

may result in name collisions and is generally disparaged by W3C practices

* use object

doesn't implement HTML{Video,Audio}Element semantics

* use JS parameters to non-standard JS interfaces

requires introduction of non-standard JS constructors, e.g., Audio(src,params),
Video(src,params); forces procedural only expression, precluding declarative
representation;

i work with a number of standards/specifications organizations that need
compatibility for video/audio with the specification of arbitrary configuration
parameters in a way that can adhere to current HTML5 languages, both HTML and
XHTML syntaxes; these other organizations intend to define profile(s) of HTML5
and *will* define certain standard uses of such parameters, making them
non-vendor dependent;

at this point, I think I've made my case clearly and repeatedly, so it won't be
fruitful to comment further unless a new alternative is offered or the proposed
solution is accepted;

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 Wednesday, 27 July 2011 14:13:34 UTC