- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Fri, 11 Jul 2008 02:31:05 +0200
- To: Andrew Fedoniouk <news@terrainformatica.com>
- Cc: www-style <www-style@w3.org>
Andrew Fedoniouk wrote: > Lachlan Hunt wrote: >> Therefore, reusing :root for this would require redefining it for a >> purpose it was not originally intended for. > > You do not need to redefine it in the first place (in master CSS spec.) > > It is just enough to put remark in your document - "for in depth subtree > queries :root is the element itself" or something like that. > It does not contradict original meaning in HTML/CSS No, because that would change the way selectors are evaluated against elements, and which ancestor elements are looked at. i.e. Consider the following fragment: <body> <section id="foo"> <div> ... </div> </section> </body> foo.querySelector("body div"); As currently defined and as it is being implemented by browsers, that would match and return the above div element. This is because the Selectors spec defines whether or not a given element matches a particular element, and the API does not redefine that. If :root were redefined as you suggest, then so would this would need to as well: foo.querySelector("body :root div"); (Note that will in fact work with the :context selector in place of :root.) But that is also another reason why :root needs to continue matching the document's root element, rather than the contextual root. Note that the same issue also occurs with scoped stylesheets in HTML5. >> http://dev.w3.org/2006/webapi/selectors-api/ > > 1) I cannot understand phrase "query selector" to be honest. Query it > for what? We had a lengthy naming debate about the issue in the WebAPI WG a while back. After an official working group vote to resolve the issue, that was the winning alternative. Admittedly, it's not perfect, but the issue is no longer up for discussion. > 2) selectors-api appears as impractical for the following reasons: > a) There is a need for parent lookups too, like: > element.selectParent("ul.foo") - returns nearest matching parent > element. > element.selectLastParent("ul.foo") - returns farthermost matching > parent element. The existing API was designed to address many use cases that were significantly from what you are trying to address. This includes addressing the needs of authors based on existing practices in real world scenarios; in particular, the use of JS libraries that offer similar features. I'm not aware of, for instance, a JS library that offers any feature remotely like what you're proposing, and the use cases you are trying to address are unclear. > b) querySelectorAll is quite ineffective in practice - it should be > form with callback function. Otherwise it is not clear of what to do with > the returned list in GC environments and functional languages > like JS. That makes no sense at all, and it is not an issue that has been raised by either of the 4 major browser vendors who are currently working on implementing the API. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Received on Friday, 11 July 2008 00:31:44 UTC