RE: Working Group Decision on ISSUE-41 Decentralized extensibility

> I'm raising Formal Objection against closing issue 41 -- Decentralized extensibility.

We have recorded this formal objection to the WG decision on ISSUE-41 at:
http://dev.w3.org/html5/status/formal-objection-status.html#ISSUE-041


Do you wish to maintain this Formal Objection?  If so then we will keep it on this list so that it can be presented to the W3C Director at the next transition of the HTML5 specification.  If not please let us know and we will drop it from the list.

/paulc

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Jirka Kosek
Sent: Tuesday, February 08, 2011 7:02 PM
To: Sam Ruby
Cc: HTML WG
Subject: Re: Working Group Decision on ISSUE-41 Decentralized extensibility

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.

Thanks,

    Jirka Kosek


--
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@kosek.cz      http://xmlguru.cz

------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

Received on Monday, 8 October 2012 21:02:10 UTC