CSS vs XPath

Коллеги.

Чем отличается XPath от СSS?

На мой взгляд CSS более читабелен.

Что нашел:

Traversing the DOM in older browsers like Internet Explorer 8 does not work with CSS but is fine with XPath. And XPath can walk up the DOM (e.g. from child to parent), whereas CSS can only traverse down the DOM (e.g. from parent to child).

Приведите, пожалуйста, пример в доходчивой форме, как мне это поможет.

Пока я предпочитаю CSS, кто переубедит?

Спасибо.

а этого разве не достаточно ? по моему это большой + в пользу xpath, хождение от чайлда к паренту и далее от парента к другому чайлду , например.

Особенно если тебе нужно протестировать значения строки в таблице.

а этого разве не достаточно ? по моему это большой + в пользу xpath, хождение от чайлда к паренту и далее от парента к другому чайлду , например.

Особенно если тебе нужно протестировать значения строки в таблице.

Согласен, + в Xpath есть оси

Не помню, если в CSS contains, но что реально напрягало, что в CSS нет last(выбрать последний элемент или last()-1 - предпоследний), OR, count и т.п.

Согласен, что CSS более читабелен.

Особенно, когда элемент удобно идентифицировать по классу, а их в атрибуте несколько, весьма приятно написать tag.some-special-class вместо tag[contains(@class,'some-special-class')].

Однако, пару раз сталкивался, что при последовательном поиске элементов с разными типами селекторов (нашли один, внутри него - другой и т.п.) драйвер иногда начинает искать от корня при смене типа селектора, т.е. игнорирует контекст поиска.

Теперь больше не рискую и использую один тип селекторов. Ну, и выбор чаще делается в пользу XPATH из-за более богатого функционала.

Кстати, не знаю, было это или нет на форуме, но вот ссылка на шпаргалку по разным способам поиска:

https://www.simple-t...-rosetta-stone/

+ css  быстрее http://stackoverflow...tteraccording-t

+ css лаконичнее

Не помню, если в CSS contains, но что реально напрягало, что в CSS нет last(выбрать последний элемент или last()-1 - предпоследний), OR, count и т.п.

 

CSS contains  - [attribute~=value]

last()-1            - :nth-last-child(-n+2) /* represents the two last rows of an HTML table */

OR                  - ,

но минусы есть

- нет возможности проверить текст в ноде

- нельзя обратиться к родительской ноде

Я стараюсь использовать css везде, где не нужно находить элемент по тексту внутри (а это как по мне всегда плохо) и если нужен сложный селектор с использованием родителя

Однако, пару раз сталкивался, что при последовательном поиске элементов с разными типами селекторов (нашли один, внутри него - другой и т.п.) драйвер иногда начинает искать от корня при смене типа селектора, т.е. игнорирует контекст поиска.

тоже сталкивался в случае если сначала css а потом xpath. В таком случае мне помогло начинать xpath с "./"

Извечная тема. Переубеждать не буду, так как тоже предпочитаю CSS, но зачастую приходится комбинировать, особенно когда нужно искать по тексту в теге. Соглашусь с теми, кто считает что CSS более удобочитаем.

Всем спасибо. Вывод сделал следующий - буду продолжать использовать CSS в пользу более удобочитаемости, если не справится, то XPath. При парсинге резюме с работных сайтов пока CSS полностью справлялся. Вопрос возник, т.к. по моим личным наблюдениям сообщество Селениум предпочитает XPath. Опять же это мои личные наблюдения или просто по XPath задают больше вопросов.

Вопросы по XPath задают начинающие, начинающие, XPath - сами знаете как получают, а дальше либо происходит осваивание css или не происходит )))

по моим наблюдением многие даже не пытаются разобраться с css. С XPath разобрались, зачем еще напрягаться :)

по моим наблюдением многие даже не пытаются разобраться с css. С XPath разобрались, зачем еще напрягаться :)

По моим наблюдениям :))))...
...многие любят, когда вебэлементы "помечены". Мы от своих требуем необходимые элементы помечать id-шниками - ИМХО читабильно, понятно, да и разрабы знают что за ними люди тестировать будут.