Как стать автором
Обновить

Комментарии 139

Советы хоть и известные, но в общем и целом годные. И изложено хорошо.

Единственное, я как ни старался (а стараюсь уже года 2), так и не смог для себя понять — зачем использовать html5-тэги? То есть идея-то была хорошая, но конкретная реализация настолько неполна и убога, что никаких практических преимуществ они не несут. Только лишние костыли тянут.
Спасибо за отзыв!
Лично для меня их использование освобождает пространство имен для классов, плюс код смотрится гармоничнее.
Так же поговаривают, что поисковики лучше ориентируются в них, при сложной структуре сайта.
> освобождает пространство имен для классов, плюс код смотрится гармоничнее
Вы несколько притягиваете желаемое к действительному. Да, именно это они и призваны делать. Но на практике — не делают. Потому что набор новых тэгов очень скуден, спецификация их нечетка, они не покрывают множество ситуаций. В итоге все равно имеем кашу из разных тэгов.
Плюс упомянутые проблемы с обратной совместимостью, которые нужно решать скриптами.
Идея, повторюсь, очень правильная — но реализация всё убила.
Вы несколько притягиваете желаемое к действительному.

Возможно. Но из опыта могу сказать, что мне реально удобнее работать с таким кодом.
Тег:
<footer></footer>

более заметен, чем тег
<div class='footer'></div>
<footer class="footer"></footer>
<!-- footer start -->
<footer id="footer" class="footer" role="footer"></footer>
<!-- footer end -->
Не сразу понятно, footer ли это
footer.footer#footer[role=footer] {

}
предвидел такой комментарий.
вспомнил не сразу
Тогда уж

footer.footer#footer[role=contentinfo] {

}
Да ерунда. Всё равно его потом классами стилизовать — и будет дублирование.
Вот сейчас не совсем понял, стилизация будет идти по названию тега, вот так:
footer {
    //some CSS
}
НЛО прилетело и опубликовало эту надпись здесь
В таком случае я бы назначил класс тому объекту, которому принадлежит footer, и стили задавал бы соответственно:
.object footer {
//css
}
А вот тут лучше через один класс
<footer class="object-footer"></footer>

Хотя возможно зависит от их количества (footer): если их на странице много, то уж лучше через клас
Ну многократно же обсуждалось, что вешать стили на тэг (в общем случае) — плохо.
Потому что потом этот тэг вылезет где-то ещё и подтянет стили, которые ему не предназначались.
Стили нужно вешать на классы. Исключения, понятное дело, могут быть, но в общем случае — на классы.

