Так что для специфических задач getClientRects пойдёт, а для мелких и частых изменений состояния, возможно, лучше более примитивные. Безусловно, одна операция копеечная — даже в Chrome всего 2 мкс.
Кстати, на самом блоке getBoundingClientRect существенно быстрее (тот же 1 000 000 итераций):
200 мс [FF]
100 мс [Chrome]
Так что я ошибался с мыслью, что реализация client-, offset-, scroll- параметров так же затратна, как и определение областей элементов.
Да вроде метод-то поддерживается с незапамятных времён. Так что единственный вопрос — производительность. То ли clientRects(), то ли расчёт высоты и деление (возможно, с округлением).
Терзают смутные сомнения, что для clientHeight задействуются механизмы, схожие с теми, что и при clientRects().
Остроумности?))) Звучит почти как запоздалость или ходибельность...
Автор дрыхнет давно, и снится ему, как он в штанах с енеральскими лампасами бороздит по Силиконовой долине, а инвесторы как назойливые мухи кружат, только отмахиваться успевай.
@rimosevskij ниже @MaxKorz написал вариант вызова независимо от места в коде страницы. Такой вариант вызова подразумевает наступление события DOMContentLoaded — DOM построен, можно заняться траверсом.
Вот только это — жесть $('a').live('click', function(){})
Во-первых, этот метод давно deprecated, используем on().
Во-вторых, зачем нужно находить все ссылки и тратить на это ресурсы браузеры? При том, что на 99% ссылок никогда не кликнут.
Представьте, что в раковине гора грязных тарелок, вам нужна одна, а вы как дурак моете все. Понятно, что тут я какбэ пошутил, но правильно отслеживать всплытие (это ещё называют делегированием) $(document).on('click', 'a[href]', function(){})
@bookworm я не до конца понял вопрос, тут уж извините — конечно, контент обязан соответствовать всем устройствам, для которых предназначен.
Я не в курсе особенностей работы парсеров ePub — вроде в описании формата нет жёсткого требования к XML синтаксису. С учётом того, как подружили HTML5 и разновидности XML типа SVG, а также ориентации ePub на HTML5, мне кажется, что жёсткого требования и не будет.
Про замену в контенте символов, на которых ломается XML -парсер (даже в свете всеядности HTML-парсера) всё понятно — ты мы единодушны. Лучше заменять, чем не заменять:)
Ну а про модификацию DOM я уже сказал, что как только появляются дополнительные требования, то фтопку innerHTML и здравствуйте, createElementNS().
ПыСы. Я про закрывающий тэг и писал, хотя с точки зрения парсера, отсутствие закрывающей скобки в тэге — ровно такое же отсутствие тэга.
@Ayk72 это не имеет значения. Почему не должно быть?
Полученный ответ — текст. Что на деле он представляет — вам решать. XML, JSON, просто текст, или с текст с тэгами — это определяет фронтенд разработчик.
Если получаете HTML, то будете просто его вставлять куда нужно, заменяя предыдущее содержание. Или добавляя... Тут вам решать, что происходить должно:)