Комментарии 26
отличное улучшение. а то приходилось прибегать к различным сложностям для реализации live
и надеюсь это не одно улучшение 1.3. Хотелось бы еще работы с адресной строкой и куками
и надеюсь это не одно улучшение 1.3. Хотелось бы еще работы с адресной строкой и куками
+2
Да, эта новая функция позволит изначально задать функциональность для типов элементов на странице, а затем выстраивать из них интерфейс. Такой путь конечно будет более универсальным и удобным.
0
скорее, она позволит не думать о функционале при изменении DOM
ведь все равно функционал, по хорошему, задается в $(document).ready, когда уже весь базовый интерфейс построен
ведь все равно функционал, по хорошему, задается в $(document).ready, когда уже весь базовый интерфейс построен
-1
Это делает более удобным динамическое построение дерева. Я это имел в виду.
0
Кстати о $(document).ready.
Недавно я выяснил что в Хроме(в сафари не тестил) $(document).ready происходит до подгрузки css. Т.е. если в каком-нибудь main.css у нас установлен фиксированный размер блока #content {width:550px;}, то $(document).ready(function() { alert($('#content').width();) }); покажет значение отличное от 550px. Получается $(document).ready не так хорош, жедем $(css).ready :). А пока я выкрутился засунув $(document).ready в js файл и поставил после загрузки css. Вариант неахти, но уж больно сроки жали.
Недавно я выяснил что в Хроме(в сафари не тестил) $(document).ready происходит до подгрузки css. Т.е. если в каком-нибудь main.css у нас установлен фиксированный размер блока #content {width:550px;}, то $(document).ready(function() { alert($('#content').width();) }); покажет значение отличное от 550px. Получается $(document).ready не так хорош, жедем $(css).ready :). А пока я выкрутился засунув $(document).ready в js файл и поставил после загрузки css. Вариант неахти, но уж больно сроки жали.
0
НЛО прилетело и опубликовало эту надпись здесь
Лаконичный подход. Интересно, будет ли он так же скор, медленнее или быстрее, чем применение динамического навязывания или перехвата события у родительского элемента?
0
перехвата события у родительского элемента
По идее, именно так это и работает:
По идее, именно так это и работает:
Works by adding an event handler to the root document element itself and relying on event bubbling.
Simon Willison
0
отписал багрепорт на groups.google.com/group/jquery-dev
с примером habradigest.ru/garbage/jq/HTMLPage3.htm
подожду ответа, но похоже live вернули в доработку
с примером habradigest.ru/garbage/jq/HTMLPage3.htm
подожду ответа, но похоже live вернули в доработку
-1
Был такой плагин livequery, я его использовал для своего сайта как раз из-за этой проблемы.
А теперь это в ядре. Круть, минус 2 килобайта при загрузке страницы )
А теперь это в ядре. Круть, минус 2 килобайта при загрузке страницы )
0
.live это просто отлично. Конечно, костыли для этого уже давно подобраны, но нет ничего лучше, чем костыли, уже встроенные в базовый набор :)
0
был еще Intercept
0
jQuery.Listen пока никто не отменял, но если будет работать без плагина — я, конечно, за live.
0
Как они, интересно, выкрутятся при использовании события 'change', для селектбокса, например, т.к. это событие не «баблится».
+1
Обработчик не создаётся для каждой новой кнопки, не обманывайте. Используется один общий обработчик.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
live: новый способ задать обработчик события