Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
По-моему, самый лучший совет прогерам — пользоваться комментариями в коде хотя бы для отделения блоков в массивных участках. Или, на крайний случай, поставить лишний ентер.
А скрипты вобще всегда подключал только в head, создавая собственный файл code.js, который делал всю изначальную инициализацию.
А скрипты вобще всегда подключал только в head, создавая собственный файл code.js, который делал всю изначальную инициализацию.
в HEAD должны подключаться только те скрипты, без которых оформление страницы будет рушиться. Ну мол только те, загрузку которых нельзя отложить. Остальное лучше складывать внизу, перед закрытием body. Это ускорит отрисовку страницы.
Это какой-то кривой подход «без которых оформление страницы будет рушиться» — в идеале скрипты _добавляют_ функциональность. Т.е. все супер-важное должно уже быть на странице, а скрипты накатываются сверху и реализуют интерактивность. Это верно, если у Вас не JS приложение, где вообще все рисуется JSом, но это совсем другая история.
Ваш комментарий был актуален лет 5 назад во-первых (когда интернет был медленный, а компьютера слабые), а во вторых, это очень сомнительный ход, чтобы его использовать.
Суть в подключении js перед закрывающим body заключается в том, чтоб страницы быстрее загружались (визуально).
Я думаю, это было бы актуально во времена диал-апа. Да, сейчас бывает медленный интернет еще, но не каждый проект достоин такого решения.
Особенно бесит когда вот загружается (медленный у меня на работе интернет), начинаешь читать… А тут бах — js сработал и половину скрыл приветствием с новостями и предложением зарегиться, а вот картинка закрытия еще не подгрузилась и ее очередь еще далеко…
Приходится лезть в отладчик и руками скрывать.
Особенно бесит когда вот загружается (медленный у меня на работе интернет), начинаешь читать… А тут бах — js сработал и половину скрыл приветствием с новостями и предложением зарегиться, а вот картинка закрытия еще не подгрузилась и ее очередь еще далеко…
Приходится лезть в отладчик и руками скрывать.
У некоторых Yota (причем ловит она не фонтан, но других вариантов нет — только дороже и хуже), у некоторых GPRS, и это только Default City (^_-) А Россия, как показала практика, больша-а-а-ая… В некоторых селах только-только интернет начинает появляться.
Кстати, это еще и костыль, чтобы не создавать отдельную функцию и не вешать ее на onLoad, а сразу писать код, который должен выполняться после загрузки элементов разметки. ЕМНИП, такой plain code, размещенный в <head>, содержимого страницы не увидит.
Кстати, это еще и костыль, чтобы не создавать отдельную функцию и не вешать ее на onLoad, а сразу писать код, который должен выполняться после загрузки элементов разметки. ЕМНИП, такой plain code, размещенный в <head>, содержимого страницы не увидит.
Кстати, совсем недавно столкнулся с такой некрасивой вещью в хроме: ondomready срабатывал раньше загрузки файла стилей.
Решение было в перемещении строки выше загрузки кода.
Костыль — костылем. Я понимаю, что не все компьютеры одинаковополезны быстры. Но есть определенные решения, которых стоило бы придерживаться и плакать ради одной функции — по-моему не лучшее решение.
Например, я сознательно отказался от поддержки IE6 уже год назад, хотя сейчас, по воле судьбы-злодейки, мне приходится с ним работать в корпоративном сегменте.
А по сути — это не решение.
Решение было в перемещении строки выше загрузки кода.
Костыль — костылем. Я понимаю, что не все компьютеры одинаково
Например, я сознательно отказался от поддержки IE6 уже год назад, хотя сейчас, по воле судьбы-злодейки, мне приходится с ним работать в корпоративном сегменте.
А по сути — это не решение.
Ну, во-первых в статье речь была именно о подключаемых скриптах, а не о всем js-содержимом страницы.
Во-вторых костыль скорее все же второе решение, возможно оно более простое в реализации, но читать код с такими plain-вставками все же сложнее(личный взгляд, опытов не проводил). И правильнее все же вешать обработчик, чем ожидать что все загрузиться в правильном порядке.
В-третьих очень многое зависит от того, с какой конкретно целью скрипт помещается в конец страницы, не стоит так делать только потому, что так делают все, и уж тем более не стоит это называть «хорошей практикой» — именно этому был посвящен абзац в моей статье=)
Во-вторых костыль скорее все же второе решение, возможно оно более простое в реализации, но читать код с такими plain-вставками все же сложнее(личный взгляд, опытов не проводил). И правильнее все же вешать обработчик, чем ожидать что все загрузиться в правильном порядке.
В-третьих очень многое зависит от того, с какой конкретно целью скрипт помещается в конец страницы, не стоит так делать только потому, что так делают все, и уж тем более не стоит это называть «хорошей практикой» — именно этому был посвящен абзац в моей статье=)
Такого рода вещи (которые должны появиться сразу) надо помещать сразу в код, почти любое модальное окно можно сделать без JS вовсе. Закрывать Вы его будете, скорее всего, JSом, но пока юзер доведет мышку до кнопки Close и кликнет, скрипт уже 10 раз загрузится.
Если подключается куча всякого социального хлама, то актуально и сейчас, т.к. этот хлам иногда сильно всё замедляет
или новые стандарты уже предусматривают селектор «footer»?
Хмм… а разве нет? www.w3schools.com/html5/tag_footer.asp
Рекомендация не использовать имена классов в стиле «item» преследует как раз уход от безликости элементов.
Речь была именно об именовании классов(и вообще переменных, констант, идентификаторов и т.п.), ваши рекомендации не отменяют тех, о которых писал я, или я этого не заметил=)
Речь была именно об именовании классов(и вообще переменных, констант, идентификаторов и т.п.), ваши рекомендации не отменяют тех, о которых писал я, или я этого не заметил=)
в любом списке данных хранятся какие-то данные, неправда ли? Например, пункты меню, пункты таск-листов?
так почему бы не назвать menu_item, task_item? Кто сказал что эти item-ы не встретятся на одной странице?) и вы всегда можете быть уверены в новом проекте, что изменив стиль класса item вы изменили только пункт меню, а не зацепили случайно пункт такс-листа?)
так почему бы не назвать menu_item, task_item? Кто сказал что эти item-ы не встретятся на одной странице?) и вы всегда можете быть уверены в новом проекте, что изменив стиль класса item вы изменили только пункт меню, а не зацепили случайно пункт такс-листа?)
Не все item, что можно так назвать.
И как по мне нет ничего плохого в том, чтобы придерживаться стандарта и все каскадные таблицы и подключаемые скрипты описывать в шапке документа
Скрипты следует подключать как можно позже, чтобы дать странице возможность отрендериться без них, не кушать процессорное время на парсинг скриптов, а рендерить страницу. А уже потом, по мере загрузки, отрисовать то, что делается скриптами. Особо критично это для мобильного веба и веба в целом, но через GPRS, к примеру. А вот CSS файлы нужно подключать в HEAD.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Спорные правила простой верстки