Re: [selectors-api2] Seeking status and plans
On 2013-10-03 17:51, Arthur Barstow wrote: I'm not sure what you mean re draft of DOM here. Do you mean integrating the selectors API into WebApps' DOM4 [ED]; or do you mean the HTMLWG should start working towards a TR publication of DOM4 that includes the selectors API; or something else? I was referring to this http://www.w3.org/TR/dom/ I didn't realise that was being taken over by the HTMLWG, as I haven't been actively following spec stuff for a while as I've been busy with other work. I guess they'll take care of it, then, so never mind. -- Lachlan Hunt http://lachy.id.au/
Re: [selectors-api2] Seeking status and plans
On 2013-10-02 18:31, Arthur Barstow wrote: If any of the data for the Selectors API v2 spec in [PubStatus] is not accurate, please provide corrections. Also, if you have any new information re your plans for the spec - last published 28-June-2012 - or the spec's status with respect to being feature complete, implementation status, etc., please let us know. The features from selectors API 2 are being integrated into DOM, with some design changes from the last selectors api spec. I don't forsee any future edits to the selectors api 2 specification itself. If you like, we can re-publish it as a NOTE, and get a draft of DOM that includes selectors api features published. -- Lachlan Hunt http://lachy.id.au/
Re: [selectors-api] Matching of :scope in document.querySelector(All)
On 2012-11-30 03:01, Boris Zbarsky wrote: When implementing :scope support, I discovered that as things stand this call: document.querySelector(:scope) is specified to return null. In particular http://dev.w3.org/2006/webapi/selectors-api2/#queryselector step 1 calls http://dev.w3.org/2006/webapi/selectors-api2/#determine-contextual-reference-nodes which returns an empty set. Then this empty set is passed as an explicit contextual reference set to selector matching in http://dev.w3.org/2006/webapi/selectors-api2/#evaluate-a-selector so that :scope doesn't match anything. Is this intentional? I believe the spec was written the way it was to deal with the case where an explicitly empty set of reference nodes was given for find() and findAll(). So it seems the current spec ended up treating these in the same way by matching nothing: document.querySelector(:scope) document.findAll(:scope) document.findAll(:scope, null) document.findAll(:scope, []) I would have expected the above call to return the documentElement, which is what :scope would match in a non-scoped stylesheet... I can change the spec to make the first 2 examples above match documentElement, but keep the latter two with explicit refNodes parameters matching nothing. -- Lachlan Hunt http://lachy.id.au/ http://www.opera.com/
Re: CfC: publish WD of DOM; deadline December 2
On 2012-11-25 16:19, Ms2ger wrote: On 11/25/2012 02:49 PM, Arthur Barstow wrote: This is Call for Consensus to publish a Working Draft of the DOM spec using #ED as the basis. Same objections as to the XHR WD. From your XHR objection: I object unless the draft contains a clear pointer to the canonical spec on whatwg.org. In addition to the link I already had in the draft, I have now included this statement above the W3C copyright notice. This specification is based on DOM Standard published by the WHATWG. DOM Standard is licensed under Creative Commons CC0 1.0 (Public Domain Dedication). I have also stated this in the status section: This document is published by the Web Applications Working Group in co-operation with the Web Hypertext Application Technology Working Group. The Working Group expects to advance this Working Draft to Recommendation Status. Does that address your concerns? I have committed a WD ready copy, with the publication date tentatively set for 6 December. http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html -- Lachlan Hunt http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Reference to obsolete ECMAScript Language spec version
On 2012-10-29 14:38, Norbert Lindenberg wrote: The current drafts of the Selectors API specifications [1, 2, 3] refer to the third edition of the ECMAScript Language Specification, The references have been updated. Thank you. -- Lachlan Hunt http://lachy.id.au/ http://www.opera.com/
[selectors-api] Editoral Changes and Test Suite Progress
Hi, The test suite has been reviewed by a colleague at Opera, which resulted in a few minor corrections. No corrections required any changes to the implementation report. However, it did result in a few editorial changes to Selectors API spec. These changes should not affect conformance of any implementations. In particular, I fixed the algorithm for processing selectors to explicitly refer to the definition for invalidity in Selectors, with regards to throwing a syntax error. This was always implied, and is what browsers do, but now the spec is clearer. I also updated the Acknowledgements section to include people who have submitted comments over the years who had been missed. I tried to at least include people who's comments resulted in changes to the spec. I believe we can now finally proceed with publishing this as PR, as discussed at TPAC. I will co-ordinate with Chaals to make this happen as soon as possible. -- Lachlan Hunt http://lachy.id.au/ http://www.opera.com/
[selectors-api] Updated Testsuite
Hi, I worked on redesigning the testsuite to resolve a number of issues with the design of the old tests, including removing significant amount of redundancy and fixing broken tests. In the process, I have discovered a number of new bugs in various browsers that need to be addressed. *Summary of Changes* 1. The Level 1 baseline tests are no longer a subset of the additional tests. The baseline and additional test files now test a completely separate set of tests. 2. The :target tests were moved from baseline to additional because :target was added in Selectors 3. 3. All selectors from CSS 1, 2 and Selectors 3 are being tested. 4. level1-lib.js now contains the common functions shared among the 3 testsuites: baseline, additional and xhtml. 5. The files level1-content.html and level1-content.xht contain the all of the (X)HTML that is queried by the API, included within the iframe of each testsuite. Every element in the file is assigned an ID that is used for verification. 6. selectors.js contains all selectors for both valid and invalid selector tests. This includes annotations about the expected result from each selector, with a list of expected element IDs. These IDs are compared with the results from the queries. This change in architecture resolves some major issues with the old testsuite, which had previously resolved in false positives being reported. Notably, the namespace tests. See below. Some additional tests were added for :link and :visited, which now reveal failures in both Gecko and WebKit. Notes: * The Selectors API Level 2 tests have not yet been updated. * Some tests are still needed for :not() and ~ sibling combinator. * Some test descriptions have not been finished in selectors.js. *Failures* Opera: Baseline: 1157 PASS, 10 FAIL * (no parameter) tests (throwing WRONG_ARGUMENTS_ERR instead of TypeError) * #head :link, #head :visited (new bug in 12.10 beta, passes in 12.02) Additional: 512 PASS, 0 FAIL Chrome/Safari: Baseline: 1140 PASS, 27 FAIL * hasFeature() returns false * namespace tests Additional: 508 PASS, 4 FAIL * :target tests Mozilla Gecko: Baseline: 1154 PASS, 13 FAIL * hasFeature() returns false * (no parameter) tests (throwing NS_ERROR_XPC_NOT_ENOUGH_ARGS instead of TypeError) * :link and :visited for fragment and detached element tests failing to match A and AREA elements. Additional: 512 PASS, 0 FAIL * No failures (I haven't got access to IE at this time, so I have not tested it.) The testsuite can be found here. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ All files for these tests are located in the hg repo. http://w3c-test.org/webapps/SelectorsAPI/tests/submissions/Opera/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Updated Testsuite
On 2012-10-22 16:29, Boris Zbarsky wrote: On 10/22/12 6:10 AM, Lachlan Hunt wrote: * hasFeature() returns false Just as a note, this is a pretty pointless test, and the language about it should be removed from this spec, assuming http://dom.spec.whatwg.org/#dom-domimplementation-hasfeature stays the way it is. I dropped the feature string from both selectors api specs. I'll update the tests shortly. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
On 2012-08-06 13:25, Lachlan Hunt wrote: On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote: (12/07/31 20:06), Arthur Barstow wrote: On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518 I think this is a very minor issue, and it has a simple workaround - mark it as undefined. However, if Lachlan doesn't feel like paying extra fee for versionning (what Anne calls make work) or he thinks having undefineds in a spec significantly lowers the quality, I think that's fair enough and I suggest the way to move forward (if we really want to) is to consider my comment as retracted (let's just do so if Lachlan doesn't reply to this). I'd rather find a way to address the issue. I've just been a bit busy with other tasks for the last 2 weeks to look into this. I'd like feedback from implementers about how best to address the issue. The options I can think of: 1. Disallow all comments within the selector for this API. Throw SyntaxError when they are used. 2. Allow comments, but define that unclosed comments should throw a SyntaxError. 3. Allow comments, define that unclosed comments are silently ignored. After thinking about this for a while, I'm still not much closer to figuring out exactly what the right solution is, nor how the spec should change. But I think it may be acceptable to leave this issue as undefined in Selectors API 1, so as to not continue to hold up taking that spec to Recommendation status. Then we can figure out how to fix it in Selectors API 2, where I can spend more time and effort more clearly defining the parsing requirements. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Kudos on find/findAll, feedback on spec readability
On 2012-09-16 23:40, David Greenspan wrote: 6.2 - ... first matching Element node within the subtrees... Don't define a new term subtrees which just means descendants. Say, ... first matching Element node that is a descendant of the context object. I could do that, but doing so makes it harder to rephrase this statement without making it more complex. 3. The implementation must then run the algorithm to evaluate a selector against element nodes in the specified tree or subtrees using parsed selector as the selector and reference nodes as the contextual reference element set, as needed to return the required result for the invoked method. If you have a suggestion for how to rephrase that to remove subtrees in a readable way without altering the meaning, please let me know. The main take-away from section 6.2 should be that find/findAll use a *different algorithm* from querySelector/querySelectorAll, or the same algorithm with a different setting (relative=true). This point is almost entirely lost. I think the clearest of those two alternatives is to clearly separate the two algorithms. I have made this change in the spec. I think the intent is for the reader to perform a sort of dispatch on type when the algorithm in 6.5 is invoked, but it's confusing because you can't really look at a selector and a relative selector and tell them apart, and certainly not before parsing them. The intent was that the reader is supposed to know whether you have a selector or relative selector based on which method was invoked. The above changes now make that clearer. 6.2 - When either method is invoked... - there are four methods, not 2 Good point, but with the above changes, I also made it more explicit about which methods are being referred to in each case. 6.5 - ... begins with a combinator and that combinator is not ' ' (space) - how can a relative selector, in a comma-separated list with whitespace, physically start with a space, i.e. a descendant combinator?? This was added to clarify that ' ' is excluded from the set of possible combinators that trigger automatic prepending of :scope, regardless of whether the selector meets any of the other conditions. At this stage in the algorithm, no whitespace has been trimmed from the selector, so if the input is div, then it needs to be clear that :scope is not prepended in step 1. Note that there is a known bug in the way the grammar is defined that does actually allow for a relative selector to begin with a descendant combinator. I just haven't figured out a good way to fix this. I have now noted this issue in the spec. Supposing it can (at the beginning of the string, perhaps), why would you special-case it and prepend what's presumably a second descendant combinator in step 5? Because if steps 2, 3 or 4 apply, then step 5 doesn't apply and :scope is not prepended. e.g. document.find( div); // Matches condition in step 2 elm.find( not(:scope)); // Matches condition in step 3 elm.find( body.foo :scope p); // Matches condition in step 4 If space was not excluded, the the spec could be interpreted such that :scope should be prepended in those cases. 7 - contextual reference element - This term is revealed to mean simply a potential :scope element. I would call it something like a scope candidate -- or basically anything besides what it's called. This section was intended to be dropped now that Selectors 4 defines :scope adequately, and as such the term contextual reference element has been removed. However, the term contextual reference element set still remains due to its definition in Selectors 4. If you wish to have that changed, please follow this up with the CSS WG. I have now removed section 7 The :scope Pseudo-class entirely from this spec. 8 - Feature Strings - Change last paragraph to: Conforming implementations must return true ... if they are perfectly compliant, and false if they are not. No. Feature strings are a notoriously unreliably method of determining support for a given feature and it only exists to provide an indication that there is some support for the API, without specifying how compliant a given implementation is. 9 - Examples of find() and :scope MUST be added here. Seriously. This section is the last chance to push that lucky reader over the final threshold to feeling like they fully understand the spec. They will be added in due course. They hadn't been added yet due to the prior instability of the new API design and their low priority. However, feel free to contribute some examples if you like and I will consider including them. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
On 2012-08-06 13:08, Kang-Hao (Kenny) Lu wrote: (12/07/31 20:06), Arthur Barstow wrote: On 7/19/12 11:15 PM, ext Kang-Hao (Kenny) Lu wrote: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/thread#msg518 I completely missed that comment of yours when you originally sent it, which is why I didn't address it back then. Lachlan, Kenny - what is the status of this comment (f.ex. does the spec need to be changed)? I think this is a very minor issue, and it has a simple workaround - mark it as undefined. However, if Lachlan doesn't feel like paying extra fee for versionning (what Anne calls make work) or he thinks having undefineds in a spec significantly lowers the quality, I think that's fair enough and I suggest the way to move forward (if we really want to) is to consider my comment as retracted (let's just do so if Lachlan doesn't reply to this). I'd rather find a way to address the issue. I've just been a bit busy with other tasks for the last 2 weeks to look into this. I'd like feedback from implementers about how best to address the issue. The options I can think of: 1. Disallow all comments within the selector for this API. Throw SyntaxError when they are used. 2. Allow comments, but define that unclosed comments should throw a SyntaxError. 3. Allow comments, define that unclosed comments are silently ignored. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[selectors-api] New Implementation Report for Updated Testsuite
I have now generated a new implementation report [1] to go with the updated testsuite. As I detailed previously on public-webapps-testsuite [2], the new tests use testharness.js and, as a result, some of the tests which passed under the old framework now fail in some browsers. This is mostly because the new tests explicitly check for TypeError on the 'no parameter' tests, whereas the old tests accepted any exception as a pass. WebKit is also failing one of the :target selector tests, probably releated to the way the test loads the testing page in an iframe. [1] http://dev.w3.org/2006/webapi/selectors-api-testsuite/level1-baseline-report.html [2] http://lists.w3.org/Archives/Public/public-webapps-testsuite/2012Jun/0009.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] RfC: LCWD of Selectors API Level 1; deadline July 19
On 2012-06-28 18:03, Stewart Brodie wrote: Arthur Barstow art.bars...@nokia.com wrote: This is a Request for Comments for the June 28 Last Call Working Draft of Selectors API Level 1: http://www.w3.org/TR/2012/WD-selectors-api-20120628/ The comment deadline is July 19 and all comments should be sent to the public-webapps@w3.org list with a Subject: prefix of [selectors-api]. Section 1 contains a unwanted duplication: With these methods methods, Fixed in both level 1 and 2. There is something odd about the way matching is defined: Section 6 defines matching Element node directly in terms of the [SELECT] reference, then section 6.4 defines what it means to evaluate a selector but this is never referenced. I think section 6 needs to define matching Element node as something like: Oops, this was supposed to have the content similar to that in the level 2 spec defining what to do when the methods were invoked. I've now backported this from that spec, but omitted all things related to :scope. The changes are in the editor's drafts. http://dev.w3.org/2006/webapi/selectors-api/ http://dev.w3.org/2006/webapi/selectors-api2/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: CfC: publish a LCWD of Selectors API Level 1; deadline June 25
On 2012-06-18 15:57, Arthur Barstow wrote: Lachlan has made some changes to the Selectors API Level 1 spec (last published as a CR) and we consider the changes sufficient to require the spec be published as a Working Draft (see the [1] thread). As such, this is a Call for Consensus to publish a new LCWD of this spec using the following document as the basis http://dev.w3.org/2006/webapi/selectors-api/. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by June 25 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. This draft has been prepared for publication and checked into the repository. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: CfC: publish WD of Selectors API Level 2; deadline June 25
On 2012-06-18 15:41, Arthur Barstow wrote: Lachlan would like to publish a new Working Draft of the Selectors API Level 2 spec and this is a Call for Consensus to do so using the following Editor's Draft as the basis http://dev.w3.org/2006/webapi/selectors-api2/. If you have any comments or concerns about this proposal, please reply to this e-mail by June 25 at the latest. This draft has been prepared for publication and checked into the repository. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 2012-06-18 11:06, Lachlan Hunt wrote: Since it seems there are no objections to the latter option, and a few people in favour of that, I've tentatively updated both drafts to reflect this. It now states: If the group of selectors include namespace prefixes that need to be resolved, the implementation must raise a SYNTAX_ERR exception http://dev.w3.org/2006/webapi/selectors-api/#resolving-namespaces http://dev.w3.org/2006/webapi/selectors-api2/#resolving-namespaces I have now updated the testsuite to reflect this change. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 2012-06-20 17:46, Marat Tanalin | tanalin.com wrote:
20.06.2012, 18:14, Lachlan Hunt lachlan.h...@lachy.id.au:
4. Support for returning elements that are not descendants of the
context object.
This feature allows a selector to be constructed such that it matches an
element anywhere in the tree relative to the context element. This
feature is not relevant to document.find(), since it can already return
anything from the whole tree.
elm.find(+span)// span is a sibling
elm.find(/for/ input) // input could be anywhere
elm.find(:not(:scope)) // Everything except the context object
This feature cannot be supported on Element.qSA, even when using eplicit
:scope, because matching elements need to be descendants of the context
object.
It's unclear why an _updated_ qSA version should have same limitation
that matching elements need to be descendants of the context
object. There is nothing obvious that makes h1.querySelector('+ H2')
impossible to work in newer implementations (in older ones it would
not work anyway -- to the same extent as `elm.querySelector(span)`
that you've declared as could work).
Supporting this without the risk of breaking compatibility would require
switching selection behaviour based on the presence of the :scope pseudo
class (either explicit or implied), for each individual selector in the
group. When :scope is present, then matching could be applied to the
entire tree, just like it is in element.find().
That is, given the group of selectors:
elm.querySelectorAll(:scope+p, div p)
(Note: After pre-processing, there is no difference between explicit
:scope and implied :scope in +p)
Only :scope+p would be permitted to match non-descendant elements and
the other div p would have to retain the backwards compatible
selection behaviour where the subject of the selector must be a
descendant of the context object.
That means, the implementation would need to split the group of
selectors such that :scope+p (or any other selector with explicit or
implied :scope) is potentially compared with all elements in the tree.
Then the other selector div p should only be compared with descendants
of the context object.
It will also not work for the reference combinator in some cases. If
switching selection behaviour depends on the presence of :scope, then
the reference combinator will not always work effectively.
elm.querySelectorAll(label /for/ input)
In this case with no :scope, the matching input must be a descendant of
the context object, but the label may or may not be. Compare that with
this:
elm.findAll(label /for/ input)
In this case, :scope is implied at the beginning, so the label must be a
descendant of the context object, but the matching input elements may
appear anywhere in the tree.
Overall, this adds significant complexity to the implementations, so
while it may actually be technically possible in some cases, it's far
from ideal and doesn't address all problems.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Bikesheds Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 2012-06-21 15:56, Kang-Hao (Kenny) Lu wrote: (12/06/20 22:26), Lachlan Hunt wrote: On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. While I don't think a WG vote is the right way to do, I strongly disagree that naming of a function belongs to an editorial decision. Changing the name of a function requires all the tests be rewritten, and therefore it is by definition not editorial. By editorial decision, I meant that the decision of what to name it should be up to the editor, not that it is a minor editorial issue. Sorry for the confusion. Fixing tests is trivial, but the name should be decided before implementation begins and a testsuite is written anyway. At this stage, I haven't seen any overly strong objections to the names find/findAll anyway, so hopefully this is a non-issue. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. I don't know what happened when the WG decided on the poor name querySeletor, but from a outsider's point of view, along with the final decision, I also care about a detailed description about why a function name is chosen. For example, attributing the poor querySelector decision to an abstract concept of design by committee doesn't seem to be reasonable and genuine. I'd rather want to see a long explanation like: What happened last time was that I carefully reviewed the entire debate, taking into account all arguments for and against every suggested alternative I found at the time and posted a thorough review and rationale for the decision I made at the end. http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0077.html This then resulted in some people in the group complaining loudly enough because they weren't happy, mostly because it's impossible to please everyone, leading to a vote between 6 choices, ultimately overruling me. Anecdotally, I heard from a few web developers at the time saying they even liked the names I'd chosen, despite them being a little long, but were later disappointed with the result of the vote. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Selectors API Implementation Report
Hi, I have created a basic implementation report covering the baseline tests. All 5 browser implementations are at 99.2% pass rate, each browser only failing 8 of these tests because of the recent change for the NAMESPACE_ERR issue. http://dev.w3.org/2006/webapi/selectors-api-testsuite/001-report.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On 2012-06-20 10:42, Charles McCathieNevile wrote: In other words we have the same arguments that we had five years ago, when we settled on querySelector as the one that provoked least objection. ... But spending another few months arguing about it hasn't proven that we are any wiser, nor (importantly) any closer to agreement. This is why it should be an editorial decision, not a group vote. The least-objectionable alternative is rarely the best alternative, and trying to please everyone is a fool's errand. Hopefully, this time, the group will let me, as editor, evaluate the options and supporting rationale and make a decision based on that. Right now, that draft uses find/findAll() simply because they're the names that were used throughout the discussion that led to them being added. There are still issues to resolve, however, which I would like feedback on. In particular, is there really value in adding two distinct methods that differ only by whether they return 1 element or a collection? Resolving this issue first would help with resolving the naming issue. It should be noted that JQuery/sizzle does not use querySelector() at all, AFAICS. It only uses querySelectorAll() and sometimes switches to .getElementById() or document.body. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 2012-06-18 04:29, Boris Zbarsky wrote: Consider how this is parsed in a depth-first recursive descent parser: a|b +, 1) The identifier a is scanned. This might be a tag name or a namespace; look at the next token. 2) The symbol '|' is scanned. Great. a was a namespace. Resolve it. And you're done. You have an error and bail out. You never even got to the '+'. This is a good reason not to strictly define one having precedence over the other. That leaves 2 options: Leaving it explicitly undefined (only mildly better than the current situation) or using only syntax error. Since it seems there are no objections to the latter option, and a few people in favour of that, I've tentatively updated both drafts to reflect this. It now states: If the group of selectors include namespace prefixes that need to be resolved, the implementation must raise a SYNTAX_ERR exception I also removed the note about non-namespace supporting implementations throwing a syntax error instead of a namespace error. http://dev.w3.org/2006/webapi/selectors-api/#resolving-namespaces http://dev.w3.org/2006/webapi/selectors-api2/#resolving-namespaces -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Updates to Selectors API
On 2012-06-18 13:57, Arthur Barstow wrote: In the process, I also made a few minor editorial changes to v2 just to tidy it up. At this stage, we should be able to publish v1 as a revised CR, or possibly move it up to PR. I like the changes Lachlan, especially the new section 6.4. Although I have argued to the Advisory Committee and Advisory Board the process should (under certain circumstances) permit a CR to be directly re-published as a CR, that currently is not possible. Nevertheless, I think it could be a bit tricky to argue to the Director in this case that there were no substantive changes (e.g. the new 6.4) so my recommendation is that we publish a new LCWD with the minimum 3-week review period (and make sure all of the changes can be reviewed). OK. Let's get started on that process. Do you or Chaals have the interop data now (and if so, where is it)? What do you think about going the LC-PR route? Opera, Firefox, Safari, Chrome and IE all pass 100% of the baseline (HTML/CSS 2.1 selectors) and additional (HTML/Selectors 3) tests. Firefox, Safari and Chrome also pass 100% of the XHTML/Selectors 3 tests. Opera only passes 99.2% of these and IE only passes 67.7% of these. However, these are additional tests that are not required to declare interoperability of the API, as the failures relate more to XHTML and Selectors support, rather than any particular bug with the API. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ Do I need to prepare some kind of formal testsuite report with the results for each test? However, with the recent change from NAMESPACE_ERR to SYNTAX_ERR, this test suite will need to be updated with new tests, so this will likely delay PR for a little bit longer. We can also publish v2. as a new WD. If you want me to start a CfC to publish a new WD of v2, just let me know. Yes please. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied
On 2012-06-17 15:50, Aryeh Gregor wrote: On Sun, Jun 17, 2012 at 4:43 PM, Boris Zbarskybzbar...@mit.edu wrote: On 6/17/12 9:33 AM, Anne van Kesteren wrote: Always throwing SyntaxError is probably better. Also probably incompatible with a depth-first recursive descent parser implementation. Are we sure we want to overconstrain implementations like that? I don't know what this means. Could you clarify? I'm not sure what Anne meant, but I'd think we should just always require SyntaxError, including for namespace errors. Do enough people really use namespaces that they deserve a separate exception? CSS itself treats namespace errors the same as syntax errors in stylesheets (right?), so it doesn't make sense to require Selectors APIs to distinguish them. The distinction made sense when we were considering supporting namespaces, as it would help authors to diagnose mistakes. But looking at sizzle.js [1], it doesn't make a distinction between them at all. It just catches the error, ignores it and moves on. This may be one thing that could be changed without risk of breaking anything, since the lack of any namespace support means its unlikely that there are any scripts performing any special error handling for namespace errors that differs from other syntax errors. Is there any reason we should keep this distinction? [1] https://github.com/jquery/sizzle/blob/master/sizzle.js -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Updates to Selectors API
Hi, I have updated the specification for Selectors API Level 1, which is currently in CR. Most of it was editorial in nature, to bring it in line with Selectors API Level 2, except without adding any of the new features like findAll() or or matches(). Importantly, the IDL has now been updated to comply with the most recent WebIDL specificiation. This was basically to split it up into 3 partial interfaces, just like what was previously done in v2. Some of the prose was rewritten, but none of the changes should adversely affect implementation requirements. This was mostly done by back porting the content from v2, but while ensuring that all the normative references still refer to the older, stable specs. (e.g. DOM3Core instead of using DOM4, as is used in the v2 draft.) This now makes v1 a proper subset of v2. In the process, I also made a few minor editorial changes to v2 just to tidy it up. At this stage, we should be able to publish v1 as a revised CR, or possibly move it up to PR. We can also publish v2. as a new WD. Alternatively, we could forgo any further progress with v1 and let v2 supersede it entirely, at which point I could simply rename it back to Selectors API without a version number and move on. (This is my preferred approach). http://dev.w3.org/2006/webapi/selectors-api/ http://dev.w3.org/2006/webapi/selectors-api2/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Proposed Specification for find/findAll/matches
On 2011-12-12 17:57, Boris Zbarsky wrote: On 12/12/11 6:07 AM, Lachlan Hunt wrote: 2. These new methods for Element may be split out to a separate interface that omits the refElements and and refNodes parameters. Yes, please. There's no point having the same interface if the behavior is totally different based on the |this| object as described. In my opinion. I did this by defining partial interfaces for each of Document, DocumentFragment and Element, rather than having a single NodeSelector interface implemented by all three. Open Issue: Should this change affect Element.querySelector() too, or leave it as currently specified? One option is to simply not do any special scope stuff in querySelector, if we suddenly have no use cases for it. I removed the refNodes stuff from querySelector, since all use cases for it are covered by find/findAll. Given a selector list as input to the method, trim whitespace and then for each complex selector, run the first step that applies: (Note: if the selector list is , then there are 0 complex selectors in the list and the following doesn't run) | 1. Otherwise, if the complex selector begins with any combinator This needs to be defined better. complex selector can't begin with a combinator, per its definition. I defined the concept of a relative selector a custom grammar to handle this better. I also started updating the draft to use Selectors 4 and DOM4 references and terminology. Some DOM3 references still remain, but they'll be changed eventually. This meant the removal of terms like context node in favour of context object defined in DOM4, among others. The editor's draft is here. http://dev.w3.org/2006/webapi/selectors-api2/#the-apis -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Proposed Specification for find/findAll/matches
On 2011-12-12 17:57, Boris Zbarsky wrote: On 12/12/11 6:07 AM, Lachlan Hunt wrote: Given a selector list as input to the method, trim whitespace and then for each complex selector, run the first step that applies: (Note: if the selector list is , then there are 0 complex selectors in the list and the following doesn't run) | 1. Otherwise, if the complex selector begins with any combinator This needs to be defined better. complex selector can't begin with a combinator, per its definition. For the purposes of this API, I think the spec needs to define a modified syntax for a DOM Selector, which is similar to, but slightly different from a regular selector. The grammar production would be: dom_selectors_group : dom_selector [ COMMA S* dom_selector ]* ; dom_selector : [ combinator ]? selector ; Where the productions for combinator and selector are defined in Selectors. The spec would then define that the parameter accepts a group of DOM selectors that matches that grammar. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Proposed Specification for find/findAll/matches
that the implied :scope behaviour needs to be made available in
the .find() methods, it would possible to make it available for
matches() too. So the most reasonable approach here is to imply :scope
according to the same rules described above for document.findAll() (i.e.
starts with a combinator or ref nodes were passed and no explicit :scope).
---
6. *Proposed IDL*
interface NodeSelector {
Element find(DOMString selectors, optional Element refElement);
Element find(DOMString selectors, sequenceNode? refNodes);
??? findAll(DOMString selectors, optional Element refElement);
??? findAll(DOMString selectors, sequenceNode? refNodes);
};
Document implements NodeSelector;
DocumentFragment implements NodeSelector;
Element implements NodeSelector;
This extends the same interface as that the existing querySelector
methods use, which will make the methods available on elements,
documents and fragments.
Open Issues:
1. The return type for findAll is yet to be decided. It may be the
proposed NodeArray, a regular Array or something else.
2. These new methods for Element may be split out to a separate
interface that omits the refElements and and refNodes parameters.
3. Do we need both find() and findAll(), or should we only have a
single new method that returns a collection?
Additionally, matchesSelector() will simply be renamed to matches().
---
7. *Summary of Proposed Spec Changes*
For Document and DocumentFragment, the refElement and refNodes
parameters are handled according to the existing algorithm to determine
contextual reference nodes currently in the specification. This
algorithm will be modified so that when the context node is document,
:scope does not match the root element.
For Element, the refElement and refNodes parameters are effectively
ignored and the algorithm to determine contextual reference nodes will
be modified to always return the element itself for these methods.
Open Issue: Should this change affect Element.querySelector() too, or
leave it as currently specified?
For all interfaces, these new find(), findAll() methods, and the renamed
matches() method must have automatic :scope prepending, subject to the
rules for prepending :scope, outlined below.
The findAll() method must return all matching elements from anywhere in
the document. The find() method must return the first matching element
in document order.
Open Issue: Should findAll() and find() throw SYNTAX_ERR or return
empty collection and null, respectively?
Note:
* Element.findAll(:matches(:scope, *)); will match all elements in
the document, equivalent to document.querySelectorAll(*);
* Similarly, Element.findAll(:not(:scope)); will match all elements
excluding the :scope element.
Notes for Implementers:
For Element methods, in cases where the selectors:
1. Only include descendant, sibling or child combinators, and
2. Do not include explicit :scope inside a functional pseudo-class
i.e. :not(:scope), :matches(:scope, *)
Implementations may optimise to only search descendants and/or
siblings, rather than the whole document.
Otherwise, it's possible for the selector to match any element in
the entire document, possibly including the :scope element itself.
---
8. *Proposed Rules for Prepending :scope*
Given a selector list as input to the method, trim whitespace and then
for each complex selector, run the first step that applies:
(Note: if the selector list is , then there are 0 complex selectors in
the list and the following doesn't run)
| 1. Otherwise, if the complex selector begins with any combinator other
|than the descendant combinator (, +, ~ or /attr/), then
|prepend :scope immediately before the combinator.
|
| 2. Otherwise, if there are no contextual reference nodes, do not
|prepend :scope.
|
| 3. Otherwise, If any compound selector includes a functional
|pseudo-class that accepts a selector as its parameter, and which
|contains the :scope pseudo-class anywhere within it, then do not
|prepend :scope.
|e.g. :matches(:scope), :not(:scope)
|
| 4. Otherwise, if the complex selector includes :scope within any
|compound or simple selector, then do not prepend :scope.
|e.g. :scope, div:scope.foo, div :scope p
|
| 5. Otherwise, prepend :scope and a descendant combinator.
Finally, return the modified list of complex selectors.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Web IDL sequenceT and item() method
On 2011-12-11 13:55, Marcos Caceres wrote: On Fri, 09 Dec 2011 19:51:48 +0100, Glenn Adamsgl...@skynav.com (mailto:gl...@skynav.com) wrote: If the answer is that no item() method is implied, then does the use of sequenceT in these newer specs entail dropping this method (with respect to prior DOM specs)? I'm also unsure as to the purpose of sequence in practice. Perhaps some examples of expected usage would help a bit? I use it in Selectors API for the refNodes parameter, which needs to accept any collection of nodes, whether it be a NodeList, Array, jQuery object or any other generic numerically indexed object. e.g. These should all work var list = document.getElementsByTagName(section) document.querySelectorAll(:scopeh1, list) document.querySelectorAll(:scopeh1, $(section)) // JQuery $() document.querySelectorAll(:scopeh1, [elm1, elm2, elm3]) -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: QSA, the problem with :scope, and naming
On 2011-10-20 10:14, Sean Hogan wrote: The primary use-case for matchesSelector() has been event-delegation, and this is the same for matches(). More specifically, consider the following scenario: jQuery adds a new event registration method that uses event delegation to mimic the behavior of: $(elem).find( div .thinger).bind(eventType, fn); The new method is called proxybind(), and the equivalent of the above is: $(elem).proxybind( div .thinger, eventType, fn); I cannot find any documentation for proxybind() and it doesn't seem to be in JQuery 1.7.1. I found a proxy() method, but it doesn't seem to match what you're talking about. http://api.jquery.com/jQuery.proxy/ Also, the JQuery.is() method, which is the method similar to .matchesSelector(), does not support any context node, and so it does not work with .is(.foo, context). Could you provide some documentation for, or at least a version of JQuery that implements proxybind? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Remaining Problems with Explicit :scope Switching in find/findAll
On 2011-11-27 21:29, Jonas Sicking wrote: Here is what I sent to the list on Nov 10th. Though it didn't get archived so maybe it didn't go through properly: ... I'll review your algorithm and respond to that a bit later. foo.find(label /for/ input+:scope~span) Can this expression ever match anything if we prepend :scope? Would simply removing step 5 above make the steps work for this case too? Yes. p input id=x strong label for=xX/label /strong span.../span /p var foo = document.find(strong); foo.find(label /for/ input+:scope~span); After prepending :scope, that will match the span element. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: XPath and find/findAll methods
On 2011-11-24 14:49, Robin Berjon wrote: So, now for the money question: should we charter this? Only if someone is volunteering to be the editor and drafts a spec. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Remaining Problems with Explicit :scope Switching in find/findAll
On 2011-11-25 03:58, Tab Atkins Jr. wrote: Alternately, assume that :matches() is eventually changed to allow complex selectors. Using :scope there is completely fine. I'm not sure what you mean. The current spec for matchesSelector does allow complex selectors as it's defined to accept a group of selectors (selectors 3 terminology), which is equivalent to a selector list (selectors 4). But :scope is still only useful when ref nodes are supplied. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 2011-11-25 00:19, Sean Hogan wrote: This has been raised before, but I'll restate it here. How should the selector be expanded in elt.findAll(div span, div :scope span)? The implication of :scope has to be done on a per complex selector basis, rather than applied to the entire list. That would be equivalent to: elt.findAll(:scope div span, div :scope span) If this isn't to throw an error then a more complex definition is required which can apply a different rule for implying :scope in different parts of the selector argument. This is sure to be confusing for anyone reading the code. Selectors in selector lists are always independent of each other, so authors who use a selector list would likely assume that one doesn't affect how another in the list matches. It would seem far more confusing for authors to do it using the other alternatives. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 2011-11-23 23:38, Sean Hogan wrote: Are there any issues with: - If you want to use selectors with explicit :scope then you use querySelector / querySelectorAll / matchesSelector. - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Remaining Problems with Explicit :scope Switching in find/findAll (was: Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?)
On 2011-11-24 00:52, Yehuda Katz wrote: On Wed, Nov 23, 2011 at 2:38 PM, Sean Hoganshogu...@westnet.com.au wrote: The alternative option (find / findAll / matches can accept explicit :scope, but will otherwise imply :scope) seems to be where all the ambiguity lies. What exact cases are ambiguous with find/findAll/matches can accept explicit :scope, but will otherwise imply :scope? The problems to be solved with automatically switching between implied and explicit :scope are basically in determining what exactly counts as an explicit :scope. The answers to each of these has is trade off between complexity and functionality, with the simplest option being always implying :scope. * Is explicit :scope allowed at the beginning of each selector? find(:scopediv); find(body.foo :scopediv); * Does :scope inside functional pseudo-classes count? find(:not(:scope)); find(:matches(:scope)); If yes, does the first match the whole document, only descendants, or descendants plus siblings? * If using an explicit :scope, can it match itself? find(:scope) // Return null or the element itself? * Is :scope always implied if it begins with an explicit combinator other than descendant, even if :scope is used elsewhere? find(div :scope); find(+div :scope); find(~div :scope); * There's also the general issue, not related to :scope, about how the reference combinator affects the range of potential matches. label.find(/for/ input) Based on the above issues, what happens in this case? foo.find(label /for/ input+:scope~span) -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?
On 2011-11-25 01:07, Sean Hogan wrote: On 24/11/11 7:46 PM, Lachlan Hunt wrote: On 2011-11-23 23:38, Sean Hogan wrote: - If you want to use selectors with :scope implied at the start of each selector in the selector list (as most js libs currently do) then you use find / findAll / matches. The matches method will not change behaviour depending on whether or not there is an explicit :scope because it is always evaluated in the context of the entire tree. There is never an implied :scope inserted into the selector, so there will not be two alternative matches methods. If and when there is a need for a matching method that does imply :scope (which I provided a use-case for in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0342.html) then it could be called matches(). Oh, it wasn't clear that you were talking about a case involving explicit reference nodes before. But adding two separate methods that are only subtly different would add more complexity for authors, since the difference will not always be obvious where there is no explicit reference nodes supplied and they may get them confused. In fact, with a method that always prepends :scope, it could result in an unexpected result in some cases: e.g. root.matches(html.foo); root.matchesSelector(html.foo); These aren't obviously different, but when you consider that the first would always prepend :scope under your proposal, the first would unexpectedly return false, since it's equivalent to: root.matchesSelector(:scope html.foo); This would happen whether the root element is the root of the document, or the root of a disconnected tree. We could instead address your use case by implying :scope if a refElement or refNodes is supplied. That way, if the author calls .matches() without any refNodes, they get the expected result with no implied :scope. If they do supply refNodes, and there is no explicit :scope, then imply :scope at the beginning. This approach would be completely backwards compatible with the existing implementations, as nothing changes until refNodes/refElement and :scope are supported. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: XPath and find/findAll methods
On 2011-11-21 20:34, Martin Kadlec (BS-Harou) wrote: Hello everyone, I've noticed that the find/findAll methods are currently being discussed and there is one thing that might be a good idea to consider. Currently, it's quite uncomfortable to use XPath in javascript. The document.evalute method has lots of arguments and we have to remember plenty of constants to make it work. IE and Opera support selectNodes method on NodePrototype, which is really useful, but what's the point in using it when it doesn't work in FF/Chrome/Safari. My idea is to combine querySelector/All and selectNodes methods. This combination - find/findAll - would make using XPath much easier and it might give a good reason to lot's of programmers to use it instead of querySelector/All although it's going to be newer technology. This idea seems similar to how JQuery used to support both Selectors and XPath in the same API [1]. Support was subsequently removed in 1.2, and at the time moved to an XPath Compatibility Plugin [2]. However, the link to the actual plugin page now returns a 404, and I can't find that plugin or any replacement elsewhere. This seems to suggest that support for XPath was not considered important enough for its continued maintenance. Are there any other popular libraries that do still offer XPath APIs, or is there any data showing that authors really want to use it? [1] http://docs.jquery.com/DOM/Traversing/Selectors#XPath_Selectors [2] http://docs.jquery.com/Release:jQuery_1.2#XPath_Compatibility_Plugin -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: XPath and find/findAll methods
On 2011-11-22 13:31, Martin Kadlec (BS-Harou) wrote: In my opinion, there are two use cases for XPath: 1) It's much harder to write the CSS selector e.g.: CSS: article div:nth-child(2) input[type=text], article div:nth-child(2) input:not([type]), article div:nth-child(2) input[type=color]; XPath: //article/div[2]//input[@type='text' | @type='color'| not(@type)]; There was a proposal to handle this. input:-moz-any([type=text], [type=color], :not([type])) The current draft of Selectors 4 includes :matches(), though, which can partially handle that case, excluding :not([type]), which would have to be left separate. input:matches([type=text], [type=color]), input:not([type]) 2) It's impossible to write the CSS selector (or really really hard/long) a - *[@data-price30]; b - *[position()30]; c - div[@*]; d - //div[parent::*//a]; Are such features really useful and desired by authors, and if so, is it possible that they could instead be introduced as features in Selectors? Anyway, mostly when I use XPath instead of CSS selectors it's because of XPath axis - the ability to go not just deeper but also higher in the element tree. XPath can also work with any node, not just elements. Could you describe a clear use case where this is useful for your needs? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: QSA, the problem with :scope, and naming
On 2011-11-15 15:13, Brian Kardell wrote: Right now, the spec does however handle that use case by doing this: document.querySelectorAll(:scope .foo, x); Where x is either an individual element, or an Array, NodeList or numerically indexed object containing 0 or more Elements. (It does however limit the result only to elements that are in the document, and any disconnected elements in the collection x would not be found.) What spec are you referring to? I've never seen that and I am having trouble finding it now. It's in the draft of Selectors API Level 2. http://dev.w3.org/2006/webapi/selectors-api2/#nodeselector See the refElement/refNodes parameters which specify elements matched by :scope. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[selectors-api] Requirements and Use Cases for Scoped Methods
Hi, Based on the ongoing discussion, I've put together the following list of requirements and sumarised use cases that should be met by the design of new features in selectors API. *Use Cases* 1. Select elements that are descendants of specific Element node, where all elements matched by the chain of selectors are all descendants of that element. section h1A/h1 div id=foo h1B/h1 section h1C/h1 /section /div section h1D/h1 /section /section e.g. JQuery $(#foo).find(section h1) This should find heading C only. 2. Select elements that is a child of a specific Element node. e.g. $(#foo).find(h1) 3. Select elements that are siblings (adjacent + or general ~) of a specific Element node. e.g. $(#foo).find(+section h1) $(#foo).find(~section h1) 4. Select elements relative to a specific Element node, conditionally based on it's own state. e.g. (Pseudo code) if Element foo has class name X, Select descendant elements matching input[type=radio] Otherwise, if Element foo has class name Y Select descendant elements matching input[type=checkbox] Alternatively, foo = document.getElementById(foo); inputs = foo.querySelectorAll(.X:scope input[type=radio], .Y:scope input[type=checkbox]); 5. Select elements relative to a specific Element node, conditionally based on the state of an ancestor or previous sibling element. e.g. (Pseudo code) if ancestor Element section has class name X, Select descendant elements matching input[type=radio] Otherwise, if ancestor Element section has class name Y Select descendant elements matching input[type=checkbox] foo = document.getElementById(foo); inputs = foo.querySelectorAll(section.X :scope input[type=radio], section.Y :scope input[type=checkbox]); *General* * Method names should be short, memorable and easy to type. - querySelectorAll is considered too long by authors. * Methods should prioritise optimisations for the common cases over full flexibility. Less common and more complex cases can be handled by existing methods. - Use cases 4 and 5 may be left to existing methods, depending on complexity they introduce and the impact upon potential optimisations. i.e. The cost vs. benefit of supporting them in new methods. * Optimisations should consider both authors and implementations *Implicit Scoping* * In the common case, when called on an element, selectors should be scoped relative to the context element * In the common case when called on the document, it either: - Search the whole document, or - Be scoped relative to a collection of reference elements * Support matching descendants, next siblings and their descendants * Should avoid matching ancestors or previous siblings - (See reference combinator issue below) *Syntax* * Should not require authors to explicitly use :scope, at least when it occurs at the beginning. * Selectors should be able to begin with combinators, :scope should be implied at the beginning. *Return Value* * Methods should return either a single Element node and/or an collection of elements * A collection of Elements should be - Mutable - Static, not live - Support all, or at least some, methods from Array. Need to determine which functionality is most important. - JS Libraries use Array.slice hack to convert a NodeList to an Array. This is a sub-optimal solution. *Implementation Optimisations* * It should be possible to, at least in the common cases, to limit the set of potential matches to a subset of the document. - This reduces the number of comparisons that need to be done and thus time to compute the result. * Ideally, it should be possible to determine heuristically from the Selector whether the impelemntation needs to check: - Only context element's descendants (descendant or child combinators) - Only context element's siblings (sibling combinators) - Both Issue: What should happen with the new reference combinator? label.find(/for/ input); div.find(label /for/ input) div.find(label /for/ input + span) * What would authors expect the result to be? * Should these search: - The whole document (or whole tree, if disconnected from document)? - Only descendants? - Only descendants and siblings? - Other subset of the document? * How does each option affect performance? * Are there any possible optimisations for these cases? e.g. label for=fooLabel/label input type=text name=a id=foo input type=text name=b id=foo label /for/ input matches both inputs, just like #foo Note: If you have anything to add, please do so. I'll be on holiday and mostly offline for the next 3 weeks. I'll review any additional discussion and attempt to draft up a possible solution in the spec after I get back from holidays. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http
Re: QSA, the problem with :scope, and naming
On 2011-10-20 12:50, Alex Russell wrote: On Thu, Oct 20, 2011 at 6:55 AM, Jonas Sickingjo...@sicking.cc wrote: Oh, and as a separate issue. I think .findAll should return a plain old JS Array. Not a NodeList or any other type of host object. I strongly agree that it should be an Array *type*, but I think just returning a plain Array is the wrong resolution to our NodeList problem. WebIDL should specify that DOM List types *are* Array types. We need NodeList separate from Array where they are live lists. I forget the reason we originally opted for a static NodeList rather than Array when this issue was originally discussed a few years ago. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: QSA, the problem with :scope, and naming
On 2011-10-20 13:18, Alex Russell wrote: On Thu, Oct 20, 2011 at 12:05 PM, Lachlan Huntlachlan.h...@lachy.id.au wrote: We need NodeList separate from Array where they are live lists. No we don't. The fact that there's someone else who has a handle to the list and can mutate it underneath you is a documentation issue, not a question of type...unless the argument is that the slots should be non-configurable, non-writable except by the browser that's also holding a ref to it. The author cannot be allowed to directly modify a live list, as such it must be an immutable object from the script's perspective. Otherwise, things would get really complicated if this happened: var p = document.getElementsByTagName(p); p.reverse(); p.push(x); p.shift(); document.body.insertBefore(document.createElement(p), p[2]); Where in the array would that new P element get added? NodeLists are supposed to be live and in document order. Ordinarily, that new P element would be inserted into the document and the change reflected in the NodeList. By allowing an author to modify the list in some way, that completely breaks the way NodeLists are defined to work. Now while it's arguable that live node lists were a mistake and that it would have been better if static Arrays were returned, we are stuck with them and cannot change that. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: QSA, the problem with :scope, and naming
On 2011-10-20 13:35, Sean Hogan wrote: I wonder if anyone is relying on querySelectorAll() returning a StaticNodeList? Only if there are people out there using list.item(n) instead of list[n], or people extending the NodeList interface and expecting such methods to be available on the result. Though I suspect the former is very rare, and the latter doesn't work in all browsers. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: QSA, the problem with :scope, and naming
On 2011-10-20 16:23, Boris Zbarsky wrote: On 10/20/11 1:08 AM, Tab Atkins Jr. wrote: I disagree. It's extremely useful and natural for .find(:scope + div) to match sibling of the context node. I really don't think it is. If you want that, use document.find(:scope + div, context). Basically, the presence of :scope would turn off *all* the limitations That's a _really_ bizarre behavior. So in this case: foo.find(:scope + div, div) what all divs in the document would be found? Or is the oh, ignore the reference node except for matching :scope meant to only apply on a per-selector basis inside the selector list? That has its own issues, especially with performance (e.g. merging nodesets while preserving DOM order). As it was specified in the old draft of queryScopedSelector (which is the definition I start with if find/findAll get introduced), it was done on a per selector basis, so the above would be equivalent to: document.querySelector(:scope + div, :scope div, foo); -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: QSA, the problem with :scope, and naming
On 2011-10-20 22:32, Tab Atkins Jr. wrote: On Thu, Oct 20, 2011 at 7:23 AM, Boris Zbarskybzbar...@mit.edu wrote: On 10/20/11 1:08 AM, Tab Atkins Jr. wrote: Basically, the presence of :scope would turn off *all* the limitations That's a _really_ bizarre behavior. So in this case: foo.find(:scope + div, div) what all divs in the document would be found? Or is the oh, ignore the reference node except for matching :scope meant to only apply on a per-selector basis inside the selector list? That has its own issues, especially with performance (e.g. merging nodesets while preserving DOM order). Per-selector basis; we're not talking about naive string manipulation here. Your example would return divs that are descendants or an adjacent sibling of the scoping element. Not necessarily. It depends what exactly it means for a selector to contain :scope for determining whether or not to enable the implied :scope behaviour. Consider: foo.find(:not(:scope)); If that is deemed to contain :scope and turn off the prepending of scope, making it equivalent to: document.querySelectorAll(:not(:scope), foo); Then it matches every element in the document except the context node. Otherwise, if it we decide that containing :scope means that it contains a :scope selector that is not within a functional notation pseudo-element, then it would prepend :scope, equivalent to: document.querySelectorAll(:scope :not(:scope), foo) Then it matches all descendants of the context element. In the latter case, then it would only ever be possible for matches to be found as descendants, siblings or descendants of siblings of the context element. That would even be true in cases like: foo.find(section:scope+div, div, ~p span, .x :scopeh1+span) With the selector pre-processing, that selector becomes section:scope+div, :scope div, :scope~p span, .x :scopeh1+span -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: QSA, the problem with :scope, and naming
On 2011-10-19 01:58, Tab Atkins Jr. wrote:
Based on discussion on the mailing list,style scoped will be
changing to the latter behavior as well, with the ability to invoke
the former behavior in the rare circumstances when you explicitly want
it.
Despite some similarities in appearance, the proposed changes to style
scoped will still use selectors differently from that proposed here for
a new findAll() method.
1. Syntax
In style scoped, selectors still can't begin with a combinator, but in
the proposed API, they can.
The @global at-rule was proposed to
2. Matching the Context Element
In scoped stylesheets, the context element itself can be the subject of
a selector. But the proposed API will never return the element itself in
the result.
div.findAll(div) // Does not match the element itself
(same as querySelectorAll() in this case)
div
style scoped
div { ... } /* Matches the context element */
/style
/div
3. The Subject of Selectors
In scoped stylesheets, the potential matches of a selector will only
include:
* The context element itself
* Descendants of the context element
In the proposed API, the potential matches will include:
* Descendants of the context element
* Siblings of the context element
In the existing API, the potential matches include:
* Descendants of the context element only
div.findAll(+p) // Matches sibling p elements
div.querySelectorAll(:scope+p) // Matches nothing
document.querySelectorAll(:scope+p, div) // Matches sibling p elements
div
style scoped
:scope+p { ... } /* Matches nothing */
/style
div
p.../p
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: QSA, the problem with :scope, and naming
On 2011-10-18 18:42, Alex Russell wrote:
Related and equally important, that querySelector and querySelectorAll
are often referred to by the abbreviation QSA suggests that its name
is bloated and improved versions should have shorter names.
I know the names suck. The names we ended up with certainly weren't the
first choice of names we were going for, but sadly ended up with after a
long drawn out naming debate and a misguided consensus poll to override
what should have been an editorial decision. So, if we do introduce new
methods, personally I'd be happy to use sensible names for any them, if
the rest of the group will allow it this time.
I therefore believe that this group's current design for scoped
selection could be improved significantly. If I understand the latest
draft (http://www.w3.org/TR/selectors-api2/#the-scope-pseudo-class)
correctly, a scoped search for multiple elements would be written as:
element.querySelectorAll(:scope div .thinger);
Both then name and the need to specify :scope are punitive to
readers and writers of this code. The selector is *obviously*
happening in relationship to element somehow. The only sane
relationship (from a modern JS hacker's perspective) is that it's
where our selector starts from.
The current design is capable of handling many more use cases than the
single use case that you are trying to optimise for here.
Ah, but we don't need to care what CSS thinks of our DOM-only API. We
can live and let live by building on :scope and specifying find* as
syntactic sugar, defined as:
HTMLDocument.prototype.find =
HTMLElement.prototype.find = function(rootedSelector) {
return this.querySelector(:scope + rootedSelector);
}
HTMLDocument.prototype.findAll =
HTMLElement.prototype.findAll = function(rootedSelector) {
return this.querySelectorAll(:scope + rootedSelector);
}
This is an incomplete way of dealing with the problem, as it doesn't
correctly handle comma separated lists of selectors, so the parsing
problem cannot be as trivial as prepending :scope . It would also
give a strange result if the author passed an empty string
findAll();
:scope + = :scope = meaning to return itself.
In another email, you wrote:
The resolution I think is most natural is to split on , and assume
that all selectors in the list are :scope prefixed and that.
Simple string processing to split on , is also ineffective as it
doesn't correctly deal with commas within functional notation
pseudo-classes, attribute selectors, etc.
I have attempted to address this problem before and the algorithm for
parsing a *scoped selector string* (basically what you're calling a
rootedSelector) existed in an old draft [1].
That draft also allowed the flexibility of including an explicit :scope
pseudo-class in the selector, which allows for conditional expressions
to be built into the selector itself that can be used to check the state
of the scope element or any of its ancestors.
(But that draft isn't perfect. It has a few known bugs in the
definition, including one that would also make it return the context
node itself under certain circumstances where an explicit :scope
selector is used.)
[1]
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api2/Overview.html?rev=1.29;content-type=text%2Fhtml#processing-selectors
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: QSA, the problem with :scope, and naming
On 2011-10-19 16:08, Alex Russell wrote: On Wed, Oct 19, 2011 at 1:54 PM, Lachlan Huntlachlan.h...@lachy.id.au wrote: I have attempted to address this problem before and the algorithm for parsing a *scoped selector string* (basically what you're calling a rootedSelector) existed in an old draft [1]. That draft also allowed the flexibility of including an explicit :scope pseudo-class in the selector, which allows for conditional expressions to be built into the selector itself that can be used to check the state of the scope element or any of its ancestors. We could accomodate that by looking at the passed selector and trying to determine if it includes a :scope term. If so, avoid prefixing. Yes, that's exactly what the draft specified. That'd allow this sort of flexibility for folks who want to write things out long-hand or target the scope root in the selector, possibly returning itself. I don't see a use case for wanting the proposed method to be able to return the element itself. The case where it's useful for elements matching :scope to be the subject of a selector is where you're trying to filter a list of elements. e.g. document.querySelectorAll(.foo:scope, list); // Returns all elements from list that match. But this wouldn't make sense el.find(.foo:scope) // Return itself if it matches. That result seems effectively like a less efficient boolean check that is already handled by el.matchesSelector(.foo). I''d also support a resolution for this sort of power-tool that forces people to use document.qsa(...,scopeEl) to get at that sort of thing. If there was no special handling to check for an explicit :scope, that would mean that any selector that does include :scope explicitly would not match anything at all. e.g. el.findAll(:scopep); That would be equivalent to: document.querySelectorAll(:scope :scopep, el); Which won't match anything. That might keep things simpler from an implementation perspective and doesn't sacrifice any functionality being requested. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: QSA, the problem with :scope, and naming
On 2011-10-18 18:42, Alex Russell wrote:
HTMLDocument.prototype.find =
HTMLElement.prototype.find = function(rootedSelector) {
return this.querySelector(:scope + rootedSelector);
}
HTMLDocument.prototype.findAll =
HTMLElement.prototype.findAll = function(rootedSelector) {
return this.querySelectorAll(:scope + rootedSelector);
}
What exactly does it mean to have a rootedSelector applied to the
Document object? As I understand it, the scoping problem explained only
seems to apply to running the query on elements, whereas the existing
document.qsa already behaves as expected by authors. It doesn't seem to
make sense to try and prepend :scope to selectors in that case.
e.g. document.find(html) shouldn't be equivalent to
document.querySelector(:scope html);
So, either we introduce the new method only for elements, or we use a
similarly named method on document for a similar, but slightly different
purpose.
A previous use case discussed on this list is the ability to take a
collection of elements, and execute the same selector on all all of
them, as if iterating the list, collecting the results and returning a
single merged collection.
The current API handles this use case with document.querySelectorAll,
explicitly specifying :scope and passing a collection of refNodes.
e.g.
var list = ...; // Elements (Array, NodeList or indexed object)
// Find the sibling p elements of all elements in the list
document.querySelectorAll(:scope+p, list);
Thus, if we do introduce the proposed method, should it behave
similarly, but with the implied rather than explicit :scope?
e.g.
document.findAll(+p, list);
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties
On 2011-05-09 22:31, Jonas Sicking wrote: On Mon, May 9, 2011 at 9:22 AM, Lachlan Huntlachlan.h...@lachy.id.au wrote: Every other tested property on HTML*Element interfaces stringified to null. What about namespaceURI, in various APIs (DOM-Core, DOM-XPath). Node.namespaceURI is readonly according to DOM3 Core, so setting it to null has no effect. But I just tested createElementNS() and got the following results: var el = document.createElementNS(null, foo); Firefox, WebKit, Opera, IE: el.namespaceURI returns null el.prefix returns null el.localName returns foo; returns FOO in Opera Same result as invoking createElementNS(, foo); var el = document.createElementNS(null, null); Firefox, WebKit, Opera (internal) throw INVALID_CHARACTER_ERR Same result as invoking createElementNS(, ); Opera 11, IE 9: el.namespaceURI returns null el.prefix returns null el.localName returns null in IE; returns NULL in Opera Same result as invoking createElementNS(, null); In general, my main priority is that we make things as consistent as possible. My second priority is that we make things follow JS behavior. So I'd be very happy if we can get away with making the just the above list stringify to , and the rest of the DOM stringify to null. We had a site compatibility bug with at least one property recently, (input.max = null), that we were stringifying to null, but where the site is expecting WebKit-compatible behaviour. We've also had similar compat problems in the past with some CSSOM properties, although they have since been defined as nullable types in that spec. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties
On 2011-05-07 16:03, Lachlan Hunt wrote: (I don't have results for IE yet because the testharness script I used to write the tests doesn't work in IE.) I've now tested IE9, which did give me results. The following properties are all stringified to . * BODY .text, .bgColor, .link, .vLink, .aLink * HR .size * A, AREA .coords, .shape * IFRAME .width, .height, .marginHeight, .marginWidth * TABLE .bgColor, .width * COLGROUP, COL .width * TR .bgColor, * TD, TH .bgColor, .height, .width * INPUT .height, .width * BUTTON .type * .textContent on everything Every other tested property on HTML*Element interfaces stringified to null. (This is testing non-readonly DOMString properties on HTML*Element interfaces documented in HTML [1], excluding those I mentioned as untested in my previous mail.) [1] http://www.whatwg.org/C -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties
On 2011-05-06 15:45, Boris Zbarsky wrote: On 5/6/11 6:10 AM, Lachlan Hunt wrote: Recently, in order to resolve a site compatibility issue caused by us stringifying to null for some properties, we made all DOMString APIs consistent in their handling of null, such that they now stringify to an empty string. We believe this is compatible with other implementations for all other attributes and properties that we are aware of. Sorry, I should have said most. We were aware of a few exceptions. document.write(null) will write null in Chrome and Gecko (but not Safari). You may want to check IE as well. For document.write(), Gecko, Webkit (including Safari 5), Opera and IE write null on both Windows and Mac. I don't know which version of Safari you were using that gave you a different result. alert(null) outputs null in all browsers. Both confirm(null) and prompt(null, null) output in Gecko and null in all others. It's possible that alert() and .write() might need to be defined as exceptions for compatibility, especially since both are commonly used for quick debugging purposes and it's useful to clearly see when a variable is null using alert(foo); I don't really have a strong opinion either way for the confirm() and prompt() methods, though consistency with alert seems sensible. There are various other cases that have this behavior. In Gecko, anything that goes through JS_ValueToString (instead of default XPConnect argument conversion that converts null to a void empt) will do this. This is unfortunately not particularly consistent. Is there any reason to believe that any or all of those are intentionally done that way for this handling of null, or are they merely a result of the way the programmers arbitrarily decided to implement them? Furthermore, some IDL in Gecko explicitly treats null as null. In addition to the selector API, there's createHTMLDocument, Opera throws an exception when invoking createHTMLDocument(null). Is there any evidence that stringifying to null is required for compatibility at all? all sorts of stuff on DOMTokenList, It seems unlikely that DOMTokenList would have any compatibility issues with either approach, considering it's a relatively new feature with limited support and limited deployment. .text on HTMLAnchorElement, a.text is defined as an alias for a.textContent in HTML, which does stringify null to in all implementations. Opera 11 stringifies .text to null. WebKit and IE don't support a.text, but do support .textContent. Is there any reason why .text and .textContent need to be handled differently? If so, then that will require HTML to be updated. Otherwise, I don't see why that isn't just regarded as a bug in Gecko. .wrap on HTMLTextAreaElement. Wrap is an enumerated property and the strings and null are both interpreted as the missing value default state, soft. It only affects the way the way the value is reflected in the content attribute. So changing that shouldn't have any compatibility issues. I also found HTMLOutputElement.defaultValue stringifies to null in Gecko. In all other cases I've checked, including 99% of all DOMString properties on HTMLFooElement interfaces documented in HTML, Gecko stringifies to . WebKit instead just removes an attribute from the DOM when the corresponding property is assigned null, and this means the default value (usually ) is returned when getting those properties. So, while not technically the same as stringifying to , it is compatible with it. Opera 11 stringified the following to : * [A, AREA, LINK, BASE] .href * SCRIPT .text * INPUT .type, .value * BUTTON .type * KEYGEN .keytype * .textContent on everything All other properties stringified to null, which caused site compat problems in some cases. (I haven't checked these properties yet: protocol, host, hostname, port, pathname, search, hash on A and AREA, selectionDirection on INPUT and TEXTAREA, value on SELECT, and outerHTML on everything.) (I don't have results for IE yet because the testharness script I used to write the tests doesn't work in IE.) I've been informed that Cameron has plans to update WebIDL to make this the default too, but hasn't yet done so. Oh, interesting. I'd either missed that or forgotten it... I'm not sure where it's been mentioned publicly. That's just what Anne has claimed internally. I don't have a problem with this change per se, but note that it will change querySelector(null) from silently doing probably the wrong thing to throwing. I do think it should be safe, though. I think it's safe since Firefox 3.6 has that behaviour and there doesn't seem to be any known issues caused by that. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[WebIDL][Selectors-API] Stringifying null for DOMString attributes and properties
Hi, WebIDL currently specifies in the ECMAScript to IDL type mapping [1] that null stringifies to null by default, unless otherwise specified with [TreatNullAs=EmptyString]. This definition matches current selectors-api implementations, which do this conversion for the selectors parameter and this is also the result expected by the current selectors api test suite. However, according to information I got from Anne, and from my own limited testing, this does not seem to be true of other DOMString attributes or properties in other implementations. Recently, in order to resolve a site compatibility issue caused by us stringifying to null for some properties, we made all DOMString APIs consistent in their handling of null, such that they now stringify to an empty string. We believe this is compatible with other implementations for all other attributes and properties that we are aware of. But this fix also had the result of changing the way we handled null in selectors-api, for which we used to stringify as null. I've been informed that Cameron has plans to update WebIDL to make this the default too, but hasn't yet done so. Since Selectors API is defined to use the default behaviour as specified by WebIDL, and if and when WebIDL gets updated, then it also means that the Selectors API implementations in Gecko, WebKit and IE will also need to be updated again and I will need to update the test suite. In Gecko's case, this means reverting back to the behaviour they had shipped in Firefox 3.6, so it's unlikely that reverting this will result in any web compatibility issues. [1] http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: More questions about contextual reference nodes
On 2011-04-13 04:43, Cameron McCormack wrote:
Lachlan Hunt:
This seems to differ from the algorithm given for T[], which
requires that the object be either an array host object or a native
object, which would not handle the JQuery case. The sequenceT
type seems more generic than that as the algorithm seems to be able
to support any object with a length and indexed properties.
Why wouldn’t it handle the JQuery case? Isn’t it a native object?
I didn't think so, but then perhaps I misunderstand what the spec means
by a native object. ECMAScript defines a native object as
object in an ECMAScript implementation whose semantics are fully
defined by this specification rather than by the host environment.
So that would include things like Array, String, etc. I don't think
NodeList fits that definition, since it's provided by the host
environment, not ECMAScript.
I also thought something like this would not be a native object either:
function init() {
...
}
var x = new init();
JQuery more or less does that to create an object with custom
properties, and then basically uses Array.prototype.push.apply(x, elms)
to add the collection to that object.
The issue of whether you want to throw eagerly if passed an array with
elements of the wrong type to an operation taking a sequenceT is an
interesting one, which probably still could bear some more discussion.
On the one hand, it helps ensure implementations don’t diverge based on
when during the course of running the method these elements from the
sequence are looked up. I could mean a lot of useless checks, though.
It's nice so that cases where authors try to pass in an array of things
that aren't nodes are handled well. The other alternative is just to
accept a collection of anything, and iterate through it to find all the
Element nodes, ignoring everything else. I don't see any reason to
prefer the latter approach.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: More questions about contextual reference nodes
On 2011-04-13 06:32, Cameron McCormack wrote: Lachlan Hunt: OK. Then I'm not sure what the practical difference between the Element[] or sequenceElement would be then, nor which one to use. ... the only difference is that with Element[] you can distinguish between null and an array of [length 0], while with sequenceElement you can’t. I don't think it's necessary to distinguish between null and length 0 here, since they both mean that there are no contextual reference elements. However, with the way in which the IDL is overloaded, it's not clear to me which of the two overloaded methods gets invoked when the parameter is null. The IDL says: querySelector(in DOMString selectors, in optional Element refElement); querySelector(in DOMString selectors, in sequenceNode refNodes); When the author invokes: x.querySelector(a, null); Does it invoke the method with refElement or refNodes? (Although, in this case, it shouldn't matter, since the algorithm I wrote to determine contextual reference nodes ignores null in either case) While i n: Let x be the result of calling [[Get]] on V with property name ToString(i). Set Ei to be the result of converting x to an IDL value of type T. This step can throw (as part of the conversion process defined for converting to type T); seems like that would involve throwing from the whole algorithm. Yep. Which conversion algorithm applies here? Is it 4.1.15. object, or 4.1.16. Interface types? http://dev.w3.org/2006/webapi/WebIDL/#es-object The former never throws, the latter will throw a TypeError. So am I right in assuming it's the latter? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: More questions about contextual reference nodes
On 2011-04-09 19:14, Boris Zbarsky wrote:
On 4/9/11 6:27 AM, Lachlan Hunt wrote:
There were cases in JQuery where the script wanted to iteratively run a
selector on all nodes in a collection, and return elements that are
descendants of those elements. This allows :scope to be used in those
cases by passing the collection as the refNodes. There was previous
discussion of this somewhere in the public-webapps archive.
Hmm... ok.
As a simple example of that, this works in JQuery:
pspan/span
pspan/span
pspan/span
script
alert($(p).find(span).length)
/script
But is jquery's collection a JS Array?
The object returned by the $() function isn't an array. It's a custom
object that mimics the functionality of an array. This means that as
currently defined, refElements could not accept a JQuery object as the
parameter like so:
var p = $(p.foo)
Var a = $(a);
a[0].matchesSelector(:scopea, p)
This would instead require scripts to do this:
a[0].matchesSelector(:scopea, p.toArray())
JQuery effectively defines .toArray() as a function that returns:
Array.prototype.slice.call( this, 0 );
Would it be useful, and is it possible to define the refElements
parameter to accept any object that contains a .length and indexed
properties, just like a JQuery object? i.e. Can we make this work?
var x = {}
x[0] = el1;
x[1] = el2;
x[2] = el3;
x.length = 3;
a.matchesSelector(:scopea, x);
I also have to include one for HTMLCollection, which doesn't inherit
from NodeList.
Yeah, that's broken... I wonder whether we can just fix that in Web DOM
Core or something
Yes, I'd like to fix it somehow. I'm not yet sure how.
WebIDL says sequences are passed by value and arrays are passed by
reference. So I suspect using an array is better here so that it doesn't
have to create a copy.
The by reference thing only happens for array host objects, which a JS
Array is not. So the copy would effectively happen in either case, I
believe, for JS Array.
OK. Then I'm not sure what the practical difference between the
Element[] or sequenceElement would be then, nor which one to use.
Yes, I would like feedback about the best way to define this,
particularly for Arrays. In particular, how to address the following
cases.
var ref = [];
ref[0] = el1;
ref[100] = el2;
That will contain almost a million empty cells. Will iterating through
that cause any unwanted performance issues?
I believe my current Gecko implementation (using our existing variant
facilities, since that's all we have to deal with overloads for the
moment) will allocate a C array with 101 entries, then ignore it
because not everything in the array is an Element.
A DOM binding implementation using WebIDL arrays or sequences would
allocate a C++ array with 101 entries, all of which except for the
first and last are null. Then the actual implementation of the selectors
API will walk this array and add only the first and last entry to the
set of scope elements. I think. I'm pretty sure this is true for Array;
the behavior for sequence is less clear to me. And maybe this can all be
optimized in implementations, somehow... Ccing Cameron for his input.
Should we require arrays to contain contiguous Elements and only
iterate up to the first empty or non-Element cell, ignoring
anything beyond that?
If using webidl array/sequence types, that would help with the
iteration, but not the large allocation.
OK, does that mean it's not really worth defining like that?
ref[1] = string;
Should passing this now throw an exception, or should it just accept
that ref[0] was an element and use that?
Webidl array/sequence would throw in this case, I think.
Yes, I just checked and I think you may be right. The WebIDL algorithm
to convert an ECMAScript array to an IDL value of type T[] iterates the
array and says:
While i n:
Let x be the result of calling [[Get]] on V with property name
ToString(i).
Set Ei to be the result of converting x to an IDL value of type T.
Set i to i + 1.
I think the second step in the loop should throw a TypeError if the
object can't be converted to the correct type (Element, in this case).
But WebIDL doesn't seems very clear about this, so I may be wrong.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Support for matchesSelector()
On 2011-04-08 16:41, Boris Zbarsky wrote:
On 4/8/11 6:44 AM, Lachlan Hunt wrote:
We are thinking that implementing with a prefix as
Element.oMatchesSelector() is unnecessary
Well, one obvious question is whether we now have good reasons to
believe that the name and number/meaning of the arguments won't change.
The name is highly unlikely to change. There's never been any
suggestion that matchesSelector is an inappropriate name and no requests
to change it that I'm aware of.
2. Using the :scope selector in existing implementations will throw a
syntax error.
That seems, to me, like something that should prevent unprefixing, no?
The same issue will occur with any new selector that gets added in the
future. The only real difference between this and any other is that
support for :scope will inherently imply refElement support.
This means that if a script in the future wants to use a selector with
:scope, they will still be able to detect whether or not a given browser
supports it using a try/catch block.
Yes, but should it have to?
3. The existing querySelector methods also don't have a prefix, but
selectors api 2 also extends those in the same way with refNodes. This
should not be a problem for those methods.
This is true, for the reasons you described, but trying to use the new
features for the existing methods does involve that try/catch pattern
you noted. But should we really require its use for matchesSelector?
There are obvious benefits to having matchesSelector support imply that
:scope is supported too...
I'm not entirely sure what you consider to be obvious benefits. Do you
think authors should be able to do this?
if (el.matchesSelector) {
// Confirms that browser supports :scope and refNodes
} else if (el.mozMatchesSelector) {
...
} else ...
Are there any other obvious benefits that I may be missing?
I should note that the way the old methods were extended is somewhat
worrisome: as soon as a UA implements the new refNodes thing we're stuck
with it. So I really hope that either we're very sure that's what we
want to do or that UAs are careful about implementing until we get to
that very sure level. I'd prefer the former, since I've been
considering implementing this stuff.
I'm fine with waiting till we're very sure, and I hope we can get to
that stage soon. Do you have any suggestions for how we could lower the
risk of unforeseen problems in the future?
I think it makes sense for matchesSelector and querySelector to use a
common API design and accept the same parameters.
As far as I know, there are a few options we have:
1. Leave the spec as is and implement with the refElements parameter.
This has the advantage of keeping the API simple.
2. Create a more generic extension mechanism, such as an options
parameter. Then define the method as
matchesSelector(selector, options);
Where options is defined to take an object with various properties, like
this:
options = {
ref: [el1, el2], // Reference nodes
ns: [...], // Namespaces
... // Other future extensions
}
This would allow for easier extensions in the future where the method
just ignores unknown options, but at the expense of a more complex
syntax. It's not clear what the chances are of wanting more extensions,
nor if it's worth the complexity cost to go down such a path now merely
as a precaution.
2a. Initially do what the spec says (#1), and then if such extensions
are wanted in the future, overload the method in a backwards compatible
way to accept both an refElements or an options object (#2). That is,
if adding a 3rd parameter or introducing a new method is undesirable.
3. Introduce new methods every time we want to add a new feature.
This isn't the most scalable, but might be the best option when it comes
to namespace support, if we ever decide it's necessary to support that.
I'd rather not have to do it for refElements, since it would mean that
the existing methods and the new methods without refElements would be
functionally identical.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: More questions about contextual reference nodes
On 2011-04-10 13:30, Lachlan Hunt wrote:
But is jquery's collection a JS Array?
The object returned by the $() function isn't an array. It's a custom
object that mimics the functionality of an array...
var p = $(p.foo)
Var a = $(a);
a[0].matchesSelector(:scopea, p)
...
Would it be useful, and is it possible to define the refElements
parameter to accept any object that contains a .length and indexed
properties, just like a JQuery object? i.e. Can we make this work?
var x = {}
x[0] = el1;
x[1] = el2;
x[2] = el3;
x.length = 3;
a.matchesSelector(:scopea, x);
I reviewed WebIDL again, and I think I've started to understand the
difference between sequenceT and T[] now.
As I understand it, the algorithm to convert an ECMAScript object to an
IDL sequence should work with any object that has a length property and
indexed values containing Node objects. That is true for an Array of
Nodes, NodeList, HTMLCollection and the above JQuery case, they can all
be handled in the same way.
This seems to differ from the algorithm given for T[], which requires
that the object be either an array host object or a native object, which
would not handle the JQuery case. The sequenceT type seems more
generic than that as the algorithm seems to be able to support any
object with a length and indexed properties.
I've updated and simplified the spec to handle the above case using the
parameter sequenceNode. I still need to update the prose to say that
while the collections may contain any Node, only Element nodes are added
to the list of contextual reference elements. But the following cases
should all work.
1. Array of Elements
document.querySelector(:scopea, [el1, el2, el3]);
2. NodeList
document.querySelector(:scopea, el.childNodes);
3. NodeList converted to an array
document.querySelector(:scopea,
Array.prototype.slice.call(el.childNodes, 0));
// Conversion to an array is unnecessary here, but just showing that
// it will work anyway.
4. HTMLCollection
s.matchesSelector(:scope~a, document.images);
5. Objects with indexed properties, including JQuery
var x = {}
x[0] = el1;
x[1] = el2;
x[2] = el3;
x.length = 3;
document.querySelector(:scopea, x);
x = $(.foo, .bar);
a.matchesSelector(:scopea, x);
a.matchesSelector(:scopea, x.toArray());
// Unnecessary converstion to array here
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: More questions about contextual reference nodes
On 2011-04-09 10:12, Boris Zbarsky wrote: I have two questions about http://www.w3.org/TR/selectors-api2/#determine-contextual-reference-nodes 1) What are the use cases for supplying more than one contextual reference node, exactly? It seems weird to allow more than one node to match :scope. There were cases in JQuery where the script wanted to iteratively run a selector on all nodes in a collection, and return elements that are descendants of those elements. This allows :scope to be used in those cases by passing the collection as the refNodes. There was previous discussion of this somewhere in the public-webapps archive. 2) If we do want to allow the multiple node thing, can we please do it in IDL instead of the (currently pretty vague) prose? Something like: I know the draft is quite poorly written with regards to how to deal with collections right now. Element querySelector(in DOMString selectors, in optional Element refElement); Element querySelector(in DOMString selectors, in optional NodeList refElements); Element querySelector(in DOMString selectors, in optional sequenceElement refElements); I also have to include one for HTMLCollection, which doesn't inherit from NodeList. But if that would be better, then yes, we can do that. It just makes the IDL 4 times longer, as that has to be repeated for each method of the 3 methods. Ive made this change now. I also dropped queryScopedSelector at the same time, since it wasn't able meet the original requirements that it was being designed for and so not worth keeping. or some such? It's not quite clear to me whether we want a sequenceElement or a T[]; that's worth checking. WebIDL says sequences are passed by value and arrays are passed by reference. So I suspect using an array is better here so that it doesn't have to create a copy. In either case, the prose will need to define what happens with the NodeList or sequence/array cases, but there will be no ambiguity about how one gets Elements out of what's passed in. The one difference is that in the array case if non-elements are present in the array an exception will be thrown. I think that's fine, myself. Yes, I would like feedback about the best way to define this, particularly for Arrays. In particular, how to address the following cases. var ref = []; ref[0] = el1; ref[100] = el2; That will contain almost a million empty cells. Will iterating through that cause any unwanted performance issues? Should we require arrays to contain contiguous Elements and only iterate up to the first empty or non-Element cell, ignoring anything beyond that? ref[1] = string; Should passing this now throw an exception, or should it just accept that ref[0] was an element and use that? For NodeLists, should it accept any NodeList and only use the Element nodes? e.g. element.childNodes may contain text or comment nodes. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Support for matchesSelector()
Hi,
The matchesSelector() method has been implemented by both Mozilla [1]
and WebKit [2], and we are implementing the same level of support for it
as they did (without support for :scope or refNodes parameter).
However, both Mozilla and WebKit opted to implement it using prefixed
methods, and I'm wondering if people from Mozilla and WebKit could
explain their justification for using a prefix?
We are thinking that implementing with a prefix as
Element.oMatchesSelector() is unnecessary because:
1. Using refNodes without using the :scope selector has no effect and
additional parameters are just ignored.
e.g. el.matchesSelector(a, [el1, el2]); works now as defined.
2. Using the :scope selector in existing implementations will throw a
syntax error.
This means that if a script in the future wants to use a selector with
:scope, they will still be able to detect whether or not a given browser
supports it using a try/catch block.
e.g.
try {
var x = el.matchesSelector(:scopea, [el1]);
} catch (e) {
// Use alternative technique here to check.
}
3. The existing querySelector methods also don't have a prefix, but
selectors api 2 also extends those in the same way with refNodes. This
should not be a problem for those methods.
Therefore, I would like to get feedback from others, particularly the
Mozilla and WebKit developers about this approach, and find out whether
Mozilla and WebKit will also consider dropping the prefix?
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=518003
[2] https://bugs.webkit.org/show_bug.cgi?id=29703
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Support for matchesSelector()
On 2011-04-08 18:22, Boris Zbarsky wrote: On 4/8/11 6:44 AM, Lachlan Hunt wrote: 2. Using the :scope selector in existing implementations will throw a syntax error. On which note, it seems like :scope will first show up prefixed as well, right? Yes, that's reasonable. In which case, do we just want to define :scope as matching the documentElement of the ownerDocument of the element in question? Fixed. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Selectors API IDL Issues
Hi,
Presently, the IDL in Selectors API defines the NodeSelector
interface using [Supplemental, NoInterfaceObject].
I'm not quite sure why I have supplemental in there, but it seems to be
left over from an old edit that should have been removed, since
NodeSelector is not a pre-existing interface that this is supplementing.
So I will be removing [Supplemental] from the IDL when I make the
edits necessary to take the spec to PR.
It's also been brought to my attention that the use of
[NoInterfaceObject] may not be quite right either and I would like to
get clarification.
According to a mail from Cameron [1], the use of [NoInterfaceObject] and
the implements statement has an observable difference from defining a
Supplemental interface, though I originally thought there would not be.
I thought that the following were identical from a black box
implementation perspective:
1)
[Supplemental]
interface Element {
Element querySelector(in DOMString selectors, in optional any
...
}
2)
[NoInterfaceObject]
interface NodeSelector {
Element querySelector(in DOMString selectors, in optional any
...
};
Element implements NodeSelector
(And similarly for Document and DocumentFragment, omitted for simplicity)
The querySelector methods should exist on Element.prototype, which does
seem to be what Opera, Gecko and WebKit do.
According to Cam's mail, that is what does happen in case #1, but is not
in case #2, as in the current spec, though I'm not sure why. So I would
like to get clarification whether that is in fact the case, and whether
[NoInterfaceObject] really is what I should be using here.
[1] http://lists.w3.org/Archives/Public/public-web-perf/2011Mar/0058.html
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: Status of Selectors API Level 1 Candidate
+public-webapps, -team-webapps On 2010-05-04 18:23, Arthur Barstow wrote: The Selectors API Candidate says: [[ http://www.w3.org/TR/2009/CR-selectors-api-20091222/ There are several known implementations believed to be complete and interoperable (or on the point of being so) and the WebApps Working Group expects to develop a test suite and use it to show that that these implementations pass early in 2010. The Working Group does not plan to request to advance to Proposed Recommendation prior to 30 April 2010. There is no formal implementation report available at the present time. ]] What's the status and plan for this spec? I believe the test suite is nearly ready [1]. As I mentioned last year, Minefield currently passes 100% of the test suite. However, this has not yet shipped in a release build. I assume it will make it into the next major release after the current 3.6.x branch. The browser used in the BlackBerry 9700 also reportedly passes 100% of the test suite. Opera passes 100% of the baseline test suite. We have failures in the additional tests, which are related to bugs in our Selector implementation. This level of support has shipped in the recent 10.5x builds. WebKit (Safari and Chrome) is still failing 16 of the baseline tests. IE8 is failing 252 of the baseline tests. It exhibits a scripting error in the additional tests that prevents them from running, but I haven't investigated the cause. I have not been able to test IE9 because I don't have access to Windows Vista or 7. I would appreciate it if anyone who has a copy of the last public development build, or someone from Microsoft, could report on the implementation status in IE9. Given the implementations in Opera and Blackberry pass the baseline tests, we technically meet requirements in the proposed exit criteria [2], although I don't see any harm in waiting for the next major Firefox release build. I think only released builds, as opposed to development builds, should be used for meeting the implementation requirement. There was previously a question about whether JavaScript implementations should count, like JQuery. I don't think they should count because they are generally not subject to the same interoperability requirements as a native browser implementation are subject to. i.e. JavaScript implementations only have to work on sites where the author explicitly includes the script, browsers have to work on any site a user visits. I think we should produce some kind of implementation report documenting the results for each browser. P.S. Please feel free to send your response to public-webapps. OK. [1] http://dev.w3.org/2006/webapi/selectors-api-testsuite/ [2] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1221.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Steps to creating a browser standard for the moz-icon:// scheme
Pierre-Antoine LaFayette wrote: Yes, I wish to expose the platform and possibly Browser theme specific icons to web content with the Icon URI scheme. The idea is to allow the Icon URI scheme to be used anywhere an image is specifiable by a data URI in HTML and JavaScript. This will allow web content to emulate the look and feel of the native Operating System and of the Browser itself in the case of themed icons. I believe this will benefit both content creators and consumers. Could you elaborate on the use cases for these icons? What sort of web applications would really benefit from emulating the native look and feel of the user's OS, and in particular, what sort of functionality would these icons be used to represent? My concern is that application developers will find it difficult for their app's own custom theme to visually integrate well with system specific icons. It seems much more likely that developers would want to have all icons used to be designed with a common style. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Steps to creating a browser standard for the moz-icon:// scheme
Pierre-Antoine LaFayette wrote: The actual use case that triggered my want to have this was the FTP and file:// URI directory listings pages in Chromium. They currently are quite bland and without icons, as may be true for other browsers. Opera doesn't have icons for files, i think Safari uses 2 stock icons for folders and files. Firefox' equivalent pages use the moz-icon scheme and have the platform specific icons. Makes for very nice directory listing pages. OK, and I suppose the standard directory listing pages that Apache generates could also make use of them. It wasn't clear from your original mail that this was just about file type icons, based on the file extension. You also mentioned: stock-image is of the format: stock/icon-name icon-name is a valid icon name, such as 'ok', 'cancel', 'yes', 'no'. It's not clear what the use cases for these are, but for these, it does seem like we would need to define a common set of icons that are available, unlike the file type icons that can load the system's associated icon. Have you considered using the existing about: URI scheme for this? This scheme is in the process of being standardised, and it is possible for specs to define URIs using it, which are then meant for resolving in application/platform specific ways. See the draft here. http://github.com/josephholsten/about-uri-scheme/blob/master/draft-holsten-about-uri-scheme-03.txt The important part is defined in section 5, which has significant amendments described here, which have yet to be integrated into the draft. http://lists.w3.org/Archives/Public/public-html/2009Sep/0755.html http://lists.w3.org/Archives/Public/public-html/2009Sep/0767.html You could write a spec to define an about:icon URI to work like this like, e.g. about:icon?html;32 or about:icon?ext=htmlsize=32 (though, I think being shorter and avoiding '' is better, so authors don't have to bother escaping it in their HTML) -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Steps to creating a browser standard for the moz-icon:// scheme
Pierre-Antoine LaFayette wrote: So in HTML a user can have: img src=moz-icon://unknown?size=16 alt=File:/ If opened in Firefox, the browser will provide an icon for the filetype. I think this is a useful scheme that other browsers could benefit from. There is a chrome://fileicon/path scheme in Chromium, however it is purely internal and not exposed to the Web. I thought that having a standard icon:// scheme of some sort would be the best approach rather than Chromium and Mozilla having their own browser specific schemes for icon retrieval. What benefit is there for trying to achieve interoperability by standardising this? Are these icons meant to be used by web content, or meant only for internal use by the browser? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Publishing Selectors API Level 2 as an FPWD?
Boris Zbarsky wrote: On 1/10/10 11:58 PM, Sean Hogan wrote: Even if jQuery deprecates non-standard selectors, the current spec for queryScopedSelector*() doesn't support the jQuery implicitly scoped selector *. As I understand it, jquery selectors on elements are always scoped in the sense that they behave differently from the v1 Selectors API. In particular, if I understand correctly, the behavior of: element.querySelector(body div) in matching all divs that are descendants of |element| and also descendants of a body (which may be an _ancestor_ of |element|) is different from the selector behavior in jquery. Yes. All that said, I just read the draft at http://dev.w3.org/2006/webapi/selectors-api2/ and I can't make heads or tails of either what the new arguments to querySelector(All) are supposed to mean (are they just an enumaration of the things :scope is allowed to match during the selector evaluation?) When there's no reference nodes passed and no :scope selector used, the behaviour of querySelector and querySelectorAll is unchanged from v1. If there is a :scope selector used, then it matches the context node. If there are also additional reference nodes passed, then :scope will instead match any of the elements in given collection. or what queryScopedSelector(All) is supposed to do. Am I just missing something? Am I reading the wrong draft? (I'd link to the dated version of the draft, in case it changes, but that link is broken, sadly.) You can link to the CVS revision instead. The link to the dated version in the page header is generated automatically by the spec generator, regardless of whether it actually exists or not. In the following forms :scope is misleading: element.queryScopedSelector(:scope + *) element.queryScopedSelector(:scope ~ *) What's misleading about that? :scope would match the context node (what the element variable points to), and would return its sibling elements. and especially: element.querySelector(* :scope *, refNode) Again, how is that misleading? :scope matches whichever element refNode points to, and then follows the normal rules for evaluating querySelector. Given that selector, any descendents of refNode that are also descendents of element (the context node) will be matched, the first of which will be returned. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api2] Should we keep the queryScopedSelector methods? (was: Publishing Selectors API Level 2 as an FPWD?)
Boris Zbarsky wrote: That answers my complaint, but not my question: what is queryScopedSelector supposed to do? When it was originally added, it was supposed to handle all of the pre-parsing of the selector to prepend :scope to each selector in the group, including handling things like div, +p. But it got watered down a lot since then due to complaints from the CSSWG about modifying the selector syntax, and now it can only handle implying :scope and a descendant combinator. Admittedly, that does lower its value significantly and I may end up just dropping it. The only benefit it has now is that it's mildly more intuitive for authors, since unlike the existing non-scoped method, it can return siblings of the context node. e.g. elm.queryScopedSelectorAll(:scope+p); But, in most cases, except where elm is in a disconnected tree, that is really equivalent to: document.querySelectorAll(:scope+p, elm); Anyway, since the CfC for FPWD has already begun, I'd rather not make any major changes till afterwards. I'd also like to hear from a few other people on this issue. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Publishing Selectors API Level 2 as an FPWD?
Sean Hogan wrote: In summary, the proposed :scope pseudo-class only acts as a scope for the query in special cases, not in the general case. Yes, I'm aware of that. That was basically my reasoning for attempting to change it to :reference, but that name wasn't particularly well received either. However, keep in mind, I'd prefer to avoid having this turn into another naming debate. Selectors API has suffered enough in the past as a result of that. So if you have anything more to add, I'd request that you check the archives for this list and www-style for messages relating to :scope/:reference/:context, etc. to see what arguments have been raised previously. The most recent discussion of and objections to :reference are in this thread from www-style last September. There were also other objections raised with me on IRC and told to me directly. http://lists.w3.org/Archives/Public/www-style/2009Sep/thread.html#msg251 In particular, this one lists most of the alternatives have been considered, and it also sums up why the selector pre-processing for scoped selectors got watered down to its current state. http://lists.w3.org/Archives/Public/www-style/2009Sep/0317.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Publishing Selectors API Level 2 as an FPWD?
Sean Hogan wrote: On 8/01/10 1:19 AM, Lachlan Hunt wrote: can we publish Selectors API Level 2 as an FPWD? http://dev.w3.org/2006/webapi/selectors-api2/ FYI, it seems the whole Status of this Document hasn't been updated for Selectors-API2. Yeah, that will get fixed up when I get the spec ready for publication and do all the PubRules checks, etc. Also, the links to the W3C CVS are for Selectors-API, not Selectors-API2. Likewise. I can't see the value of queryScopedSelector*() methods. The original rationale was that JS libs could potentially drop their selector engines, but this isn't facilitated by the proposed methods. Given that JS libs will still have to parse the selectors it is a trivial step to call querySelector*(rewrittenSelector, refNode) rather than queryScopedSelector*(rewrittenSelector) Personally, I agree and was initially hesitant about adding it, but there were some reasonable arguments put forth suggesting that lifting the burden of pre-processing the selector to prepend :scope from JS libs would be useful [1]. Evidence to the contrary would be helpful. John Resig also once told me he had an alternative proposal, but he hasn't yet shared it with me. The queryScopedSelector*() methods have misleading names - they don't match the definition of scope. It would be ridiculous to stick with those names if there are no implementations already out there. Do you have a better alternative suggestion? Similarly, the :scope pseudo-class has a misleading name. I've tried various alternative names, like :context, :reference, etc., but so far scope seems to be the least objectionable. But all things considered, I don't think :scope is a particularly bad name, since it's name somewhat describes it's purpose and relates it to its utility in scoped stylesheets. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Publishing Selectors API Level 2 as an FPWD?
Hi, Now that Selectors API Level 1 is published and basically all but finalised (just waiting for some implementations to be officially released before taking it to REC), can we publish Selectors API Level 2 as an FPWD? It would be useful to have it more widely reviewed, especially since Mozilla and WebKit have begun their implementation of matchesSelector, which is defined in it. The editor's draft is here. http://dev.w3.org/2006/webapi/selectors-api2/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] querySelector with namespace
Robin Berjon wrote: On Nov 26, 2009, at 15:07 , Lachlan Hunt wrote: Jonathan Watt wrote: Nevertheless, that doesn't mean that Web content shouldn't be able to process XML that uses xml:id using script and present the processed information to the user using content and semantics that *does* belong on the Web. Anyway, please also note that xml:id was just the example that drew my attention to this defficency in querySelector. It's an example, nothing more. The deficiency is my focus here. I really do not understand what use case you are trying to address. It appears that you are trying to find a solution to a problem that does not exist. That's because you're not reading what Jonathan has been saying. He said xml:id was just the example that drew his attention to the fact that the selectors API can't do namespaces. Yes, I know what he said. The point is that since he agrees that xml:id can't be used in practice on the web, and because even if it could, the ID selector would be good enough, it's not really a compelling, real-world use case for *why* namespace resolution is needed. And other than xml:id, he didn't clearly describe any other use cases at all. He points out, rather correctly, that there is no reason that Web content shouldn't be able to process XML and present the processed information to the user. The question is not and should not be about proving why it shouldn't be able to process XML with namespaces. The question is about why is it worth spending any more time, money and effort than we already have developing a solution for namespace prefix resolution? That is the question that namespace proponents have continually failed to address, and is why I have so far not deemed the issue worthy of significantly more of my time. The lack of namespace resolution in selectors is extremely annoying because it means that one has to switch between selectors (if only for classes support) and the XPath APIs for namespace support whenever one tries to do, you know, one of those real-world things where you have to aggregate data from multiple sources that might not be talking to one another. Please clearly explain what one of those real-world things are, where selectors without namespaces is inadequate. In fact, if you could show some real world examples of where sites are switching from selectors api to xpath for the namespace support, or using some other work around, that would go a long way towards understanding what the use cases are, and what problems really need to be solved, as well as help in determining whether or not the problems are significant enough to be worth addressing. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] querySelector with namespace
Robin Berjon wrote: There are quite a few services out there that return XML — it would be disingenuous to pretend otherwise. The addition of x-site requests to the stack makes these even more available. XHR supports XML natively, including namespace. Selectors support namespaces natively. Implementations already support that — exposing it at the API level is hardly a massive cost. So apart from saying that all of these are wrong, or saying that XML, XHR, Selectors aren't part of the web stack I can hardly see where your argument is going. No-one is disputing the fact that those tools exist and that they could be used for XML with namespaces. But are those tools being used in ways that utilise namespaces in useful ways, such that having them exposed at the selector API level would be either useful or even necessary? How about we take a look at some public website APIs using XML that could be suitable for use in cross site requests, and see which, if any, could possibly benefit from supporting prefixes in this API? Twitter: http://apiwiki.twitter.com/Twitter-API-Documentation Does not use namespaces at all, would not benefit from it being added to this API. Flickr: http://www.flickr.com/services/api/ Again, does not use namespaces at all. Validator.nu: http://wiki.whatwg.org/wiki/Validator.nu_Web_Service_Interface http://wiki.whatwg.org/wiki/Validator.nu_XML_Output This does use namespaces in the XML version of it's API. It nests fragments of the XHTML markup within the message and extract elements. These tag names don't clash with any in XHTML, and so they can be selected without bothering about namespaces, or by using a selector like messageserrorelaboration To select any of the XHTML itself, it's easy enough to use a selector like: errorelaboration div or infomessage code The source element does clash with the source element in HTML5, but it can be easily and unambiguously selected using messagessource. So, even if a script opted for the XML output, there is no clear dependency on using namespaced selectors here. Besides, all of those APIs mentioned also offer JSON output, which is much more optimised for use in JavaScript environments where cross site requests will be most common. So what other sorts of APIs do you have in mind which would greatly benefit from namespace support in selectors API? It would help if you could find some other APIs and illustrate with some real world sites that use them, where namespace-supporting APIs are utilised for good reasons on the client side. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: Selectors CR criteria
Sean Hogan wrote: What is the reason for the native implementation requirement? Is it W3C policy? There's a couple of reasons for this. The main reason being that JavaScript libraries are not limited by the same compatibility constraints as a browser, and so something that could be implemented in a JavaScript library without any problems may prove to have backwards compatibility issues with some legacy sites and affect a browser's ability to implement it. Basically, in this sense, a JS library is effectively a walled garden implementation where it's only used on sites that are explicitly built for it. So allowing such implementations to count effectively undermines the whole purpose of the implementation requirement, which is there to help demonstrate that the spec works in practice. The other reason is that it's not always technically possible for a JS library to implement all the required functionality due to the limitations of the DOM, or at least some implementations of it. For example, it's not possible in IE to add the methods to the prototypes for the Document, Element or DocumentFragment nodes. Also, in practice, implementations like in JQuery don't actually try to implement the methods themselves. They just implement somewhat compatible functionality and expose it on their own objects (e.g. $(divp); instead of document.querySelector(divp);). -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] querySelector with namespace
Jonathan Watt wrote: During a discussion about xml:id I was about to make the throw away comment that you could use querySelector to easily work around lack of support for xml:id, but on checking it turns out that's not the case. querySelector, it seems, cannot be used to select on a specific namespace, since you can only use namespace prefixes in selectors, and querySelector does not resolve prefixes. What is the use case for xml:id on the web? Maybe the working group could consider adding some sort of non-prefix namespace support to selectors for the sake of querySelector/querySelectorsAll, something like: [url(http://www.w3.org/XML/1998/namespace;)|id=foo] Your proposal would require modifying the syntax of Selectors, which is out of scope for this working group. As for the issue of resolving namespace prefixes, the previous attempt at including them in the API proved to be a very difficult, time consuming and costly effort that failed to reveal substantial use cases, nor find a viable solution. As such, my current position is that there has been insufficient justification provided for spending such significant time and effort addressing this issue. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: CfC - publish Selectors API as CR
Maciej Stachowiak wrote: The proposed exit criteria are in a separate thread, but essentially are: For a set of tests based on HTML, CSS 2.1 selectors and this spec, there are two implementations that pass every test interoperably, and do not fail any additional tests based on misimplementing this specification (i.e. failures based on not supporting a technology used only in the additional tests, such as MathML, will not be taken into account). Request for clarification. Does this require: A) There must be two implementations, each of which passes every test (i.e. the same two implementations pass all the tests); or B) For each test, there are two implementations that pass it (but not necessarily the same two for every test). It reads like (A), but I have seen similar wording interpreted as (B) in the context of other specs... The intention in the original exit criteria proposal [1] was for there to be at least two complete implementations, each passing 100% of the baseline tests. I can make this clearer in the exit criteria as follows: --- There must be at least two complete, independent implementations, each of which must pass 100% of the baseline testsuite and should pass additional tests, dependent on the following conditions: * The implementations must be native implementations in shipping products. (JavaScript library implementations don't count). * The baseline testsuite comprises tests that check for conformance to all requirements in the API using only HTML and Selectors defined in CSS 2.1. * Tests using Selectors introduced in Selectors Level 3, or XHTML+SVG, are considered to be additional tests. * An additional test may be marked as N/A for an implementation if: - The test uses a selector that the implementation does not support - The test uses XHTML+SVG that the implementation does not support * Implementations are not required to pass all additional tests, however no failures must be caused by an incorrect implementation of the API itself. Failures of additional tests caused only by an incorrect implementation of Selectors do not count. --- The current state of implementations is as follows: Minefield: Baseline Tests: HTML/CSS2.1:PASS Additional Tests: HTML/CSS3: PASS Additional Tests: XHTML+SVG/CSS3: PASS Opera gogi (Internal build) Baseline Tests: HTML/CSS2.1:PASS Additional Tests: HTML/CSS3: FAIL 4 (non-API bugs) Additional Tests: XHTML+SVG/CSS3: FAIL 22 (non-API bugs) WebKit: Baseline Tests: HTML/CSS2.1:FAIL 16 (API bug) Additional Tests: HTML/CSS3: FAIL 16 Additional Tests: XHTML+SVG/CSS3: FAIL 16 IE8: Baseline Tests: HTML/CSS2.1:FAIL 252 (API bugs) Additional Tests: HTML/CSS3: N/A Additional Tests: XHTML+SVG/CSS3: N/A BlackBerry 9700 browser: (Kartikaya Gupta from RIM e-mailed me off list about this to tell me, I'm unable to verify these results myself without access to the device.) Baseline Tests: HTML/CSS2.1:PASS Additional Tests: HTML/CSS3: PASS Additional Tests: XHTML+SVG/CSS3: PASS With Minefield and BlackBerry, we have two complete implementations passing everything. Opera's results also meet the above criteria, so that gives us 3 implementations. [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1221.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] querySelector with namespace
Jonathan Watt wrote: On 2009-11-26 12:33 PM, Henri Sivonen wrote: On Nov 26, 2009, at 13:18, Jonathan Watt wrote: During a discussion about xml:id I was about to make the throw away comment that you could use querySelector to easily work around lack of support for xml:id, but on checking it turns out that's not the case. querySelector, it seems, cannot be used to select on a specific namespace, since you can only use namespace prefixes in selectors, and querySelector does not resolve prefixes. Isn't the easiest solution not to support xml:id on the Web? It's not supported in Gecko, WebKit or Trident. What's the upside of adding it? Please note my use of the phrase work around. Nowhere in my email did I suggest supporting xml:id on the Web. Nevertheless, that doesn't mean that Web content shouldn't be able to process XML that uses xml:id using script and present the processed information to the user using content and semantics that *does* belong on the Web. Anyway, please also note that xml:id was just the example that drew my attention to this defficency in querySelector. It's an example, nothing more. The deficiency is my focus here. I really do not understand what use case you are trying to address. It appears that you are trying to find a solution to a problem that does not exist. Why does it matter that the API can't select xml:id using a selector involving namespaces, especially given that xml:id is not used on the web, and even if it was, the ID selector would work fine? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: CfC - publish Selectors API as CR
Lachlan Hunt wrote: There must be at least two complete, independent implementations, each of which must pass 100% of the baseline testsuite and should pass additional tests, dependent on the following conditions: ... The current state of implementations is as follows: Minefield: Baseline Tests: HTML/CSS2.1: PASS Additional Tests: HTML/CSS3: PASS Additional Tests: XHTML+SVG/CSS3: PASS Opera gogi (Internal build) Baseline Tests: HTML/CSS2.1: PASS Additional Tests: HTML/CSS3: FAIL 4 (non-API bugs) Additional Tests: XHTML+SVG/CSS3: FAIL 22 (non-API bugs) ... With Minefield and BlackBerry, we have two complete implementations passing everything. Opera's results also meet the above criteria, so that gives us 3 implementations. Actually, correction. Minefield and Opera don't meet the condition if we keep the shipping requirement in the exit criteria. But as soon as either of those builds make it into release products, we'll be good to go. Alternatively, we could just say public development builds are good enough, and Minefield would count, but I don't see any problem with just waiting. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: CfC - publish Selectors API as CR
Boris Zbarsky wrote: On 11/26/09 9:58 AM, Lachlan Hunt wrote: Actually, correction. Minefield and Opera don't meet the condition if we keep the shipping requirement in the exit criteria. Which imo we should. I don't think we want to be opening up that loophole. The Gecko 1.9.2 branch builds have the null/undefined issues, right? If that's the branch that's going into Firefox 3.6, yes. Personally, I added the shipping requirement to the exit criteria when I revised it earlier today for basically the same reasons you outlined in your other e-mail, so I agree we should keep the requirement. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Test Suite Progress
Lachlan Hunt wrote: I have now split the test suite up into 3 files, similar to how I prevoiusly described [1]: 1. Baseline Tests: HTML with CSS Level 2.1 Selectors. 2. Additional Tests: HTML with Selectors Level 3. 3. Additional Tests: XHTML+SVG with Selectors Level 3. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ More progress has now been made, and each of those test files have been updated and all bugs I'm aware of have been fixed. I've also begun to add tests for the namespace selector syntax [2] to the second set, but they are currently a work in progress and are not functioning properly. If anyone can figure out what I've done wrong, please let me know. Once these are written, they will also be incorporated into the third set. I managed to find a simple solution to this bug adding HTML elements as descendants of the non-namespaced elements, and made those the target of the selector instead. This allows the .style property to be checked by the script to make sure the color is green. The third set is an XHTML version of the tests which incorporates the tests that Erik had submitted [3]. I haven't verified that all these tests are functioning properly, I simply applied the patch from Erik without modification. I fixed a few bugs in bugs in these tests and it now works properly. The Firefox trunk, Minefield, now passes 100% of all those tests, making it the first browser to do so. Finally, I still need to merge in the tests from Hixie [4]. [4] http://www.hixie.ch/tests/adhoc/dom/selectors/001.html I'm not sure whether or not I should incorporate any of those tests. I need to check which are not covered by the existing test suite. Those tests pass in Opera and Firefox, but WebKit has 2 failures relating to NodeLists (tests 011 and 082). The bug is that webkit exposes the IDs of elements in the list as properties on the node list, such that nodelist.elementid returns an element with that ID, if it exists. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: CfC - publish Selectors API as CR
Charles McCathieNevile wrote: Hi folks, this is a Call for consensus to request publishing the Selectors API draft at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=iso-8859-1 as a Candidate Recommendation (assuming Lachy fixes the apparent encoding errors, the incorrect URIs and so on as editorial corrections). The encoding errors are caused because you're overriding the encoding with the content-type parameter in the query string. Just change that to UTF-8 and it'll work. http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?rev=1.101content-type=text/html;%20charset=UTF-8 I'll make all the necessary editorial changes to get it ready for CR when I find out what the publication date will be. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Selectors API 2 Status
Hi, Since we didn't get much time to discuss selectors api 2 during TPAC, this is an overview of the status, and a rough idea of how much work needs to be done. Please refer to the draft spec [1] and the issue list for features being added [2]. The spec has a proposal to address a number of use cases, based on feature requests that I summarised previously [3]. In particular, matchesSelector which has been partially implemented by WebKit and Mozilla already, and the :scope selector which addresses several use cases like node list filtering, collective querying, etc. There is also the queryScopedSelector() method which does some magic selector processing and makes things slightly easier than using an explicit :scope selector in some cases. This method is somewhat controversial, and it's not clear whether or not we should keep it, or whether we should just require authors to either explicitly use :scope or have JS libraries insert it. I believe, the parts of the spec defining those features are ready for FPWD. However, John Resig has told me that he has an alternative proposal, but has not yet sent me any details. Although, I believe we could proceed with FPWD now, and evaluate John's proposals if and when he sends them. The major issue yet to be dealt with is namespace resolution. This is the one that will take a very significant amount of time. This will require first evaluating the use cases and reaching a conclusion about whether or not it's even needed, and then if it is, finding a solution that solves the problems identified without suffering from the design flaws of the previous proposals. But I'd really like to avoid having this issue get in the way of addressing the other more pressing issues, as much as it did during the development of v1. Because of this, it is not something I'm particularly interested in adding to the spec myself at this stage, but If the group believes it's worthwile to be worked on, I'd be happy for some other editor to draft a proposal somewhat independently from the rest of the spec. [1] http://dev.w3.org/2006/webapi/selectors-api2/ [2] http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Selectors%20API [3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/1198.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Summary of Feature Requests for v2
Garrett Smith wrote: On Thu, Sep 24, 2009 at 1:28 AM, Lachlan Huntlachlan.h...@lachy.id.au wrote: And overload the querySelector() and querySelectorAll() methods to also accept a Selector object as the selector parameter. createSelector would allow the browser to parse and compile the selector and store it, much like createExpression does in DOM 3 XPath. If a contextElement is provided, then that element is defined as the Scope Element that matches the :scope pseudo-class. If impliedScope is set to false, the the browser treats it as an ordinary selector. If it's set to true, then it's treated as an implicitly scoped selector that needs to be pre-parsed into a valid selector and imply the presence of :scope (like em,strong). Why not use the selector text for the scope? I already did that 2 days ago when I dropped createSelector() and found a way for it to work with the descendant selector. The spec now defines that if the selector starts with either a combinator (, + or ~), or an exclamation point, then it's a scoped selector, and the processing requirements are adjusted accordingly. I also attempted to define the processing requirements to interpret a selector like em as being equivalent to :referenceem. I also defined the :reference pseudo class in the spec (formerly known as :scope in previous discussions) to match the contextual reference elements. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Scoped Selectors
Boris Zbarsky wrote:
On 9/26/09 4:36 PM, Lachlan Hunt wrote:
A scoped selector string is a string that begins with an exclamation
point followed by a the remainder of the selector.
This assumes that '!' will never be allowed at the beginning of a CSS
selector, right?
It does, but the workaround would be to insert an extra space at the
beginning.
I'd be willing to pick an alternative character to avoid any possible
clash. Perhaps a comma instead, like ,div div, which can never be
used at the beginning of a conforming group of selectors.
I'm also considering adjusting the idea it so that it will work when the
string simply begins with any combinator ('+', '~', or ''), but we
still need something to use in place of the descendant combinator as the
space won't have the desired effect.
Have you run this by the CSS working group?
Not yet, but will do so after I find out from this group if the
technique is viable.
e.g. The selector em, strong supported by JS libraries can simply be
prefixed with a !, like !em, strong and the implementation will be
able to process it to become :scopeem, :scopestrong. Of course, it
will also work with the other combinators.
That processing still needs to be defined, right?
Yes. It would be useful to get feedback from implementers about how I
should define this.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [selectors-api] Scoped Selectors
, the ! will trigger a syntax error and allow JS libraries to fallback to their custom processing. The following examples illustrate how this API can be used to address the use cases. Assume the variable elm refers to a single element and and elms refers to a collection of elements, such as an array or nodelist. Use Case: Select elements based on their relationship to one specific element. i.e. Given an Element elm, be able to select child, grandchild or sibling elements. In JQuery: $(em, strong, elm); $(div div, elm); $(+p, elm) or the equivalents using $(elm).find(...); To do either of these in Selectors API, use: // Equivalent to :scopeem, :scopestrong. Use either: document.querySelectorAll(!em, strong, elm); elm.querySelectorAll(!em, strong); // Equivalent to :scope div div. Use either: document.querySelectorAll(!div div, elm); elm.querySelectorAll(!div div); // Equivalent to :scope+p. Use either: document.querySelectorAll(!+p, elm); elm.querySelectorAll(!+p); Use Case: Select elements based on their relationship to elements in a collection. i.e. Given a collection of elements elms, be able to select child or grandchild elements, or sibling elements, of each element in that collection. In JQuery: $(em, strong, elms); $(div div, elms); $(+p, elms) This effectively works the same as the previous use case. Just create the selectors in the same way, and pass the elms collection to querySelectorAll(), as in: document.querySelectorAll(!+p, elms); Use Case: Given a collection of elements, find a subset that meets specific conditions. e.g. Given an array of elements elms, select only those that have a specific class name. For instance, a document contains several input elements, like: input type=text name=addr-line1 class=required input type=text name=addr-line2 input type=text name=addr-suburb class=required input type=text name=addr-country In JQuery: var elms = $(input); // do something with elms. // Now select only the required controls for additional processing: var filterdList = elms.filter(.required); document.querySelectorAll(.required:scope, elms) (There's currently no shorthand syntax that can be used by JS libraries to have this generated automatically. It might be worth defining one analogous to scoped selector strings.) The one limitation of the above is that if the elms collection contained nodes from both within the document and disconnected elements, only matching elements within the document would be selected. (The results would be similar, if this was done on a DocumentFragment or disconnected Element node). So it's not quite identical to running the query on each individual element and merging the results. But it's not clear whether or not such a use case is significant. It seems more natural to want to restrict the results to those within the same tree. See the current editors draft for more details. http://dev.w3.org/2006/webapi/selectors-api2/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Scoped Selectors
Sean Hogan wrote:
Here's a proposal.
querySelector*(selector, context) // allows selectors with :scope
pseudo-class
queryScopedSelector*(selector, context) // allows selectors with implied
:scope
matchesSelector(selector, context) // allows selectors with :scope
pseudo-class
Yes, this is effectively the same as option #2 that I described, except
you haven't provided a way to support implied scope there.
To check if the :scope pseudo-class is available, use:
try { document.body.matchesSelector(:scope, document.body); }
catch (error) { /* not supported */ }
I'm not sure that relying on exceptions for feature testing is an ideal
way to provide that functionality.
Now, querySelector*() can't accept selectors with implied :scope because
while em is unambiguously :scope em, p em would become
ambiguous. (is it p em or :scope p em)
So we need a new method, such as queryScopedSelector*().
Well, we at least need some way to tell the implementation to
pre-process the selector to imply the presence of :scope.
queryScopedSelector*() would do this, as would providing an explicit
pre-processing step, the result of which can be passed to the
querySelector*() methods.
element.querySelector*() limits selection to descendants of elements,
and element.queryScopedSelector*() should be consistent.
If element is the scope then element.queryScopedSelector*(~p) will
return no elements.
If we want to support sibling queries then we need to provide a scope
explicitly, so:
element.parentNode.queryScopedSelector*(~p, element);
Notes:
1. I don't think browsers should provide queryScopedSelector*()
This seems contradictory. You seemed to be proposing that we use
queryScopedSelector, and now you're saying we shouldn't. Personally, I
agree that we shouldn't. It's my least favourite solution of them all.
2. I think :context is a better name than :scope
Yeah, the name of :scope is a complicated issue. :context isn't ideal
either. It would be slightly confusing because selectors API defines
the term context node as being the node upon which the method is being
invoked. Maybe something like :ref or :reference might work.
3. If the context argument of these methods could be an element or a
NodeList it might satisfy some of the other feature requests.
Yes, the reference elements parameter will accept either a single
element, Array or NodeList.
I have checked in a new draft containing my first attempt at supporting
scoped selectors, with support for both :scope (or whatever it gets
called) and implied scope selectors. I've opted for a combination of
options 1 and 2 that I previously described, using the createSelector()
and SelectorExpression object for being able to represent implied scoped
selectors easily, and optional refNodes parameters on querySelector*()
and matchesSelector() methods for supplying contextual reference
elements (that match :scope).
Basically, for the simple case, it works as illustrated in these examples:
elm.querySelector(:scopep);
document.querySelectorAll(:scopep, elm);
document.querySelectorAll(:scopep, [elm1, elm2]);
To provide the functionality of JS libraries supporting implied scope
selectors, you first create a SelectorExpression object like this:
document.createSelector(em,strong, true);
That object can then be passed to either the querySelector*() or
matchesSelector() methods.
The effect of this is basically that JavaScript libraries can mostly use
document.createSelector(str, true) as a direct replacement their own
custom selector parsing libraries (except for the cases where they're
using custom pseudo-classes not supported by the browser)
One possible modification I'm considering is introducing a separate
factory method for creating implied scope selectors:
createScopedSelector(selector); rather than using a boolean parameter.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [selectors-api] Summary of Feature Requests for v2
Sean Hogan wrote:
I think a couple of those features are pretty low priority:
- I don't see the point of collective queries on NodeLists.
Are there any references for the proposal?
Otherwise I can't think of any useful queries that can't already be
achieved with a single querySelectorAll().
It was discussed a couple of days ago in IRC. It's based on the
functionality provided and needed by javascript libraries.
Garrett Smith wrote:
Lachlan Hunt wrote:
div2.matchesSelector(:scope~div, div1);
The matching seems backwards. Should be on the matcher, instead of the
element? I don't see the role of the element being something that does
matching. The matching should be something left to some sort of a
Matcher.
A function to get an actual Selector object would allow the program to
creating a cached matcher.
var selector = QuerySelector.create(div.panel);
var isPanel = selector.matches(event.target);
That's an interesting concept. We could perhaps define something like this:
Interface DocumentSelector {
Selector createSelector(DOMString selector, [Element scopeElement,
[boolean impliedScope]]);
}
Interface Selector {
boolean matches(Node element);
}
And overload the querySelector() and querySelectorAll() methods to also
accept a Selector object as the selector parameter.
createSelector would allow the browser to parse and compile the selector
and store it, much like createExpression does in DOM 3 XPath. If a
contextElement is provided, then that element is defined as the Scope
Element that matches the :scope pseudo-class. If impliedScope is set to
false, the the browser treats it as an ordinary selector. If it's set
to true, then it's treated as an implicitly scoped selector that needs
to be pre-parsed into a valid selector and imply the presence of :scope
(like em, strong).
A possible extension to consider would be to also allow scopeElement to
be specified as an array or NodeList of elements, such that :scope will
match any of the elements in the elements in the array, instead of
limiting it to just one.
Scripts can then do this:
var selector = document.createSelector(em,strong, elm, true);
Or this:
var selector = document.createSelector(h1+:scopea, [elm1, elm2,
elm3], false);
And then pass that selector to querySelector*() like
document.querySelectorAll(selector)
And matchesSelector is handled like this:
document.createSelector(input[type=checkbox]).matches(evt.target);
John Resig wrote:
Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists:
Neither of these are useful, as is, to libraries. What is actually useful is
the ability to run these against an array (or array-like collection) of DOM
nodes.
I believe this would be handled using the Array.filter() method, with a
callback that checks if the selector matches the element, as Jonas
pointed out:
filteredArray = myArrayOfNodes.filter(function(node) { return
node.matchesSelector(someselector); });
(That could also work with the above Selector.matches() proposal)
If I can do:
document.querySelectorAll.call([document.getElementById(node1),
document.getElementById(node2)], div span); then yes, this proposal is
useful. Rarely do libraries store raw NodeLists (they need to be converted
into an array or array-like collection first).
So this means that defining the API directly on NodeLists wouldn't
handle the use cases dealing with arrays of elements, so the
NodeList.querySelectorAll() idea is out.
Perhaps on the Selector interface described above, we could also define:
Interface Selector {
boolean matches(Node element);
NodeList querySelector(DOMArray nodes)
NodeList querySelectorAll(DOMArray nodes)
}
(where nodes either accepts an Array or a NodeList containing a
collection of Document, Element or DocumentFragment nodes)
Then when these methods are run, they iteratively run querySelector() or
querySelectorAll() on each of the nodes in the collection, using the
selector and then return the result as a NodeList containing the union
of unique elemenets in document order.
e.g.
var selector = document.createSelector(input);
selector.querySelectorAll([elm1, elm2, elm3]);
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [selectors-api] Summary of Feature Requests for v2
Lachlan Hunt wrote: Sean Hogan wrote: I think a couple of those features are pretty low priority: - I don't see the point of collective queries on NodeLists. Are there any references for the proposal? Otherwise I can't think of any useful queries that can't already be achieved with a single querySelectorAll(). It was discussed a couple of days ago in IRC. It's based on the functionality provided and needed by javascript libraries. Sorry, I forgot to provide the link. The relevant discussion is spread out quite a bit throughout this log, beginning here. http://krijnhoetmer.nl/irc-logs/whatwg/20090922#l- I've highlighted the relevant parts. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Summary of Feature Requests for v2
Garrett Smith wrote: QuerySelector could be extended to have properties: readonly attribute boolean valid StaticNodeList match(in HTMLElement contextNode) What's the valid property for? It seems redundant. If the selector isn't valid, then the factory method should throw an error when it tries to create it. Otherwise, it will be valid. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Summary of Feature Requests for v2
John Resig wrote:
Filtering NodeLists/StaticNodeLists, Queries on NodeLists/StaticNodeLists:
Neither of these are useful, as is, to libraries.
I believe this would be handled using the Array.filter() method, with a
callback that checks if the selector matches the element, as Jonas pointed
out:
filteredArray = myArrayOfNodes.filter(function(node) { return
node.matchesSelector(someselector); });
(That could also work with the above Selector.matches() proposal)
Array.filter() will meet the need of filtering
NodeLists/StaticNodeLists/Arrays of Elements - sure - but it won't meet the
need of NodeList.querySelectorAll (especially if that works with an
array-like collection of DOM elements).
Right, but I'm dealing with that as an entirely separate issue, which I
disucssed later on in that email.
Basic filtering of nodelists is bug 5864, which I've resolved WONTFIX
for now because the functionality doesn't seem too desirable or beneficial.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864
The issue you're discussing is bug 7707, which is still open.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707
The problem is that when you have multiple collections of DOM elements and
you wish to reduce them to a single collection it ends up being a very
expensive task. The steps are as follows:
- The collections must be merged together into a single array of DOM
elements.
- The elements must be sorted to be in document order.
- Duplicate elements must be removed from the collection.
So the question is, at which point in the chain do you want to address
this issue? The options are:
A) Have specific selectors API feauture that allowed executing a
selector query on a whole collection of elements that returns a
single, sorted collection of unique elements.
B) A more generic API for being able to easily merge and sort
NodeLists/Arrays of elements.
Option A saves the step of having to run the queries on each individual
element manually and just returns a merged and sorted collection of
unique elements. But it's limited to running selector queries, rather
than any other getElementsBy*() method to obtain the results.
Option B is more generic in that it could potentially merge and sort any
set of NodeLists, and those NodeLists could be obtained by any method,
but would still require running the queries on each element individually
to obtain the the lists that then need to be merged.
Both options present an issue with sorting, since they could result in
lists that contain both connected and disconnected elements, and the
sort order for connected elements in relation to disconnected elements
would need to be defined.
Option B seems potentially harder to define and possibly implement,
especially if you want to be able to sort merge NodeList objects with
Array objects. Since Arrays aren't limited to just containing DOM
Nodes, the issue of what to do with other types objects and how to sort
them along with the Nodes is complicated.
It would be great to have a separate, standalone, function that handles
these merge/sort/unique operations for collections of DOM elements
(especially if they're disconnected from the document!).
The proposal from my previous mail falls into Option A. Would it
address this issue adequately? Specifically, defining
document.createSelector() and a Selector interface that allows running a
query like this:
var elements = [...] // Some Array (or NodeList) of Elements
var selector = document.createSelector(em, strong);
var list = selector.querySelectorAll(elements);
This is equivalent to iterating over the elements array, running
elements[i].querySelectorAll(em, strong) on each, and then
merging/sorting all of the results into a single collection.
If there was a merge/sort/unique method it would drop the need for having a
NodeList/Array.querySelectorAll.
Whether we should go for the extra complexity required for this really
depends on the use case you're trying to address. Do you just need to
merge NodeLists that are all obtained via querySelector methods, or do
you need to merge any random NodeLists or Arrays that could be obtained
via querySelector*() or getElementsBy*(), or wherever else.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [selectors-api] Summary of Feature Requests for v2
Sean Hogan wrote: http://krijnhoetmer.nl/irc-logs/whatwg/20090922#l- I couldn't see where it was needed, only that it was possible in jQuery. I still can't think of any NodeLists that this could usefully be applied to that couldn't be achieved with a single querySelectorAll(). At least until we can create arbitrary NodeLists. It would simplify the issues that John described in his last e-mail, but the exact use cases aren't entirely clear which is making finding and determining the most appropriate solution difficult. I'm hoping John can answer this question. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Summary of Feature Requests for v2
John Resig wrote: So the question is, at which point in the chain do you want to address this issue? The options are: A) Have specific selectors API feauture that allowed executing a selector query on a whole collection of elements that returns a single, sorted collection of unique elements. B) A more generic API for being able to easily merge and sort NodeLists/Arrays of elements. Option A saves the step of having to run the queries on each individual element manually and just returns a merged and sorted collection of unique elements. But it's limited to running selector queries, rather than any other getElementsBy*() method to obtain the results. Option B is more generic in that it could potentially merge and sort any set of NodeLists, and those NodeLists could be obtained by any method, but would still require running the queries on each element individually to obtain the the lists that then need to be merged. B is a subset of A. You need B in order to implement A. Not quite. It depends what's being done and which steps need to be performed and how. AIUI, there are 3 major steps involved here. 1. Obtain a collection of Elements. This could be in one or more Arrays and/or NodeLists, depending on th. 2. Iteratively execute a selector query on all elements in the collection, saving the results from each. 3. Merge and sort all elements into a single NodeList, removing duplicates. In order to understand which of those steps need to be optimised by the browser with new APIs, it would help if you could explain some typical tasks, or use cases, that would need to perform any or all of those steps. In particular, what type of task would lead to there being more than one Array and/or NodeList to be used as input to step 2? What type of task would require executing the same selector query over a whole collection of elements? And what task would require the results of those to be merged into a single list? It would be great to have a separate, standalone, function that handles these merge/sort/unique operations for collections of DOM elements (especially if they're disconnected from the document!). The proposal from my previous mail falls into Option A. Would it address this issue adequately? Specifically, defining document.createSelector() and a Selector interface that allows running a query like this: var elements = [...] // Some Array (or NodeList) of Elements var selector = document.createSelector(em, strong); var list = selector.querySelectorAll(elements); This is equivalent to iterating over the elements array, running elements[i].querySelectorAll(em, strong) on each, and then merging/sorting all of the results into a single collection. Not a huge fan of that - it seems really backwards. Could you elaborate? Another alternative would be to implement the merge/sort/unique method and have it return a NodeList (which would, then, have qSA). The collection of elements (step 1, above) input into the qSA step (step 2) wouldn't need to be a sorted list. Technically, it doesn't even necessarily have to be a merged list if the API allows multiple arrays and/or nodelists to be provided. It will have no effect on the result. The important point seems to be that a collection of elements can be provided somehow and that the implementation can execute the query on each distinct element in that collection. How exactly that is done is just an API design issue. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[selectors-api] Matches Selector Interface
Hi, I have checked in the first copy of Selectors API Level 2, and have defined the matchesSelector() API. http://dev.w3.org/2006/webapi/selectors-api2/#matchtesting Everything else in the spec is currently identical to level 1. I had to do some minor shuffling around to make things easier to define, but otherwise, no normative changes. I also fixed up the IDL for the NodeSelector interface to match the current WebIDL requirements. I made these changes to the level 1 spec too. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[selectors-api] Scoped Selectors
Hi, I'm trying to find a suitable solution for the scoped selector issues, but figuring out what the most suitable API is proving challenging. *Use Cases* 1. JS libraries like JQuery and others, accept special selector strings beginning with combinators. e.g. em,+strong. These libraries behave as if there was a selector that matched the context node. e.g. In JQuery: $(+p, elm); This would select the p element that is a sibling of elm. 2. It would be useful to be able to check if an a given element matches a selector in relation to a specified reference element (:scope). For example, check if an event target is a sibling of a specific element, and if the parent element has a specifc class name set. e.g. Matches the selector: .foo:scope~input[type=text] This may be particularly useful for event delgation. 3. Obtain a collection of elements based on their relation to more than one specified reference elements. e.g. Query to the document to obtain elements matching :scope+span, where :scope is intended to match any of the elements in a specific collection. This would be simpler than iterating all of the nodes in the collection, running the query on each of them and then merging the results. *Problems* 1. Need a way to allow the browser to parse implicitly scoped selectors beginning with combinators and imply the presence of :scope before each in the group. 2. Need to allow :scope to be used within the selector strings, and specify one or more scope elements that will be matched by :scope. This needs to be useable with all of the querySelector(), querySelectorAll() and matchesSelector() methods, or others with equivalent functionality. 3. Ideally, there would be an easy, reliable way for scripts to test if the implementation supports scoped selectors (at least, implicitly scoped selectors. Those using :scope could only be discovered by capturing the SYNTAX_ERR exception) For legacy browsers that don't, they can fall back to their own selector engines. *Possible Solutions* 1. Define a Selector object that can be used to parse and store a selector, and which can handle pre-parsing the selector and specifying the scope elements upon creation. This selector object can then be passed anywhere that accepts a selector string. (This is basically part of the createSelector() and Selector interface proposal from earlier). 2. Add parameters to the querySelector(), querySelectorAll() and matchesSelector() methods for: a. Indicating whether the selectors parameter should be processed with an implied scope. b. Specifying one or more reference elements that would match :scope. 3. Create new scoped versions of the existing methods that accept one or more reference elements that would match the implied scope. Add an optional parameter to the existing querySelector*() methods that would Allow one or more reference elements to be specified to match the explicit use of :scope in the selector. Option 2 doesn't provide an easy way to detect browser support. Option 3 creates an additional queryScopedSelector*() and matchesScopedSelector() methods, but this could get quite verbose if we also add equivalent NS methods to handle the namespace issue, to both the scoped and non-scoped versions. This would create an unreasonable number of different methods that would make understanding the API quite complex. Option 1 is syntactically messy, and requires the creation of a new object just to handle a scoped selector, even if that selector is only used once. I'm not sure which alternative would be best, and I'm kind of hoping there's a 4th alternative I haven't thought of yet that can address the use cases easliy enough. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[selectors-api] Summary of Feature Requests for v2
Hi, I'm planning to look at beginning work on Selectors API v2 soon to add a number of requested features that didn't make it into the first version. This e-mail is a summary of what is being considered, and is intended to start discussion about which ones are really worth focussing on, and how to ensure they address the use cases appropriately. *Matches Selector* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5865 The suggestion is for being able to check if a given element matches a given selector. There is already similar functionality provided by JQuery and Mozilla have begun working on an implementation for it in Firefox. For the basic case, this is fairly trivial. The method just needs to take a selector and evaluate it against the element, and return true or false. But considering the proposed :scope pseudo-class that has been previously discussed here and in the CSS WG, it might also be nice to check if the element matches the selector in relation to a specified reference element. For example, given 2 elements, div1 and div2, you could check if div2 is a sibling of div1 like this: div2.matchesSelector(:scope~div, div1); In this case, the div1 would be the reference element that is matched by :scope. But we still need to determine how useful such functionality would be, and whether it's worth pursuing it in this next version. *Filtering NodeLists* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5864 The suggestion is for being able to take a NodeList, and filter the nodes to obtain a collection of just those that match a given selector. For example, being able to get a NodeList somehow, do something with it, and then filter it more to work with just a subset: e.g. var list = document.querySelctor(divp); // Do something with list, before obtaining the subset subset = list.filterSelector(.foo); ... We need to find and document the possible use cases for this feature. *Scoped Queries* http://www.w3.org/Bugs/Public/show_bug.cgi?id=5860 This has been discussed extensively in the past. Basically, the idea is that the selector would be evaluated in the scope of the element, in a way more compatible with how libraries like JQuery work. This slightly different from the :scope pseudo-class proposal, see bug for details. *Collective Queries on NodeLists* http://www.w3.org/Bugs/Public/show_bug.cgi?id=7707 The suggestion is to be able to run querySelector() and querySelectorAll() on NodeList, and have the result be the union of results in document order from running the method on each Element in the NodeList. e.g. list.querySelectorAll(p); Would be somewhat equivalent to running list[i].querySelectorAll(p); for on each element in the list, and then building an array with the union of distinct elements from all the results. I've been told that similar functionality for this already exists in JQuery. I believe the expectation is that both NodeList.querySelector() and .querySelectorAll() would work. The difference is that querySelector() on a NodeList would return a NodeList (unlike on Element which just returns a single element) containing the first matches from each node in the list. i.e. equivalent to running list[i].querySelector() on each node and then combining all results into an array. It also seems sensible to allow the new scoped methods to be used in an analogous way on NodeLists. *Namespace Prefix Resolution* http://www.w3.org/Bugs/Public/show_bug.cgi?id=6290 The most controversial issue of the lot. Need to clearly document the use cases and evaluate the problems being solved, and determine if it's really worth addressing in this version. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [selectors-api] Summary of Feature Requests for v2
Mike Wilson wrote:
My first priority would be Matches Selector, and see to that
it fulfills the needs for event delegation.
Is there any special functionality that would be needed to achieve this?
If I understand correctly, event delegation just needs to be able to
check whether the event target element matches a given selector. So it
would be something like:
if (evt.target.matchesSelector(.fooinput.bar)) {
...
}
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
[webdatabase] Minor Clarification Needed in Processing Model
Hi, In step 10 of the processing model, it states: Queue a task to invoke the error callback, if it is not null, with a newly constructed SQLError object that represents the last error to have occurred in this transaction. Rollback the transaction. Any still-pending statements in the transaction are discarded. Can you clarify this statement so that it's clearer that it's referring to the transaction's error callback, and not a statement error callback in executeSql. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[webdatabase] Transaction Locks
Hi, In the processing model [1], step 2 says: If an error occurred in the opening of the transaction (e.g. if the user agent failed to obtain an appropriate lock after an appropriate delay), jump to the last step. It's not clear if the spec requires the transaction to fail to open in the case that it can't yet obtain an appropriate lock, or whether the spec just allows that as an implementation decision. According to our developer, the way we've implemented it is that we will always create a new transaction and run the transaction callback, but the SQL statements themselves will be queued up and run whenever the lock becomes available. There is no timeout that will cause it to invoke the error callback. Is this acceptable, or should the transaction callback not be run while there is another lock in effect on the database? [1] http://dev.w3.org/html5/webdatabase/#processing-model -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[webdatabase] changeVersion should allow all callbacks to be optional
Hi, The spec currently requires the first 2 callbacks for the changeVersion method, while the 3rd is optional. The spec should make all of the callbacks optional so authors don't resort to specifying empty functions when they don't actually need to do anything with it. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[selectors-api] Test Suite Progress
Hi, I've made some progress with the test suite. I have now split the test suite up into 3 files, similar to how I prevoiusly described [1]: 1. Baseline Tests: HTML with CSS Level 2.1 Selectors. 2. Additional Tests: HTML with Selectors Level 3. 3. Additional Tests: XHTML+SVG with Selectors Level 3. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ The baseline tests in the first file are a subset of all the tests in the second. To create it, I basically removed any test using a selector introduced in Selectors 3 without modifying other tests. I've also begun to add tests for the namespace selector syntax [2] to the second set, but they are currently a work in progress and are not functioning properly. If anyone can figure out what I've done wrong, please let me know. Once these are written, they will also be incorporated into the third set. The third set is an XHTML version of the tests which incorporates the tests that Erik had submitted [3]. I haven't verified that all these tests are functioning properly, I simply applied the patch from Erik without modification. Finally, I still need to merge in the tests from Hixie [4]. If anyone has the time and motivation and would like to assist with incorporating/fixing these tests, please let me know. [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1221.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0713.html [3] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0788.html [4] http://www.hixie.ch/tests/adhoc/dom/selectors/001.html -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
