Re: ISSUE-41: Decentralized extensibility

Hi, Ian-

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?

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


More comments inline...

Ian Hickson wrote (on 7/21/08 5:56 PM):
> 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.

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.


>> 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. 
Companies today are less content with having their content work in a 
single browser... "Best viewed in X version n" just doesn't fly anymore. 
  The browser demographics are significantly different.  Developers 
today are proactive about testing in multiple browsers, and will quickly 
discover the flawed code, and fix it themselves, or take the remedial 
steps I mention above; they are unlikely to wait for the next version of 
the browser to be released that includes the broken fix.  More likely, 
they will use one of the many script libraries that abstract out browser 
features.

In short, the Web community has changed since Netscape 6.


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

Then what you're saying is, you have no evidence.


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

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.


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


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

Received on Tuesday, 22 July 2008 03:31:40 UTC