Last week, our own Santiago Suarez Ordoñez gave a presentation to the San Francisco Selenium Meetup group that convinced us all to say no (for the most part) to XPath and yes to CSS Locators in our Selenium tests.
In his role as official Sauce Ninja and as a prolific poster in the Selenium forums, Santi has helped more users solve locator issues than possibly anyone else in the world. He’s previously written a number of blog posts on ways to improve locator performance. As Sauce CEO John Dunham puts it, “If there was a foursquare mayorship for locators, Santi would have it for a lifetime.”
Drawing from this experience, he gave us these four reasons for using CSS Locators:
1. They’re faster
2. They’re more readable
3. CSS is jQuery’s locating strategy
4. No one else uses XPATH anyways!
I can’t speak for everyone, but Santi sure sold me on point number one when he showed off the performance metric script he wrote a script that tested the speed of XPath vs the speed of CSS Locators. There wasn’t much of a difference in Firefox, Safari, or Chrome, but with IE, the results were undeniable. Take a look:
To underscore this even further, he also recorded a video in Sauce OnDemand that uses one heck of a cute kitten to illustrate just how slow XPath can be. The cat’s paw movements represent the test clicking through the different locators. The first batch of clicks uses CSS Locators and completes in under 30 seconds. The second batch, the XPath one, continues on for another eight minutes. Eight minutes!
During the rest of the presentation, Santi dives into writing both basic and more advanced CSS Locators. He also spends some time talking about when you shouldn’t use CSS Locators (yes, there are a few cases where it is not the right tool for the job). To see the talk in its entirety, check out the recording below. And if you’re thinking of switching over from XPath, but unsure of how to go about it, check out the nifty tool Santi wrote called cssify. It does the handy work of translating your XPaths to CSS automatically.
Helpful links
View Santi’s Presentation Slides
Follow him on Twitter
Follow Sauce on Twitter
Join the San Francisco Selenium Meetup group!
Enjoy!
Er, I have to correct myself. When I said “John Resig, creator of Selenium”, I meant “John Resig, creator of jQuery”. :S
Also, you may notice I pronounce the word sheet in a funny way. Just so that you know, that wasn’t intended XD
How do you use CSS selectors with XML namespaces? I noticed nokogiri didn’t have the syntax to allow you to query for namespaces elements
Both XPath and CSS selectors kind of suck. It would be much nicer to simply be able to use jQuery syntax directly.
[...] the article here: Why CSS Locators are the way to go vs XPath | Selenium Testing? Do … Share and [...]
When you have control of the app, you can make it css friendly with liberal use of classes and ids for selection. But if you’re testing/scraping a site that wasn’t designed for css, XPath is far more flexible.
Hi Jerry,
CSS is specifically created for navigating HTML. Even though it’s technically possible, I’d be surprised if someone ported it for XML.
@Chase,
Hah, funny thing. jQuery’s syntax is just CSS, man. Actually, selenium is using Sizzle for parsing and finding with CSS selectors, which means it’s not only CSS, but also jQuery’s CSS implementation.
@Mark,
I agree that XPath is more flexible, that’s for sure. Though, I think the performance and readability are worth the effort to stick with CSS. I’d be really interested to hear about particular situations in which you found XPath being a better option than CSS for locating an element (notice my “When not to use CSS section in the presentation”.
Do you have links or tutorial site about xpath to css or about converting the html into a css locator?
thanks
Thanks for the presentation and the information. I faced some performance problems before with IE and xpath, now I’m using css and the execution time is really different in IE
Hi Santy,
Can we use something like this with the cssify?
./cssify.py ‘//a[@id=logo]/img’
./cssify.py ‘//a[@id='logo']/img’
Or this is part of the known issues that we could see?
Thanks in advanced
Hi Moises,
That should totally work, though make sure you don’t user single quotes for both, as that may break the parameters, make sure that if your xpath includes single quotes you wrap with with double quotes instead, or escape them:
./cssify.py "//a[@id='logo']/img"or
./cssify '//a[@id=\'logo\']/img"Hi Xpath user,
Just search for css in our blog’s search bar, you’ll find plenty of resources to read ;)
Cool Santy, it looks like it is working now. After I ran the command
./cssify.py “//a[@id='logo']/img”
I got this css
a#logo > img
Should I use that entire line in Selenium or just a#logo?
Thanks
I loved CSS path very well. However, it turns out to be a real pain in ass. Why?
The support for CSS (Level 2, level 3) is totally different from browser to browser, from version to version. If you need to run the script with IE, it is a total nightmare. (IE9 is much better though) Your scripts or css path can not be reused with different browsers.
Fortunately, Xpath does not have so many variants. The support for Xpath is relatively similar. IE still sucks. But, much better compared to Css path.
In terms of the performance of Xpath locator in IE, I found that it is not that bad. Acceptable for me. So, I would prefer compatibility to performance.
My conclusion is: As long as you have to test IE8, try to use xpath locator to ensure your script can be run with all browsers.
[...] Nowadays CSS selectors become popular and took place of xpath selectors. While locating elements the ideal candidate is to reference elements on the page by their unique id or name. If that is not possible, incase not available or auto generated, then XPath or CSS are the strategies available to you. Here you can get answer on Why CSS Locators are the way to go vs XPath. [...]
[...] Why CSS Locators are the way to go vs XPath [...]
would you please give an example of how to check css formatting?
In this case:
1
2
3
4
5
6
How can I locate the second one?
Hi, Santiago, I tried to use css in Selenium C# but it doesn’t seem to work. Here’s my code. When i use isElementPresent code, it finds the button but it doesn’t click the button.
if (selenium.IsElementPresent(“css=//button[id$=searchButton]“))
{
selenium.Click(“css=//button[id$=searchButton]“);
}
Does anyone know why it doesn’t click although it finds the button in CSS? Also can you show an example of using CSS for table elements?
Thanks
Ash
Thanks for the post. Really helpful.
[...] When I started automation with selenium, I started using xpath, because that was the way to go. Till, when I moved companies, there was this talk of other QA engineers relying on CSS for locating elements from the DOM. I have recently started using CSS locators for various reasons. You can read about it here [...]
[...] XPath based or CSS Selector based element access. There are lot of blogs comparing each one like, Why CSS Locators are the way to go vs XPath, and CSS Selectors And XPath [...]
[...] Refernce:http://sauceio.com/index.php/2011/05/why-css-locators-are-the-way-to-go-vs-xpath/ [...]
This article is about the absolute opposite of what John Resig had to say about Xpath a while ago.
http://ejohn.org/blog/xpath-overnight/
Hey, what happened to the video? I watched about half of it and saved the rest for later. Upon reload it had been deleted from YouTube :/
Hi there, so sorry about that, our YouTube account settings went a little haywire. We’re working on fixing the problem, the video should be viewable again sometime in the next day.