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

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

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 16 Mar 2010 23:31:44 +0000 (UTC)
To: Maciej Stachowiak <mjs@apple.com>
Cc: HTMLwg <public-html@w3.org>
Message-ID: <Pine.LNX.4.64.1003162323550.10462@ps20323.dreamhostps.com>
On Tue, 16 Mar 2010, Maciej Stachowiak wrote:
> On Mar 15, 2010, at 9:48 PM, Ian Hickson wrote:
> > On Tue, 16 Mar 2010, Ennals, Robert wrote:
> > > 
> > > Proposal Y: tries to give a better fallback and backwards-compat 
> > > story: 
> > > http://www.w3.org/html/wg/wiki/ChangeProposals/fixedprefixsimple
> > 
> > While I think this proposal is close to something that we should 
> > probably add to HTML5, I don't think it's "Distributed Extensibility". 
> > It would be more accurate to describe it as a convention for 
> > preventing vendor- specific non-standard extensions from clashing with 
> > themselves and future standard development.
> 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 

> You are correct that ISSUE-41 is extremely broad. This issue predates 
> not only the current process, but also any of the current set of Chairs. 
> Under the new Decision Policy, it's unlikely we would ever again end up 
> with such a broad scope for a single tracker issue. That being said, I 
> don't think it would be legitimate to summarily close the issue without 
> considering proposals.

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.

Asking for change proposals for something so broad that it covers a 
convention for proprietary experiments in browsers, a generic mechanism 
for communities who want to provide machine-readable data in their pages 
for post-processing, a mechanism for merging other W3C vocabularies into 
text/html, and maybe even mechanisms for extending the syntax of the 
language, or for recasting the HTML vocabulary in different formats like 
JSON, or for adding new DOM interfaces to existing elements, is not 
productive, as demonstrated by the fact that we already have at least one 
change proposal that is not particularly controversial and in fact has an 
open bug.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 16 March 2010 23:32:14 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:13 UTC