Re: Working Group Decision on ISSUE-41 Decentralized extensibility

On 02/08/2011 07:02 PM, Jirka Kosek wrote:
> Sam Ruby wrote:
>
>> == Next Steps ==
>>
>> Bug 10720 is to be closed and marked as WGDecision.  Issues 41 is also
>> to be closed.
>>
>> Since the prevailing Change Proposal does not call for a spec change, no
>> further actions are required.
>>
>> == Appealing this Decision ==
>>
>> If anyone strongly disagrees with the content of the decision and would
>> like to raise a Formal Objection, they may do so at this time. Formal
>> Objections are reviewed by the Director in consultation with the Team.
>> Ordinarily, Formal Objections are only reviewed as part of a transition
>> request.
>
> Dear Chairs and WG members,
>
> I'm raising Formal Objection against closing issue 41 -- Decentralized
> extensibility.
>
> In accordance with W3C Process I'm below providing technical arguments
> and proposing changes that would remove the Formal Objection.
>
> Arguments against closing issue 41
> ----------------------------------
>
> The current HTML5 specification doesn't provide safe mechanism for
> introducing and testing new browser vendor features. Without ability to
> safely introduce new features in the form of new elements either
> innovation or interoperability of HTML5 implementations will be impossible.
>
> Decentralized extensibility allows introduction of new elements by
> different HTML5 stakeholders without creating collisions and ambiguity.
> It's unreasonable to expect that there will be no need for adding new
> features in a form of elements in the future and thus mechanism for
> decentralized extensibility should be part of HTML5.
>
> Proposed changes that would remove the FO
> -----------------------------------------
>
> HTML5 specification should provide mechanism for using custom (or
> user/vendor defined) elements with fallback mechanism that handles
> elements unknown to the implementation.
>
> Below is the idea how such mechanism could work.
>
> 1. Specification should allow custom elements with name in the form
> x-prefix-name.
>
> 2. If user agent doesn't understand to custom element it will ignore its
> content and only content of<fallback>  subelement will be used instead.
>
> To show it on some real world example imagine that browser vendors see
> demand for some new feature, let's say video (for now, I'm pretending
> that there is no standardized<video>  element yet) and they
> independently decide try to find best way how to integrate it into language.
>
> One vendor introduces the following new markup:
>
> <x-ms-video>
>    <x-ms-source href="clip.mp4">
> </x-ms-video>
>
> Web developer who would like to try out this new feature can use
> <fallback>  to cope with the rest of browsers:
>
> <x-ms-video>
>    <x-ms-source href="clip.mp4">
>    <fallback>
>      Your browser doesn't support direct video playback
>    </fallback>
> </x-ms-video>
>
> At the same time another vendor creates similar feature but with
> slightly different naming as:
>
> <x-moz-video>
>    <x-moz-data src="clip.mp4">
>    <fallback>
>      Your browser doesn't support direct video playback
>    </fallback>
> </x-moz-video>
>
> Now web developer who would like to have video shown in both browser can
> leverage nested<fallback>s as
>
> <x-ms-video>
>    <x-ms-source href="clip.mp4">
>    <fallback>
>      <x-moz-video>
>        <x-moz-data src="clip.mp4">
>        <fallback>
>          Your browser doesn't support direct video playback
>        </fallback>
>      </x-moz-video>
>    </fallback>
> </x-ms-video>
>
> One day video is recognized as an important feature and the best from
> design of different vendor video features is blended into a new
> standardized<video>  element.
>
> <video>
>    <source src="clip.mp4">
> </video>
>
> Of course it will take some time before new element is supported accross
> browsers. So web developer can still use fallback to use older vendor
> specific video features like:
>
> <video>
>    <source src="clip.mp4">
>    <fallback>
>      <x-ms-video>
>        <x-ms-source href="clip.mp4">
>        <fallback>
>  <x-moz-video>
>  <x-moz-data src="clip.mp4">
>  <fallback>
>  Your browser doesn't support direct video playback
>  </fallback>
>  </x-moz-video>
>        </fallback>
>      </x-ms-video>
>    </fallback>
> </video>
>
> Or alternatively he/she can link small JS library to page which will
> replace<video>  with<x-ms-video>  or<x-moz-video>  as necessary.
>
> Just for the record I'm well aware of Maciej's arguments for not
> allowing vendor elements (see
> http://lists.w3.org/Archives/Public/public-html/2009Oct/0894.html). But
> his proposal builds on some assuptions which are not always true:
>
> 1) Different vendor/custom elements for the same feature use the exactly
> same content models
>
> 2) Content of unknown element should be always processed
>
> I hope that issue-41 will be reopened and good mechanism for
> decentralized extensibility will be developed instead of ignoring and
> postponing problem.

Your formal objection has been recorded:

http://dev.w3.org/html5/status/formal-objection-status.html#ISSUE-041

> Thanks,
>
>     Jirka Kosek

- Sam Ruby

Received on Wednesday, 9 February 2011 00:49:25 UTC