In the official W3c webdirver 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 docs are obsolete and the "real" story is in the new spec 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 specs.
I remember reading on a Chromium issue that they would only ever implement the official Webdriver specs.
Now: I know the generic answer, where "specs are not always followed 100%" etc. However, what I'd like to know is:
Ways to identify one or more specific elements in the DOM. A locator is a way to identify elements on a page. It is the argument passed to the Finding element methods.
: one that locates something (such as a mining claim or the course of a road)
ID locator in Selenium is the most preferred and fastest way to locate desired WebElements on the page. ID Selenium locators are unique for each element in the DOM. Since IDs are unique for each element on the page, it is considered the fastest and safest method to locate elements.
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 selectorSnapshot :
However, the JsonWireProtocol
was once used to support the Locator Strategies enlisted below but currently the documentation clearly states it's 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 switchcase 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 Specs
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With