RE: NSResolver Re: Selectors API naming

Whose job is it in the W3C?  (This isn't "how you transform HTML into a DOM" - it's "what doctype do you presume when it's not there?")

-----Original Message-----
From: Anne van Kesteren [mailto:annevk@opera.com] 
Sent: Thursday, December 21, 2006 1:35 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 22:25:11 +0100, Chris Wilson  
<Chris.Wilson@microsoft.com> wrote:
> 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.

Euhmmm... I care about interoperability, a lot. It's sort of my day job to  
care about that. I'm just saying it's not our issue. It depends on HTML is  
reflected in the DOM. That requires someone to specify how you transform  
HTML into a DOM. I explained that the HTML5 proposal did that and how it  
did that. I think it's out of scope of the Selectors API specification to  
define how you convert a string of HTML into a DOM. (The methods from the  
Selectors API operate on a DOM.)


In general you don't need to use the namespaces by the way. Certainly not  
for HTML. You would just do:

   document.matchAll("div.example, div.examples")

which will match the <div> element in any namespace with either a class  
"example" or "examples" which is fine for HTML.


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

Yeah, I think every reasonable person agrees with this :-)


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

And with this too!


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Thursday, 21 December 2006 21:59:10 UTC