Цепляться на контекст тоже далеко не всегда уместное решение.
Интересно, почему Вы считаете, что тег <article> может неожиданно «вылезти где-то ещё», а тег <div class="article"> — не может?
тег <article> может вылезти на странице также как и тег <div>.
С классом вероятность меньше.
Учитывая, что те, кто начал использовать новые секционные теги просто заменили на них div-ы с соответствующими классами, мне кажется, что вероятность не меньше, а абсолютно та же самая — ведь это те же самые теги, просто переименованные.
Потому что классы нужно именовать более предметно и специфично, чем .article или .footer
Почитайте про яндексовскую методологию БЭМ (на хабре море статей про неё) — это один из самых попуярных сейчас вариантов. Не обязательно придерживаться именно её, можно придумать что-то своё — но важно понять принцип, что слишком общие названия классов есть зло.
И кстати, вторая причина, почему стилизовать по классам плохо — это изменчивость DOM-а в ходе развития проекта. Дивы меняются на спаны и наоборот, оборачиваются в промежуточные дивы, которых раньше не было, и т.д. Это абсолютно реальная ситуация, которую я знаю на практике.
Может быть, конкретно в случае с footer такая вероятность и не очень велика — но к section применимо на 100%.
Опечатался — правильно «вторая причина, почему стилизовать по тэгам плохо»
Насколько я понимаю, в большей степени это сделано для улучшения понимая страницы поисковыми системами.
http://habrahabr.ru/post/49734/ не плохая статья на эту тему.
Зачем это сделали — я понимаю :)
Я говорю, что в нынешнем виде это не решает поставленной задачи, малопригодно к использованию и потому может быть проигнорировано.
В будущем, когда допилят — с удовольствием.
НЛО прилетело и опубликовало эту надпись здесь
Была где-то замечательная англоязычная статья, где автор по полочкам расписывал, почему нынешние html5-тэги плохи.
Когда я на неё наткнулся, это фактически было строгое изложение того, что я чувствовал интуитивно.
Но, блин, полчаса уже гугл мучаю и не могу её найти :(
НЛО прилетело и опубликовало эту надпись здесь
Точно, спасибо. Только я оригинал подразумевал.
Я вот плохо представляю как это можно допилить. Тем более есть уже готовые способы семантической разметки schema.org и microformats.org
НЛО прилетело и опубликовало эту надпись здесь
Мне не очень понятно какую семантическую нагрузку несет, например, тег <footer>. Для меня это позиция на странице, а семантика в моём понимании не имеет ничего общего с позиционированием.
НЛО прилетело и опубликовало эту надпись здесь
Опять же, с таким подходом можно в итоге иметь миллион тегов на все случаи жизни.
Я вот разрабатываю достаточно сложные интерфейсы, а теги footer, article, aside и т.п. можно эффективно использовать, разве что, при верстке блога или новостного сайта.
Мне кажется, что надо тег «советы начинающим» поднять в заголовок статьи.
Я много думал над заголовком, и несколько раз дописывал туда слово «начинающим», но в итоге убрал его.
Дело в том, что я сам часто встречаю в верстке крупных проектов те вещи о которых написано в статье, и посчитал что «матерым» верстальщикам этот материал тоже пойдет на пользу.
А разве html5 не позволяет использовать несколько тегов h1 на странице?
Конечно можно, никто вам не запретит, но в статье внутри <a> нет тега <div>
Данный пример обусловлен логикой, зачем пихать блочный элемент в строчный?
А если надо блок ссылкой сделать?
<a href='' class='block'>Блочный контент</a>

.block {
    display: block;
}
Ну а после этого можно пихать в него сколько угодно разных элементов.
К сожалению не помню где и при каких обстоятельствах, но я встречал случай, когда браузер при отрисовке страницы из конструкции вида:
<a href='/url'>
    <div>Some text</div>
</a>

делал такую:
<a href='/url'></a>
<div>Some text</div>

С тех пор внутри тега <a> я использую элементы, которые строчные по умолчанию, а дальше с помощью CSS можно делать их так же блочными
НЛО прилетело и опубликовало эту надпись здесь
a { display: block; }

внутри использовать span
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Убедили, уберу это из статьи, дабы не смущать людей
По спецификации HTML в каждый тег section может входить по одному h1 заголовку, но я не встречал официальных заявлений от Яндекса и Google о том, что в их индексе учитывается этот факт, поэтому продолжаю использовать по старинке.
Официальный канал Google Webmasters на эту тему: www.youtube.com/watch?v=GIn5qJKU8VM
К сожалению у меня не очень хорошо с английским, но насколько я его понял, он просто сказал:
«Если хотите — используйте»
А вот что будет при индексации страницы, какой заголовок поисковая система посчитает основным — ни слова
Основным поисковая система все равно посчитает title.
Подразумевается SEO оптимизация. Всегда можно было использовать много H1, это формально не запрещено.
ага, 5
Наверное, дело не в технических ограничениях, а в хорошем тоне
НЛО прилетело и опубликовало эту надпись здесь
При использовании нестандартных шрифтов подключай только нужные начертания через Google Web Fonts или аналоги

Не забывайте прописывать правильные аналоги для OS X/Linux Вот, например, сервис в помощь cssfontstack.com/

При использовании JQuery или других библиотек воспользуйся CDN

А также можно сначала проверить доступна ли библиотека, чтобы не получилось так habrahabr.ru/post/231853/ (но это скорее к программистам)

Еще есть классная статья тут: habrahabr.ru/post/114256/
Спасибо за http://cssfontstack.com/ учту эту деталь
Подключай JavaScript перед закрывающим тегом body

Douglas Crockford рекомендует перестать использовать эту практику и переходить на defer async
Тут говорится, что IE 11+ поддерживает атрибут async, так что пока рано
НЛО прилетело и опубликовало эту надпись здесь
И то правда, учту это, спасибо!
Если в таком случае гарантия, что скрипты выполнятся в том порядке, в котором подключались?
+ Используйте autoprefixer
+ Удобно использовать Gulp, Grunt или аналоги. Например, можно автоматически оптимизировать изображения, обработать Compass, пропустить получившееся через Autoprefixer и CSScomb, и всё это с LiveReload.

Правда, с Gulp крайне неудобно то, что он требует хранить свои компоненты в папке с проектом, если проектов много, то в каждой папке надо хранить тысячи файлов весом в десятки мегабайт. Я это обошёл, использовав symlink в нужные проекты из единой папки с модулями Gulp.
Заглянул в демо autoprefixer — это 14 тысяч(!) строк JS-кода (если в неминифицированном виде смотреть).
Зачем тянуть этого монстра, если проще решить задачу десятком микшинов в CSS-препроцессоре, и браузер получит уже статичные стили?
НЛО прилетело и опубликовало эту надпись здесь
Я верно понимаю, что он работает на стороне клиента, определяет браузер посетителя и подставляет только нужные префиксы?
НЛО прилетело и опубликовало эту надпись здесь
А, значит я недопонял. В таком случае вопрос снимается.
Я бы не стал говорит в общем случае об Grunt или Gulp так как их использование ограничивается node.js
А LiveReload я так и не смог завести на винде в связке SublimeText 2 + Chrome
А что мешает разработчику держать на локальной машине NodeJS?
Об этом я не подумал, пойду открою для себя новый мир :)
Для хрома есть расширение LiveReload. Прекрасно работает в связке с grunt-contrib-watch.
Я ставил расширение для Chrome и плагин к Sublime Text 2. В итоге Sublime Text говорит что видит Chrome, а Chrome в тоже самое время никак не реагирует. В чем проблема так и не смог выявить. Находил в интернете похожие проблемы у других людей, но все они были без ответа.
Попробуйте BrowserSync
Спасибо, попробую
Добавлю свои 5 копеек:
1) CSS препроцессоры – это конечно отлично, так что не грех использовать что-то подобное для JS (CoffeeScript) и для HTML (Jade). С CoffeeScript у меня как-то не сложилось, а вот без Jade жить не могу.
2) Также, советую посмотреть в сторону Grunt тем, кто этого еще не сделал. Правильно настроенный конфиг сэкономит уйму времени и сил.
3) Для уменьшения размера изображений, использую ImageOptim (OS X). Пытался делать Imagemin таск в Grunt, но работает он как-то криво.
4) Для больших фронтенд-проектов, с большим количеством JS кода и сторонних библиотек, нужно строить его по AMD технологии (Require JS).
5) Я думаю, что использовать :hover как триггер действия все-таки можно. Главное делать это с умом.
1) На сколько я понял Jade, это аналог Emmet, только структура разворачивается не по нажатию tab, а при компиляции файла, так что тут каждому свое
3) Дал ссылки на сайт как кроссплатформенный вариант
5) С умом можно делать многое, что категорически запрещается. Это не самый плохой вариант :)
Но вот совет «используй CDN для jQuery» на практике не особенно полезный. Steve Souders — гуру фронтенд-производительности, автор книг High Performance Web Sites и Even Faster Web Sites, руководитель групп разработки Y!Slow и PageSpeed в Yahoo и Google соответственно — проводил исследования данных HTTPArchive как раз на эту тему.

