- From: Glenn Adams <glenn@skynav.com>
- Date: Wed, 22 Feb 2012 01:41:57 -0700
- To: Mark Watson <watsonm@netflix.com>
- Cc: Adrian Bateman <adrianba@microsoft.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, David Dorwin <ddorwin@google.com>
- Message-ID: <CACQ=j+drLtfj08CjpDD4SrX8+QzdC7f0QHthnqAgn-p0B+86yQ@mail.gmail.com>
On Tue, Feb 21, 2012 at 11:01 PM, Mark Watson <watsonm@netflix.com> wrote: > > One of us is missing something here: <object> enables the web page to > embed completely arbitrary functionality (plugin) that is chosen by and > known to the web page author. <audio> and <video> enable the web page to > embed a well-defined media playback function, implemented by the UA, not > chosen by the page author. Yes, there are variations in the capabilities of > those media playback functions implemented by different browsers in terms > of protocols and codecs, so there needs to be capability discovery, but no, > you cannot choose to pull in arbitrary media capabilities of your choosing > that might need to be configured through <param>: you get what the UA > supports. > Would you agree that different codecs and media protocols employ distinct, though sometimes overlapping parameters that are not necessarily covered by existing attributes on video/audio/track? Would you agree that the set of codecs and media protocols supported by a given UA is not determined by HTML5 nor necessarily determined by any external specification (e.g., DLNA)? Would you agree that this set is not closed and will change over time? If you agree with any of these statements, then you will recognize that there will in all likelihood need to be a mechanism to interchange such parameters. If so, there are a number of options: 1. use a non-standard, adhoc, vendor specific approach such as advocated by Sylvia, e.g., add x-acme-codec-*, x-waterworks-protocol-*, etc. attributes willy-nilly 2. or, create a new version of HTML5 every time a new attribute is required 3. or, use a generic extensibility mechanism such as <param> In case #1, you end up with non-interoperable attribute soup, and you end up running into problems like the CSS property prefixing problem currently bogging down the CSS WG. In case #2, you have to obtain consensus for every parameter attribute and then rev HTML5. In case #3, you publish external (or other W3C) specifications defining one or more param name/value pairs for use with specific codecs and/or protocols. The UA simply passes the set of specified name/value pairs to the internal media component (whether or not it is native to the UA or a UA plugin -- this difference is irrelevant). To me, the choice is very simple: case #3 is already a tried and true solution, demonstrated by existing implementations of object. Many (most?) UAs will probably use existing plugin interfaces to support video/audio elements. Case #3 wins on solution reuse. Case #3 wins on extensibility and ease of processing. It may not invalidate the other use-cases, but what you call a "generic > solution" doesn't appear to me to be a solution at all. It just punts > definition of the functionality into some black hole. Where is an > application developer to look for definition of what parameters to set on > <param> ? > The application developer already has the quandary of not knowing what media codecs/protocols are supported by a UA. The application developer already has the quandary of not knowing what capabilities and parameters are available on those media codecs/protocols. There is no capability discovery mechanism to discover the latter in either case. And, notwithstanding canPlayType(), there is no reliabile capability discovery mechanism to determine the nature of codec support. [At best, a UA may say that it "probably" supports a MIME type.] To date, the definition of parameter support on built-in media codecs (via object) has been defined by UA manufacturers. However, other external specifications, such as CEA-2014 CE-HTML, have defined specific parameters to be supported in a standards compliance fashion. I would expect other, future external specifications or standards to fill this gap, but it they should not be forced to introduce x-cea-* or x-dlna-* attributes or define another adhoc syntactic mechanism when the generic mechanism supported by <param> is readily available, tested, and deployed. I can't understand the recent trend of jettisoning extensibility mechanisms in HTML5. This (not supporting param on audio/vide) seems like one more example of a false over-confidence to get it right the first time. Perhaps its my age, but I have little confidence in any organization's ability to get standards right the first time. There are good architectural reasons for extensibility, the most obvious being: we didn't think of it at the time... Not supporting param means reducing extensibility and architectural flexibility. It means reducing interoperability with existing and past practices that used object, and for which audio/video/track are now expected to provide at least functional parity, but also introduce newer and greater features. The zero-change counter proposal is a step backwards in functionality, utility, and extensibility. G.
Received on Wednesday, 22 February 2012 08:42:49 UTC