Re: comments on Selectors API WD
On Sep 30, 2006, at 04:21, Daniel Glazman wrote: Robin Berjon wrote: I don't think we need to cram as many features as possible into v1. Defining the exact semantics of scoped CSS selectors can be a little tricky, and it clearly is the job of the CSS WG to do so. The WG thinks Tricky. Ah. When it comes to defining how matchSingle() and matchAll() work, I fail to see how, sorry. You don't have to worry about specificity, cascade or precedence because Selectors API do not deal with it! We have to worry about defining how scoped selectors work. *That* is the tricky part. It's not a question of being technically difficult, it's a question of overstepping our boundaries. A stylesheet applies to a subtree, that subtree being the whole document. A scoped stylesheet applies to a deeper subtree, that's all. No it's not all, as you note immediately after this paragraph there is at least one issue. The one and only issue is the :root matching, and it makes perfect sense here to say it matches the root of the subtree because there is no other root element in this context ! The other option, ie match the root of the document, is pure non-sense... In the scope, that element is just not visible. And here you prove my point. I come to the exact opposite conclusion from you. I think that having :root match the root of the subtree and not that of the entire tree is pure nonsense. Again, it's not up to us to decide. If we do get to make that kind of decision, the first thing I'll ask for is to rename the Selectors draft to something sensible that reflects its content :-D I thought your WG was more disruptive than that :-) Seriously, we're really, really not! Boring and conservative, that's us! More seriously, I really think this WD does not push far enough. The cost is little. Your WG and the CSS WG could probably solve this quickly. If the cost is small then it'll be just as small in v2. 4. I really hate having two different methods for matchSingle and matchAll, and I'd prefer a single method with a boolean indicating if only the first result should be retrieved or all. I think that's largely a matter of taste, isn't it? No. That's a matter of consistency. Having similar methods both performing a search, the result of the first one being a subset of the second one, reply similar constructs is a matter of consistency. I don't see the consistency argument here, and I really do dislike methods that pile up long lists of ordered boolean arguments. It always starts with one, too. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: comments on Selectors API WD
On Sat, 30 Sep 2006 04:21:39 +0200, Daniel Glazman [EMAIL PROTECTED] wrote: The one and only issue is the :root matching, and it makes perfect sense here to say it matches the root of the subtree because there is no other root element in this context ! The other option, ie match the root of the document, is pure non-sense... In the scope, that element is just not visible. Well, there have been several suggestions as to how it could work (this being a new one): * An implied descendant combinator at the start; * An implied child combinator at the start; * You select nodes from the whole Document, but only those part of the relevant subtree are returned (here :root matching the root of the Document does make sense); * You require :root at the start? Or something similar to that? that it's simpler and safer to restrict ourselves to Document at first, and extend to Element (or Node) later, rather than do the latter now and find out later that it introduces issues with what the CSS WG intends to do in the area. I thought your WG was more disruptive than that :-) More seriously, I really think this WD does not push far enough. The cost is little. Your WG and the CSS WG could probably solve this quickly. I'm happy for the CSS WG to suggest something sensible. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
comments on Selectors API WD
Hello, Here are my comments on the last WD Selectors API : 1. I think the title of the document is badly chosen. The spec* does not offer any API on selectors themselves but, in substance, offers an implementation for document.getElementsBySelector(). Since we may have in the future a real API for accessing selectors themselves into the CSS OM, I strongly recommend a name more related to the contents than it is today. 2. I think it's an error to restrict this new API to the document level, in particular if we have scoped stylesheets in the near future. I recommend extending the API to all nodes. 3. for scoped stylesheets, and if item 2 above is accepted, I recommend adding a boolean parameter to both matchSingl() and matchAll() methods saying if it's a scoped request or not. In the case of a scoped request, the :root pseudo-class then represents the current node on which the method is invoked. 4. I really hate having two different methods for matchSingle and matchAll, and I'd prefer a single method with a boolean indicating if only the first result should be retrieved or all. The result should always be a StaticNodeList. If the boolean is true, then the length of the result is = 1, and it's unconstrained otherwise. 5. Disruptive Innovations SARL becoming a W3C member on the 1st of October, we are ready to help on this specification. Best, /Daniel
Re: comments on Selectors API WD
On Fri, 29 Sep 2006 09:50:45 +0200, Daniel Glazman [EMAIL PROTECTED] wrote: 1. I think the title of the document is badly chosen. The spec* does not offer any API on selectors themselves but, in substance, offers an implementation for document.getElementsBySelector(). Since we may have in the future a real API for accessing selectors themselves into the CSS OM, I strongly recommend a name more related to the contents than it is today. We've been through this several times. Some people think the name is ok, others don't and I don't really care anymore. Regarding the CSSOM, that will just let you access a selector as a DOMString and if it would provide an API that would be CSSSelector or something... 2. I think it's an error to restrict this new API to the document level, in particular if we have scoped stylesheets in the near future. I recommend extending the API to all nodes. Well, the option is kept for extending it to other nodes. I'd like scoped selectors to be defined first. 3. for scoped stylesheets, and if item 2 above is accepted, I recommend adding a boolean parameter to both matchSingl() and matchAll() methods saying if it's a scoped request or not. In the case of a scoped request, the :root pseudo-class then represents the current node on which the method is invoked. 4. I really hate having two different methods for matchSingle and matchAll, and I'd prefer a single method with a boolean indicating if only the first result should be retrieved or all. The result should always be a StaticNodeList. If the boolean is true, then the length of the result is = 1, and it's unconstrained otherwise. I don't think adding more arguments is acceptable. 5. Disruptive Innovations SARL becoming a W3C member on the 1st of October, we are ready to help on this specification. If you could provide a testsuite, that'd be cool! -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: comments on Selectors API WD
Anne van Kesteren wrote: 4. I really hate having two different methods for matchSingle and matchAll, and I'd prefer a single method with a boolean indicating if only the first result should be retrieved or all. The result should always be a StaticNodeList. If the boolean is true, then the length of the result is = 1, and it's unconstrained otherwise. I don't think adding more arguments is acceptable. Well having matchSingle and matchAll reply two different things is from here hardly acceptable too... That means that a given code will have to implement two different handlers depending on the queried set, first one or all. At least, make both methods reply a StaticNodeList please ! On scoped stylesheets : getElementsByTagName() is available on all Elements and matchAll() won't be allowed on Elements ??? While the former is a subcase of the latter ? Wow... Sorry, this is, from a DOM user point of view, VERY suboptimal /Daniel
Re: comments on Selectors API WD
Anne van Kesteren wrote: 5. Disruptive Innovations SARL becoming a W3C member on the 1st of October, we are ready to help on this specification. If you could provide a testsuite, that'd be cool! We'll do better : we'll provide a JS cross-browser implementation for all CSS 3 selectors (excluding dynamic). /Daniel
Re: comments on Selectors API WD
On Fri, 29 Sep 2006 10:54:36 +0200, Daniel Glazman [EMAIL PROTECTED] wrote: Well having matchSingle and matchAll reply two different things is from here hardly acceptable too... That means that a given code will have to implement two different handlers depending on the queried set, first one or all. I don't really understand this argument. You need a separate codepath anyway because you only want to return the first and you might want to use some different (faster) code for that than when you're returning all nodes matching a given group of selectors. At least, make both methods reply a StaticNodeList please ! On scoped stylesheets : getElementsByTagName() is available on all Elements and matchAll() won't be allowed on Elements ??? While the former is a subcase of the latter ? Wow... Sorry, this is, from a DOM user point of view, VERY suboptimal So have the CSS WG define scoped selectors. I don't think the Web APIs WG should define that. This API isn't set in stone, there will be a version 2 if there's sufficient demand and need. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: comments on Selectors API WD
Hi Daniel, just expanding on some of Anne's arguments. On Sep 29, 2006, at 09:50, Daniel Glazman wrote: 1. I think the title of the document is badly chosen. The WG went through that discussion already. Unless new arguments can be provided than those which have already been beaten to death, I would really, *really* prefer we didn't have yet another discussion on the name of something to do with Selectors. Please. 2. I think it's an error to restrict this new API to the document level, in particular if we have scoped stylesheets in the near future. I recommend extending the API to all nodes. I don't think we need to cram as many features as possible into v1. Defining the exact semantics of scoped CSS selectors can be a little tricky, and it clearly is the job of the CSS WG to do so. The WG thinks that it's simpler and safer to restrict ourselves to Document at first, and extend to Element (or Node) later, rather than do the latter now and find out later that it introduces issues with what the CSS WG intends to do in the area. 4. I really hate having two different methods for matchSingle and matchAll, and I'd prefer a single method with a boolean indicating if only the first result should be retrieved or all. I think that's largely a matter of taste, isn't it? 5. Disruptive Innovations SARL becoming a W3C member on the 1st of October, we are ready to help on this specification. That's excellent news! -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: comments on Selectors API WD
Robin Berjon wrote: I don't think we need to cram as many features as possible into v1. Defining the exact semantics of scoped CSS selectors can be a little tricky, and it clearly is the job of the CSS WG to do so. The WG thinks Tricky. Ah. When it comes to defining how matchSingle() and matchAll() work, I fail to see how, sorry. You don't have to worry about specificity, cascade or precedence because Selectors API do not deal with it! A stylesheet applies to a subtree, that subtree being the whole document. A scoped stylesheet applies to a deeper subtree, that's all. The one and only issue is the :root matching, and it makes perfect sense here to say it matches the root of the subtree because there is no other root element in this context ! The other option, ie match the root of the document, is pure non-sense... In the scope, that element is just not visible. that it's simpler and safer to restrict ourselves to Document at first, and extend to Element (or Node) later, rather than do the latter now and find out later that it introduces issues with what the CSS WG intends to do in the area. I thought your WG was more disruptive than that :-) More seriously, I really think this WD does not push far enough. The cost is little. Your WG and the CSS WG could probably solve this quickly. 4. I really hate having two different methods for matchSingle and matchAll, and I'd prefer a single method with a boolean indicating if only the first result should be retrieved or all. I think that's largely a matter of taste, isn't it? No. That's a matter of consistency. Having similar methods both performing a search, the result of the first one being a subset of the second one, reply similar constructs is a matter of consistency. /Daniel
