- From: Chris Wilson <Chris.Wilson@microsoft.com>
- Date: Thu, 21 Dec 2006 13:25:11 -0800
- To: Anne van Kesteren <annevk@opera.com>, Charles McCathieNevile <chaals@opera.com>, Dave Massy <dave.massy@microsoft.com>, "Web API WG (public)" <public-webapi@w3.org>
- CC: Tina Duff <tinad@microsoft.com>
I don't care about the particular conclusion. For the purposes of interoperability across implementations (and that IS the point of creating a standard, right?) I believe it absolutely should be defined, and is the issue of the WebAPI WG - unless you don't really care about interoperability, in which case I'm not sure I see the point of having a standard to begin with. Look, I've been involved in developing a lot of the W3C standards that the web development community relies on today - HTML, DOM, CSS, XSL - and I can say without reservation the biggest lesson I've learned about building a durable standard on which multiple interoperable implementations can be built is that you must think about the edge cases and capture them in the standard as early as possible. Otherwise you end up with a debacle[1] like CSS, where the original version is so loosely defined that it can be interpreted in many different ways, and you progressively introduce detail into later versions of the spec (or have wildly incompatible implementations), screwing the early implementers and adopters along the way (hi there). A very senior person in IE's development in the past repeatedly stated to me that he didn't believe that there would ever be truly interoperable DOM implementations, because (e.g.) getting the event timing perfectly the same was nearly impossible - there would always be timing differences or whatever. Let's prove him wrong. Designing loose standards doesn't help. -Chris [1] I'm not saying CSS as a whole is a debacle - I consider getting an initial implementation of CSS into IE3 to be one of the proudest and most industry-affecting single moments of my career in retrospect - but I do believe the progressive-refinement process it's been going through for the last ten years is. -----Original Message----- From: Anne van Kesteren [mailto:annevk@opera.com] Sent: Thursday, December 21, 2006 12:36 PM To: Chris Wilson; Charles McCathieNevile; Dave Massy; Web API WG (public) Cc: Tina Duff Subject: Re: NSResolver Re: Selectors API naming On Thu, 21 Dec 2006 19:47:58 +0100, Chris Wilson <Chris.Wilson@microsoft.com> wrote: > Nope, that's what I meant. The spec should give more examples, > particularly in the simplistic cases. The one case I wanted a > definition for was if there is no doctype given on an HTML document, and > there is a specific namespace given for XHTML (or whatever), does it > match? (e.g. is there a presumed doctype default for HTML in browsers, > and if so what is it. I would prefer not, BTW.) How HTML documents end up in the DOM is an issue of the HTML WG / WHATWG. The HTML5 proposal puts HTML elemenets in the http://www.w3.org/1999/xhtml namespace during parsing. I don't think that's implemented in any user agent yet. What is implemented is that HTML elements are assumed to be in that namespace for the purposes of CSS. Anyway, not our issue in my opinion. You're free however to provide more examples for inclusion in the specification. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Thursday, 21 December 2006 21:25:50 UTC