Why should we use css selector instead of xpath

[Andi Lao]

Hello everyone,

Have two questions:

1. why should we use css selector instead of xpath?

2. Advantages and Disadvantages of cssSelector?

Thanks,

andi

[Karthik Kulkarni]

andi, 

Research suggests identification of webelement by css selector is efficient and at the end helps a great deal with the performance of your test cases . It also helps across browsers . 

css selectors can behave weird on ie 

--
You received this message because you are subscribed to the Google Groups "Selenium Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-user...@googlegroups.com.
To post to this group, send email to seleniu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/selenium-users/-/KYU-3JKIv9AJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Andi Lao]

thanks kulkarni,

while cross browser testing cssselector method will face some problems?

thanks,

andi

[Krishnan Mahadevan]

Andi,

Please go through this : http://sauceio.com/index.php/2011/05/why-css-locators-are-the-way-to-go-vs-xpath/

Thanks & Regards
Krishnan Mahadevan

"All the desirable things in life are either illegal, expensive, fattening or in love with someone else!"
My Scribblings @ http://wakened-cognition.blogspot.com/

To view this discussion on the web visit https://groups.google.com/d/msg/selenium-users/-/WB-pY5ecYTcJ.

[Arran]

To be honest, if you are running tests against later and modern browsers you may not even notice the difference.

CSS selectors aren't all they can up to be. They still suffer from compatibility issues. For instance one CSS selector that works in IE9 may not work in IE8. 

I would honestly go with what is readable, what makes logical sense, and then and only then, if it causes performance issues look at changing it. People are too crazy on micro optimisation these days.

[Mark Collin]

I need to write "Why XPath is the way to go instead of CSS" at some point :)

[Oscar Rieken]

@mark  :( please don't most people wont realize you are making a joke

[Ross Patterson]

It’s not a joke.  There are lots of things CSS can’t do that XPath can, and at least one of the Selenium developers has measured both and found XPath to be just as fast and in some cases faster.  XPath locators aren’t any more brittle than CSS locators.  Hand-crafted XPath and CSS locators can be equally reliable, beautiful, and performant.

 

XPath gets a bad reputation primarily because Selenium IDE and Firebug both recommend really horrible XPath locators, and people use them without thinking.  Failing to think is almost always a Bad Thing.

 

Ross

[Mark Collin]

+1

I'm really not joking.

XPath is usually more cross browser compliant than CSS because different browsers have different levels of CSS support and Selenium will only use locators that the browser natively supports.  When it comes to XPath it's a pretty consistent experience across all browser, the only gotcha's are where different browsers render a different DOM for different sites, but CSS locators can and will break in this case as well.

The main reason for using CSS is that it's faster in IE.

--

[David Lai]

CSS selectors are also a bit easier to use and more stable since it uses more class and ID attributes which are more stable than node hierarchy.  Of course there are also bad ways to write css that makes it brittle.

There is also a performance advantage.  Browsers already have built in native functions that run much faster for selecting css since it's an HTML standard.  While XPath on the other hand is an XML standard and isn't as optimized on the browser end.  For headless browsers like PhantomJS and HTMLUnit, there is a clear performance difference, since xpath a node hiearchy needs to be built, because xpath needs to support the "." and ".." and other path traversal selectors.  CSS can only select decendants and siblings so a top to bottom string find can be use to implement CSS.

[Oscar Rieken]

It maybe I don't know I try with much success to never have to use either. more than likely If there are not id's I add them keeps things simple pretty much even across all browsers

the brittleness of being dependent of where the objects are in the dom and having tests fail restricts UI/UX people from actually doing what they need to do when they check in code. They are an often forgotten part of a dev team

code check in with new layout changes

units pass

build pass

deploy pass

functional regression fails not because the application actually has a problem but more because the UI/UX person made a small ui change

now that potentially good build has failed because of testing code not production code

what about 

But I have to use xpath because there are no id's :(

Talk to the devs?

add id's yourself?

all the code belongs to the team they should want to make testing easier because it provides them feedback about how the application works 

:) sorry about the rant and going off topic

you can use 

[David Lai]

I do agree that that IE seems to be the bane that makes me sometimes use xpath over CSS.  I think IE does a decently ok job if you're only doing selectors that operate 1 or 2 levels deep without using any of the attribute selector.

In the ideal world, we should be able to refer to the elements using the same selector the devs are using for their JavaScript.  But in reality devs are bending over backwards more than we testers are in writing IE specific code.

[David Lai]

In terms of performance difference, you probably will not see much in real browsers since those have to render the DOM anyways.  In headless browsers however the performance difference is very clear and orders of magnitude better.  This is because CSS does not allow parent selection and node traversal, so an element can be located using a simple top down string scan.

[Gorillatester]

Can you give us an example of a css selector that works in iE9 and doesnt work in ie8? I have done a lot of compatibility testing as part of automated regressions, across linux, os x, and many versions of windows, with the full set of browsers in each space. I have never run into an instance of a css selector not working everywhere.

On Wednesday, February 27, 2013 4:28:16 AM UTC-8, Arran wrote:

[Arran Huxtable]

Most CSS3 selectors, like nth-child & nth-of-type.