И оказалось, что хотя в целом jQuery из Google CDN загружеют 18% из топ 300 тысяч сайтов интернета, — что, в общем-то, очень даже круто — когда дело доходит до конкретной версии, то наблюдается одромный разброс значений и по сравнению с 2011 годом фрагментация только растет:

Table 1. Top Versions of jQuery from GHL Mar 1 2013
jQuery version percentage of sites
1.4.2 (http) 1.7%
1.7.2 (http) 1.6%
1.7.1 (http) 1.6%
1.3.2 (http) 1.2%
1.7.2 (https) 1.1%
1.8.3 (http) 1.0%
1.7.1 (https) 0.8%
1.8.2 (http) 0.7%
1.6.1 (http) 0.6%

Так что вероятность того, что именно ваша версия jQuery уже есть в кеше браузера, ничтожно мала. Гораздо более выгодно собирать ваш JS, ваши стили и картинки и отдавать их от какого-то CDN. Тогда если пользователь ходит на ваш сайт часто, вы получите горадо больший прирост по скорости. А если редко, то что с Google CDN, что без него, ему придется загружать ваш сайт целиком с нуля (тут особую роль играют оистрически малые размеры кеша браузеров). Услуги CDN сегодня очень дешевы и легко подключаются.
Вот это интересно.
Документальное подтверждение того, что на интуитивном уровне мне уже давно казалось.
Хотя подключаю jQuery с гугла просто по принципу «хуже тоже не будет» :)
Я сейчас пришел к такому:

