IE8b1 представляет поддержку очень интересной спецификации — Selectors API. Пока что это W3C working draft, но бьюсь об заклад, что т.к. IE и Webkit уже реализовали спецификацию, Presto и Gecko не заставят себя ждать.
UPDATE: разработчики Firefox пояснили, что в релизе 3.0 ожидать поддержки Selectors API не приходится, однако в 3.5 оно, скорее всего, реализовано будет.
Итак, что мы имеем? Cпецификация содержит два новых метода интерфейса IHTMLElement'a —
Таким образом, у нас появляется новый элегантный и удобный способ поиска документов в DOM'е.
Можно будет забыть об изобретениях вроде
В данный момент эти методы есть почти во всех популярных js-фреймворках, но в браузерах, не поддерживающих Selectors API работают они по одному принципу — обходят DOM и ищут элементы, соответствующие заданному CSS-селектору.
Для того, чтобы сравнить производительность библиотек и родной поддержки Selectors API авторы Webkit создали testcase. Результаты как Webkit'a, так и IE8b1 впечатляют.
Впрочем, необходимо помнить, что Selectors API ограничены уровнем поддержки браузером CSS-селекторов. Не поддерживает IE8b1 CSS3-селектор
Не обошлось и без небольшой ложки дёгтя — IE8b1 поддерживает спецификацию Selectors API лишь частично, вот цитата из статьи в MSDN:
Но для сайтов, где namespaces не используются, эта ложка дёгтя бочку мёда не испортит.
Также интересный факт — реализация Selectors API открывает потенциальную угрозу кражи информации о посещённых страницах в случае успешного внедрения javascript'а на страницу-жертву можно отправить href'ы всех
В результате IE8b1 игнорирует псевдоклассы
А вот и пример!
UPDATE: разработчики Firefox пояснили, что в релизе 3.0 ожидать поддержки Selectors API не приходится, однако в 3.5 оно, скорее всего, реализовано будет.
Итак, что мы имеем? Cпецификация содержит два новых метода интерфейса IHTMLElement'a —
querySelector() и querySelectorAll(), которые принимают в качестве параметра строку с любым корректным CSS-селектором. querySelector возвращает ссылку на первый HTMLElement, удовлетворяющий указанному CSS-селектору; querySelectorAll возвращает StaticNodeList с элементами, удовлетворяющими указанному CSS-селектору.Таким образом, у нас появляется новый элегантный и удобный способ поиска документов в DOM'е.
Можно будет забыть об изобретениях вроде
document.getElementsByClassName — нужно всего лишь выполнить document.querySelectorAll(".myClass") и получить все элементы с данным классом.В данный момент эти методы есть почти во всех популярных js-фреймворках, но в браузерах, не поддерживающих Selectors API работают они по одному принципу — обходят DOM и ищут элементы, соответствующие заданному CSS-селектору.
Для того, чтобы сравнить производительность библиотек и родной поддержки Selectors API авторы Webkit создали testcase. Результаты как Webkit'a, так и IE8b1 впечатляют.
Впрочем, необходимо помнить, что Selectors API ограничены уровнем поддержки браузером CSS-селекторов. Не поддерживает IE8b1 CSS3-селектор
:last-child, и не вернёт document.querySelectorAll("body:last-child") ничего.Не обошлось и без небольшой ложки дёгтя — IE8b1 поддерживает спецификацию Selectors API лишь частично, вот цитата из статьи в MSDN:
Because Internet Explorer 8 does not formally support XHTML documents, it does not support the namespace features of the W3C Selectors API specification, such as the NSResolver parameter.
Но для сайтов, где namespaces не используются, эта ложка дёгтя бочку мёда не испортит.
Также интересный факт — реализация Selectors API открывает потенциальную угрозу кражи информации о посещённых страницах в случае успешного внедрения javascript'а на страницу-жертву можно отправить href'ы всех
document.querySelectorAll("a:visited") и таким образом узнать, какие ссылки на данной странице пользователь уже посещал. Спецификация оставляет разрешение этой проблемы производителю, реализующему Selectors API.В результате IE8b1 игнорирует псевдоклассы
:visited и :link в качестве параметров querySelector/querySelectorAll.А вот и пример!
