W3C home > Mailing lists > Public > public-html@w3.org > March 2010

RE: TWO Change proposals for ISSUE-41 : Distributed Extensibility

From: Ennals, Robert <robert.ennals@intel.com>
Date: Tue, 16 Mar 2010 23:59:32 +0000
To: Ian Hickson <ian@hixie.ch>, Maciej Stachowiak <mjs@apple.com>
CC: HTMLwg <public-html@w3.org>
Message-ID: <83D7DEC65EB438489DE261BD36F1F11F016D0EBD@irsmsx503.ger.corp.intel.com>
Ian Hickson wrote:
> On Tue, 16 Mar 2010, Maciej Stachowiak wrote:
> > It seems to me that this proposal adds a new extensibility mechanism,
> > and thus is in the scope of the issue as I presented it last month:
> >
> > http://lists.w3.org/Archives/Public/public-html/2010Feb/0796.html
> >
> > The fact that you could also describe it in more specific terms, based
> > on the nature and purpose of the proposed extensibility mechanism, does
> > not make it out of scope for the issue.
> If this is a "distributed extension" mechanism, then the term means even
> less than I thought it did. I'm even more at a less as to what this issue
> is supposed to cover than I was before. Is readding microdata to the spec
> in scope? Is merging all of XBL2 into the spec in scope? Both of those are
> much more "distributed extensibility" than conventions for vendor- specific
> experiments.

Referring to the original ISSUE-41 definition, I think what people want is the ability to define extensions similar to SVG, MathML, and FBML that can be used in an HTML document.

Notably, these were all extensions that changed the way that a page was visually rendered. This is different from Microdata, which is designed to be used exclusively for metadata IIRC.

Extensions of this sort would be supported by both of my two proposals. Granted, each of them would have to have been reformulated to use only attributes in order to work with proposal Y, but they would have worked. Proposal X would allow use of these extensions "out of the box".


> I'm not suggesting that we "summarily close the issue without
> considering
> proposals", I'm asking that we ask people who feel this issue is a real
> issue to put forward specific problem statements, ideally in the form of
> bugs, so that we can follow up each such problem separately.

I outlined several such problem statements in my proposals. In particular:

It is often useful for people to define extensions to HTML. These may be vendor-specific experiments for features that may eventually get folded into the main HTML spec. They may be enterprise-specific extensions that would be of little use for general HTML. They may be community-specific features that are useful to too few people to make sense as part of the core spec. They may be experiments by a relatively obscure group on top of a patched open source browser that turn out to work well and get adopted by a vendor.

I think there is value in allowing people to experiment with extensions such as SVG, MathML, FBML, 3D, Canvas, etc, without having to wait for the HTML WG to merge such specs into the HTML standard.

I think that this is the core essence of what people want when they say they want "distributed extensibility".


Received on Wednesday, 17 March 2010 00:00:14 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:59 UTC