— index.html — с моего сервера
— styles.css, vendor.js, app.js — с CDN

можно было бы jquery из vendor.js вытянуть и с CDN гугла грузить, но зачем лишний запрос делать?
Ну, я бы эти данные истолковал не как «есть вероятность в полтора процента, что у пользователя закешировалась нужная вам версия jQuery», а как «у пользователей уже есть дохренища версий jQuery в кеше, выбирай любую».
Проблема в том, что браузеру не скажешь «ой, мне подходит любая версия jQuery выше 1.3, поищи там у себя в кеше».
Интересное замечание, обдумаю на досуге, как все-таки поступить
Мы просто включили SPDY и отказались от статик-сайтов и yandex.st.
И каков реальный прирост в скорости загрузки страниц получился?
в пределах 1-5%, для нас сыграло то, что так просто проще :)
По поводу оптимизации png могу посоветовать PNG Gauntlet, работает не хуже tiny png, но позволяет оптимизировать изображения прямо на жестокм диске, без загрузки и обратного скачивания через веб интерфейс + абсолютно бесплатная утилита.
Сейчас попробовал на PNG файле размером 70.4 кб
PNG Gauntlet
64.43 кб
Подергал настройки но лучшего сжатия не добился
tinyPNG
21.4 кб
Какие настройки должны быть чтобы «работал не хуже»?
Насколько я знаю, tinypng оптимизирует с ухудшением качества (сжатие палитры), а pngout/optipng сохраняет картинку изначальной (если только не указать обратное принудительно).
Да, tinyPNG использует метод квантования, и действительно ухудшает качество когда речь идет о полноцветной фотографии (ума не приложу зачем в таком случае использовать *.PNG)
Но в случае сжатия изображений интерфейса ухудшения качества нет
Вы правы tinyPNG сжимает сильнее. Взял сейчас для примера логотип гугл tinyPNG умудрился оптимизировать его с 14К до 8К.

Но меня вполне устраивает оптимизация PNG Gauntlet в большинстве случаев, вобще начал использовать оптимизаторы с того момента как заметил, что если сохранить изображение размер 1х1 пиксель в фотошопе CC, то оно будет занимать 20КБ, можно сохраняться через save for web, ctrl + alt + shif +s, но сохраняет не от места где лежит файл PSD, а от того места где был сохранен файл в последний раз и мне это неудобно.

Недавно открыл для себя Generate — Image assets, оно сохраняет все нужные картинки уже оптимизированными в отдельную папкку «image-assets» по соседству с файлом PSD и приходится из этой папки все равно переносить в другую, что тоже не всегда удобно.
Попробовал PNG Gauntlet вот на этой картинке, результаты:
  • Оригинал: 228кб
  • PNG Gauntlet: 186кб
  • Tiny PNG: 30кб

