Today, I would like to introduce you to the W3C selector API, an exciting step in the DOM scripting field. So far, if you want to obtain HTML elements from the DOM using the dom2 API, you can only use document. getelementbyid, or use document. getelementsbytagname for manual filtering. With the popularization of CSS, JavaScript developers keep raising an obvious question: "Why cannot a browser provide a shortcut to select HTML elements that match the CSS selector ?"
As a result, the selector API defines the queryselector and queryselectorall methods. They take the CSS selector as the parameters and return the staticnodelist (static node list) of the First Matching Element and all matching elements respectively ). The two methods can be called through the document object to query the target element in the entire document scope, or through individual HTML elements, to query the target element only in the child element of the element.
Here is a simple HTML example to demonstrate how to use the selector API:
-
- <Ul id = "menu">
- <Li>
-
- <Input type = "checkbox" name = "item1_done" id = "item1_done">
-
- <Label for = "itemincludone"> bread </label>
- </LI>
-
- <Li class = "important">
-
- <Input type = "checkbox" name = "item2_done" id = "item2_done">
- <Label for = "item2_done"> milk </label>
-
- </LI>
-
- <! -- More list items -->
- </Ul>
Our task is to use the script to select the check box (checkbox) in the list items of all classes named "important ). If you use the dom2-level API method, you can do this:
-
- VaR items = Document. getelementbyid (
-
- 'Menu'
- ). Getelementsbytagname (
-
- 'Lil'
-
- );
- For (VAR I = 0; I <items. length; I ++ ){
-
- If (items [I]. classname. Match (/important /)){
-
- If (items [I]. firstchild. type = "checkbox "){
- Items [I]. firstchild. Checked = true;
-
- }
-
- }
- }
With the new selector API, you canCodeSimplified:
-
- VaR items = Document. queryselectorall (
-
- '# Menu Li. important input [type = "checkbox"]'
- );
-
- For (VAR I = 0; I <items. length; I ++ ){
-
- Items [I]. Checked = true;
- }
Is it simpler and more convenient? Note that the queryselector and queryselectorall methods also support combination selector, that is, multiple selectors separated by commas. Currently, browsers that support selector APIs include safari3.1, IE8 beta, and firefox3.1. Opera is also actively adding support for this API.
If the reader is good at using various JavaScript libraries, he may secretly say, "I have been able to do this through the library for a long time ?" In fact, many people use various JavaScript libraries because these libraries implement the query mechanism through CSS selector. Recently, because these database authors share their technology, we found that the CSS selector query speed has been significantly improved. So, what is the need to use the selector API? Simply put: Speed-the advantage of local implementation is speed! In addition, all these JavaScript libraries value this very much. Jquery and prototype are moving closer to the path using the selector API, while dojo toolkit, domassistant, and base2 are already using this API.
There is a reason why these three databases can use this API in the first batch. Kevin's blogArticle"Is Your JavaScript library standards compliant? (Is your JavaScript library compatible with the standard ?)" I have discussed these issues. Because the selector API requires a standard CSS selector, if the browser does not support a certain selector, it cannot be used. These libraries that have begun to use the selector API originally only support the standard CSS selector. For these libraries, supporting this API (almost) is equivalent to adding the following code:
-
- If (document. queryselector ){
-
- Return document. queryselector (selector );
- } Else {
-
- Return oldselectorfunction (selector );
-
- }
However, the libraries that support user-defined selector APIs are far from that simple. First, if developers have already used a large number of custom CSS separators in their projects, it is very difficult to get faster through this library, because these libraries must use their default selector rather than the selector API. Secondly, even if these libraries take some measures to solve the problem of using custom selector and support selector API, the library must also face the risk of increasing volume.
Ideally, the selector API is intended to encourage people to use the standard CSS selector and give up using the custom selector. In fact, if the new version of the browser can be good enough, and the performance improvement of the new selector API is also impressive, the custom selector function is likely to be automatically transferred to the auxiliary library, it is used only when dealing with compatibility issues with legacy code.
I personally think that the base2 library of Dean Edwards is best implemented. Because base2 fully implements this API, that is, developers can use the standard API method when writing JavaScript using base2-Because base2 only supports standard APIs in browsers, to create the queryselector and queryselectorall methods. This is already an ideal state. However, base2 implements a non-standard "! = "Attribute selector (apparently due to pressure from peers), thus the score is also incorrect.
Whether you are using or writing JavaScript libraries, the support of the selector API by the new browser will bring a direct performance improvement to everyone's development work. In other words, we will all be beneficiaries. Long live!
Alex Russell, father of dojo, made an "advertisement" for his toolbox in mastering dojo ":
Dojo is built based on principles that are compatible with future standards. These standards will eventually be implemented in all browsers and developers will be able to use fast and simple local methods. The dojo. query method is a good example. The W3C selectors API standard describes an API that uses CSS delimiters to query the DOM tree. The web API workgroup defines a programming method called queryselectorall. The queryselectorall method is the same as the dojo. query method. A node array is returned. Although the CSS query engine of dojo is fast, by keeping the query syntax consistent with the CSS syntax, it effectively solves the problem of always relying on the engine. In fact, in browsers that fully support the preceding APIs, Dojo uses the queryselectorall method. It is only a matter of time to believe that dojo. query becomes the method of packaging queryselectorsall-but by packaging it, it will also add some sweet syntactic sugar (syntactic sugar) to the returned node array ). The best result is that the above APIs have become real standards and will not change any more. Developers will also enjoy the fast and convenient query engine implemented by C ++. At the same time, not to worry about backward compatibility issues. For a dojo user, selecting this toolbox that focuses on the future development of the Web is equivalent to enjoying the above benefits.
In fact, Alex Russell is indeed an important recommender of W3C selector API.