Annotation of 2006/webapi/selectors-api/Overview.html, revision 1.51
1.1 avankest 1: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
2:
1.11 avankest 3: <html lang=en-US>
1.20 lhunt 4: <head><meta content="text/html;charset=UTF-8" http-equiv=Content-Type>
5:
1.1 avankest 6: <title>Selectors API</title>
7:
8: <style type="text/css">
1.36 lhunt 9: pre.idl { border:solid thin; background:#eee; color:#000; padding:0.5em }
1.50 lhunt 10: pre.idl :link, pre.idl :visited { color:inherit; background:transparent }
1.20 lhunt 11:
1.36 lhunt 12: div.example { border-left:double; padding-left:1em }
13: dfn { font-style:normal; font-weight:bolder }
14: em.ct { font-style:normal; font-weight:normal; font-variant:small-caps }
15: p.note { margin-left:2em; color:green; font-style:italic; font-weight:bold }
16: p.note:before { content:"Note: " }
17: .issue { padding:.5em; border:solid red }
18: .issue:before { content:"Issue: " }
19: code { color:#FF4500; }
20: code :link, code :visited { color:inherit }
21: </style>
1.41 lhunt 22: <link href="http://www.w3.org/StyleSheets/TR/W3C-ED" rel=stylesheet
1.29 lhunt 23: type="text/css">
1.1 avankest 24:
25: <body>
1.11 avankest 26: <div class=head>
1.31 lhunt 27: <p><a href="http://www.w3.org/"><img alt=W3C height=48
28: src="http://www.w3.org/Icons/w3c_home" width=72></a></p>
1.1 avankest 29:
1.46 lhunt 30: <h1 id=title>Selectors API</h1>
1.12 avankest 31: <!-- "DOM Selectors" was not acceptable. "DOM Level 4 Selectors" and
1.36 lhunt 32: conforming to the DOM specification template (if there is such a thing) is
33: just silly so we got stuck with this weird name. -->
1.12 avankest 34:
1.50 lhunt 35: <h2 class="no-num no-toc" id=W3C-doctype>W3C Working Draft 10 May 2008</h2>
1.1 avankest 36:
37: <dl>
1.5 avankest 38: <dt>This Version:
1.1 avankest 39:
1.11 avankest 40: <dd><a
1.50 lhunt 41: href="http://www.w3.org/TR/2008/ED-selectors-api-20080510/">http://www.w3.org/TR/2008/ED-selectors-api-20080510/</a>
1.1 avankest 42:
1.5 avankest 43: <dt>Latest Version:
1.1 avankest 44:
45: <dd><a
46: href="http://www.w3.org/TR/selectors-api/">http://www.w3.org/TR/selectors-api/</a>
47:
1.12 avankest 48: <dt>Previous Versions:
49:
50: <dd><a
1.44 lhunt 51: href="http://www.w3.org/TR/2007/WD-selectors-api-20071221/">http://www.w3.org/TR/2007/WD-selectors-api-20071221/</a>
52:
53: <dd><a
1.31 lhunt 54: href="http://www.w3.org/TR/2007/WD-selectors-api-20071019/">http://www.w3.org/TR/2007/WD-selectors-api-20071019/</a>
1.29 lhunt 55:
56: <dd><a
1.12 avankest 57: href="http://www.w3.org/TR/2006/WD-selectors-api-20060926/">http://www.w3.org/TR/2006/WD-selectors-api-20060926/</a>
1.1 avankest 58:
59: <dd><a
60: href="http://www.w3.org/TR/2006/WD-selectors-api-20060525/">http://www.w3.org/TR/2006/WD-selectors-api-20060525/</a>
61:
1.20 lhunt 62: <dt>Editors:
63:
1.46 lhunt 64: <dd><a href="http://annevankesteren.nl/">Anne van Kesteren</a> (<a
65: href="http://www.opera.com/">Opera Software ASA</a>) <<a
66: href="mailto:annevk@opera.com">annevk@opera.com</a>>
67:
1.29 lhunt 68: <dd><a href="http://lachy.id.au/">Lachlan Hunt</a> (<a
69: href="http://www.opera.com/">Opera Software ASA</a>) <<a
1.20 lhunt 70: href="mailto:lachlan.hunt@lachy.id.au">lachlan.hunt@lachy.id.au</a>>
1.1 avankest 71: </dl>
72:
1.11 avankest 73: <p class=copyright><a
1.1 avankest 74: href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
1.44 lhunt 75: © 2006-2007 <a href="http://www.w3.org/"><acronym title="World Wide Web
76: Consortium">W3C</acronym></a><sup>®</sup> (<a
1.31 lhunt 77: href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute
78: of Technology">MIT</acronym></a>, <a
79: href="http://www.ercim.org/"><acronym title="European Research Consortium
80: for Informatics and Mathematics">ERCIM</acronym></a>, <a
81: href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
82: href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
83: <a
84: href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
85: and <a
86: href="http://www.w3.org/Consortium/Legal/copyright-documents">document
87: use</a> rules apply.</p>
1.33 lhunt 88: </div>
1.1 avankest 89:
90: <hr>
91:
1.11 avankest 92: <h2 class="no-num no-toc" id=abstract>Abstract</h2>
1.1 avankest 93:
1.23 lhunt 94: <p>Selectors, which are widely used in CSS, are patterns that match against
95: elements in a tree structure [<cite><a
1.24 lhunt 96: href="#ref-selectors">Selectors</a></cite>] [<cite><a
97: href="#ref-css21">CSS21</a></cite>]. The Selectors API specification
98: defines methods for retrieving <code>Element</code> nodes from the <abbr
1.23 lhunt 99: title="Document Object Model">DOM</abbr> by matching against a group of
100: selectors. It is often desirable to perform DOM operations on a specific
101: set of elements in a document. These methods simplify the process of
1.36 lhunt 102: acquiring specific elements, especially compared with the more verbose
1.23 lhunt 103: techniques defined and used in the past.
1.1 avankest 104:
1.11 avankest 105: <h2 class="no-num no-toc" id=sotd>Status of this Document</h2>
1.1 avankest 106:
107: <p><em>This section describes the status of this document at the time of
108: its publication. Other documents may supersede this document. A list of
109: current W3C publications and the latest revision of this technical report
110: can be found in the <a href="http://www.w3.org/TR/">W3C technical reports
111: index</a> at http://www.w3.org/TR/.</em>
112:
1.29 lhunt 113: <p>This is a Last Call Working Draft of "Selectors API". The W3C Membership
114: and other interested parties are invited to review the document and send
115: comments to <a href="mailto:public-webapi@w3.org">public-webapi@w3.org</a>
116: (<a href="http://lists.w3.org/Archives/Public/public-webapi/">public
117: archive</a>) with <kbd>[selectors-api]</kbd> in the subject, through 06
118: January 2008.
119:
120: <p><span class=notetoeditor>Web content and browser developers are
121: encouraged to review this draft. This draft is considered relatively
122: stable and is expected to progress to Candidate Recommendation after the
1.44 lhunt 123: review period.</span> The editor’s copy of this specification is <a
1.30 lhunt 124: href="http://dev.w3.org/2006/webapi/selectors-api/">available in W3C
125: CVS</a>. A detailed list of changes is also available <a
1.1 avankest 126: href="http://dev.w3.org/cvsweb/2006/webapi/selectors-api/">from the CVS
1.29 lhunt 127: server</a>.
1.1 avankest 128:
1.29 lhunt 129: <p>This document was developed by the <a
130: href="http://www.w3.org/2006/webapi">Web API Working Group</a>. The
131: Working Group expects to advance this Working Draft to Recommendation
132: Status.
133:
134: <p>Publication as a Working Draft does not imply endorsement by the W3C
135: Membership. This is a draft document and may be updated, replaced or
136: obsoleted by other documents at any time. It is inappropriate to cite this
137: document as other than work in progress.
1.1 avankest 138:
139: <p>This document was produced by a group operating under the <a
140: href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February
141: 2004 W3C Patent Policy</a>. W3C maintains a <a
142: href="http://www.w3.org/2004/01/pp-impl/38482/status"
1.11 avankest 143: rel=disclosure>public list of any patent disclosures</a> made in
1.1 avankest 144: connection with the deliverables of the group; that page also includes
145: instructions for disclosing a patent. An individual who has actual
146: knowledge of a patent which the individual believes contains <a
147: href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
1.31 lhunt 148: Claim(s)</a> must disclose the information in accordance with <a
1.1 avankest 149: href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
150: 6 of the W3C Patent Policy</a>.
151:
1.11 avankest 152: <h2 class="no-num no-toc" id=toc>Table of Contents</h2>
1.1 avankest 153: <!--begin-toc-->
154:
1.11 avankest 155: <ul class=toc>
156: <li><a href="#introduction"><span class=secno>1. </span>Introduction</a>
157: <ul class=toc>
1.36 lhunt 158: <li><a href="#examples"><span class=secno>1.1 </span>Examples</a>
1.49 lhunt 159: </ul>
1.1 avankest 160:
1.49 lhunt 161: <li><a href="#conformance"><span class=secno>2. </span>Conformance
162: Requirements</a>
163: <ul class=toc>
164: <li><a href="#terminology"><span class=secno>2.1 </span>Terminology and
165: Conventions</a>
166: </ul>
1.1 avankest 167:
1.49 lhunt 168: <li><a href="#interoperability"><span class=secno>3.
169: </span>Interoperability Considerations</a>
170: <ul class=toc>
171: <li><a href="#extensibility"><span class=secno>3.1
172: </span>Extensibility</a>
173: </ul>
174:
175: <li><a href="#security"><span class=secno>4. </span>Security
176: Considerations</a>
1.21 lhunt 177:
1.49 lhunt 178: <li><a href="#privacy"><span class=secno>5. </span>Privacy Considerations
179: </a>
1.1 avankest 180:
1.50 lhunt 181: <li><a href="#nodeselector"><span class=secno>6. </span>The
1.51 ! lhunt 182: <code>NodeSelector</code> Interface</a>
1.16 avankest 183: <ul class=toc>
1.50 lhunt 184: <li><a href="#resolving"><span class=secno>6.1 </span>Resolving
185: Namespaces</a>
1.51 ! lhunt 186: </ul>
1.50 lhunt 187:
1.51 ! lhunt 188: <li><a href="#nsresolver-interface"><span class=secno>7. </span>The
! 189: <code>NSResolver</code> Interface</a>
1.1 avankest 190:
1.11 avankest 191: <li class=no-num><a href="#references">References</a>
1.1 avankest 192:
1.11 avankest 193: <li class=no-num><a href="#acknowledgements">Acknowledgements</a>
1.1 avankest 194: </ul>
195: <!--end-toc-->
196:
1.11 avankest 197: <h2 id=introduction><span class=secno>1. </span>Introduction</h2>
1.1 avankest 198:
199: <p><em>This section is non-normative.</em>
200:
1.20 lhunt 201: <p>This specification introduces two methods that take a group of selectors
1.24 lhunt 202: (often simply referred to as a selector) as an argument and return the
1.20 lhunt 203: matching elements [<cite><a href="#ref-selectors">Selectors</a></cite>].
1.24 lhunt 204: With these methods, it is easier to match a set of <code>Element</code>
1.20 lhunt 205: nodes based on specific criteria. So instead of having to filter the
1.22 lhunt 206: result of a <code>getElementsByTagName()</code> call, authors can directly
1.44 lhunt 207: “filter” in the query.
1.10 avankest 208:
1.36 lhunt 209: <h3 id=examples><span class=secno>1.1 </span>Examples</h3>
1.1 avankest 210:
211: <p><em>This section is non-normative.</em>
212:
1.24 lhunt 213: <p>Some ECMAScript [<cite><a href="#ref-ecma262">ECMAScript</a></cite>]
214: examples:
1.1 avankest 215:
1.14 avankest 216: <div class=example>
1.41 lhunt 217: <p>This is an example table written in HTML 4.01.</p>
1.22 lhunt 218:
1.20 lhunt 219: <pre><table id="score">
220: <thead>
221: <tr>
222: <th>Test
223: <th>Result
224: <tfoot>
225: <tr>
226: <th>Average
227: <td>82%
228: <tbody>
229: <tr>
230: <td>A
231: <td>87%
232: <tr>
233: <td>B
234: <td>78%
235: <tr>
236: <td>C
237: <td>81%
238: </table></pre>
239:
240: <p>In order to obtain the cells containing the results in the table, which
241: might be done, for example, to plot the values on a graph, there are at
242: least two approaches that may be taken. Using only the APIs from DOM
243: Level 2, it requires a script like the following that iterates through
244: each <code>tr</code> within each <code>tbody</code> in the
245: <code>table</code> to find the second cell of each row.</p>
246:
247: <pre>var table = document.getElementById("score");
1.23 lhunt 248: var groups = table.tBodies;
249: var rows = null;
1.24 lhunt 250: var cells = [];
1.20 lhunt 251:
1.23 lhunt 252: for (var i = 0; i < groups.length; i++) {
253: rows = groups[i].rows;
254: for (var j = 0; j < rows.length; j++) {
255: cells.push(rows[j].cells[1]);
1.20 lhunt 256: }
1.36 lhunt 257: }</pre>
1.20 lhunt 258:
1.46 lhunt 259: <p>Alternatively, using the <code
260: title=document-selectallelements>querySelectorAll()</code> method, that
261: script becomes much more concise.</p>
1.20 lhunt 262:
1.36 lhunt 263: <pre>var cells = document.querySelectorAll("#score>tbody>tr>td:nth-of-type(2)");</pre>
1.41 lhunt 264:
265: <p>This script will also function correctly for a table written in XHTML
266: markup instead of HTML.</p>
1.20 lhunt 267: </div>
268:
1.49 lhunt 269: <h2 id=conformance><span class=secno>2. </span>Conformance Requirements</h2>
1.1 avankest 270:
1.21 lhunt 271: <p>All diagrams, examples and notes in this specification are
1.20 lhunt 272: non-normative, as are all sections explicitly marked non-normative.
273: Everything else in this specification is normative.
1.1 avankest 274:
1.23 lhunt 275: <p>The key words <em class=ct>must</em>, <em class=ct>should</em>, and <em
276: class=ct>may</em> in the normative parts of this document are to be
1.24 lhunt 277: interpreted as described in RFC 2119 [<cite><a
1.1 avankest 278: href="#ref-rfc2119">RFC2119</a></cite>].
279:
1.11 avankest 280: <p>The following conformance classes are defined (and considered) by this
281: specification:
1.1 avankest 282:
283: <dl>
1.22 lhunt 284: <dt><dfn id=conforming>conforming user agent</dfn>
1.1 avankest 285:
1.48 lhunt 286: <dd>A user agent that implements the <code><a
1.49 lhunt 287: href="#dom-document-selector">NodeSelector</a></code> and
1.48 lhunt 288: <code>NodeList</code> interfaces described in this specification and
289: conforms to all <em class=ct>must</em>-level criteria that apply to
290: implementations.
1.22 lhunt 291:
292: <dt><dfn id=conforming0>conforming namespace resolver</dfn>
293:
294: <dd>An object implementing the <code><a
295: href="#nsresolver">NSResolver</a></code> interface which conforms to all
1.36 lhunt 296: <em class=ct>must</em>-level criteria that apply to the <code><a
1.23 lhunt 297: href="#nsresolver">NSResolver</a></code> interface.
1.22 lhunt 298:
299: <dt><dfn id=conforming1>conforming application</dfn>
300:
301: <dd>An application that uses the interfaces defined in this specification
1.36 lhunt 302: and conforms to all <em class=ct>must</em>-level criteria that apply to
303: applications.
1.1 avankest 304: </dl>
305:
1.49 lhunt 306: <h3 id=terminology><span class=secno>2.1 </span>Terminology and Conventions</h3>
1.16 avankest 307:
1.23 lhunt 308: <p>The terminology used in this specification is that from Selectors
309: [<cite><a href="#ref-selectors">Selectors</a></cite>].
1.16 avankest 310:
1.23 lhunt 311: <p>Conformance requirements phrased as algorithms or specific steps may be
312: implemented in any manner, so long as the end result is equivalent. In
1.39 lhunt 313: doing so, implementations <em class=ct>may</em> assume that the
314: <code>lookupNamespaceURI()</code> method of the object implementing the
315: <code><a href="#nsresolver">NSResolver</a></code> interface (or ECMAScript
316: <code>Function</code> being used in place of such an object) returns
317: consistent results when invoked.
1.16 avankest 318:
1.23 lhunt 319: <p>The construction "<code>Foo</code> object", where <code>Foo</code> is
320: actually an interface, is sometimes used instead of the more accurate
1.24 lhunt 321: "object implementing the <code>Foo</code> interface".
1.23 lhunt 322:
1.46 lhunt 323: <p>The IDL used in this specification uses the syntax defined in Language
324: Bindings for DOM Specifications [<cite><a
325: href="#ref-bindings">Bindings</a></cite>].
326:
1.49 lhunt 327: <h2 id=interoperability><span class=secno>3. </span>Interoperability
328: Considerations</h2>
1.16 avankest 329:
1.23 lhunt 330: <p><em>This section is non-normative.</em>
331:
1.36 lhunt 332: <p>Since implementations may optimise the algorithms described in this
1.23 lhunt 333: specification, and because some may invoke the <code><a
334: href="#nsresolver">NSResolver</a></code> object more than others,
1.36 lhunt 335: interoperability concerns may arise if the <code><a
336: href="#nsresolver">NSResolver</a></code> object causes side effects or
337: returns inconsistent results each time it is invoked.
1.16 avankest 338:
1.19 avankest 339: <div class=example>
1.22 lhunt 340: <p>In the following example, the <code><a
341: href="#nsresolver">NSResolver</a></code> causes a side effect when
342: executed.</p>
343:
344: <pre>function resolver(prefix) {
1.21 lhunt 345: sideEffect();
1.24 lhunt 346: if (prefix == "test") {
347: return "http://example.org/test";
348: }
1.22 lhunt 349: }
350:
1.36 lhunt 351: var x = document.querySelectorAll("test|*:empty > test|p", resolver)</pre>
1.22 lhunt 352:
1.36 lhunt 353: <p>Some implementations may not need to <span>resolve the namespace
1.22 lhunt 354: prefix</span> in order to determine that the selector cannot match any
355: elements, in which case <code>sideEffect()</code> will not be invoked.</p>
356:
357: <p>The following example could return inconsistent results each time it is
358: invoked, depending on the order in which namespace prefixes are resolved
359: and the number of times the resolver is invoked to for the
360: <code>foo</code> prefix.</p>
361:
362: <pre>var i = 0;
363: function resolver(prefix) {
364:
365: var ns = ["http://example.org/foo",
366: "http://example.org/bar",
1.24 lhunt 367: "http://example.org/baz"];
1.22 lhunt 368: return ns[i++];
369: }
370:
1.41 lhunt 371: var x = document.querySelectorAll("foo|x, foo|y, bar|z", resolver);</pre>
1.22 lhunt 372:
373: <p>This could result in selecting <code>x</code>, <code>y</code> and
374: <code>z</code> elements from almost any combination of namespaces that
375: may be returned. The result is unpredictable and different results may
1.36 lhunt 376: occur in different implementations.</p>
1.19 avankest 377: </div>
378:
1.49 lhunt 379: <h3 id=extensibility><span class=secno>3.1 </span>Extensibility</h3>
1.5 avankest 380:
381: <p><em>This section is non-normative.</em>
382:
383: <p>Extensions of the APIs defined in this specification are <em>strongly
1.36 lhunt 384: discouraged</em>. Implementors, Working Groups and other interested
385: parties should discuss extensions on a relevant public forum, such as <a
1.5 avankest 386: href="mailto:public-webapi@w3.org">public-webapi@w3.org</a>.
387:
1.49 lhunt 388: <h2 id=security><span class=secno>4. </span>Security Considerations</h2>
1.11 avankest 389:
390: <p>It is expected that implementing this specification introduces no new
1.21 lhunt 391: security risks for users.
392:
1.36 lhunt 393: <p>Implementations <em class=ct>should</em> ensure they do not crash or
1.46 lhunt 394: behave erratically when facing when facing a misbehaving or hostile
395: <code><a href="#nsresolver">NSResolver</a></code> object. Since the
396: <code><a href="#nsresolver">NSResolver</a></code> object may be
397: implemented by application authors, its behaviour could be unpredictable.
398: Such behaviour could include:
1.21 lhunt 399:
400: <ul>
401: <li>Returning inconsistent results;
402:
403: <li>Hanging;
404:
405: <li>Changing the DOM during the operation.
406: </ul>
407:
1.49 lhunt 408: <h2 id=privacy><span class=secno>5. </span>Privacy Considerations</h2>
1.11 avankest 409:
1.20 lhunt 410: <p>History theft is a potential privacy issue because the
1.24 lhunt 411: <code>:visited</code> pseudo-class in Selectors [<cite><a
1.20 lhunt 412: href="#ref-selectors">Selectors</a></cite>] allows authors to query which
413: links have been visited.
414:
415: <p class=note>This is not a new problem, as it can already be exploited
416: using existing CSS and DOM APIs, such as <code>getComputedStyle()</code>
417: [<cite><a href="#ref-dom2style">DOM2Style</a></cite>].
418:
419: <div class=example>
1.36 lhunt 420: <p>In this example, <var>vlinks</var> will acquire a list of links that
421: the user has visited. The author can then obtain the URIs and potentially
1.20 lhunt 422: exploit this knowledge.</p>
423:
1.27 lhunt 424: <pre>var vlinks = document.querySelectorAll(":visited");
1.20 lhunt 425: for (var i = 0; i < vlinks.length; i++) {
426: doSomethingEvil(vlinks[i].href);
427: }</pre>
428: </div>
429:
430: <p>As <a href="http://www.w3.org/TR/css3-selectors/#link">defined in
1.24 lhunt 431: <cite>Selectors</cite></a> ([<cite><a
432: href="#ref-selectors">Selectors</a></cite>], section 6.6.1), user agents
1.47 lhunt 433: <em class=ct>may</em> treat all links as unvisited links. It is <em
434: class=ct>recommended</em> that implementations behave consistently with
435: other uses of Selectors supported by the user agent.
1.11 avankest 436:
1.51 ! lhunt 437: <h2 id=nodeselector><span class=secno>6. </span>The <code><a
! 438: href="#dom-document-selector">NodeSelector</a></code> Interface</h2>
1.16 avankest 439:
1.46 lhunt 440: <p>Objects implementing either the <code>Document</code>,
441: <code>DocumentFragment</code> or <code>Element</code> interfaces, as
1.36 lhunt 442: defined in DOM Level 3 Core, <em class=ct>must</em> also implement the
1.46 lhunt 443: <code><a href="#dom-document-selector">NodeSelector</a></code> interface.
444: [<cite><a href="#ref-dom3core">DOM3Core</a></cite>]
1.1 avankest 445:
1.46 lhunt 446: <pre class=idl>interface <dfn id=dom-document-selector>NodeSelector</dfn> {
1.50 lhunt 447: Element <span title=document-selectelement>querySelector</span>(in DOMString selectors)
448: raises (NAMESPACE_ERR, SYNTAX_ERR);
449: Element <span title=document-selectelement>querySelector</span>(in DOMString selectors,
450: in <a href="#nsresolver">NSResolver</a> nsresolver)
451: raises (NAMESPACE_ERR, SYNTAX_ERR, NOT_SUPPORTED_ERR);
452:
453: <span>NodeList</span> <span title=document-selectallelements>querySelectorAll</span>(in DOMString selectors)
454: raises (NAMESPACE_ERR, SYNTAX_ERR);
455: <span>NodeList</span> <span title=document-selectallelements>querySelectorAll</span>(in DOMString selectors,
456: in <a href="#nsresolver">NSResolver</a> nsresolver)
457: raises (NAMESPACE_ERR, SYNTAX_ERR, NOT_SUPPORTED_ERR);
1.16 avankest 458: };
1.46 lhunt 459: </pre>
1.36 lhunt 460:
461: <p>The term <dfn id=first>first</dfn> used in the definitions of the
462: <code>querySelector</code> methods means <em>first in document order</em>.
463: The term <dfn id=document>document order</dfn> means a depth-first
464: pre-order traversal of the DOM tree or subtree in question. The term <dfn
1.47 lhunt 465: id=context>context node</dfn> refers to the node upon which the method was
466: invoked. The term <dfn id=nodes>node’s subtree</dfn> refers to the tree
467: of elements that are descendants of the <a href="#context">context
468: node</a>. The term <dfn id=matching>matching <code>Element</code>
469: node</dfn> refers to an <code>Element</code> node that matches the group
470: of selectors (<var>selectors</var>) that was passed to the method,
471: according to the rules for matching elements defined in Selectors
472: ([<cite><a href="#ref-selectors">Selectors</a></cite>]).
1.1 avankest 473:
1.21 lhunt 474: <p>The <dfn id=element-selectelement
1.27 lhunt 475: title=element-selectelement><code>querySelector()</code></dfn> methods on
1.46 lhunt 476: the <code><a href="#dom-document-selector">NodeSelector</a></code>
1.36 lhunt 477: interface <em class=ct>must</em>, when invoked, return the first matching
1.46 lhunt 478: <code>Element</code> node within the node’s subtree. If there is no such
479: node, the methods <em class=ct>must</em> return <code>null</code>.
1.1 avankest 480:
1.21 lhunt 481: <p>The <dfn id=element-selectallelements
1.27 lhunt 482: title=element-selectallelements><code>querySelectorAll()</code></dfn>
1.20 lhunt 483: methods on the <code><a
1.46 lhunt 484: href="#dom-document-selector">NodeSelector</a></code> interface <em
1.43 lhunt 485: class=ct>must</em>, when invoked, return a <code>NodeList</code>
1.47 lhunt 486: containing all of the matching <code>Element</code> nodes within the
1.46 lhunt 487: node’s subtree, in document order. If there are no such nodes, the
1.43 lhunt 488: methods <em class=ct>must</em> return an empty <code>NodeList</code>.
489:
1.46 lhunt 490: <p>Both <code title=document-selectelement>querySelector()</code> and <code
491: title=document-selectallelements>querySelectorAll()</code> take a group of
492: selectors (<var>selectors</var>) as the first argument and optionally an
493: <code><a href="#nsresolver">NSResolver</a></code> (<var
1.50 lhunt 494: title="">nsresolver</var>) as the second.
1.46 lhunt 495:
1.50 lhunt 496: <p>The caller <em class=ct>must</em> pass a valid group of selectors. If
497: the group of selectors uses namespace prefixes, or if the default
498: namespace for group of selectors is not the <code>null</code> namespace,
499: the caller <em class=ct>must</em> also pass in an <code><a
500: href="#nsresolver">NSResolver</a></code> object that correctly defines the
501: default namespace and/or the namespace prefixes used. Otherwise, the
502: caller <em class=ct>may</em> set the <var title="">nsresolver</var>
503: argument to <code>null</code> or omit it if the language binding permits.
1.36 lhunt 504:
505: <p class=note>Authors are advised that while the use of pseudo-elements in
506: selectors is permitted, they will not match any elements in the document,
507: and thus would not result in any elements being returned. Therefore,
1.46 lhunt 508: authors should avoid the use of pseudo-elements in selectors that are
509: passed to the methods defined in this specification.
1.36 lhunt 510:
1.50 lhunt 511: <p>The implementation <em class=ct>must</em> first trim any leading or
512: trailing whitespace from the value of the <var>selectors</var> parameter.
513: The implementation <em class=ct>must</em> then process the value according
514: to <a href="http://www.w3.org/TR/css3-selectors/#w3cselgrammar">the
515: grammar of Selectors</a> ([<cite><a
516: href="#ref-selectors">Selectors</a></cite>], section 10). If the
517: <var>selectors</var> parameter is set to either <code>null</code> or
518: <code>undefined</code>, the implementation <em class=ct>must</em> behave
519: as if an empty string had been passed instead. Selectors are evaluated
520: against a given element in the context the entire DOM tree in which the
521: element is located. If the given group of selectors is <a
1.36 lhunt 522: href="http://www.w3.org/TR/css3-selectors/#Conformance">invalid</a>
523: ([<cite><a href="#ref-selectors">Selectors</a></cite>], section 13), the
524: implementation <em class=ct>must</em> <a
1.25 lhunt 525: href="http://www.w3.org/TR/DOM-Level-3-Core/core.html#DOMException-SYNTAX_ERR">raise
526: a <code>SYNTAX_ERR</code> exception</a> ([<cite><a
527: href="#ref-dom3core">DOM3Core</a></cite>], section 1.4).
1.20 lhunt 528:
1.50 lhunt 529: <p>If the user agent also supports some level of CSS, the implementation
530: <em class=ct>should</em> support the same set of selectors in both these
531: APIs and CSS.
1.1 avankest 532:
1.50 lhunt 533: <p>The <code>NodeList</code> object returned by the
534: <code>querySelectorAll()</code> methods <em class=ct>must</em> be static,
535: not <a href="http://www.w3.org/TR/DOM-Level-3-Core/core.html#td-live"
536: title="Document Object Model Core">live</a>. ([<cite><a
537: href="#ref-dom3core">DOM3Core</a></cite>], section 1.1.1) Subsequent
538: changes to the structure of the underlying document <em class=ct>must
539: not</em> be reflected in the <code>NodeList</code> object. This means that
540: the object will instead contain a list of matching <code>Element</code>
541: nodes that were in the document at the time the list was created.
1.1 avankest 542:
1.22 lhunt 543: <div class=example>
544: <p>The methods accept a group of selectors (comma separated) as the
545: argument. The following example would select all <code>p</code> elements
1.36 lhunt 546: in the document that have a class of either "<code>error</code>" or
547: "<code>warning</code>".</p>
1.22 lhunt 548:
1.27 lhunt 549: <pre>var alerts = document.querySelectorAll("p.warning, p.error");</pre>
1.22 lhunt 550:
1.46 lhunt 551: <p>The <code title=document-selectelement>querySelector()</code> methods
552: also accept a group of selectors and they will return the first element
553: (if any) that matches any of the selectors in the group.</p>
1.22 lhunt 554:
1.27 lhunt 555: <pre>var x = document.querySelector("#foo, #bar");</pre>
1.22 lhunt 556:
557: <p><var>x</var> would contain the first element in the document with an ID
558: of either <code>foo</code> or <code>bar</code> (or both).</p>
559:
560: <p>The methods can also be invoked on elements. In this example, the
561: method is invoked on an element that is the target of an event listener.</p>
562:
563: <pre>function handle(evt) {
1.50 lhunt 564: var x = evt.target.querySelector("span");
565: ...
566: // Do something with x
567: }</pre>
1.22 lhunt 568: </div>
569:
1.50 lhunt 570: <h3 id=resolving><span class=secno>6.1 </span>Resolving Namespaces</h3>
571:
572: <p>Support for resolving namespaces is <em class=ct>optional</em>.
573:
574: <p>If the implementation does not support resolving namespaces, then when
575: the <var>nsesolver</var> parameter is provided and it is not set to either
576: <code>null</code> or <code>undefined</code>, the implementation <em
577: class=ct>must</em> <a
578: href="http://www.w3.org/TR/DOM-Level-3-Core/core.html#DOMException-NOT_SUPPORTED_ERR">raise
579: a <code>NOT_SUPPORTED_ERR</code> exception</a>. ([<cite><a
580: href="#ref-dom3core">DOM3Core</a></cite>], section 1.4).
581:
582: <p>If the implementation does support resolving namespaces, then the
583: implementation <em class=ct>must</em> use the <var
584: title="">nsresolver</var> to <a href="#get-the">get the default
585: namespace</a> for the group of selectors. If the group of selectors
586: include namespace prefixes, the implementation must also use it to <a
587: href="#resolve" title=resolve-prefixes>resolve those prefixes</a>.
588:
589: <p>For languages that support optional arguments for methods, such as
590: ECMAScript, if the <var title="">nsresolver</var> argument is omitted, the
591: implementation <em class=ct>must</em> act as if the <var
592: title="">nsresolver</var> argument was set to <code>null</code>.
593:
594: <p>An <dfn id=unresolvable>unresolvable namespace</dfn> is a namespace that
595: cannot be resolved because there was no <code><a
596: href="#nsresolver">NSResolver</a></code> provided or the given <code><a
597: href="#nsresolver">NSResolver</a></code> returns an empty string (<a
598: href="#convert-value">or equivalent</a>) for a prefix. When an <a
599: href="#unresolvable">unresolvable namespace</a> is encountered, the
600: implementation <em class=ct>must</em> <a
601: href="http://www.w3.org/TR/DOM-Level-3-Core/core.html#DOMException-NAMESPACE_ERR">raise
602: a <code>NAMESPACE_ERR</code> exception</a> ([<cite><a
603: href="#ref-dom3core">DOM3Core</a></cite>], section 1.4).
604:
605: <p class=note>Unresolvable namespaces can only occur for namespace
606: prefixes. The default namespace will always resolve as either the null
607: namespace or the value returned by the <code><a
608: href="#nsresolver">NSResolver</a></code>.
609:
610: <p>To <dfn id=get-the>get the default namespace</dfn>, if there was an
611: <code><a href="#nsresolver">NSResolver</a></code> object provided,
612: implementations <em class=ct>must</em> invoke the
613: <code>lookupNamespaceURI()</code> method with the empty string as the
614: argument. If there is no <code><a href="#nsresolver">NSResolver</a></code>
615: object provided, or if the method returns an empty string, then there is
616: no default namespace. Otherwise, the return value is the default
617: namespace.
618:
619: <p>To <dfn id=resolve title=resolve-prefixes>resolve namespace
620: prefixes</dfn>, if there was an <code><a
621: href="#nsresolver">NSResolver</a></code> object provided, implementations
622: <em class=ct>must</em> pass the prefix, preserving case, to the
623: <code>lookupNamespaceURI()</code> method. Implementations <em
624: class=ct>must</em> handle prefixes case sensitively. If there was no
625: <code><a href="#nsresolver">NSResolver</a></code> object provided, or if
626: the method returns an empty string, the prefix represents an <a
627: href="#unresolvable">unresolvable namespace</a>. Otherwise, the return
628: value is the namespace for the given prefix.
629:
630: <p class=note>Although prefixes are case sensitive, there are no
631: restrictions imposed by this specification on how the implementation of
632: the <code><a href="#nsresolver">NSResolver</a></code> object may handle
633: them internally. Thus, while the resolver may handle them case
634: insensitively, such an approach is effectively the same as declaring all
635: case variants of the prefix with the same namespace URI.
636:
637: <p id=convert-value>While resolving either a prefix or the default
638: namespace, if the <code>lookupNamespaceURI()</code> method returns
639: <code>null</code> or <code>undefined</code>, the implementation <em
640: class=ct>must</em> act as if an empty string had been returned. If the
641: method returns an object other than a string, the object <em
642: class=ct>must</em> be converted to a string and the implementation must
643: act as if the resulting string had been returned instead. The method to
644: convert an object to a string is dependent upon the language used. For
645: example, in ECMAScript, this is achieved by invoking the
646: <code>toString()</code> method on the object.
647:
648: <p>If an exception is raised by the <code><a
649: href="#nsresolver">NSResolver</a></code> while resolving namespaces,
650: processing <em class=ct>must</em> be aborted and the exception propagated
651: to the caller.
652:
653: <p>In the algorithms to <span>resolve namespace prefixes</span> or to <a
654: href="#get-the">get the default namespace</a>, if the implementation is
655: passed a <code>Function</code> (in language bindings such as ECMAScript
656: that support this) instead of an object implementing the <code><a
657: href="#nsresolver">NSResolver</a></code> interface, it must instead invoke
658: the function itself instead of the <code>lookupNamespaceURI()</code>
659: method.
660:
1.51 ! lhunt 661: <h2 id=nsresolver-interface><span class=secno>7. </span>The <code><a
! 662: href="#nsresolver">NSResolver</a></code> Interface</h2>
1.6 avankest 663:
1.14 avankest 664: <p>The <code><a href="#nsresolver">NSResolver</a></code> interface allows
1.39 lhunt 665: prefixes to be bound to a namespace URI.
1.7 avankest 666:
1.20 lhunt 667: <pre class=idl>interface <dfn id=nsresolver>NSResolver</dfn> {
1.39 lhunt 668: DOMString <span>lookupNamespaceURI</span>(in DOMString prefix);
1.6 avankest 669: };</pre>
1.1 avankest 670:
1.39 lhunt 671: <p class=note>The object implementing this interface is expected to be
672: implemented by applications. Other specifications may introduce methods
1.44 lhunt 673: that return an object implementing the <code><a
674: href="#nsresolver">NSResolver</a></code> interface, in which case it would
675: be implemented by the user agent. When the object is implemented by the
1.39 lhunt 676: application, some conformance requirements are relaxed in order to make it
677: easier for authors to write a conforming implementation.
678:
679: <p>When the <code>lookupNamespaceURI()</code> method is invoked, the
680: implementation <em class=ct>must</em> perform the following algorithm:
1.22 lhunt 681:
682: <ul>
1.39 lhunt 683: <li>If the given prefix is an empty string, then:
684: <ul>
685: <li>If there is a default namespace, return the default namespace URI.
686:
687: <li>If there is no default namespace, return an empty string.
688: </ul>
689:
690: <li>Otherwise, look up the namespace URI associated with the given prefix
691: and:
692: <ul>
693: <li>If the prefix has an associated namespace URI, return the URI.
694:
695: <li>If the prefix has no associated namespace URI, return an empty
696: string.
697: </ul>
698: </ul>
1.22 lhunt 699:
1.39 lhunt 700: <p>If the <code>lookupNamespaceURI()</code> method is passed a value of
701: <code>null</code> or <code>undefined</code>, then the implementation <em
702: class=ct>must</em> act as if an empty string had been passed instead. If
703: the method is passed an object other than a string, the object <em
704: class=ct>must</em> be converted to a string and the implementation <em
705: class=ct>must</em> act as if the resulting string had been passed instead.
706: The method to convert an object to a string is dependent upon the language
707: used. For example, in ECMAScript, this is achieved by invoking the
708: <code>toString()</code> method on the object.
709:
710: <p>If the <code><a href="#nsresolver">NSResolver</a></code> object is
711: implemented by the application instead of the user agent, then, where the
712: algorithm says to return an empty string, the implementation <em
713: class=ct>may</em> return <code>null</code> or <code>undefined</code>
1.40 lhunt 714: instead. Additionally, the implementation is not required to handle being
1.39 lhunt 715: passed <code>null</code>, <code>undefined</code> or non-string objects as
716: the prefix parameter.
1.22 lhunt 717:
1.39 lhunt 718: <p>The <code>lookupNamespaceURI()</code> <em class=ct>must</em> return
719: consistent results each time it is invoked.
1.22 lhunt 720:
721: <p class=note>Authors are <em>strongly discouraged</em> from writing an
722: <code><a href="#nsresolver">NSResolver</a></code> that returns
723: inconsistent results.
724:
1.36 lhunt 725: <p>For ECMAScript, this object <em class=ct>may</em> be implemented as a
726: <code>Function</code> and implementations <em class=ct>must</em> support
727: the <code><a href="#nsresolver">NSResolver</a></code> being implemented as
1.50 lhunt 728: either a <code>Function</code> or an <code>Object</code>.
1.36 lhunt 729:
730: <p>The number of times that an implementation <em class=ct>may</em> invoke
1.39 lhunt 731: the <code>lookupNamespaceURI()</code> method with each prefix and the
732: order in which prefixes are resolved is not defined by this specification.
1.20 lhunt 733:
1.22 lhunt 734: <div class=example>
1.36 lhunt 735: <p>The following examples make use of this sample document.</p>
1.20 lhunt 736:
1.22 lhunt 737: <pre><html xmlns="http://www.w3.org/1999/xhtml"
738: xmlns:svg="http://www.w3.org/2000/svg"
739: xml:lang="en">
740: <head>
741: <title>Selectors API Example</title>
742: </head>
743: <body>
1.44 lhunt 744: <div><svg:svg … > … </svg:svg></div>
745: <p><svg:svg … > … </svg:svg></p>
746: <p><svg xmlns="http://www.w3.org/2000/svg" … > … </svg></p>
1.22 lhunt 747: </body>
1.36 lhunt 748: </html></pre>
1.20 lhunt 749:
1.21 lhunt 750: <p>The <code><a href="#nsresolver">NSResolver</a></code> may be
1.39 lhunt 751: implemented as an object with a <code>lookupNamespaceURI</code> method.</p>
1.21 lhunt 752:
753: <pre>var resolver = {
754: lookupNamespaceURI: function(prefix) {
755: var ns = {
756: "xh" :"http://www.w3.org/1999/xhtml",
1.22 lhunt 757: "xbl" :"http://www.w3.org/ns/xbl",
1.21 lhunt 758: "svg" :"http://www.w3.org/2000/svg",
759: "math":"http://www.w3.org/1998/Math/MathML"
760: };
1.23 lhunt 761: return ns[prefix];
1.21 lhunt 762: }
763: }</pre>
764:
765: <p>For convenience, in ECMAScript, the <code><a
766: href="#nsresolver">NSResolver</a></code> may also be implemented as a
767: function. In the above example, namespace prefixes are resolved case
1.36 lhunt 768: sensitively. If case insensitive namespace prefixes are desired, it is
1.21 lhunt 769: possible to implement this in the resolver by altering the case of the
770: prefix before comparison.</p>
771:
772: <pre>function resolver(prefix) {
773: var ns = {
774: "xh" :"http://www.w3.org/1999/xhtml",
1.22 lhunt 775: "xbl" :"http://www.w3.org/ns/xbl",
1.21 lhunt 776: "svg" :"http://www.w3.org/2000/svg",
777: "math":"http://www.w3.org/1998/Math/MathML"
778: };
1.23 lhunt 779: return ns[prefix.toLowerCase()];
1.22 lhunt 780: }
781:
1.41 lhunt 782: var svgImages = document.querySelectorAll("xh|p SVG|svg", resolver);</pre>
1.21 lhunt 783:
1.44 lhunt 784: <p class=note>This is not a proper implementation of caseless matching in
785: Unicode, which requires both strings that are being compared to be case
786: folded prior to performing a binary comparison [<cite><a
787: href="#ref-casemap">CaseMap</a></cite>]. However, this is a sufficient
788: approximation for prefixes that are restricted to characters, such as
789: those in the US-ASCII subset, for which simply converting both strings to
790: lowercase and comparing returns the correct result. If desired, an
1.46 lhunt 791: implementation of the full case mapping algorithm is left as an exercise
1.44 lhunt 792: for the reader.</p>
793:
1.21 lhunt 794: <p>Using the case insensitive namespace resolver, the prefix
795: <code>xh</code> will be resolved as
796: <code>http://www.w3.org/1999/xhtml</code> and <code>SVG</code> as
1.22 lhunt 797: <code>http://www.w3.org/2000/svg</code>. The <var>svgImages</var>
1.43 lhunt 798: variable will be a <code>NodeList</code> containing the two
1.22 lhunt 799: <code>svg</code> elements that are descendents of the <code>p</code>
800: elements.</p>
801:
802: <p>The default namespace can be specified so that prefixes do not need to
803: be used for selecting elements in a specific namespace. In the following
804: example, the default namespace has been set to the XHTML namespace.</p>
805:
806: <pre>function resolver(prefix) {
807: var ns = {
1.23 lhunt 808: "" :"http://www.w3.org/1999/xhtml", // Default namespace
1.22 lhunt 809: "xbl" :"http://www.w3.org/ns/xbl",
810: "svg" :"http://www.w3.org/2000/svg",
811: "math":"http://www.w3.org/1998/Math/MathML"
812: };
1.23 lhunt 813: return ns[prefix];
1.36 lhunt 814: }</pre>
1.22 lhunt 815:
816: <p>Using this resolver, the previous example can be rewritten without
817: explicitly declaring the XHTML namespace using the <code>xh</code>
818: prefix.</p>
819:
1.41 lhunt 820: <pre>var svgImages = document.querySelectorAll("p svg|svg", resolver);</pre>
1.21 lhunt 821:
822: <p>In the following example, the <code>foo</code> namespace is undefined
823: and will result in an unresolvable namespace. The
824: <code>NAMESPACE_ERR</code> exception can be handled using a
825: <code>try</code>/<code>catch</code> block.</p>
826:
827: <pre>try {
1.41 lhunt 828: document.querySelectorAll("foo|bar", resolver);
1.21 lhunt 829: } catch (e) {
830: switch (e.code) {
831: case DOMException.NAMESPACE_ERR:
832: // Namespace error
833: break;
834: case DOMException.SYNTAX_ERR:
835: // Syntax error
836: break;
837: default:
838: // Unknown error
839: }
840: }</pre>
1.14 avankest 841:
1.21 lhunt 842: <p>This example demonstrates how to iterate through the items in a
1.43 lhunt 843: <code>NodeList</code>.</p>
1.21 lhunt 844:
1.41 lhunt 845: <pre>var lis = document.querySelectorAll("ul.nav>li");
1.24 lhunt 846: for (var i = 0; i < lis.length; i++) {
1.21 lhunt 847: process(lis.item(i));
848: }</pre>
849:
850: <p>In ECMAScript, the language binding also allows <code>NodeList</code>s
1.43 lhunt 851: and to be addressed using the array notation, so that loop could be
852: rewritten like this:</p>
1.21 lhunt 853:
1.24 lhunt 854: <pre>for (var i = 0; i < lis.length; i++) {
1.21 lhunt 855: process(lis[i]);
856: }</pre>
857:
1.43 lhunt 858: <p>Since the <code>NodeList</code> objects returned by these methods are
1.22 lhunt 859: not live, changes to the DOM do not affect the content of the list.
1.21 lhunt 860: Consider the <code>process()</code> function called in the previous
861: examples is defined as follows:</p>
862:
1.36 lhunt 863: <pre>function process(elmt) {
1.21 lhunt 864: elmt.parentNode.removeChild(elmt);
865: }</pre>
866:
867: <p>This would cause each selected element to be removed from the DOM, but
1.43 lhunt 868: each element will remain in the <code>NodeList</code>. If the list were a
1.21 lhunt 869: live <code>NodeList</code>, removing an item from the DOM would also
870: remove the element from the list and adjust the indexes of subsequent
871: elements. That would have adverse effects upon the loop because not all
872: selected elements would be processed.</p>
873: </div>
874:
1.11 avankest 875: <h2 class=no-num id=references>References</h2>
1.1 avankest 876:
877: <dl>
1.23 lhunt 878: <dt id=ref-casemap>[CaseMap]
1.1 avankest 879:
1.24 lhunt 880: <dd>(Non-normative) <cite><a
1.21 lhunt 881: href="http://unicode.org/reports/tr21/tr21-5.html">Unicode Standard Annex
1.24 lhunt 882: #21 Case Mappings</a></cite>, M. Davis, editor. Unicode Consortium, March
883: 2001.
1.1 avankest 884:
1.23 lhunt 885: <dt id=ref-css21>[CSS21]
886:
887: <dd>(Non-normative) <cite><a href="http://www.w3.org/TR/CSS21">Cascading
1.44 lhunt 888: Style Sheets, level 2 revision 1</a></cite>, B. Bos, T. Çelik, I.
889: Hickson, H. Wium Lie, editors. World Wide Web Consortium, June 2005.
1.23 lhunt 890:
1.22 lhunt 891: <dt id=ref-dom2style>[DOM2Style]
1.20 lhunt 892:
1.23 lhunt 893: <dd>(Non-normative) <cite><a
1.20 lhunt 894: href="http://www.w3.org/TR/DOM-Level-2-Style/">Document Object Model
1.44 lhunt 895: (DOM) Level 2 Style Specification</a></cite>, C. Wilson, P. Le Hégaret,
896: V. Apparao, editors. World Wide Web Consortium, November 2000.
1.20 lhunt 897:
1.11 avankest 898: <dt id=ref-dom3core>[DOM3Core]
1.1 avankest 899:
900: <dd><cite><a href="http://www.w3.org/TR/DOM-Level-3-Core">Document Object
901: Model (DOM) Level 3 Core Specification</a></cite>, A. Le Hors, P. Le
1.44 lhunt 902: Hégaret, L. Wood, G. Nicol, J. Robie, M. Champion, S. Byrne, editors.
1.1 avankest 903: World Wide Web Consortium, April 2004.
904:
1.11 avankest 905: <dt id=ref-ecma262>[ECMAScript]
1.1 avankest 906:
907: <dd><cite><a
908: href="http://www.ecma-international.org/publications/standards/Ecma-262.htm">ECMAScript
909: Language Specification</a></cite>, Third Edition. ECMA, December 1999.
910:
1.25 lhunt 911: <dt id=ref-rfc2119>[RFC2119]
912:
913: <dd><cite><a href="http://ietf.org/rfc/rfc2119">RFC 2119: Key words for
914: use in RFCs to Indicate Requirement Levels</a></cite>, S. Bradner. IETF,
915: March 1997.
916:
1.11 avankest 917: <dt id=ref-selectors>[Selectors]
1.1 avankest 918:
919: <dd><cite><a
920: href="http://www.w3.org/TR/css3-selectors">Selectors</a></cite>, D.
1.44 lhunt 921: Glazman, T. Çelik, I. Hickson, P. Linss, J. Williams, editors. World
922: Wide Web Consortium, December 2005.
1.1 avankest 923: </dl>
924:
1.11 avankest 925: <h2 class=no-num id=acknowledgements>Acknowledgements</h2>
1.1 avankest 926:
1.45 avankest 927: <p>The editors would like to thank to the following people who have
1.7 avankest 928: contributed to this specification (ordered on first name):
929:
1.1 avankest 930: <ul>
1.19 avankest 931: <li>Alex Russell
932:
1.44 lhunt 933: <li>Björn Höhrmann
1.1 avankest 934:
1.36 lhunt 935: <li>Boris Zbarsky
936:
1.1 avankest 937: <li>Cameron McCormack
938:
1.19 avankest 939: <li>Charles McCathieNevile
940:
941: <li>Chris Wilson
942:
1.1 avankest 943: <li>Daniel Schierbeck
944:
1.19 avankest 945: <li>Dave Massy
946:
1.44 lhunt 947: <li>David Håsäther
1.36 lhunt 948:
1.1 avankest 949: <li>Dean Jackson
950:
1.44 lhunt 951: <li>Erik Dahlström
1.36 lhunt 952:
1.1 avankest 953: <li>Ian Hickson
954:
955: <li>Jim Ley
956:
957: <li>Jonas Sicking
958:
1.11 avankest 959: <li>Jorgen Horstink
960:
1.5 avankest 961: <li>Karl Dubost
962:
1.1 avankest 963: <li>Maciej Stachowiak
964:
965: <li>Mohamed Zergaoui
966:
1.24 lhunt 967: <li>Philip Taylor
968:
1.19 avankest 969: <li>Robert Sayre
970:
1.1 avankest 971: <li>Robin Berjon
1.14 avankest 972:
1.19 avankest 973: <li>Simon Pieters
974:
1.36 lhunt 975: <li>Steven Pemberton
976:
1.14 avankest 977: <li>Tarquin Wilton-Jones
1.21 lhunt 978:
979: <li>Travis Leithead
1.1 avankest 980: </ul>
981:
982: <p>Thanks to all those who have helped to improve this specification by
983: sending suggestions and corrections. (Please, keep bugging us with your
984: issues!)
Webmaster
![[BACK]](/https/dev.w3.org/cvsweb/icons/back.gif){kind=icon}
Return to Overview.html CVS log ![[TXT]](/https/dev.w3.org/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/https/dev.w3.org/cvsweb/icons/dir.gif){kind=icon}
Up to [Public] / 2006 / webapi / selectors-api