Выше уже разобрались, PNG Gauntlet не меняет качество изображения, в то время как tinyPNG может запросто сделать из png24 png8, если изменения в качестве будут не существенные
Это же обычный градиент, можно вполне через CSS сделать. Поддерживается даже 9ым ослом.

www.colorzilla.com/gradient-editor/
НЛО прилетело и опубликовало эту надпись здесь
Вот тут сделано при помощи утилиты приведенной выше. Работает в ИЕ9 (на оригинальном IE9 на Windows XP не проверял, но должо работать). Насколько понимаю сделано через фоновый svg в data uri формате. Я считаю, что такое решение лучше чем картинка.

http://codepen.io/Artrayd/pen/zcveK
НЛО прилетело и опубликовало эту надпись здесь
Не знаю зачем так сделано, я в последнее время вобще на ИЕ9 забиваю, не будет там градиента на кнопочке, а будет сплошной цвет, ну да и ладно. Никто от этого не умрет. Текст читается, кнопочки нажимаются, все работает — ну и отлично.

Я лучше лишний час поработаю над интерактивным эффектами для современных браузеров, чем буду возиться с ИЕ9.
НЛО прилетело и опубликовало эту надпись здесь
Неплохо. Нашел для себя пару полезных моментов. Но прекращайте эксплуатировать котят!
Каждый раз загружая изображение для портфолио, и скругляя его вручную в фотошопе где-то в мире плачет один котенок.
НЛО прилетело и опубликовало эту надпись здесь
И загружать изображения для портфолио. Остается открытым вопрос: чье это портфолио? Уж не котенка ли?
Я бы не использовал cdn от гугл при разработке крупных международных сайтов. (Пример Китай и его великий фаирволл)
Нормально все с китаем, специально просил знакомую проверить пару недель назад
Создай папку с готовым шаблоном для начала работы

Для Sublime Text довольно удобно использовать плагин Nettuts+ Fetch.
Шаблоны можно хранить где-нибудь в дропбоксе или на гитхабе.

Изложено доходчиво. Но если каждый день этим заниматься, то уже даже не думаешь как делать, а просто делаешь как правильно. В заметки себе оставлю этого юзера. Вообщем почитать можно, мне понравилось.
Есть одно «но» в случае использования mailto, tel и аналогичных. Это всё хорошо в теории, но на практике подобные вещи стоит делать либо картинками (что не очень хорошо — нельзя выделить), либо генерировать с помощью JS. Причина проста — в интернете бродит полно всяких ботов, которые очень любят парсить подобные ссылки и рассылать спам. Так что к этому стоит быть повнимательнее.
Я спалил все свои ящики давно и много раз в разных местах. Спам приходит максимум раз в месяца 3. Спамфильтры гугла рулят.
Я не спорю. Но если на своём сервере самопальный почтовик — выводы можно сделать. Моё дело предупредить о последствиях, т.к. подобный негативный опыт был.
Где-то видел решение, где не вспомню, по началу на странице все ссылки с mailto пустые или текст «Включите javascript», все email'ы хранятся в js объекте и специальный скриптик, по какому-то опознавательному атрибуту, например data-ml="eml5" при попадании ссылки во viewport подставлял в ссылку нужный email.
Мне пока что ни разу не звонили боты :)
А насчет почты тут вопрос удобства конечного пользователя, или защита от спама, нужно выбирать.
1) Мне тоже не звонили, но понасылали всякого смс-спама — тучи.
2) см. предложение генерировать адрес с помощью JS ;)
У меня с давних пор хранится значок «Альпинист СССР». Значкисты — это был следующий этап за новичком. Значкисты отличались тем, что все знали, все умели и всегда могли объяснить, как надо делать правильно. Ведь, знания, полученные в альплагере, не успели еще выветриться из головы, а свои маленькие успехи подхлестывали рассказать о них всему миру.
С опытом былая уверенность постепенно исчезала и человек начинал понимать, что горы, как и жизнь, сложны и непредсказуемы.
К чему это я? Да просто хочется выдать автору какой-то такой значок. Не то «Вебмастер СССР», не то «Программист HTML».

