float,
ну так именно об этом и речь, главное скорость и достоверные результаты. Чем-то приходится жертвовать. Хотя что-то мне подсказывает, что совсем не сильно понизится производительность если в цикле будет 5 дополнительных if, я б даже сказал что практически совсем не понизится, будет регулярка такая TYPE|ID|CLASS|ATTR|PSEUDO|UNMATCHED, все виды простых селекторов могут быть описаны со всей грубостью и жестокостью, а если не один из них не подойдет под критерий, то мы увидим UNMATCHED, и просто смотрим, если этот карман содержит значение, кидаем ошибку. Ну на словах просто, на практике чуть больше проверок будет возможно..

poorking,
спасибо, я реально от подобных повисаний писал специально условие. Но как оказалось не дописал. То-есть нужно было еще в одном месте написать условие.

Сейчас исправил версию, подправил регу. Дописал условие на проверку гнилых селекторов.

насчет ковычек хотел сказать. Парсер работает по такому принципу:
допустим есть атрибут [blah*="test"] или такой [blah*='test'] или такой [blah*=test] в этом случае он его разобъет так:

blah
*=
test

если же попадется такой как вы указали: [blah*='test\"]
то он разобъет его так:

blah
*=
'test\"

тоесть будет искать подстроку вместе с кавычками в атрибуте.

Нашел оставленную на память регуляшку. Описание скобок:

( 1 - Запятая или комбинатор слева - ошибка если заполнено)?

(

2 - литерал ИД или КЛАССА (чтобы понимать для кого скобка 3)
3 - значение ИД или КЛАССА

ИЛИ

(4 - Пространство имен селектора ТИПА)?
5 - Значение селектора типа

ИЛИ

( 6 - Пространство имен селектора атрибута )?
7 - имя атрибута
(8 - тип сравнения значения аттрибута с переданной строкой
9 или 10 или 11 - значение аттрибута)?

ИЛИ

12 - псевдокласс
(13 - аргумент псевокласса)?

ИЛИ

14 - ошибка
)

(
15 - запятая или комбинатор (если нет его, то далее будет сова прстой селектор)
)?

var GRINDER = /\s*([,>+~])?\s*(?:([#\.])(-?(?:\\[\s\S]|[_a-zA-Z\u0080-\uFFFF])(?:\\[\s\S]|[\w\-\u0080-\uFFFF])*)|(?:(-?(?:\\[\s\S]|[a-zA-Z_\u00C0-\uFFFF])(?:\\[\s\S]|[\-\w\u00C0-\uFFFF])*|\*)?\|)?(-?(?:\\[\s\S]|[a-zA-Z_\u00C0-\uFFFF])(?:\\[\s\S]|[\-\w\u00C0-\uFFFF])*|\*)|\[\s*(?:(-?(?:\\[\s\S]|[a-zA-Z_\u00C0-\uFFFF])(?:\\[\s\S]|[\-\w\u00C0-\uFFFF])*|\*)?\|)?(-?(?:\\[\s\S]|[_a-zA-Z\u0080-\uFFFF])(?:\\[\s\S]|[\w\-\u0080-\uFFFF])*)(?:\s*(\S|)=\s*(?:'((?:\\[\s\S]|[^'\n\r\f])*)'|"((?:\\[\s\S]|[^"\n\r\f])*)"|(-?(?:\\[\s\S]|[_a-zA-Z\u0080-\uFFFF])(?:\\[\s\S]|[\w\-\u0080-\uFFFF])*)))?\s*\]|:(-?(?:\\[\s\S]|[_a-zA-Z\u0080-\uFFFF])(?:\\[\s\S]|[\w\-\u0080-\uFFFF])*)(?:\(((?:'(?:\\[\s\S]|[^'\n\r\f])*'|"(?:\\[\s\S]|[^"\n\r\f])*"|\((?:\\[\s\S]|[^()])*\)|\\[\s\S]|[^()])*)\))?|([^,>+~\s]+))(?:\s*(?:$|([\s,>+~])\s*))?/g;

Если это погонять в цикле,

while ( m = GRINDER.exec(selectror) )

то из

var selector = " NS|TYPE#ID.CLASS + :PSEUDO(ARG)[NS|ATTR='VAL'] "

можно собрать что-то типа

[ [ ["TYPE", "NS"], ["ID"], ["CLASS"] ], [ ["PSEUDO", "ARG"], ["ATTR", "=", "VAL", "NS"] ] ]

Каждую итерацию по номеру заполненных скобок мы можем узнавать какого типа простой селектор и сразу брать его, уже разобранного на части. Когда появлялся m[15], я по содержимому, определял что будет дальше, следующая последовательность (комбинатор + последовательность простых) или вообще следующий одиночный селектор (если там запятая)

Чтобы понимать в коде выборок к какому типу простого селектора относятся эти распарсенные куски, можно определить константы для разных типов и записывать значения например свойством массива (в котором кусочки простого селектора). Так же для оберток этих простых селекторов (последовательностей простых селекторов) и комбинаторов. Потом можно будет эти sequense сортировать, чтобы применять в том порядке в каком лучше. Ну это я так думаю, регулярное выражение писал давно, мне лень тестировать его производительность, но теоретически оно не шибко шустрое, 15 скобок, хотя я не исследовал производительность регекспов.

За парсер, код которого к сожалению не сохранился, могу только одно сказать, что синтаксис селекторов полностью соответствовал спецификации и нельзя было передать не правильный селектор, 100% было бы SyntaxError

Ну вот в реге что я привел, я значение ищу без ковычек, поэтому, значение находится в одной из 3х скобок '(STRING1)'|"(STRING2)"|(IDENT), не оптимально конечно, но тогда было интересно именно разобрать правильно, как я уже говорил на механизме выборок я остановился, find Просто возвращал [], а match false, хотя каркас был, надо будет восстановить

а что начет таких селекторов?

NS|TYPE#ID.CLASS + :PSEUDO(ARG)[NS|ATTR='VAL'][NS|ATTR='VAL'][NS|ATTR='VAL']

несколько атрибутов подряд

все будет ок, за одну итерацию находит один простой селектор

да но эти атрибуты относятся к одному элементу, тоесть это не разные селекторы, а просто для элемента нужно найти допустим:

a[href=blah][rel=test]

то есть найти элемент А с трибутом href который содержит blah и атрибутом rel который содержит test

О раз уж ты в теме селекторов сейчас, можешь сказать достаточно ли такой регулярки, чтобы убрать ненужные слэши?

<prefix:tag-name class="class\name">

alert("prefix\\:tag-name.class\\\\name".replace(/\\([^\w\s])/g, "$1"))

все что внутри кавычек в значениях атрибутов предварительно через escape заменено.

не понимаю зачем поставлены слеши после prefix это что двоеточие за экранировали чтоль? тут какие-то правила экранирования как я понял. обычно достаточно двойные слеши заменить на одиночные.