Re: [selectors-api] matchesSelector() Proposal (was: Call for Consensus - Selectors Last Call)
Sean Hogan wrote: Lachlan Hunt wrote: Sean Hogan wrote: Gregory Reimer (the author of reglib) points out that Element.matchesSelector would be useful for event delegation. See http://blogs.sun.com/greimer/entry/opera_10_will_suport_selector It would also neatly tie in with NodeFilter in DOM-Traversal, facilitating something like a live querySelectorAll() during document load. I forgot to mention before that I already have an open bug for tracking this issue. http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865 It would be useful if you could elaborate upon those use cases. Are you asking for a better explanation of the concepts or more specific examples? Well, you already explained the concept of event delegation below, but some examples would also be useful, especially real world examples. Do any JavaScript libraries implement functionality similar to the matchesSelector proposal? If so, then examples of those would also be useful. How is that nonsensical? Without having use cases presented, it's hard to justify the feature and even harder to make sure it's designed in the most optimal way for those use cases. - The feature is already justified by the first paragraph of the specification. It facilitates the performing of DOM operations on an element that matches a selector. There are other potential features that fit that description, but which weren't included in this version. For example, NodeList filtering, scoped methods and namespace resolution, each of which will be reconsidered for the next version. - The feature is already defined in the specification as part of the querySelector* methods. The term 'matching Element node' refers to an Element node that matches the group of selectors (selectors) that was passed to the method. The only decision to be made is about the name. That just means it will be somewhat easier to specify. Although there are lots of other issues to consider which can make it slightly more complex, either for the spec and/or implementations. e.g. * Defining how it works with :scope (as mentioned previously) * Any potential security issues (there may not be any, but we need to be sure) And potentially many others that get raised during implementation. Also, don't underestimate the cost of choosing an appropriate method name. - Event delegation plus Element.matchesSelector is a better match for event registration that querySelectorAll. Say you want to add event handlers to elements that match a selector. If you perform document.querySelectorAll(S1) and then addEventListener on each found element, and then one such element (E1) is relocated in the document in such a way that it no longer matches S1 then (presumably) the handlers attached on E1 become invalid and need to be removed (and perhaps different ones added). Sure, if you're using event delegation, then I agree that a matchesSelector method could be useful. But be aware that event delegation is just one possible solution to that problem. XBL2 is another more flexible solution with features designed specifically for that. Hopefully that will become available within a few years, but unfortunately, implementing it isn't yet a priority for implementers. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] SVG WG Review of Selectors API
== Section 6. The NodeSelector Interface The caller must pass a valid group of selectors. That's an authoring requirement, explain how that is applicable? The group of selectors must not use namespace prefixes that need to be resolved. That also sounds like an authoring requirement. If it's an authoring requirement please mark it as informative, or as only applying to conforming applications. Aren't most W3C Recommendations intended as specifications for both implementations and authors? Since NSResolver was taken out, please consider adding hardcoded namespace prefixes for svg and xhtml similar to how the empty and any namespaces are handled by this draft. Or alternatively forward the reader to DOM 3 XPath for the cases where the Selectors API falls short. Even if hardcoded namespace prefixes are added it'd still be a good idea to link to DOM 3 XPath, since it looks like Selectors API is unable to deal with arbitrary xml markup. Do note that XPath can't deal with 'arbitrary xml markup' either as it is not turing complete. (only when combined with XSLT it is). However I do agree that having informative links to DOM 3 XPath is a very good idea as it is a very similar technology. / Jonas
Re: [selectors-api] SVG WG Review of Selectors API
Doug Schepers wrote: As a high-level comment, the SVG WG would prefer to see support for namespaces in the specification. We believe that there will be an increasing amount of (X)HTML+SVG content produced, and that there are a number of cases where it would be easier for authors to have this functionality natively, instead of hacking the results of a selector query. However, we are also sensitive to the preference to get the functionality into developers' hands as quickly and interoperably as possible, and don't wish to obstruct quick adoption of this specification. As a compromise, we believe that if the NSResolver support remains removed from this specification, there should be explicit mention of workarounds (see below), and an informative note mentioning that it may be readded in a future version of the spec, to ensure that implementers set up their architecture accordingly. There are several features which will be considered for inclusion in the next version of the spec. Why should this one in particular be called out over any other requested feature? == 1.1 Examples This script will also function correctly for a table written in XHTML markup instead of HTML. I suggest this be reworded to say something like If the above table is converted to wellformed XHTML markup then this script will function correctly on that as well. The real intention of that statment is to illustrate that the method works on the DOM, independently from any specific syntax used to create the DOM. I have rewritten it to make that more clear. Note that the script operates on the DOM and works independently from the syntax used to create the document. Thus this script will also work correctly for an equivalent table created from well-formed XHTML instead of HTML, or dynamically created and inserted into a document using DOM APIs. == Section 6. The NodeSelector Interface The caller must pass a valid group of selectors. That's an authoring requirement, explain how that is applicable? It seems perfectly applicable for the spec to define how the methods need to be used by conforming applications. Please explain why you think it is not applicable? The group of selectors must not use namespace prefixes that need to be resolved. That also sounds like an authoring requirement. If it's an authoring requirement please mark it as informative, or as only applying to conforming applications. The implementation must first trim any leading or trailing whitespace from the value of the selectors parameter. The implementation must then process the value according to the grammar of Selectors ([SELECT], section 10). If the processing means that the whitespace-trimmed value must match the 'selectors_group' production please say so. I have addressed these two concerns by adjusting the requirements for conforming applications to state: The caller must pass a valid group of selectors that matches the selectors_group production ([SELECT], section 10) with the additional provision that leading and trailing whitespace ([SELECT], section 4) is permitted. This group of selectors must not use namespace prefixes that need to be resolved. Selectors are evaluated against a given element in the context the entire DOM tree in which the element is located. ...in the context of? I'm not sure how to phrase that any more clearly. It means that when evaluating a selector, all elements in the document may be taken into account, and not just those within the node's subtree. This means that the object will instead contain a list of matching Element nodes that were in the document at the time the list was created. Is this time defined? I propose to reword it as follows: This means that the object will instead contain a list of matching Element nodes that were in the document at the time the method was invoked. IIRC, the original reason for saying at the time the list was created instead of what you propose was that, when the NSResolver was still part of the spec, it was possible that the nsresolver function could modify the document in ways that would affect which elements were matched. I could change it, but I'd prefer to get feedback from implementers about the implications of the change before doing so. If the group of selectors include namespace prefixes that need to be resolved, the implementation must raise a NAMESPACE_ERR exception ([DOM-LEVEL-3-CORE], section 1.4). Since NSResolver was taken out, please consider adding hardcoded namespace prefixes for svg and xhtml similar to how the empty and any namespaces are handled by this draft. Similar functionality was previously requested and rejected for the xml and xmlns prefixes, and I see no reason to treat the xhtml and svg prefixes any differently. http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0062.html Additionally, doing so could have adverse affects on any future plans to
Re: [selectors-api] SVG WG Review of Selectors API
On Dec 8, 2008, at 17:26 , Lachlan Hunt wrote: Since NSResolver was taken out, please consider adding hardcoded namespace prefixes for svg and xhtml similar to how the empty and any namespaces are handled by this draft. Similar functionality was previously requested and rejected for the xml and xmlns prefixes, and I see no reason to treat the xhtml and svg prefixes any differently. http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0062.html That's a shame, they should be defined for a DOM that supports XML features, especially the xml namespace. Or alternatively forward the reader to DOM 3 XPath for the cases where the Selectors API falls short. Please explain how providing a reference to DOM 3 XPath would be of any benefit? How would it help readers in their understanding of this spec? DOM 3 XPath solves pretty much the same problem but is more powerful, providing a reference to it will be very useful to people who want to select nodes from a DOM but bump into limitations of the Selector API. It changes nothing to normative requirements, but makes the spec more considerate towards its users, and a wee bit more useful. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: [selectors-api] SVG WG Review of Selectors API
On Mon, 08 Dec 2008 17:26:18 +0100, Lachlan Hunt [EMAIL PROTECTED] wrote: == Section 6. The NodeSelector Interface The caller must pass a valid group of selectors. That's an authoring requirement, explain how that is applicable? It seems perfectly applicable for the spec to define how the methods need to be used by conforming applications. Please explain why you think it is not applicable? The spec still needs to describe what happens for the case where a user of the API doesn't adhere to this 'must' requirement (and yes, I believe it does). However I'm not finding many examples in w3c specs of this type of requirement so far. One example I did find was from DOM 3 Core, where the createAttributeNS method makes a requirement on applications to pass the value null for the namespaceURI parameter if they wish an attribute to have no namespace. But that's a bit different in any case. The quoted sentence from the Selectors API spec to me translates into this: The caller must pass a valid group of selectors [in order to get a return value that is of any use. Failure to do so will result in either an exception or in some empty results.] This should be rather obvious to the reader of the spec anyway. IMHO the spec is trying to require something that is not enforcable anyway, and might as well not mention it, but instead just describe what happens for all possible indata. Cheers /Erik -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Re: [selectors-api] Typo
Doug Schepers wrote: Hi, Lachlan- Lachlan Hunt wrote (on 12/8/08 11:26 AM): Selectors are evaluated against a given element in the context the entire DOM tree in which the element is located. ...in the context of? I'm not sure how to phrase that any more clearly. It means that when evaluating a selector, all elements in the document may be taken into account, and not just those within the node's subtree. I think you're overthinking this one... you're missing an of in context the. Oh, I see. Fixed. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
