5

I am working on an application which is compatible only with IE7 and IE8. I didn't know why but some suggested to use CSS over XPath while identifying the elements in IE. When I visited the official Selenium site. I read the message

WebDriver uses a browser’s native XPath capabilities wherever possible. On those browsers that don’t have native XPath support, we have provided our own implementation. This can lead to some unexpected behaviour unless you are aware of the differences in the various xpath engines.

I would like to know where I can find the differences in the various xpath engines and in which situations I should use CSS and and in which XPath specifically if I'm using IE. Thanks.

Code Enthusiastic
  • 2,827
  • 5
  • 25
  • 39
  • 4
    You ask two questions. The first one ("where can I find the differences") seems like a fine question to me. The second one ("when should I use X over Y") is not very well suited for SO as there's no definitive answer, any good answer would have to start with "It depends...". Please consider updating the question (and title) so the second "question" is only a side note. – Jeroen Jan 02 '13 at 09:53
  • 3
    You want to compare apples with bananas. XPath is much more powerful than CSS, and thus can be used in cases where CSS cannot be used. Even if there are performance differences, if they are not significant/noticeable, it would be more consistent to use a single language, and in this case XPath is that single language. – Dimitre Novatchev Jan 05 '13 at 04:35

4 Answers4

13

According to Ashley Wilson's report from sauce labs:

Pros:

  1. They’re faster
  2. They’re more readable
  3. CSS is jQuery’s locating strategy
  4. No one else uses XPATH anyways!

It's a bit outdated, however here are the numbers:

image from cause lab's web site

Personally, I would argue about (2)-nd statement, I must agree with the rest.

Cons:

  1. No "bottom up" navigation. XPath has elem\..\another_elem
  2. Is Sizzle injected? Or Browser's CSS locator parser is used? Depends on the browser, and there are inconsistencies.
Alex Okrushko
  • 7,212
  • 6
  • 44
  • 63
4

The biggest reason for suggesting CSS selectors over XPath in IE is performance. IE does not provide a native XPath-over-HTML option as does Firefox and Chrome. It does, however, provide a native CSS selector engine, which will always be faster than the JavaScript-only XPath engine implementation used in the IE driver. And the performance comparison isn't even close. I've seen it measured as much as an order of magnitude slower for XPath locators than CSS selectors (though I can't find the citation at the moment). This is particularly true in versions of IE before 9, where the IE JavaScript engine was vastly slower than the Chakra JavaScript engine introduced in 32-bit IE9.

JimEvans
  • 27,201
  • 7
  • 83
  • 108
  • 1
    Not to beat a dead horse, but I did a recent quick run using various selectors against http://princeton.edu, and xPath seemed to do just fine... http://stackoverflow.com/questions/22519336/selenium-element-selectors-i-thought-xpath-was-slowest – JackhammersForWeeks Mar 20 '14 at 00:03
1

Brevity and Clarity are other reasons, in addition to speed.

In addition to speed, I find that css is usually shorter and cleaner and easier to read. For example:

xpath:

 //ol[@class='choice-group'//li//label//input

vs

css:

 css=ol.choices-group li label input
Michael Durrant
  • 93,410
  • 97
  • 333
  • 497
  • There are not the same, as css's .choices-group matches roughly xpath's [contains(concat(' ', @class, ' '), ' choices-group ')] http://stackoverflow.com/a/1604480/872856, but your point still stand of course – Jacek Kaniuk Nov 20 '13 at 11:55
0

Using CSS locator is the best option, not only on IE, also on FF and Chrome. Also, xpath is always the worst choice, because it needs to parse the whole page to find a simple element, so if you want performance in your tests and you can avoid it, just do it.

Also, if you are using pageObjects I strongly recommend you to use cacheLookup, so the element will be located just once:

@CacheLookup
@FindBy(id="doLogin")
private WebElement loginButton;

Personally, I do the following:

  • If element has css class, use this locator
  • If element has name or id, use this locator
  • If none of the above is present, and you can not use linkText or another locator, go for xpath.
Santiago Hernandez
  • 306
  • 2
  • 8