Enforcing xpath lookup for drivers to lookup elements.

[HenningL]

The api for easy use of selectors is contra productive. All what a selenium api has to provide, is the xpath. It is the most open. You can redirect all others to xpath resolution. eg. By.id(theId) is the same as By-xpath(//*[@id = theId]). But implementors of the driver api might focus on implementing stuff for id, instead of focusing to implement xpath lookup. Enforcing xpath lookup will drive the focus for future implementors of WebDriver-Api.

[ghost]

👋 Hi there! Thank you for creating this issue.

I am the Selenium Assistant Bot 🤖, I triage issues in this repository. If I can't do it, I label it to help maintainers identify issues that need triaging.

I am an Open Source project 🙌, post bugs or ideas here!

[ghost]

❗️ It seems this issue is not using any of the supported templates

💡 Supported issue types are (they start with):

• 🐛 Bug Report (bugs found in a recent release)
• 🚀 Feature Proposal (a useful feature you would like to propose)
• 💥 Regression Report (a supported feature is not working anymore)

Issue templates help this project to stay in shape, please use them and fill them out completely. By doing that you are helping the project because the community and maintainers can provide prompt feedback, and potentially solve the issue.

If you are asking a question, a better way to address this is:

• 📫 Send questions and support requests to the Selenium user group
• 📮 Post them to StackOverflow
• 🗣 Join us in the IRC/Slack channel where the community can help you as well

If you think this is incorrect, please feel free to open a new issue.

Thank you for your contributions.

[twalpole]

@HenningL XPath can’t do everything CSS can (input:checked against actual page state for instance) and vice versa.

[HenningL]

Im developing testautomation for 5y now and i never needed css-selectors. your example , i think, is doable with xpath. The only issue i had to use cssselector was the shadow-dom access. hope that will be implemented like iframes, since iframe is obsolete and shadow-dom the new one. so..., i disagree. XPath is the only tech one should focus on.

thx for your input :)! glad to exchange thoughts in the future.

[barancev]

To be honest, most By classes are internally converted to CSS selectors (not XPath, sorry). There are two reasons:

1. Converting to CSS selectors is more straightforward. If we take your example By.id("theId"), it corresponds to a rather long XPath query "//*[@id='theid']" and a much shorter and easier to read CSS selector #id. If we take a more complex example of searching by class the difference willl be even more obvious: By.className("myclass") would be converted to either CSS selector .myclass or an XPath query //*[contains(concat(' ', normalize-space(@class), ' '), 'myclass')]. Don't blame us for choosing a simpler implementation.

2. Browser vendors don't like XPath and we don't expect extening XPath support in near future (see for example this thread: Proposal - Update XPath to (at least) v2.0 whatwg/dom#903). At the same time they implement all the recent CSS-related standards. It does not seem illogical to rely on the technology that has better support.

As for the API -- yes, we could remove all these By.id, By.className etc because they can be easily replaced by equivalent CSS selectors. But we don't think that the API for easy use of locators is contra productive from the customer point of view.

On the other side, we don't insist that all client binding libraries implement all the variety of By classes available in Java or C# clients, it's up to the binding author.