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: Wed, 27 Jul 2011 07:44:06 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Qlymk-0000RH-HF@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333

--- Comment #25 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-07-27 07:44:04 UTC ---
(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.

-- 
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 07:44:07 UTC

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