Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 78
>11. О методе animate()
жаль пропущено важное описание параметра easing
>20. Как узнать, что рисунок загрузился
Также можно узнать, что рисунок не загрузился (404/403 итд):
.error(function() {})
жаль пропущено важное описание параметра easing
>20. Как узнать, что рисунок загрузился
Также можно узнать, что рисунок не загрузился (404/403 итд):
.error(function() {})
А подскажите пожалуйста, у меня есть большая страница со множеством img, flash, напичкана javascript с асинхронным изменением этой странице в браузере, при открытии в IE висит (почти бесконечно) progressbar. Как можно получить список того, что не может IE загрузить?
ну это немного из другой темы вопрос, поскольку .error() сработает тогда, когда сервер ответит, что картинки нет или что он не может ее дать. т.е. ответ от сервера уже придет. долгий прогресс-бар означает, что сервер затягивает с ответом (либо долго грузится большое количество ресурсов).
если бы я столкнулся с подобной проблемой, я бы в первую очередь проверил через firebug какие ресурсы грузятся дольше всего. если firebub ничего определенного не показал (проблема специфична для IE), определил происходит ли «затык» при первоначальное загрузке страницы, либо в момент «асинхронных изменений», т.е. первым делом отключил эти самые изменения. (еще можно вставить [script] $(document).ready(function() { alert(«DOM READY»); }); [/script] и посмотреть в какой момент появится alert (и появится ли вообще).
1) если проблема в первоначальной загрузке — в строке статуса должно быть написано какой ресурс грузится. если не пишется — можно попробовать поэтапно отключать ресурсы (опираясь на время загрузки, показанное в firebug — сначала наиболее долгие). и соответственно, таким методом исключения нашел источник проблемы, а дальше все зависит от его типа.
2) если проблема в асинхронности, все проще — у каждого запроса (в т.ч. .load() для картинок) есть возможность повесить callback, а значит отследить время начала и окончания загрузки, а также ее продолжительность. т.е. можно нарисовать на страницу таблицу открытых/закрытых соединений с сервером, где будет отчетливо виден ответ на Ваш вопрос.
а вот насчет flash ничего не скажу, не нравится мне эта технология и я с ней почти не работал.
если бы я столкнулся с подобной проблемой, я бы в первую очередь проверил через firebug какие ресурсы грузятся дольше всего. если firebub ничего определенного не показал (проблема специфична для IE), определил происходит ли «затык» при первоначальное загрузке страницы, либо в момент «асинхронных изменений», т.е. первым делом отключил эти самые изменения. (еще можно вставить [script] $(document).ready(function() { alert(«DOM READY»); }); [/script] и посмотреть в какой момент появится alert (и появится ли вообще).
1) если проблема в первоначальной загрузке — в строке статуса должно быть написано какой ресурс грузится. если не пишется — можно попробовать поэтапно отключать ресурсы (опираясь на время загрузки, показанное в firebug — сначала наиболее долгие). и соответственно, таким методом исключения нашел источник проблемы, а дальше все зависит от его типа.
2) если проблема в асинхронности, все проще — у каждого запроса (в т.ч. .load() для картинок) есть возможность повесить callback, а значит отследить время начала и окончания загрузки, а также ее продолжительность. т.е. можно нарисовать на страницу таблицу открытых/закрытых соединений с сервером, где будет отчетливо виден ответ на Ваш вопрос.
а вот насчет flash ничего не скажу, не нравится мне эта технология и я с ней почти не работал.
тут может помочь метод дихотомии:
сначала удалить первую половину кода, если ошибка исчезнет, то проблема во второй половине кода, и наоборот. так можно постепенно локализовать проблему, когда нет других средств отладки.
сначала удалить первую половину кода, если ошибка исчезнет, то проблема во второй половине кода, и наоборот. так можно постепенно локализовать проблему, когда нет других средств отладки.
Интересно, меня одного раздражают заголовки вроде «N советов чтобы стать богатым и успешным»?
за всех не отвечу, но меня не раздражают. К тому же советы очень даже дельные.
Меня часто раздражают.
Обычно под таким заголовком размерщается сборная солянка из пунктов, связанных между собой максимум тем, что им номера идут по порядку.
К тому же, это известный прием для увеличения привлекательности рекламы. Посему считаю подобные вещи насилием над мозгом :)
Обычно под таким заголовком размерщается сборная солянка из пунктов, связанных между собой максимум тем, что им номера идут по порядку.
К тому же, это известный прием для увеличения привлекательности рекламы. Посему считаю подобные вещи насилием над мозгом :)
Очень полезно, спасибо!
п.5. мне мерещится, или это действительно не кэширование, нечто другое?
бага перевода: неупорядоченный список → ненумерованный список
п.5. мне мерещится, или это действительно не кэширование, нечто другое?
бага перевода: неупорядоченный список → ненумерованный список
Вот и я думаю что где то это уже было
Пипец. Три дня переводил. Закрываю.
Тем не менее, спасибо за труд.
а я пропустил. спасибо за повтор
А я бы на ту статью и не наткнулся.
Надо сделать в Хабре периодическое циклическое «всплывание» статей — для тех, кто проморгал :-)
Таки спасибо: половину советов я уже знал, но в половине нашёл полезные детали.
Успехов.
Надо сделать в Хабре периодическое циклическое «всплывание» статей — для тех, кто проморгал :-)
Таки спасибо: половину советов я уже знал, но в половине нашёл полезные детали.
Успехов.
сиравно афатру спасибо,
старую статью я пропустил
старую статью я пропустил
Да. Я тогда даже распечатал в коллекцию шпаргалок на стене. До сих пор вот висит. Очень удивился когда снова увидел такую статью. Подумал что это со мной что-от не то… :)
Вот яразу читаю «1. Загружайте библиотеку с Google Code» — и я против. Это создает проблемы. У меня сайт изначально и работал на этих аякс либах с гугла. Но потом случается следующее. Гугловский репозиторий чего-то лег на минут 30, ну как бы и все. Теперь всякая страничка, а это почти все, которые юзали эту либу — подвисают. Вот вы скажите сами себе — вам такой геморой нужен? Если либа грузится с моей странички — я знаю что это у меня проблема и я сам могу хоть как-то повлиять на работоспособность. А с гуглом нет. Поэтому пришлось отказаться от этой мегаидеи. Подожду пока другие набью шишки и гугл приведет отзывчивость серваков в порядок.
Эти советы мало относятся к самой jQuery, а к javascript в целом. По этому название немного не соответствует содержанию.
Особо порадовал автор своей фразой: «Я не могу объяснить, почему это так работает, но наверняка эксперты в jQuery дадут на это ответ» =)
Особо порадовал автор своей фразой: «Я не могу объяснить, почему это так работает, но наверняка эксперты в jQuery дадут на это ответ» =)
Меня уже смутил пункт №1. Если в новой версии уберут функции, использующиеся в вашем коде, то что вы будете делать? Загружать код хорошо, если проект один и есть возможность быстро реагировать на обновления. На практике же лучше грузить руками всё-таки
В примера заметил, довольно часто используется
menuItem.removeClass('collapsed').addClass('expanded');
Так вот для того чтобы просто прятать и показывать элементы можно заюзать TOGGLE()
довольно простая, но код позволяет немного уменьшить.
В примерах ее практически никто не используют, а зря
menuItem.removeClass('collapsed').addClass('expanded');
Так вот для того чтобы просто прятать и показывать элементы можно заюзать TOGGLE()
довольно простая, но код позволяет немного уменьшить.
В примерах ее практически никто не используют, а зря
12 — Делегирование уже давным-давно умеет делать сама jQuery через метод live. Но народ всё пишет и пишет свои решения, а потом ещё и статьи по ним…
live по ощущениям очень тяжелая. Если не ошибаюсь, биндер срабатывает на любые изменения DOM? На сложный селектор лучше даже не пытаться вешать, люди с ие7 и меньше устанут ждать.
У меня как раз наоборот ощущения — после перехода на live всё стало глаже работать. Но оно не для сложных селекторов, да. На несколько сложных элементов лучше вешать индивидуальные обработчики. А вот если на странице десяток-другой ячеек таблицы, которые должны как-то реагировать на мышь — live самое то.
не понимаю, зачем использовать два разных алгоритма для «десятка-другого» ячеек и для «тысячи-другой», если мы жертвуем универсальностью, и при этом в обоих случаях делегирование работает быстрее.
А вам простите что важнее — универсальность или оптимизация? Насколько я понял, весь этот топик об оптимизации. Если вы применяете различные решения задачи в зависимости от условий — это признак того, что вы хороший программист, а не просто кодер.
так в том то и дело, что мы жертвуем универсальностью, ничего взамен не получая (забыл это написать).
у меня, к сожалению, так и не дошли руки (хотя давно чешутся) посмотреть как в jquery реализован live, но я подозреваю, что он вешается на изменения DOM. если это так, то такой вариант как минимум в разы медленее делегирования.
у меня, к сожалению, так и не дошли руки (хотя давно чешутся) посмотреть как в jquery реализован live, но я подозреваю, что он вешается на изменения DOM. если это так, то такой вариант как минимум в разы медленее делегирования.
стоп, ничего я не забыл.
написано же «в обоих случаях делегирование работает быстрее.»
написано же «в обоих случаях делегирование работает быстрее.»
Дата написания оригинальной статьии — 14 Dec 2008, тогда еще не было 1.3 версии.
да. только в новых версиях. но не забываем что в новых версиях есть баги которые не дают многим воспользоваться этими новыми версиями
вот например jQuery('#'+objectId+'>param[name=flashvars]').val() не будет работать в новой версии, хотя прекрасно работает в v1.2.6
вот например jQuery('#'+objectId+'>param[name=flashvars]').val() не будет работать в новой версии, хотя прекрасно работает в v1.2.6
Да! И еще попроще пример: jQuery("#div #subdiv") не выбирает. Нужно менять на jQuery("#div").find("#subdiv").
Не спрашивайте меня, зачем так делать… мне очень нравится плагин facebox, но он клонирует кусок DOM'a, когда создает лайтбокс-окошко… а это нужно чтобы разместить в клонированном окошке формочку, которую можно аяксом отправить
Не спрашивайте меня, зачем так делать… мне очень нравится плагин facebox, но он клонирует кусок DOM'a, когда создает лайтбокс-окошко… а это нужно чтобы разместить в клонированном окошке формочку, которую можно аяксом отправить
24 — можно сделать лучше
упс, извините, сорвалось… :)
$('popup').click(function(event){
// какой-нибудь код
event.preventDefault();
});
$('popup').click(function(event){
// какой-нибудь код
event.preventDefault();
});
простите, но Вы не правы.
preventDefault() и return false; — это разные вещи, потому что return false; помимо отмены действия отменят и bubble-эффект.
поэтому, верным будет код:
$(«popup»).click(function(e) {
// code
e.preventDefault();
e.stopPropagation();
});
что, согласитесь, не «лучше», чем return false;
preventDefault() и return false; — это разные вещи, потому что return false; помимо отмены действия отменят и bubble-эффект.
поэтому, верным будет код:
$(«popup»).click(function(e) {
// code
e.preventDefault();
e.stopPropagation();
});
что, согласитесь, не «лучше», чем return false;
А чем лучше то?
тем, что можно разделить отмену дефолт ивента и всплывание ивента же
return false как уже упоминалось выше делает и то и то одновременно, что не всегда нужно/удобно
return false как уже упоминалось выше делает и то и то одновременно, что не всегда нужно/удобно
а можно пример?
пример чего? :)
дефолт ивент — например сабмит формы, или переход по адресу на клик по ссылке — отменяеца так: e.preventDefault();
всплывание ивента — например если несколько элементов лежат друг над другом то клик может выстрелить на каждом из них — отменяеца с помощью e.stopPropagation();
return false делает и то и то одновременно
дефолт ивент — например сабмит формы, или переход по адресу на клик по ссылке — отменяеца так: e.preventDefault();
всплывание ивента — например если несколько элементов лежат друг над другом то клик может выстрелить на каждом из них — отменяеца с помощью e.stopPropagation();
return false делает и то и то одновременно
Да ладно, сам Резиг в своей книге Pro Javascript Techniques использует такой способ. Native & unobtrusive javascript: )
1. Старайтесь не использовать jQuery — вот лучший совет, имхо.
Совет, про подключение с Гугла — бред. С нашего сервера файлы грузятся быстрее чем с Гугла, тем более в России. Также набили шишки на подключении с dev.jquery.com, он периодически падает дней так на 5, причем падает, не отвечая на соединения и подвешивая загрузку страницы…
Совет, про подключение с Гугла — бред. С нашего сервера файлы грузятся быстрее чем с Гугла, тем более в России. Также набили шишки на подключении с dev.jquery.com, он периодически падает дней так на 5, причем падает, не отвечая на соединения и подвешивая загрузку страницы…
там плюшка не в скорости загрузки, а в отсутствии ее необходимости, для тех, у кого файл скеширован (с другого сайта).
хотя я тоже предпочитаю делать локальную копию.
хотя я тоже предпочитаю делать локальную копию.
Многотысячная аудитория пользователей jQuery нубы и ничего не понимают? Обоснуйте пожалуйста тезис насчет нерациональности этой библиотеки.
Многотысячная аудитория обменивает качество сайта на скорость написания скрипта (или что чаще, скорость скачивания и прикручивания плагина = пара минут).
Зачастую использование jQuery+плагинов необосновано, можно ради пары разворачивающихся меню и ручками написать скрипт, кроме того, на очень многих сайтах скрипты включаются в секции head (хотя в этом нет необходимости), также при этом не используется gzip, что вызывает необходимость загрузки 75 или 120 (если не minified версия) Кб только основного скрипта. В сочетании с размещением тега script в заголове страницы, это радикально замедляет загрузку сайта. Я считаю, на среднестатистическом информационном (или варезном, прости господи :) ) сайте приоритетом является скорость загрузки и отображения страницы, а не наличие примитивных бесполезных эффектов и анимаций.
Кто тут нубы, думайте сами.
Зачастую использование jQuery+плагинов необосновано, можно ради пары разворачивающихся меню и ручками написать скрипт, кроме того, на очень многих сайтах скрипты включаются в секции head (хотя в этом нет необходимости), также при этом не используется gzip, что вызывает необходимость загрузки 75 или 120 (если не minified версия) Кб только основного скрипта. В сочетании с размещением тега script в заголове страницы, это радикально замедляет загрузку сайта. Я считаю, на среднестатистическом информационном (или варезном, прости господи :) ) сайте приоритетом является скорость загрузки и отображения страницы, а не наличие примитивных бесполезных эффектов и анимаций.
Кто тут нубы, думайте сами.
Зачастую использование jQuery+плагинов необосновано
В этом Вы правы.
Но в остальном слишком категоричны и предвзяты.
а вы считаете, что jQuery — это для «примитивных бесполезных эффектов и анимаций»?
Ну это проблема не тех, кто «написал» плохую библиотеку. Это проблема использующих.
В любом случае при написании клиентской части кода вам придется создавать небольшую библиотеку часто используемых кроссбраузерных функций. Так почему бы не использовать для этих решений jQuery. Она написана людьми не глупыми. Чрезвычайная универсальность — это да, не поспоришь. Но если вас смущает размер библиотеки 19Кб, то можно сделать свою minified сборку. К примеру, не нужна вам анимация средствами JS — значит выкидываем все функции animate. Думаю, похужевшая jQuery будет весить 10-12 Кб.
В любом случае при написании клиентской части кода вам придется создавать небольшую библиотеку часто используемых кроссбраузерных функций. Так почему бы не использовать для этих решений jQuery. Она написана людьми не глупыми. Чрезвычайная универсальность — это да, не поспоришь. Но если вас смущает размер библиотеки 19Кб, то можно сделать свою minified сборку. К примеру, не нужна вам анимация средствами JS — значит выкидываем все функции animate. Думаю, похужевшая jQuery будет весить 10-12 Кб.
> Особенно это относиться к проектам
Господи, ну сколько можно то?
А статья отличная, только я не любитель jQ.
Господи, ну сколько можно то?
А статья отличная, только я не любитель jQ.
Если не заменять угловые скобки («>» и «<») на их соответствующие HTML entities, то тогда Хабр начинает выкусывать их вместе с теми тегами HTML, которые угловыми скобками обрамлены.
В пункте 24 и, вероятно, в пункте 6 было больше HTML изначально, нежели сейчас видно.
В пункте 24 и, вероятно, в пункте 6 было больше HTML изначально, нежели сейчас видно.
Шпоры в статье старые, уже давно для 1.3 сделали:
acodingfool.typepad.com/blog/jquery-13-cheat-sheet.html
acodingfool.typepad.com/blog/jquery-13-cheat-sheet.html
пункт 20 в таком виде не будет работать в опере, надо сначала повесить событие, а уже потом присваивать src.
Хочу возвразить по поводу контекста (пункт 9)
когда задаешь контекст $(".myElement",$(".myContect")) то это ничего не даст в плане производительности потому что $(".myContect") выполнится в контексте документа прироста не будет даже если контекстом будет $("#myContect").
отвечаю сразу на несколько появившихся вопросов.
1 Как надо делать? вот так
$(".myElement",document.getElementById(«myContect»))
2 Нет, document.getElementById(«myContect») и $("#myContect") не но и тоже. второй вариант это конечно же обертка к первому но перед тем как он выполнится сначала пройдет проверка регуляркой выделение селектора поиск в кеше, только потом будет выполнет поиск самого элемента, а потом он еще будет обернут в объект jQuery
3 Да, в прошлом пункте я помалодушничал. если браузер поддерживает метод document.querySelect(All) то будет быстрее немного. это естественно не касается ИЕ 6 и 7 (насчет 7 не уверен)
когда задаешь контекст $(".myElement",$(".myContect")) то это ничего не даст в плане производительности потому что $(".myContect") выполнится в контексте документа прироста не будет даже если контекстом будет $("#myContect").
отвечаю сразу на несколько появившихся вопросов.
1 Как надо делать? вот так
$(".myElement",document.getElementById(«myContect»))
2 Нет, document.getElementById(«myContect») и $("#myContect") не но и тоже. второй вариант это конечно же обертка к первому но перед тем как он выполнится сначала пройдет проверка регуляркой выделение селектора поиск в кеше, только потом будет выполнет поиск самого элемента, а потом он еще будет обернут в объект jQuery
3 Да, в прошлом пункте я помалодушничал. если браузер поддерживает метод document.querySelect(All) то будет быстрее немного. это естественно не касается ИЕ 6 и 7 (насчет 7 не уверен)
в 9-м пункте скорее всего имеется ввиду
не #listItem
а .listItem
не #listItem
а .listItem
По части пункта 21 не согласен. Предпочитаю немного подождать. Использовать свежий продукт не всегда полезно для здоровья и нервов.
то файл вообще загрузиться с кеша.
Уважаемые некоторые авторы Хабра. Может быть стоит запомнить простую проверку:
— файл что сделает? Загрузится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
25 советов по улучшению вашего кода jQuery