Official locator strategies for the webdriver

Question

In the official W3C webdriver documentation, it's clearly stated that the location strategies are:

State                       Keyword
-----------------------------------------------
CSS selector                "css selector"
Link text selector          "link text"
Partial link text selector  "partial link text"
Tag name                    "tag name"
XPath selector              "xpath"

However, Selenium's wire protocol allowed:

class name
css selector
id
name
link text
partial link text
tag name
xpath

In theory, Selenium's documentation is obsolete and the "real" story is in the new specification document. However...

I ran some tests on the latest Chrome's own Webdriver, and I can confirm that name and class name both work; however, they are not in the specifications.

I remember reading on a Chromium issue that they would only ever implement the official Webdriver specifications.

Now: I know the generic answer, where "specifications are not always followed 100%", etc. However, I'd like to know:

• Can you find the code in Chromium that implements this? (a link would be most welcome)
• Have there been discussions about these in the Chromium mailing list?
• Are the "unofficial" commands (which are documented in the "old" Selenium specifications file) likely to stay? Where is the evidence for it?

Cactus

Chrome driver code is somewhere inside these links on the page - sites.google.com/a/chromium.org/chromedriver/contributing. Some more info that will be helpful in explaining this discrepancy -- github.com/mozilla/geckodriver/issues/1041. – Dickens

Answer 1

Yes, you saw it right.

As per the current WebDriver - W3C Candidate Recommendation the Locator Strategies enlisted are as follows:

• "css selector": CSS selector
• "link text": Link text selector
• "partial link text": Partial link text selector
• "tag name": Tag name
• "xpath": XPath selector

Snapshot:

However, the JsonWireProtocol was once used to support the Locator Strategies enlisted below, but currently the documentation clearly states its Status as obsolete:

• class name: Returns an element whose class name contains the search value; compound class names are not permitted.
• css selector: Returns an element matching a CSS selector.
• id: Returns an element whose ID attribute matches the search value.
• name: Returns an element whose NAME attribute matches the search value.
• link text: Returns an anchor element whose visible text matches the search value.
• partial link text: Returns an anchor element whose visible text partially matches the search value.
• tag name: Returns an element whose tag name matches the search value.
• xpath: Returns an element matching an XPath expression. The provided XPath expression must be applied to the server "as is"; if the expression is not relative to the element root, the server should not modify it. Consequently, an XPath query may return elements not contained in the root element's subtree.

Snapshot:

The change was propagated through the respective client-specific bindings. For the Selenium-Java clients here is the client code where we have the switch case working for the users:

        switch (using) {
          case "class name":
            toReturn.put("using", "css selector");
            toReturn.put("value", "." + cssEscape(value));
            break;

          case "id":
            toReturn.put("using", "css selector");
            toReturn.put("value", "#" + cssEscape(value));
            break;

          case "link text":
            // Do nothing
            break;

          case "name":
            toReturn.put("using", "css selector");
            toReturn.put("value", "*[name='" + value + "']");
            break;

          case "partial link text":
            // Do nothing
            break;

          case "tag name":
            toReturn.put("using", "css selector");
            toReturn.put("value", cssEscape(value));
            break;

          case "xpath":
            // Do nothing
            break;
        }
        return toReturn;

Snapshot:

Now, your question must be why this change in the W3C specification and in the clients. As per #1042 the answer from the WebDriver Contributors was pretty straight as:

This keeps the specification simple as these can be implemented using the CSS selector, which maps down to querySelector/querySelectorAll.

Ravo

While comparing getElementById and querySelector, i found that getElementById is fast. I really don't understand Why id locator is obsolete. Please check: jsperf.com/getelementbyid-vs-queryselector – Imperialism