- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Sat, 12 Jul 2008 11:29:20 -0400
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- CC: public-webapps <public-webapps@w3.org>
Lachlan Hunt wrote: > I realise that there is work going into > implementing the current NSResolver as currently specced, but no > implementation has shipped yet, so it's not too late For what it's worth, it might well be too late as far as Gecko is concerned. I have NSResolver implemented as currently specified (modulo the "undefined" thing), and we're aiming to be done with this next release in a timeframe that I suspect is shorter than the time it'll take to spec and implement something else. I have to admit that it would have been nice to have _some_ communication on this a few weeks back when I asked what the current state of things with NSResolver was prior to spending time on implementing it. > * Deferring it until v2 and having browsers ship without support for > NSResolver in inital implementations I think Gecko would be strongly interested in allowing full namespace support in querySelector, so would like to avoid this scenario. > * Resolving the default namespace > > The DOM 3 Core Node.lookupNamespaceURI required null to be passed in > order to obtain the default namespace, but it would be better for both > authors and implementers if this were "" instead. Didn't someone recently say that treating "" and null here as equivalent (as Gecko does) was correct? > However, Boris has reported this is an > implementation problem because they are converted to "null" and > "undefined" as a result of the return value being defined as a DOMString. I reported that this is an issue with "undefined". |null| is converted to "" in Gecko (as well as Webkit, last I checked). There was a whole thread on this earlier. The key difference is that technically |null| is a valid DOMString value as far as the rest of the DOM is concerned (and in Java, say, is a null object reference), while |undefined| is in no way special as far as stringification goes. > * Navigating away from the page > > var iframe = getElementById("theIframe"); > function resolver() { > iframe.location = "..."; > } > > iframe.document.querySelectorAll("p", resolver); > > I'm not really sure what should or could happen there. I don't see the problem: navigation is async, while the query is sync. > If the browser resolves a prefix multiple times, e.g. if given the > selector "x|p x|span", what if it returns inconsistent results? Opera > currently does this, but still uses first value returned anyway. Gecko's current implementation would resolve twice in this case and use the two values. That's not something to rely on, though. Your list of use cases does not include "ability to resolve any namespace prefix in the selector to something (at least '') without knowing anything about the selector string". There was one mention of this as a use case earlier, but I'm not sure whether it's one we care about. > * Use the JS Object notation: {"prefix": "uri", ...} (Hash map) > > pro: Easy and familiar for authors > pro: Browsers already support it > con: Only suitable for ECMAScript, though other language bindings could > use their own Map implementation You forgot: con: has all the problems of the function approach, because of getters. > * Requiring a Node with appropriate namespace declarations to be passed. > > pro: Easy for implementations to obtain the namespaces > con: More complex for authors to create a node and set all necessary > namespaces > con: Using a Node from the document itself ties the script to use the > same prefixes as the document. This last need not be true if one just creates the node on the fly, but I agree that this seems like a pain for authors. > * Defining a new native object that can have namespace declarations > added to it by scripts. > > var resolver = new NamespaceResolver() > resolver.add("prefix", "uri"); > > pro: Easy for authors to use > pro: Relatively easy for implementers to implement > con: Requires me to specify a new interface Honestly, that last con might only apply to the "* Easy to define in the spec" requirement, and I don't think it's that big a deal in terms of difficulty of definition. Offhand, this sounds like the simplest approach to me if we do decide to change things around at this late date. > DOMString: JSON syntax '{"prefix": "uri"}' > con: Quite verbose for authors It doesn't seem any more verbose than any other solution here. Am I missing something? > DOMString: the @namespace syntax defined in CSS. > con: Slightly verbose for authors, but less verbose than JSON This seems a good bit more verbose that JSON to me. Again, what am I missing. I admit this is also a tempting alterntative, though it requires more surgery than the other approaches here (e.g. not creating actual namespace rules in the parser when parsing this, etc). It's probably a lot more of a pain to implement than you seem to think. > con: Browsers need to fix their buggy case folding implementations Honestly, that's the smallest concern I have with implementing this. ;) > I will draft up the replacement specification for this shortly Can you possibly give a timeframe here? Are we talking a day or two? A week? A few weeks? -Boris
Received on Saturday, 12 July 2008 15:30:10 UTC