Re: ISSUE-41: Decentralized extensibility

Hi, Ian-

Ian Hickson wrote (on 5/23/08 6:05 AM):
> 
>   The implementors of Browser B end up forced to change their handling
>   of Feature F, possibly removing it altogether. The spec has failed.

Rather than changing their browser, which affects more sites that just 
Developer D's, it seems more reasonable and economical for Browser B to 
look at what Developer D is doing wrong (a process Browser B will have 
to do anyway), and contact Developer D to indicate what Developer D 
could change about their site to make it work properly in all browsers. 
  I've seen this work very pragmatically in Mozilla's bugtracking 
system, where Developer D reports a bug, then is shown the way to 
correct their own mistake; developer lists are good for this too.  Why 
put the bulk of the burden on implementors?


> If you think this is farfetched, consider the random, incomplete, and 
> ill-formed SVG and MathML fragments that already exist in text/html markup 
> today, 

You've pointed out (on IRC) a few obscure sites with a smattering of 
non-functional SVG elements... extrapolating from that to your stated 
scenario seems like a dubious connection.  Do you have any substantive 
evidence to support your claim that major content creators will be as 
sloppy?  Please confine your evidence to cases of mixed-namespace 
content, specifically.

What patterns exist in the random and incomplete markup that suggest 
that such sites will be fatally broken by another browser based on 
particular features?  Please be specific.


> before Author A even has any reason to deploy SVG and MathML (aka
> Feature F) on his site.

As far as SVG goes, the Adobe SVG Viewer has allowing inline SVG in HTML 
for 6 years or so, and in the past 3 years, SVG in XHTML has worked in 
FF and Opera at least.  That seems like enough reason for a dabbler in 
Web technology to think that it might somehow benefit them, even if they 
don't really understand how or why.  On the other end of the scale, 
there are well-made sites that are using SVG+XHTML properly.  So, there 
is a reason for deployment, even if there isn't critical mass yet.


> With the MathML stuff in HTML5, the spec has been very carefully designed 
> to have simple and effective "bail out" behaviour in case the scenario 
> above happens. We can do that because MathML is a specific vocabulary that 
> we can plan for. We don't need to be especially generic. We don't have to 
> handle any random markup, only MathML and HTML mixed in specific ways.

But your proposal doesn't handle it properly, because it provides no 
facility for fallback.  This is a bad fit for the open Web platform, 
because it discourages people from using those features in the HTML 
language (to wit, MathML integration) which are not universally 
interoperably supported, leading to the chicken-and-egg problem.


> I'm not convinced that it is possible to design a generic syntax that is 
> resilient in the face of the above developer behaviour. Even if I thought 
> that such generic syntax was desireable, we would need a very concrete 
> proposal before even considering this.

Could you please help me out here?  I couldn't decide which was the best 
fit here, according to this helpful guide:
   http://ian.hixie.ch/bible/handling-people

I'm torn between, "Say it would be better to wait for a wider and more 
detailed study over a longer time scale" and "Say that there is not 
really any need for a fundamental rethink of existing policies".

(By the way, nice use of point 2 on Committees.  Textbook, really... a 
long speech, with an manufactured anecdotal example of 
good-code-gone-bad.  The patriotism in "The Web platform is, frankly, 
too important to let people extend it without inviting the entire Web 
community to take part in the extension process" was emotional without 
containing enough substance that someone could challenge it technically. 
  Bravo!)


> As this is the editors' response to Issue 41, I have marked the issue 
> closed, as recommended by the chairs.

If you are going to close the issue, I think it behooves you to cite the 
technical arguments for doing so.  Your scenario did not appear to be 
technical at all, despite your labeling it as such; it seemed to be a 
purely hypothetical projection of a misuse of code, with exaggerated 
results.  Does the problem lie in the parser, the tokenizer, the DOM 
representation, the script execution, or the rendering?  What is the 
nature of the problem, and what solutions have you tried and rejected, 
and on what grounds?

Microsoft has explicitly stated that they (at least) are interested in a 
features for decentralized extensibility.  You claim to defer to browser 
vendors, even when you don't like the solution or the feature... why is 
this feature an exception?

Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF

Received on Monday, 21 July 2008 21:38:53 UTC