Мне стало интересно, почему практически во всех случаях XPath работает медленее (пуская в доли секунды для FireFox или секунды для Internet Explorer) чем CSS?
когда страница загружается - браузер парсует CSS в любом случае, тогда селениум просто обращается к уже загруженному объекту. когда же речь идет про xpath - HTML парсуется по запросу, но один раз за страницу - так что второй запрос к xpath на странице будет немного быстрее, но все равно не так как CSS. А отсюда уже претензии к разработчикам парсера (не селениум)
Дело в том, что CSS-локаторы были разработаны специально для HTML, а XPath-локаторы -- это универсальный механизм для поиска по XML DOM.
Поэтому для CSS идентификатор и имя -- это особые атрибуты, он строит табличку-индекс для быстрого обращения к элементам, снабженным этими атрибутами. Поскольку эти атрибуты должны быть уникальными, индексация работает очень эффективно. А с точки зрения XPath -- это "просто атрибуты", поиск ведётся не по таблице-индексу, а по всему DOM-дереву.
Поиск по классу уже не так эффективен, а поиск по контенту в обоих случаях работает без индексации, здесь разница между XPath и CSS незначительна.
Спасибо, я не знал о такой таблице, а где можно больше почитать о ней?
В CSS спецификации даже упомянули "Selectors have been optimized for use with HTML and XML, and are designed to be usable in performance-critical code.". Походу они своего добились.
Про name надо уже смотреть реализации на JS. Насколько я понял, в этом ролике речь идет про Se1, он использует библиотеку Sizzle, вот там и надо искать.
То что можно использовать метод document.getElementById - понятно, что хотелось найти “строит табличку-индекс для быстрого обращения к элементам”. Так и не нашел.
Я посмотрел на реализации Sizzle и jQuery -- для поиска по имени они обращаются к другой стандартной функции getElementsByName -- http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/html.html#ID-71555259 , то есть реализация опять таки нативная, надо искать в коде браузеров. Именно там прячутся эти таблички-индексы.