If the browser supports document.querySelector then Selenium will use that for CSS selector querying.

If it doesn't, Selenium injects Sizzle into the page to workaround that. Sizzle is the CSS selector behind jQuery.

Since IE8 does support document.querySelector, it will not inject Sizzle but use that instead.

IE8 doesn't support any CSS3 selectors and thus, IE8 will just return an error (it will be that it cannot find the element)

Further proof can be found by running something like document.querySelector('a:nth-child(2)') in IE8's Developer tools, you'll see it will not work either (should error horribly if I remember rightly)

--
You received this message because you are subscribed to a topic in the Google Groups "Selenium Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/selenium-users/pugZh1AXVMU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to selenium-user...@googlegroups.com.

To post to this group, send email to seleniu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-users/ad0e0979-cdc5-4976-9c3d-eb7f32c63d4b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David]

Well, in the worse case where CSS natively don't work well like in IE8, there is option to inject Sizzle or jQuery manually and then use that to find elements (whether via custom By class or just via pure javascript execution to return DOM WebElement).

I also do find CSS is lacking in sibling selection in that you can't quite do preceding-sibling like you can with XPath, it's more for following-sibling. And there are things you still can't do in standard CSS3 like these:

http://stackoverflow.com/questions/22779225/xpath-feature-name-for-these-and-comparison-to-css-selectors

Also, it is nice to be able to traverse back up the DOM tree sometimes that CSS lacks. 

I tend to like to define my locators such that looking at the locator definition/value itself can point you to the element on the screen without really having to peak into the DOM, and this can be helpful whether your locator variable/constant is well named or not. That can be achieved sometimes by clever use of text contains() and node traversal up/down along with sibling referencing, and/or feature referencing techniques I mentioned in the stack overflow link. Much harder to do in CSS due to the limitations, so I end up with a workable and nice CSS but not visually descriptive such that you do have to peak into the DOM to correlate visual element to locator.

[Arran Huxtable]

If you are electing to use JS or Sizzle to find an element and not using something like native, like XPath, then you are doing something very very wrong.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-users/efb7db56-0e44-452d-a00d-9f945caa4db0%40googlegroups.com.

[David]

I only mentioned jQuery and Sizzle as an option for those who prefer to stick with CSS when it is lacking since Sizzle supports the contains() pseudo selector method that CSS3 doesn't.

Obviously going native is better. As for JS, there is nothing wrong to use the native support of DOM document object methods like document.getElementById(), etc. though one would wonder why not use the native Selenium findBy methods instead, but there may be rare cases you may want to resort to the document object in JS (it happened in the past when the native method had issues in SafariDriver).

[Филипп Левин]

Here's some nice information about Xpath and CSS selectors' usage performance. With real numbers and graphics. 

http://elementalselenium.com/tips/34-xpath-vs-css-revisited-2

[Paul]

It may sound that we are deviating from the actual discussion point, but why we keep only one locator through out the Automation project?

Is it the most optimum approach to keep elements using only one type of locator in our Object Repository,if Yes then why we have different methods like By.xpath, By,name, By.partialLinkText etc...if No then there is no point to discuss...

[suneel kumar]

They are just two different types of way of locating the Web element.

They just provide various ways to overcome the challenges faced because of different development technologies.

Now to answer your question, in many Web pages the XPath changes very frequently whereas CSS would be little bit stable. So you need not to change it frequently.

Sometimes if the CSS is same for more than one element, you have to go for XPath(assuming you don't have static id or name or something else ).

Everything has it's own advantages and disadvantages. Just use them accordingly.

Regards,
Suneel oleti

--

You received this message because you are subscribed to the Google Groups "Selenium Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-user...@googlegroups.com.

To post to this group, send email to seleniu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-users/f485c7f7-a4fb-4373-bb6b-0d5fa8ae9907%40googlegroups.com.

[Sridevi Sugumaran]

CSS selectors perform far better than Xpath and it is well documented in Selenium community. Here are some reasons,

• Xpath engines are different in each browser, hence make them inconsistent
• IE does not have a native xpath engine, therefore selenium injects its own xpath engine for compatibility of its API. Hence we lose the advantage of using native browser features that WebDriver inherently promotes.
• Xpath tend to become complex and hence make hard to read in my opinion

SRIDEVI S. INDIUM SOFTWARE, AUTOMATION COE

http://www.indiumsoft.com/core-qa-offerings/test-automation

[Arran]

1) Possibly, but with Firefox/Chrome I'd be shocked to see any differences.

2) Yes

3) Debatable. If people learned the language (XPath) then the XPath queries you come up with can be fine and fast to run. However if you rely on tools to do it for you, then no. They are going to be horrible and slow. It's the same for anything. You let a tool generate C# for you, it's going to be horrific. XPath is no different. It's still a language to learn and understand to get the best results out of it. "Bad XPath queries come from people not bothering to understand the language.

[Vikram]

Few thoughts from my side

1. I think it depends on your web app as well.

2. In my case I've used xpath almost for 95% of weblement , but they are hand-made means I didn't used once generated by IDE/FireBug etc . I have put check points like look for element under particular class type or any other unique attribute etc

3. It has worked really well for Chrome , FF , Safari.

Regards,
Vikram