Детский сад, а не Хабр, вы уж простите.
Советы начинающего, который нахватался умных слов из популярных статей. Куча ошибок, неточностей и неверных рекомендаций. Самый яркий пример:
<nav> — для навигации, причем их может быть много на странице
Противоречит спецификации, которая рекомендует группировать в один <nav> основную навигацию на странице.

Закройте и забудьте.
НЛО прилетело и опубликовало эту надпись здесь
См. мой комментарий дальше по ветке. «Много на странице» — опасный совет, который ведёт к неправильному пониманию. Вся статья полна опасных советов.
По вашей ссылке написано
> Not all groups of links on a page need to be in a nav element
Это не запрещает повторного использования тега
«Много на странице» — это опасный совет, теперь все бросятся заворачивать в <nav> каждую группу ссылок, мол, это же навигация.

Проблема в том, что вы неприлично и опасно упростили случаи использования элементов.

<header> — это не только шапка сайта, это шапка любой самостоятельной части содержимого, например, <article>
<article> — не только для контента страницы, но для каждой самостоятельной части содержимого, в частности, для тизеров статей и комментариев.
<aside> — не только для боковых колонок, но для любого вторичного содержимого
<footer> — не только подвал сайта, но и, к примеру, подвал каждой <article> с датой статьи или комментария
НЛО прилетело и опубликовало эту надпись здесь
Починил, первый пост, не знал :)
Не публикуйте картинки в статьях на Dropbox, товарищи.
Публичные ссылки сдохли, потому что Dropbox ограничивает трафик.

P.S. Опередили.
Статья, к сожалению, проигрывает за счет своего названия. Чем вы занимались 10 лет с момента знакомства с вебом и в течение 5 лет активной практики — сомнительная деятельность, ибо пара комментариев от pepelsbey ценнее, чем вся статья.
Проше сделать подборку ссылок на видеокурсы от тех же Nettuts, CSS-Tricks, etc. Пользы больше.
Простите, но это так.
Используй препроцессоры для CSS


Изложить в следующей редакции: Используй препроцессоры.

Препроцессоры для HTML важнее, чем для CSS, поскольку структура кода гораздо более ветвистая. Jade, Node-blade, и т.п.

Препроцессоры для JS (CoffeeScript) позволяют прекратить продираться через скобки и повышают скорость разработки на 94,817%.
Да кто ты такой, чтобы давать мне советы?
А кто вы такой, чтобы считать, что эти советы вам не нужны?
Это была шутка на тему второго абзаца поста.
Для сжатия в Windows графических файлов без потери качества есть программа FileOpimizer. Это оболочка, которая последовательно применяет набор известных утилит оптимизации. Для PNG получается отличный результат.
Какие-то зануды тут собрались, «советы от новичка», «хабр не торт». Сами бы что-нибудь написали для начала.
За статью спасибо, задумался, стоит ли начать использовать CDN, например от Яндекса, а также поставил autofocus на страницу с формой, над которой сейчас работаю.
Спасибо за отзыв. Всегда приятно, когда твои советы помогают людям.
Вместо спрайтов и google fonts, советую инлайнить все это в base64.
Не согласен, также про JS плагины, я бы вообще начинающим разработчикам рекомендовал отказываться от плагинов, начинающим очень полезно пытаться решать задачи самостоятельно.
В качестве CDN рекомендую использовать JSDelivr, когда от плагинов все же не отказаться, большинство из них наверняка там есть (и не только js), а возможность забирать все плагины одним запросом, вообще волшебство.
НЛО прилетело и опубликовало эту надпись здесь
Молодец.

Только graceful degradation это совсем не о том что надо забивать на поддержку старья. Я бы сказал это «помнить о фоллбэке где это возможно». Так скажем вместо span class='Underline' onclick='ajaxload(page)' лучше сделать ссылку с тем же обработчиком и с правильным href. Чтобы могло работать без JS плюс открывало in new tab если надо. И к слову есть еще progressive enhancement. Правда все это уже наверное устарело.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории