Re: ISSUE-41: Decentralized extensibility

On Mon, 21 Jul 2008, Doug Schepers wrote:
> 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.

This works sometimes. It's expensive -- millions of dollars a year 
expensive, based on what Netscape was spending on outreach in the 6.x 
days, and for the browser vendors there's very little payoff as opposed to 
just changing the rendering engine.

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

The implementors are the ones who are most motivated to make their new 
browsers work with existing sites. The burden isn't put on the 
implementors, it's just that the implementors are the only ones who care 
enough to effect practical change.


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

As far as I'm aware, there are no major content creators writing 
mixed-namespace content.

As far as other content goes, all studies I've seen uniformly show that 
all developers -- major or minor -- deploy very broken content.


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

I don't understand this question.


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

Given how much MathML-in-HTML content already exists _today_, I am not at 
all convinced that actually _supporting_ MathML in text/html will 
discourage deployment.

Indeed, the chicken-and-egg problem in the case of MathML is a non-issue, 
given the existing deployed MathML markup. (This is a rare opportunity; we 
are not often afforded content before implementations.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 21 July 2008 21:56:39 UTC