John Resig 씨는 "새로운 Selectors API 명세(와 이어질 구현체)에 대해 흥분하지 않을 JavaScript 개발자는 없을 것"이라고 했습니다.

그는 API에 대한 피드백을 제공해주기를 요청받았고, 다음과 같은 내용의 메일을 보냈습니다.

그는 세가지를 고려했습니다:

잘못된 엘리먼트를 반환하는 DOMElement.querySelectorAll

이것이 가장 치명적인 이슈입니다. 이것 덕분에 DOM 엘리먼트 기반의 쿼리들은 라이브러리와 사용자들에게 거의 쓸모가 없습니다. 기본 동작은 예상을 벗어나고, 혼란스럽습니다. Dojo를 사용한 예제를 실행해보세요:그 후 그는 다른 라이브러리 개발자들에게 동의하는지 물어보았습니다:

Andrew Dupont (Prototype의 셀렉터 엔진 작성자):

이것과 관련한 저의 논지는 이것이 최소 놀람의 법칙을 위반하고 원래의 API와 닮은 구석이 없다는 것입니다.

Alex Russell (Dojo의 셀렉터 엔진 작성자):

이건 스펙상의 버그입니다.

결합자(Combinator) 기반 쿼리

저는 이전에 이와 관련된 몇가지 논의를 읽었습니다(특히 DOMElement.querySelectorAll - 스타일 쿼리와 관련있는). 이것은 그대로 대부분의 라이브러리에서 중요한 부분입니다. Maciej씨가 제안한 해결책에 - 선행 결합자를 허용하는 :root를 사용한 - 저도 완전히 동의합니다(:root가 document element가 아닌 element와 동등하게 만들어져있는 한).
라이브러리는 이것을 쉽게 찾아내고 삽입할 수 있습니다.

에러 처리

저는 제안된 try/catch 해결책이 마음에 들었습니다, 하지만 셀렉터의 어떤 부분이 잘못되었는지 쉽게 알려줄 방법이 있어야만 합니다. 현재 Safari에선 다음과 같이 발생합니다:만약 셀렉터의 적합하지 않은 부분을 가리키는 특별한 속성이 있었다면, 그것은 원래는 중요한 것입니다. 아마도 아래와 같이 작동하는 문자 인덱스를 제공하는 것이 최선의 해결책(구현자와 JavaScript 라이브러리 개발자 모두에 있어)이 될 것입니다:
이 모든 것을 공개적으로 볼 수 있어 좋습니다. 특히 우리에게 영향을 끼칠 스펙에 라이브러리 개발자들이 참여하는 것을 지켜볼 수 있어서 말입니다.

from We are JavaScript library authors. Hear us roar! on Ajaxian