Имелась ввиду проверка наличия дочерних элементов по аналогии с hasChildNodes, который проверяет наличие дочерних узлов, т.к. текстовые узлы не могут содержать дочерние узлы, то проверка:
node.getElementsByTagName("*").length
всегда верно будет показывать факт наличия дочерних элементов, но не всегда правильно их количество.
Так варнинги были из-за присваивания внутри while, вроде break здесь не причем.
А о том, что так быстрее, в этой ситуации на 2-х проверках конечно бессмысленно о каком то выигрыше в скорости говорить, я просто взял себе за правило, всегда писать сравнение со строкой без привидения типов, т.к. это гораздо быстрее при сравнении разных типов, но тут typeof выдает строку, поэтому наверное, никакой разницы не будет в скорости, поспешил я написать :-)
Стандартные методы, геттеры и сеттеры тоже в прототипе находятся, не думаю, что добавление еще нескольких пользовательских геттеров в прототип объекта Element/HTMLElement для браузеров, не поддерживающих ElementTraversal, существенно понизит производительность, но все же попробую протестировать.
Наверное, решили не дублировать уже имеющийся во всех браузерах, кроме Firefox, геттер children, пришедший из IE4, а для Firefox его можно сделать тем же __defineGetter__. Кстати, children появится в новой версии Firefox 3.5, об этом написано в MDC на странице «Firefox 3.5 for developers» в разделе «Other improvements».
Да браузеры не грузят каждый раз указанный файл с доктайпом, но речь то не об этом. Проблема в том, что от DTD зависит работа с DOM в Javascript и CSS. Да сейчас отличия только в режимах без доктайпа (QuirksMode) и c DTD (Standards Compliance Mode), а между версиями Transitional и Strict в XHTML 1.0 врятли в работе Javascript найдутся отличия, но кто может гарантировать что теже евангелисты из Mozill'ы не сделают в очередной новой версии браузера бесполезным для работы в режиме Strict, к примеру, такой код:
document.createElement("iframe")
или
element.setAttribute("target", "_blank")
Да я согласен, что это маловероятно :-) просто если есть возможность следовать стандартам, лучше так и делать :-) хотя бывают и исключения.
Да, но все же DTD влияет на работу с DOM, возьмите к примеру document.all в Gecko, который доступен только в Quirks Mode, или scrollTop для document.body и document.documentElement в Internet Explorer. Нет уверенности, что не выйдет новая версия браузера с каким нибудь Super Standards Compliance Mode, в котором будут игнорироваться не описанные в DTD атрибуты тегов, для которых браузер должен автоматически синхронизировать соответствующие свойства DOM-элементов.
Нет, я правильно написал, для списка значений, разделенных пробелом нужно использовать ~=, в документации по jQuery его почему-то нет, но он поддерживается (строка №2028 в jQuery 1.3.2):
type === "~=" ?
(" " + value + " ").indexOf(check) >= 0 :
В старых версиях тоже есть поддержка такого селектора атрибутов, а так же он является стандартным и описан в спецификации.
jQuery же может сразу для всего списка атрибуты изменить, и селектор атрибута неправильно подобран, нужно использовать ~= для списка значений, разделенных пробелом:
Хм… проверил, querySelectorAll в новых версиях Chrome и Safari стали возвращать просто NodeList, а Opera 10a и IE8RC1 так и возвращают по прежнему «StaticNodeList»
…the collection (being static) will not be updated when the element tree changes.
теперь понятно для чего все к Array приводить, похоже стандартов даже в новейших возможностях нам не увидеть :-)
Звените :-) мне показалось, что вы не правильно понимаете, почему возрастает производительность в новых браузерах, и какое к этому отношение имеют библиотеки типа Sizzle.
Когда вы смотрите тесты в Slick Speed, там нет не стандартных селекторов (потому что не все тестируемые библиотеки их поддерживают), все примеры соответствуют синтаксису CSS, а значит в браузерах Opera 10, Safari 3.2, Google Chrome 2, IE8, Firefox 3.1 вы смотрите не производительность движка селекторов Sizzle, YASS, Pappy или еще какого-то, а производительность браузера при работе со стандартным для него методом querySelectorAll, в который при возможности (когда селектор стандартный или соответствует синтаксису CSS2.1, как в IE8RC1) эти библиотеки просто передают параметры напрямую, т.е., если отбросить условия, в простейшем случае это выглядело бы так:
function Sizzle(selector) {
var result;
if(document.querySelectorAll) {
result = document.querySelectorAll(selector);
}
else {
// тут алгоритм поиска для браузеров,
// не поддерживающих querySelectorAll
}
return result;
}
Поэтому не позволяйте себя запутать красивыми диаграмками, иллюстрирующими, как выросла производительность в новых браузерах. Реальную скорость движка можно увидеть только в старых браузер, либо в сравнение не стандартных селекторов, если такие есть в нескольких библиотеках.
всегда верно будет показывать факт наличия дочерних элементов, но не всегда правильно их количество.
Я перепробовал всякие NeoReader, UpCode, Semacode, QuickMark и др., но I-nigma показался мне самым лучшим вариантом.
А о том, что так быстрее, в этой ситуации на 2-х проверках конечно бессмысленно о каком то выигрыше в скорости говорить, я просто взял себе за правило, всегда писать сравнение со строкой без привидения типов, т.к. это гораздо быстрее при сравнении разных типов, но тут typeof выдает строку, поэтому наверное, никакой разницы не будет в скорости, поспешил я написать :-)
Не сталкивался с проблемами при использовании children, можно подробнее?
Вообще я за то, чтобы пользоваться всей гибкостью языка, но тоже поправил :-)
Так быстрее
Разницы в скорости не заметил :-)
или
Да я согласен, что это маловероятно :-) просто если есть возможность следовать стандартам, лучше так и делать :-) хотя бывают и исключения.
В старых версиях тоже есть поддержка такого селектора атрибутов, а так же он является стандартным и описан в спецификации.
$('a[rel~="external"]').attr("target", "_blank");теперь понятно для чего все к Array приводить, похоже стандартов даже в новейших возможностях нам не увидеть :-)
Поэтому не позволяйте себя запутать красивыми диаграмками, иллюстрирующими, как выросла производительность в новых браузерах. Реальную скорость движка можно увидеть только в старых браузер, либо в сравнение не стандартных селекторов, если такие есть в нескольких библиотеках.