Re: ISSUE-41: Decentralized extensibility

On Mon, 21 Jul 2008, Doug Schepers wrote:
> 
> Thanks for addressing some of my questions.  You missed a couple that I 
> think are important, not only to this issue, but to how the WG operates.  
> I'll repeat them here for your convenience:
> 
> * 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?

I assume you are referring to this e-mail:

   http://lists.w3.org/Archives/Public/public-html/2008Jul/0197.html

As far as I am aware, Chris' points aren't contentious. The current HTML5 
draft has a generic extension mechanism that can be trivially extended in 
future versions to handle other vocabularies just as he desires.

I'm sure if Chris has any specific technical feedback he won't hesitate to 
let us know.

More generally, HTML4 has a number of extensions mechanisms, and HTML5 
both builds on those and introduces new ones. As far as I am aware, lack 
of extension points is not an issue browser vendors would like me to work 
on at this point.


> * What is your technical rationale for closing Issue-41?

The rationale at the time was that the issue had been resolved with the 
various mechanisms discussed at the time. At this point the issue tracker 
tool is no longer the way bugs and feature proposals are tracked in the 
Bugzilla database.


> > > 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.
> 
> This ignores the cost of changing incompatibly with other existing 
> content. Microsoft has reported rather damaging effects for doing that 
> more recently than the Netscape days, with some of the changes they made 
> in IE6 and IE7.

My point was that there are costs, very high costs, to developer outreach 
programmes, and that that is why browser vendors tend to prefer changing 
their engines rather than doing developer outreach. I'm not trying to 
justify this, I'm just saying that that's how it is.


> > > 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.
> 
> Presumably the creators and maintainers of the site care as well.

We're talking about unrelated browsers, or just-released browsers -- and 
in practice, to be honest, most creators and maintainers of sites _don't_ 
care about such small portions of the market. Just look at Google's sites. 
The odds of a Google site working in IE and Firefox are high, the odds of 
if working in Safari are lower, the odds of it working in Opera lower 
still, and the odds of it working in Links or Amaya are nearly nil if the 
site in question is anything more than a static page. Google is definitely 
not unusual in this respect.

 
> You cite a few cases of strange mixed-namespace content.  You don't show 
> how this content would break the site as dramatically as you claim in 
> your scenario.  Please draw the connection, if one exists, between your 
> evidence and your conclusion.

I'm assuming you are really asking "how would a particular proposal fail 
when exposed to the existing content?".

Well for instance if a page looks like the following (I'm doing this from 
memory but this is quite similar to some of the pages I saw in some of my 
research):

   <html>
    <head>...<head>
    <svg xmlns="http://www.w3.org/2000/svg">
    <p>Hello world
   </html>

...then in today's browsers, the page would just say "Hello world". Now if 
we instead use the proposal that the SVGWG has put forward, for instance, 
the page would no longer say "Hello world", it would instead either show a 
blank page or say something like "tml>" or "html>", depending on exactly 
how we define where the XML parser fails. That's an example of this 
proposal "breaking" a page -- the page would look significantly different 
in a browser that implemented the proposal than in a browser that did 
not, despite the page being written before the proposal existed.


> > 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.
> 
> "Supporting" MathML in HTML5 is different than seeing MathML supported 
> in everyday browsers.  There will be a likely lag in at least one or two 
> browsers.
> 
> Mandating MathML in HTML5 is a great thing; it's not that it will 
> discourage deployment, obviously... it's that not providing a fallback 
> mechanism will not encourage it enough.

We don't need to encourage use. It's already being used without it even 
being supported. In a few years when major browsers support it widely, 
people who want to write mathematics will be happy to do so.

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

Received on Tuesday, 22 July 2008 05:27:12 UTC