devote,
кстати сизл так работает потому, что так так работает реальны css селектор :)

возможно, но тесты дают не лучший результат при обратном поиске. у меня частично так реализовано, для некоторых правил, но не для всех.

Оперу я так, интереса ради. На старух браузерах qsa всегда лидирует в общем зачёте. Но для оперы 8,5, например, это только за счёт разницы в полминуту, так бы проиграл.
А вообще я прицепился потому, что в принципе во всех браузерах qsa не всегда, но часто проигрывает на старте, а там как бы самые употребительные селекторы...
А вообще этот тест немного странный. На одних и тех же ячейках иногда очень разный результат... Мб из-за работы сборщика или ещё чего...

И это тоже... сложно выяснить средний результат от одного запуска, тут надо сидеть с десяток раз запускать и смотреть средний результат.

Обновил версию

devote,
Так что нового?, это ж самое интересное :)

Посмею пролить немного занудной слизи по поводу этих движков селекторов. Когда cмотришь регулярные выражения подобных творений, складывается впечатления что авторы не потрудились посмотреть грамматику селекторов в спецификации, где, чуть ли не готовые регулярные выражения написаны. Конечно адекватный пользователь интерфейса (который заведомо кривые селекторы вводить не будет), не натолкнется на косяки, но раз уж авторы утверждают, что движок dom выборок по CSS селекторам, то я думаю, что нужно соответствовать спецификации, раз уж мы имеем право гневно обсуждать, например, разработчиков браузеров, которые им не следуют. Например, приведу, некоторые из частей регулярного выражения QSA. В спецификации есть понятие IDENT, в QSA это выглядит вот так

[\w\-]+

Хотя по спецификации IDENT выглядит, если не ошибаюсь, вот так

-?(?:\\[\s\S]|[_a-zA-Z\u0080-\uFFFF])(?:\\[\s\S]|[\w\-\u0080-\uFFFF])*

Это конечно наглеж, но я хотя бы вот так написал

-?[_a-zA-Z][\-\w]*

чтобы цифру первой не вводили


И так далее. Такие допущения позволяют пользователю вводить невалидные данные и получать в лучшем случае никакой результат, в худшем - повисший браузер. Но это еще ладно.

У меня есть элемент

<a href = "javascript: void 0">

Я накосячил, написал

qsa.querySelectorAll("a[href*='jav\"]")

И получил [], и не понимаю почему? ведь если бы я неправильно ввел что-то, то получил бы SyntaxError, верно? А элемент искомый в моем документе 100% есть. Потом я ввел "a[href*='jav\"] +" и браузер вообще ушел куда то в бесконечность, дальше исследовать не стал.

Нет стал, еще интересный момент. В последовательности простых селекторов NS|TYPE#ID.CLASS[NS|ATTR]:PSEUDOFN(ARG) селектор типа может быть ТОЛЬКО первым номером. Но рядовой регексп с радостью обнаружит селектор типа например в таком случае [ATTR]TYPE или в таком :not(ololo)div, я в своем парсере ( однажды заморочился и написал парсер такой, который не позволял вводить невалидные данные, но выборки сделать сравнительно быстрые не получилось, особенно на том моменте где идет удаление дубликатов и сортировка (дубликаты ок, но наф вообще сортировка?) ) это все контролировал и кидал SyntaxError. Но к сожалению если все это учесть, то регулярка получается толстенная, которая ловит еще и ошибки, в ней около 15-20 карманов и возможно (я тогда не сравнивал) было не шибко производительно

А если без занудства, то движок реально крут, что так быстр.
IMHO qsa настолько быстр потому что не валидирует входные данные, а парсер очень мягок

poorking,
полностью соглашусь с тобой по поводу придерживания стандартов. Я не старался искать ошибки и их обрабатывать. НО! Скорость важнее, это же все же не нативный метод. Хотя если сравнивать с многими другими селекторами, то там обзор характеристик куда хуже. Не то что бы ошибки ловили, а порой и на валидных селекторах падают.

Да я читал спецификацию, и видел готовые реги для тех или иных случаев, но меня в первую очередь интересовала скорость работы с валидными селекторами. То что виснет, конечно не есть гуд. Обязалово посмотрю. Но проверять каждую мелочь, хм... а стоит ли? Нужно ли пожертвовать скоростью и компактностью ради проверок?

devote,
Если вы хотите чтобы ваш движок был попопулярен, то надо найти компромисс, то есть контролировать реально наглые опечатки типа TYPE + (и после комбинатора нет селектора), и обеспечить неконкурентную производительность.

Про селектор типа не обязательно на первом месте можно вообще сказать что это фича, а кавычки написать так, чтобы левая была двойная, а правая одинарная, или наоборот, только безумцу может прийти в голову, в Sizzle вообще без облома написано ['"][^'"]['"] (давно смотрел сейчас не знаю) хотя это не верно, потому что вот так например "'" не написать, хотя валидно. Думаю это можно упустить. Так что если для масс - то главное хотя бы чтобы не висло ничего, и бегало быстро :) А специально чепуху аргументами вводить никто не будет, потому что это никому не надо, главное контролировать всякие левые типы кроме строк :)

Да согласен, постараюсь это все организовать.

Ну у меня селектор нормально находит такие селекторы.

Вообще-то любые проверки сильно ударяют по скорости(хотя в регэкспах может и не особо. смотря где.)...
Помойму главное гарантировать то что не произойдёт зависания/зацикливания функции. А там: может имя класса с цифры начинаться или не может - дело десятое.
Хотя с другой стороны... Расхождение в поведении с встроенной функцией(в плане выброса исключений) тож не хорошо.