- From: Doug Schepers <schepers@w3.org>
- Date: Mon, 21 Jul 2008 17:38:08 -0400
- To: HTML WG <public-html@w3.org>
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