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
------------------------------------------------------------------