Frontend Developer
0,0
рейтинг
22 февраля 2011 в 04:47

Разработка → Чек-лист вёрстки. Что можно отдавать клиенту, а что надо переделывать

Идеальная вёрсткаВы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

Клиенту неважно насколько красив ваш код, но ему важен результат. Качественный код нужен фирме, т.к. он надёжней и в будущем его будет легче поддерживать.

Требования должны были быть такие, что соблюсти их легче, создавая качественную вёрстку, а не говнокод. Я составлял такой чек-лист в течении полутора лет. За последние полгода в него не добавилось ничего. Значит самое главное учтено.

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:
  • 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
  • 2015/08/10: актуализирован список исключений для CSSLint
  • 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
  • 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
  • 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
  • 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
  • 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
  • 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
  • 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
  • 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.



На хабре была статья про «Требования к html-верстке». Но это ТЗ для исполнителя/соглашение о кодировании/советы хорошего тона, но не проверочный список: готова-ли работа и можно-ли её принимать. Он хороший, но увы, его соблюдение не гарантирует что проблем не будет.



Для того чтобы отдавать вёрстку клиенту, достаточно соблюдения первых 5 пунктов.
Для выдачи в продакшен — первых 6.


  1. Соответствие макету
  2. Кроссбраузерность, кодировка и DOCTYPE
  3. Валидность (включая CSSLint и JSHint), доступность, микроформаты
  4. Независимость блоков в CSS: минимизация каскада, использование техник БЭМ
  5. Сайт должен нормально смотреться во всех стандартных разрешениях от 1024 и выше, не иметь горизонтального скролла и вписываться в экран мобильных устройств
  6. Корректная работа при вбивании реального текста, надёжность вёрстки
  7. Использование препроцессоров и систем сборки
  8. Проверка и оптимизация скорости загрузки: github.com/ihorzenich/WebPerformanceChecklist
  9. Поддержка Retina
  10. Наличие Win/Mac/Linux-аналогов шрифтов
  11. Доступность при выключенных(загружающихся) картинках
  12. HTML5 формы, линковка, валидация
  13. Семантичность. Отсутствие глупостей в html и css, единообразие, аккуратность
  14. Правильная структура заголовков (H1,H2,… и т.д. и TITLE)
  15. Работоспособность при выключенном JavaScript
  16. Работоспособность при выключенном Flash
  17. Отсутствие багов при увеличенном шрифте
  18. И последний пункт – мелкие проверки (ниже подробней)



Пункт номер 1. Соответствие макету


Pixel perfectРасположение блоков должно быть 1:1 по сравнению с макетом. Допускается расхождение до 5px для текста. Разрешены и даже приветствуются правки размеров и расположения криво нарисованных блоков (разница размерах в 1-2px на разных страницах).

Ясное дело что при изменениях контента, размеры блоков могут меняться (по высоте например), это нормально. Мы используем Pixel Perfect не для попиксельного задротства (адекватный ПМ не должен затягивать сдачу проекта, тратя время, а значит и деньги фирмы, на вылизывание каждого пикселя), а для проверки что все базовые блоки находятся там где надо, их размеры, отступы — соответсвуют макету.

Проверяется в Firefox через плагин addon Pixel Perfect. Для проверки в других браузерах используйте ModularGrid, но в принципе достаточно просто глянуть намётанным глазом, если расхождения заметные — они будут бросаться в глаза.



№2. Кроссбраузерность, кодировка и DOCTYPE


HTML5
  1. Кодировка: UTF-8
    Зачем нужно: UTF-8 это универсальность и совместимость. Это современный стандарт, за ним даже не будущее, а настоящее.
    Как проверяется: в FF Инструменты→Информация о странице, в появившемся окне должно быть написано «Кодировка: UTF8». Эта кодировка должна использоваться для всех файлов: html, css, js (если файлы в разных кодировках могут быть проблемы)
  2. DOCTYPE: HTML5
    Зачем нужно: наличие корректного doctype необходимо чтоб страницы отображались в соответсвии со стандартами. Новый doctype позволяет нам смело использовать современные тэги (canvas, header, article,...) и старые проверенные решения, ранее бывшые в опале (например embed). HTML5 — это современный стандарт, в нём можно писать и в строгом XHTML-синтаксисе. Аргументация для сомневающихся.

    Проверка: открываем исходный код страницы, первая строка должны быть <!DOCTYPE HTML>.
  3. Кроссбраузерность:
    • Firefox (последний)
    • Chrome (последний)
    • Safari (последний) и если у вас нет Mac чтоб проверить «размытые Mac'овские» шрифты (они чуть большего размера, из-за этого бывает вылазят баги) то установите в Preferences→Appearance, «Font Smoothing» в Medium (по дефолту там «Windows Standart»).
    • iPhone (смотрим в landscape и portrait режимах, т.е. вертикально и горизонтально) + Android. Тут важно чтоб верстальщик не забыл указать правильный viewport.
    • Opera (последняя) Имеет смысл также посмотреть на 12-версии с движком Presto, если там есть баги в отображении — это признак потенциальных проблем в качестве кода
    • IE7+ (для IE6 выводится уведомление о неподдержке и предложении скачать другой браузер или установить Google Frame, но с возможностью всё-таки просмотреть сайт)
    • Opera Mini (проверяется в Opera Developer ToolsOpera Mini Simulator, нужно установить Java плагин к браузеру, или в крайнем случае: Opera 9.64→Вид-Маленький экран, но в 9.64 JS будет работать полноценно в отличие от настоящей Opera Mini, это нужно учитывать)

    Проверяется просмотром сайта в вышеперечисленных браузерах.
    • Проверка в IE7 делается переключением IE8 в режим IE7 (F12→Режим обозревателя→Internet Explorer 7).
    • В IE6 можно посмотреть на ipinfo.info/netrenderer или на виртуальной машине (удобно использовать Windows XP Mode в Win7).



№3. Валидность (включая CSSLint и JSHint), доступность, микроформаты


Microformats
  1. Не должно быть js-ошибок!
  2. Valid HTML5Титулка должна быть валидна в любом случае. Ошибки на внутряках простительны в следующих случаях:
    • Упоротая секретарша копипастит тексты из Word’а в визиг;
    • Программеру ну очень нужны какие-то кастомные атрибуты (хотя для этого в HTML5 ввели специальные пользовательские атрибуты «data-*»).
  3. Valid CSS3CSS валидируется по версии 3.0, его валидность не требуется (да и валидатор ещё кривоват), а вот синтаксические ошибки (типа margin: 10xp) исправлять надо.
  4. Микроформаты должны быть. Как минимум – hCard. Желательно также hCalendar, XFN, hAtom.
  5. Проверка статическими анализаторами качества кода: CSSLint и JSHint
IE JavaScript error
Ошибки js проверяются просмотром сайта в IE – в левом нижнем углу не должно быть значка «есть js-ошибки».

Зачем нужна валидность? Главнейший практический плюс: валидный код обладает заранее известной структурой и упорядоченностью. Если в коде царит порядок, то такой код проще обрабатывать, обслуживать, видоизменять… Маленькое лирическое отступление: инженеры уже давно поняли, что унификация и стандартизация значительно снижают стоимость изготовления и, главное, обслуживания изделий… Код с ошибками — чаще всего именно кустарщина.
© rossomachin

HTML5 помогает нам в случае необходимости своих, кастомных, невалидных атрибутов для элементов. Просто указываем атрибут «data-чтоугодно» — и можем использовать! Это валидно!

Микроформаты не только полезны для SEO, но и здорово упорядочивают код. Не нужно полчаса думать как назвать новый блок. Выбирай из существующих стандартных имён! Бери entry-content, не ошибёшся :)

Валидность проверяется онлайн-валидаторами:


В настоящее время (2012 год) микроформаты постепенно вытесняются microdata, стоит использовать и то и другое.

WCAG2 ConformanceВ идеале вёрстка должна соответствовать стандарту доступности: WCAG.
Он имеет три уровня сложности, если проходит хотя бы WCAG1 A (Priority 1) – уже хорошо. Идеальный вариант – WCAG2 Priority 3 (AAA). Самый просто способ проверить что скорей всего WCAG1 Priority A соблюдён — www.cynthiasays.com (или addon Web Developer →Инструменты →Проверить WAI). Почему «скорей всего»? Некоторые требования WCAG невозможно проверить автоматически. Вот ещё несколько скриптов помошников:

И собственно сам чеклист WCAG2:


Некоторые ошибки в валидации допустимы.
  • HTML
    Стандарт HTML5 находится в активной разработке: вносятся изменения, что-то добавляется, что-то исключается. Валидатор HTML5 меняет правила проверки в соответствии с этим.
    То что было валидным вчера, сегодня может выдавать ошибку, например такая ситуация сейчас с apple-touch-icon и XFN.
    В отличии от HTML4 и XHTML, официальной кнопки «Valid HTML 5» не существует, поэтому валидатор не выдаст вам код для её вставки, даже если он считает документ валидным.
    Люди сами рисуют свои варианты кнопочек, вы можете использовать любые, но рекомендованным вариантом на сегодняшний день является добавление на сайт официального HTML5 badge с лентой используемых технологий, например так:
    HTML5 Powered with CSS3 / Styling, and Semantics

  • CSS
    1. По-умолчанию валидатор CSS проверяет код согласно стандарту 2.1, а не 3.
      Поэтому допустимы ошибки такого рода:
      Property box-shadow doesn't exist in CSS level 2.1
      Property border-radius doesn't exist in CSS level 2.1
      Property background-size doesn't exist in CSS level 2.1
      Value Error : background Too many values or values are not recognized : linear-gradient(top,#7baee7,#b5dbff 22%) linear-gradient(top,#7baee7,#b5dbff 22%)
      и т.п.

    2. Валидатор считает ошибкой указание вендорных префиксов
      Поэтому допустимы ошибки такого рода:
      Property -moz-box-shadow doesn't exist
      Property -webkit-background-clip doesn't exist
      Property -o-border-image doesn't exist
      Property -khtml-background-size doesn't exist
      Property -ms-filter doesn't exist
      Property -pie-background doesn't exist
      Unknown pseudo-element or pseudo-class :-moz-any-link
      Value Error : display -moz-inline-box is not a display value
      и т.п.

    3. Раньше проприентарные свойства IE было рекомендовано выносить в отдельный CSS. Сейчас стоит использовать HTML5 Boilerplate и фильтровать в style.css с помощью html.oldie, html.ie7 и т.д.
      Тогда допустимы ошибки такого рода:
      Property behavior doesn't exist
      Property progid doesn't exist
      Property _display doesn't exist
      и т.п.



Настройки CSSLint:


Я выключаю следующие опции:
<pre // We didn't support IE7!
«box-sizing»: false,
«adjoining-classes»: false,

// Allow Safety CSS Hacks
«star-property-hack»: false, // IE8-
«underscore-property-hack»: false, // IE7-

// Stupid rules
«box-model»: false, // Developers know what is box model!
«empty-rules»: false, // Empty rules are useful for describing the layout
«floats»: false, // Grids can't fully replace floats

// OOCSS didn't suitable for real life. BEM does.
«qualified-headings»: false,
«unique-headings»: false,
«font-sizes»: false


Настройки JSHint:


Допустимо (пока ещё допустимо!) выключение опции:
— When code is not in strict mode

Как правило для большинства кода необходимо включить:
+ jQuery



№4. Независимость блоков в CSS: минимизация каскада, использование техник БЭМ


Независимость блоков в cssПроверяется в FF через плагин addon Firebug
При наведении на любой блок, в его стилях не должно быть множество перечёркнутых правил (следствие длинного каскада).
Для минимизации каскада и построения надёжной, современной, масштабируемой вёрстки сейчас применяют следующие техники: БЭМ, MCSS и SMACSS.




№5. Сайт должен нормально смотреться во всех стандартных разрешениях от 1024 и выше, не иметь горизонтального скролла и вписываться в экран мобильных устройств


Mobile viewportПроверяется в FF через плагин addon Web Developer→Resize
Список классических разрешений:
  • 1024x600
  • 1024x768
  • 1152x864
  • 1280x800
  • 1280x1024
  • 1440x900
  • 1680x1050
  • 1920x1080

На больших разрешениях нужно обращать внимание что не пропадает фоновая графика по краям сайта (что размера картинки хватило на большое разрешение).

Вписывание в экран мобильных устройств лучше проверять на самих мобильных устройствах. Множество проблем решается указанием верного Viewport. Подробнее: прекрасный доклад Вадима Макеева «Прокрустовы окна. Как вписаться в устройства с минимальными потерями».


№6. Корректная работа при вбивании реального текста, надёжность вёрстки


WysiwygВёрстка должна тянутся, не разваливаться и не терять дизайнерский вид при изменении контента на странице. Его может быть больше или меньше чем на макете, он может быть обёрнут во всякие <p> из визига и т.п.
Обязательно нужно проверять удаление заголовков! Бывает что отступы между блоками после этого схлопываются, это частая ошибка, причина — что отступы были заданы не для блоков, а для внутренних элементов — заголовоков.
  1. Проверка ввода и удаления данных.
    Проверяется: на странице с контентом, пробуем добавлять и удалять содержимое – «что будет когда текста много?», «а когда мало?».
    Обязательно пробовать менять расположение элементов, чтоб после того как ты поменял блоки местами не развалилось оформление (из-за каскада).
  2. Проверка корректности работы стилей.
    Проверяется: на страницы с контентом вбиваем текст с абзацами и без абзацев (важно! бывает горе-верстальщики прописывают стили только для абзацев), со списками и картинками, таблицами и заголовками разных уровней.

Это нужно чтоб на живом сайте потом не полезли проблемы при заполнении реальными данными.
Правки содержимого страницы делаются в FF через плагин addon Firebug: HTML→Edit – меняем/добавляем/удаляем текст. Хороший пример проверочного текста находится в normalize.css в test.html между <body> и </body>.

Хорошо использовать html5-тэги для разметки: header, footer, aside, nav, section, article и т.д. Кроме того что это семантично, также повышается надёжность, «пуленепробиваемость» вёрстки. Лишний открытый или закрытый div легко может поломать вёрстку. Но когда каркас сайта — атомарные и редко повторяющиеся html5-тэги, то «поломка» локализуется в пределах html5-тэга.


№7. Использование препроцессоров и систем сборки


CSS должен быть написан с использованием препроцессоров (LESS/Sass/Stylus).
Проверяется поиском файлов с расширениями вида: .less, .sass, .scss, .styl — какое-то одно должно быть.

Желательно использование систем сборки (Grunt/Gulp) и построцессоров (PostCSS/Autoprefixer).
Проверяется поиском файлов Gruntfile.js или Gulpfile.js


№8. Оптимизация скорости загрузки


Page SpeedРаньше я советовал спрайты, base64 для картинок, CSS3 вместо графики, оптимизацию JPG и PNG и вынос JS из html во внешние файлы с объединением.
Сейчас я написал отдельный большой чеклист включающий это и многое другое: https://github.com/ihorzenich/WebPerformanceChecklist
Зачем это нужно:
скорость загрузки оказывает ключевое влияние на доступность сайта (больше психологическую, чем фактическую), активность пользователей на сайте (медленными сайтами люди предпочитают не пользоваться) и его конверсию (медленным сайтам не доверяют).
© sunnybear.
В целом скорость загрузки проверяется так:

Учитывайте что значительная часть рекомендаций: включение сжатия, установка определённых headers, minifying кода – относится к серверным работам, а не вёрстке

Ну и конечно нужно не забывать очевидные вещи: правильно выбирать тип картинки для сохранения JPG или PNG, выставлять тип Progressive для JPG, не использовать тяжелые (больше 200-300kb картинки).

Необходимо учитывать что спрайтов, base64 encode и css3-стилей может и не быть по причине ненужности (макет очень простой).


№9. Поддержка Retina




№10. Наличие Win/Mac/Linux-аналогов шрифтов


Alternative fontsЕсли альтернативные шрифты не прописаны, то у пользователей у которых отсутствует используемый в вёрстке шрифт, вместо него отобразится стандартный. Это может быть не только некрасиво, но и даже поломать отображение сайта.
Часто забывают прописывать альтернативы для Myriad Pro, Arial Narrow.

Проверяется поиском по тексту css названий “Helvetica”,“Liberation”, “DejaVu”,”Meera”,”Monaco”, “ Century Schoolbook L”,” Nimbus Mono L”, “URW”. Хотя бы два из них должны быть.

Исправляется указанием готовых наборов шрифтов (css font stack) с http://cssfontstack.com/

Также стоит ознакомится с тем какие шрифты идут стандартно в разных OS:




№11. Доступность при выключенных(загружающихся) картинках


Disabled ImagesНадписи (особенно логотип и главное меню сайта) должны оставаться читабельными, у всех информационных картинок должны быть подписи аккуратным небольшим серым шрифтом (да, для img можно задавать font – это внешний вид alt-текста, что выводится вместо картинки).
Картинки часто отключают при использовании дорогого инета, тарифицируемого по траффику (GPRS, роуминг).

Проверяется в FF через плагин addon Web Developer→Images→Replace Images With Alt Attributes.


№12. HTML5 формы, линковка, валидация


HTML5 Forms
  1. Label и input/select должны быть слинкованы.
    Это нужно для удобства юзеров. Также это очень облегчает жизнь пользователям с ограниченными физическими возможностями.
    Проверяется кликом по label – должен активироваться соответствующий ему элемент ввода.
  2. HTML5 валидация заполнения формы.
    Практическая ценность пока-что невелика, ведь серверная проверка ввода данных тоже может быть реализована без перезагрузки страницы (через ajax), но это говорит о проф. уровне исполнителя — у редкого числа юзеров современных браузеров с отключенным javascript, проверка ввода данных произойдёт средствами браузера, а не сервера.
    Проверяется в Opera: выключаем javascript, не заполняем форму, жмём Submit – должны появится уведомления о необходимости заполнить поля.
  3. JS-валидация формы.
    Это ожидаемое поведение. Пользователи привыкли что если они неправильно заполнят форму, им не дадут её отправить, а укажут на ошибки.
    Проверяется в Opera/Safari/Chrome: включаем javascript, не заполняем форму, жмём Submit – должны появится уведомления о необходимости заполнить поля.
  4. Если проверяем frontend в целом — должна быть серверная валидация формы.
    Проверяется в Firefox 3.6: выключаем javascript, не заполняем форму, жмём Submit – должны появится уведомления о необходимости заполнить поля.
  5. Правильные input type=”email/url/tel”.
    Пока-что практическая ценность для пользователя лишь в том, что на iPhone будет показываться клавиатура соответствующая формату поля ввода.
    Проверяется на iPhone — в зависимости от типа поля ввода он должен показывать различную клавиатуру: стандартную/цифровую/для набора web/email-адресов.


Уведомления об ошибках должны быть не js-alert’ом, а текстом в дизайне сайта!
Всё оформление в формах должно быть повешено на классы, id — только для линковки с label (a то потом программеры прикручивают, пишут свои id и ломается внешний вид).


№13. Семантичность. Отсутствие глупостей в html и css, единообразие, аккуратность


SemanticsПожалуй единственный пункт, где нельзя дать чётких критериев. Про то, что такое плохо можно почитать в моей статье «Вредная вёрстка» (делая скидку что она написана в 2008 году).

Плохо:
  • Самое страшное, к счастью уже редкое — float: left для всех блоков. Безумный верстальщик эмулирует привычные ячейки таблиц, расставляя блоки как кирпичи друг за другом. Вон из профеcсии! Проверяется: Web Developer Outline → Float elements, если всё в красных блоках, вёрстку нужно выкидывать на помойку.
  • Отступы между блоками на сайте должны быть за счёт margin у блоков, а не выпирающих наружу margin у содержимого блоков.
  • Плохо — отсутствие тайтлов.
  • Плохо — отсутствие alt у картинок.
  • Плохо — хаки для браузеров внутри main.css (как без фильтров, так и с ними). Без фильтров — это когда когда просто пишем {zoom: 1;} — это оч. плохо, т.к. будет применяться ко всем IE, а не только к тому, в котором проблема. С фильтрами — когда пишут (* html, *+html и т.д.) — плохо, потому что это засоряет код, делает его менее читабельным, а какие-то хаки могут быть и вообще невалидными и нарушать прогон CSSLint. Conditional Comments — тоже плохо, хотя раньше считалось хорошей техникой, плохо т.к. это увеличение кол-ва css-файлов и главное — это разнесение кода в разные места. Сейчас рекомендуется использовать специальные классы типа html.ie7, html.ie8,… (из HTML5 Boilerplate), Modernizer-детектирование фич (классы вида html.js.flexbox.canvas.no-touch…) и JS-детектирование браузера и платфорым (например CSS Browser Selector генерирующий классы вида html.webkit.chrome.chrome25.win.win8…)
  • Плохо — не проверять tabindex в формах.
  • Плохо — писать стили не думая о логике размещения элементов. Например, если элемент всегда находится сверху, у него должен быть большой z-index, нельзя надеяться на то что сейчас всё нормально смотрится — стили должны быть железобетонными. Если элемент всегда должен находится на каком-то месте, в независимости от окружающих его элементов — это position: absolute; а не float и т.д.
    Блоки независящие друг от друга не должны быть внутри одного блока (например телефон компании и поиск по сайту). Блоки независящие по расположению друг от друга должны быть position absolute, а не float’ится.
  • Очень плохо — презентационные классы (right, red).
  • Нежелательно когда вёрстка содержить пустые блоки для презентационных целей, для этого существуют псевдоэлементы
  • Плохо когда нет базовых стилей у стандартных элементов. Т.е. просто h1,h2,ul,table,etc без классов должны смотреться красиво и органично. Проще говоря — используйте Normalize, a не Reset CSS.
  • Плохо когда нет постепенного уточнения стилей для текста, когда стиль выписывается для каждого элемента отдельно, а за его пределами — внешний вид может быть кардинально другой. Речь о ситуации когда например текст, написанный без абзацев, имеет вообще не тот стиль что у всех элементов в блоке. Надо вести стили снизу вверх, постепенно уточняя их. Тут важно не путать стили для текста и стили для блоков. Для текста — каскад это добро, для блоков сайта — нужно использовать БЭМ.
  • Ещё хуже — чересчур детализированные глобальные стили. Например a {font: italic 10px Tahoma;} /* Ненависть! Ненависть! НЕНАВИСТЬ!!11 */ Потом приходится переопределять стиль ссылок для каждого блока.
  • Размеры и позиционирование элемента должны указываться в одних единицах измерения. Т.е. высота/ширина блока в px и margin/padding в em — это странно и скорей всего ошибка. Line-height — лучше задавать коэффициентом (1/1.2/1.4… т.е. без указания единицы измерения — это цифра на которую умножается font-size и получится межстрочный интервал). Если задали font-size/height в em — значит задаём и margin/padding тоже в em. Классический пример: список dl-dt-dd, где dt и dd ставятся друг на против друга с помощью подтягивания dd отрицательным margin вверх. Или — выделили padding’ом место под position: absolute какого-то текстового блока. У текстовых элементов (абзацей, ячеек таблиц) задаём padding и height в em (чтоб корректно увеличивать размер шрифта) .
  • Плохо(недопустимо!) вешать стили на селекторы вложенных стандартных тэгов, без классов. Т.е. допустим пишем что-то типа h2 a span {какая-то крепкая штука, типа картинки с графикой, что закрывает текст в заголовке}, а потом клиент в визиге внезапно вбивает такое сочетание! И получаем невероятный баг. На просто одиночные теги для вывода текста из БД — можно, но используя блок .b-text (смотри BEM CSS).
  • Плохо — напрямую задавать визуальное отображение элементов через js: $('.element').css(color,"#f00"). Это должно делаться через установку/смену классов.


Хорошо:
  • БЭМ! Важно понимать что это методология, а не инструменты. Для обычных сайтов достаточно вёрстки по BEM CSS, без использования библиотеки блоков и bem-tools. Я долго считал что «BEM — это классная идея, но это чересчур, так категорично не надо, надо чуть по-другому, под себя...», так вот — это неверно! Нужно обязательно уходить от каскада, а БЭМ — это один из отличных вариантов решения.
  • Хорошо — структурировать код в блоки описывающие логику документа. Т.е. создавать div даже там, где он для презентационных целей не нужен. И наоборот — стараться не ставить лишний div там, где структура этого не требует, а это нужно лишь для визуальных эффектов.
  • HTML5 Boilerplate — замечательный стартовый шаблон от «отцов». Используйте и присоединяйтесь к разработке, добавляйте свои велосипеды туда!
    Раньше у нас был свой самописный framework-стартовый html, теперь используем Boilerplate как основу, а в него уже добавляем старые наработки.
  • Используйте наработанные решения, чужие модули, jQuery-плагины, не изобретайте велосипедов, а если изобретаете — поддерживайте их, ведите библиотеку кода (после каждого нового проекта добавляйте туда код, обновляйте старый).
  • Для текстовых блоков, что редактируются в админке, должна обеспечиваться атомарность текстовых стилей. Т.е. есть у нас страничка с каким-то текстовым блоком, примерно такой структуры:
    .content-text h1
    .content-text .entry
    .content-text .entry .somenamedblock


    То .somenamedblock должен получать текстовые стили непосредственно — .somenamedblock {font: …; color: …;}, т.к. иначе в визиге админки мы не сможем их застайлить.
  • одинаковый html-код для блоков на морде и внутряках, с идентичным контентом, но разным визуальным представлением данных. Реализуется через модификаторы блоков и элементов, но не через модификацию от родителя (каскад от body.pagename например!)



№14. Правильная структура заголовков (H1,H2,… и т.д. и TITLE)


Document OutlineЭто забота о семантичности кода, заголовки структурируют сайт, делают его корректным документом. Корректный Document Outline важен для SEO.

Проверяется в FF через плагин addon Web Developer→Information→View Document Outline. Красных строк быть не должно!




№15. Работоспособность при выключенном JavaScript


Disabled JavascriptJS может быть выключен согласно корпоративных требований безопасности. А в Opera Mini он работает только методом перезагрузки страницы.
Но самое главное — сайт должен сохранять нормальный вид, пока он грузится на медленном 3G и js-скрипты ещё не выполнились!

Весь критически важный функционал сайта должен быть доступен без JS. Дополнительные фишки (например ссылки на увеличение шрифта или распечатку) – при выключенном JS не должны отображаться.

Если не хочется/нет возможности реализовывать функционал без JS, нужно хотя-бы выводить уведомление о необходимости его включить (реализовывается через <noscript>).

Проверяется в FF через плагин addon Web Developer→Disable→Disable JavaScript→All JavaScript.




№16. Работоспособность при выключенном Flash


Disabled FlashВ идеале весь критически важный функционал сайта был доступен без Flash. В реальной жизни нужно:
  • выводить фоновую графику в блок, где должен отображаться презентационный flash;
  • выводить хотя-бы просто тестовую инфу в блок где через flash выводится какая-то информация;
  • выводить кнопочку “Get Adobe Flash Player” и предлагать Express Install если уж без флеша совсем никак.

Flash не работает на iOS-девайсах. Flash плохо индексируется поисковиками.

Проверяется в FF отключением flash-плагина: Tools→Add-ons→Plugins→Shockwave Flash→disable.




№18. Отсутствие багов при увеличенном шрифте


Big fontsПроверяется в FF:
  • Шрифты – включением View→Zoom→Zoom Text Only и последовательным нажатие клавиш Ctrl + — (или View→Zoom→Zoom In).
  • 120 dpi – настраивается отдельным апплетом в Control Panel (Vista/Seven) или в свойствах драйвера видеокарты в XP.

Про приведение внешнего вида сайта на 120dpi к 96 читайте в моей статье «120 dpi и шрифты в em».



Для проектов, где это оговорено, проверяется:


Device Access
  • Версия для печати (она должна быть реализована через css)
  • Мобильная версия (таки тоже должна быть через css)





№19. Важные мелочи:


Small Issues
  • Лого на внутряках должно вести на титулку. На титулке logo = h1, на внутряках H1=заголовок контента, а Logo=div
  • У каждой страницы должен быть свой уникальный TITLE формата About Us — %CompanyName%
  • Все страницы должны быть слинкованы и проверены на наличие битых ссылок.
  • Все ссылки должны как-то реагировать на :hover, :active и :focus — показыванием/убиранием подчёркивания, сменой цвета, чем угодно. У всех ссылок, кроме пунктов меню, должна быть реакция на :visited
  • Проверять что все интерактивные элементы страницы что должны работать — работают.
  • «Контент в начале страницы» — содержимое страницы должно идти в начале кода, до всяких сайдбаров и прочего.
  • Все созданные странички изначально должны быть порезаны на шаблоны, чтоб программеру было легче их интегрировать.
  • Копирайт должен быть написан правильно.
  • Должны быть favicon.ico (желательно с включенными внутрь неё 32×32, 48×48 и 64×64 вариациями) и apple-touch-icon
  • В вёрстке не должны оставаться закомментированные «на всякий случай» куски кода, лишние неиспользуемые файлы, старые версии файлов и т.п. Все бекапы можно вытянуть из системы контроля версий (например Git или SVN), а на живом проекте «мусор» потом мешает разобраться как что работает.
  • Размеры для блоков, чьи размеры зависят от содержащегося в них текста, нужно задавать в em, а не px.
  • Если url ссылки неизвестен, то он должен быть равен её анкору, написанному латиницей с заменой пробелов/спецсимволов на тире.
  • Skype-плагин не должен ломать вёрстку
  • Ресайз textarea не должен ломать вёрстку
  • При проверке frontend в целом — 404-страница должна отдаваться с кодом 404 а не 200.
  • Нужно подстраховываться фиксируя в css размеры картинок, выводящихся программно.
  • Проверка орфографии Word’ом или Орфографом, желательно — оттипографить контент.
  • Ссылки на чужие сайты должны быть с target="blank", желательно выделять их иконкой «внешняя ссылка».
  • Разумеется картинки должны быть в отдельной папке, css — в отдельной и js — в отдельной. Графика, не являющаяся частью дизайна (всякие илююстрации, фото в новостях и т.д.) — нужно положить в отдельную папку, например userfiles.
  • Изображения должны масштабироваться в зависимости от размера окна (max-width:100%; height:auto;)


Где же 17? Пропущено, правильно, тест на внимание, не спи, чья-то рука в твоём кармане, йо!
И последнее, но самое важное тем не менее – на “WTF?” манагера — имей своё мнение :)

Доклад по мотивам статьи:



Чек-лист вёрстки. Что можно отдавать клиенту, а что надо переделывать
Ihor Zenich @Delka
карма
106,2
рейтинг 0,0
Frontend Developer
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (244)

  • +8
    Статья супер. Сам правда никогда не любил верстать. Но может если следовать советам из данной статьи, на выходе будет получаться хороший продукт, и я полюблю это дело.
    • +3
      Думаю, следовать этим советам следует прежде всего, если ты изначально умеешь верстать неплохо. А если верстальщих плохой, то советы эти вряд ли спасут. А пост неплохой, согласен, некий такой чеклист перед завершением всех работ.
      • +2
        Я старался написать чек-лист так, чтоб его критерии были формальными, а вёрстку можно было воспринимать как чёрный ящик.
        Например «Корректная работа при вбивании реального текста» — её можно организовать и написал килобайты css-правил и несколько выверенных строк. Для клиента результат будет один. Верстальщику же, сталкиваясь с такими требованиями, проще научится делать качественный код.

        С плохими верстальщиками дела не имел, но проекты написанные с соблюдением этих требований, ещё неопытными джуниорами, получились вполне качественными, мы время от времени вносим правки в старые проекты — желания «всё выкинуть и переписать» не возникает.
    • +2
      поправьте
      через-чур -> чересчур
      PRS -> GPRS
      роуминт -> роуминг
      аплетом -> апплетом
      В целом неплохо, только под конец теряется общая структурированность.
      Такой список уже пора и автоматизировать :)
      • +1
        поправил, спасибо

        автоматизировать было бы круто! призываем гуру-тестировщиков в тред :)
  • +32
    Ещё должна быть PHP-валидация формы.

    Какая блин php валидация на ВЕРСТКЕ?
    • +1
      Я так понял речь идет не только о верстке, а в целом, что следует проверять при создании сайта перед сдачей его заказчику. Потому что например
      >Все страницы должны быть слинкованы и проверены на наличие битых ссылок.
      этого верстальщик не обязан делать, имхо.

      Статья хорошая, Delka все по-делу расписал! Редко встретишь код, соответствующий требованиям (рекомендациям) что здесь описаны.
      • –18
        Я придерживаюсь мнения что самые простые вещи на php, например запрограммить отправку письма, верстальщик должен уметь. Бывают маленькие сайты, на которых всё статично, и php используется только для порезки на шаблоны и отправки письма с формы контактов.
        • +11
          Одно дело — мнение о том, что должен уметь верстальщик (знать то он желательно должен куда больше), но совсем другое — то, что к верстке это не имеет ровно никакого отношения.
          • 0
            воспринимайте это как чек-лист frontend'a в том числе.
            • +2
              Ну, я бы не стал. Фронтенд — слишком обширная отдельная тема.
        • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Аналогично, 404 ошибка при вёрстке?
      • +1
        Речь о маленьких, почти статичных сайтах, которые в продакшен запускает верстальщик, а не программер.
        Смотрите плиз мой коммент выше.
  • –1
    пхп-валидация наверное имеется ввиду проверка введенных значений :)

    Автору статьи — Спасибо!
  • +6
    Не забывайте только все эти требования оформить в виде ТЗ при заказе верстки, а то большинство ваших желаний отнюдь не обязательны по умолчанию.
    • +1
      конечно! ради того и писалось.
      у нас в компании это — внутренние стандарты и требования для аутсорсеров.
      • 0
        В моей компании подобное не только не является внутренними стандартами, а вообще не рассматривается кем-либо, кроме меня, всерьёз. Это печально…
  • –1
    на самом деле, все правильно сказал)
  • +3
    Великолепная статья!
    Маленькое дополнение: IE8 в режиме совместимости с IE7 != IE7. На хабре даже была статья с описанием, что за чудо этот режим совместимости, и как с ним бороться.
    • +1
      Да, есть небольшие отличия, но в целом, они почти идентичны. Во всяком случае если в режиме совместимости с IE7 возникает баг — он будет возникать и в реальном IE7.

      А, глядишь, пройдёт ещё годик и похороним IE7 так же как многие уже забыли про IE6.
      • –1
        Я на своём сайте прописал

        надеюсь этот недорежим "несовместимости со стандартами" отключается. Пользователей старых IE предупреждаю, что их браузер устарел и не придерживается страндартов. Сделал это с помощью:

        Тем, кому действительно нужен мой сайт поставит нормальный браузер или наконец-то обновит свою Windows XP через Windows Update или WSUS.
        • 0
          Ох, чёрт. Не думал, что внутри code тэги съедаются… в первом случае речь идёт о метатеге http-equiv="X-UA-Compatible" content="IE=8", во втором про [if lt IE 8].
          • +2
            для X-UA-Compatible лучше указывать IE=edge, а то скоро 9-ка выйдет и будет ваши сайты отображать так же как 8-ка, а могла бы — гораздо лучше!

            и желательно не метатегом это писать (валидатор ругается), а в .htaccess:
            <IfModule headers_module>
            Header set X-UA-Compatible: IE=edge
            </IfModule>

            ну или прямо в коде сайта отправлять этот header
            • 0
              На счёт .htaccess как-то не подумал. А вот по поводу IE=edge мне пока рано думать. В IE8 всё правильно отображается пока (собственно ничего специально под него не дорабатывал). А вот в IE9 проверять будет проблема — надо Windows 7 ещё найти.
  • +4
    Отличная статья — объёмистый материал в понятном и сжатом виде. Автору спасибо.

    Автору:
    — Следует указать, что необходимо проверять, как отображается страница при загрузке на малых скоростях (хотя бы 64 КБ). Очень часто в такие моменты пользователь видит разъехавшуюся верстку.
    Throttle — плагин FF. Позволяет ограничить скорость браузера, тем самым спытать web-проект на разных скоростях интернет соединения.
  • +26
    Выполнение всех этих пунктов увеличат себестоимость вёрстки как минимум в 2-4 раза. Не каждый заказчик согласится заплатить за вёрстку столько же сколько и за дизайн :) Но чеклист явно пригодится…
    • +1
      не вижу связи. в статье разобран подход к верстке, как к процессу. аналогично, как группа программистов договаривается о стандартах при создании кода.
      • +3
        Но вот работу программиста не всегда можно проверить, а вооружившись описанным в статье инструментарием среднестатистический заказчик начнет требовать соблюдения от вёрстальщика всех стандартов и правил при этом платя такую-же сумму как и раньше.
        • +2
          среднестатистический заказчик изначально имеет право требовать соблюдения стандартов верстки. другое дело, что
          а) большинство заказчиков этим никогда не станут заморачиваться;
          б) руководитель любой более-менее серьезной конторы должен сам требовать от своих подчиненных соблюдения стандартов. в данном случае, верстки. иначе и до гуано-кода докатиться можно;
          в) будет происходить некоторый отсев при взаимодействии «среднестатистического заказчика, вооруженного описанным инструментарием» и представителей конторы-разработчика. с тем же успехом, отсев происходит по вопросам стоимости работ, срокам выполнения и т.д;
          • +2
            Одно дело стандарты, а другое pixel perfect вёрстка и оптимизация её загрузки в браузере, микроформаты тоже кстати можно отнести больше к гиковсим-фишкам, нежели к стандарту де факто.
        • 0
          тогда вон из профессии!
          img-fotki.yandex.ru/get/5803/i-zharskiy.d/0_44d57_ea04b4f2_L.jpg
          • 0
            Уж поверьте, я вёрстаю куда лучше вас.
    • 0
      ИМХО, заказчику вовсе не обязательно знать, сколько из стоимости проекта он платит за дизайн, сколько за верстку, а сколько за программирование. Лучше сделать дороже, но качественнее.
      • +3
        Вы наверное работаете в конторе которая берёт за проект от 300 тыс. рублей. Хочу вас обрадовать, не каждая фирма может позволить себе такие излишества.
        Я думаю вёрстальщик бы с радостью потратил своё время на то, чтобы сделать качественный продукт и положил бы его в портфолио, если бы ему за это заплатили деньги и дали достаточно времени, а не как обычно у нас в стране бывает — «к вчера».
        • 0
          совсем нет, от $1000. Бывают и по $10000, но afaik средний проект в районе $5000.

          сроки для вёрстки:
          • титулка — два дня
          • внутряк — полдня
        • 0
          Какая разница, сколько стоит проект? Речь не об этом. Я считаю, что посвящать клиента во все детали ценообразования — это крайне не верный подход. Да, понятное дело, что когда горят все сроки, никто не будет заморачиваться с чек-листами, главное чтобы клиент увидел то, что он хочет. Но когда времени достаточно, почему не сделать верстку качественно?
        • 0
          если речь идет о личном портфолио верстальщика, то сделать качественно — это уже вопрос профессионализма, деньги тут вообще не причем.
  • +1
    Забавно, у нас этим тестировщики занимались, а тут сам ПМ верстку чекает. Скажите, вы, наверное, еще и бэкенд весь проглядываете?
    • +1
      так точно. у нас маленькая фирма, а римт работ довольно спокойный.
      • +1
        Думаю, у каждого приличного ПМ, на основании предыдущего опыта, уже есть сформированный чек-лист или сервис в запасе, типа launchlist.net/
  • +1
    Отличная статья.
    IE 6 можно проверять через IETeester
    • +2
      Вы ради интереса проверьте на родном IE6 и в IETeester — это небо и земля. Так что IETeester не выход.

      Удачное решение от Adobe, где можно посмотреть отображение сайта во всех браузерах
  • 0
    target="_blank"

    С удивлением обнаружил, что такого атрибута нет в xhtml1-strict
    • +1
      Вообще, читал, что использование этого атрибута не является «правильным», так как нарушает привычный паттерн — юзер просто хочет перейти по ссылке, а тут у него вдруг новое окно/вкладка открывается. Если я хочу новую вкладку, то я жму колесиком (если знаю о таком поведение), а _blank ломает шаблон.

      Если уж придерживаться такого требования для внешних ссылок, то желательно тогда добавить еще одно: для таких ссылок как-то показывать, что ссылка внешняя (иконкой например).
      • 0
        вы правы, но уж больно не нравится клиентам, когда уходят с их сайта по какой-нибудь ссылке a-la «BBB Accredited Business».

        да, желательно выделять такие ссылочки иконкой «внешняя ссылка», дополнил.
        • +4
          Клиент, который тешит себя ложными мыслями, которому больше нечем удержать посетителей, кроме как открытие внешних ссылок в новой вкладке, не вызывает восторга.
      • 0
        Некоторые браузеры подсвечивают, что будет открыто в новом окне (вкладке). Например, Konqueror подрисовывает иконку при наведении на такую ссылку.
    • 0
      Его вернули в HTML5.
      • 0
        Это я тоже обнаружил.

        Только я ещё хотел намекнуть, что там есть ещё нижнее подчёркивание.
    • +1
      Ненависть ко всем, кто использует target="_blank"!
      Все браузеры открывают страницу в новой вкладке при щелчке на колёсико (в крайнем случае можно выбрать новую вкладку в контекстно меню).
      • 0
        Колесика может не быть, а открытие контекстного меню долгим. Мне нравится как гугл в поиске сделала — открывать ссылки в поиске или нет задаётся в настройках. Жаль что ко всем ссылкам на гугле это не относится.
        • 0
          Всегда думал, что большинство пользуются Ctrl+click… но что-то в последнее время в сети встречаю описания только с колесом. Ну неудобно на него нажимать — слишком легко прокручивается и ссылка может уползти.
          • 0
            Вот Ctrl+Click не разу не пользовался, уж проще, через ПКМ. Но вообще я говорил выше о девайсах, где ни мыши нормальной, ни клавиатуры :)
  • +3
    DOCTYPE: HTML5
    Зачем нужно: это современный стандарт, XHTML – тоже хорошо, но HTML5 – актуальней, да и это модный тренд сейчас.
    Проверка: открываем исходный код страницы, первая строка должны быть <!DOCTYPE HTML>

    Это минимально необходимый доктайп, чтобы IE не свалился в Quirks, а не HTML5
      • 0
        На что вы намекаете?
    • 0
      спасибо, забыл самую главную причину то написать, настолько привык к тому что правильный doctype дожен быть, что уж и позабыл что его могут вообще не указать и не знать зачем он :)

      дополнил.
  • +3
    Плохо когда нет постепенного уточнения стилей, а стиль выписывается для каждого элемента отдельно

    Здесь частично не соглашусь. Плохо — только при плохом подходе. Например, если у каждого такого уточнения стоит разный background:url("..."), то некоторые браузеры будут загружать этот новый бэкграунд каждый раз при этом уточнении, независимо от того, какой в итоге должен быть (проверял, правда не помню, какие браузеры)

    На очень крупных и частоменяющихся проектах хорошо действует идеология clubs.ya.ru/bem/. Вложенность там есть, но очень неглубокая. Там же рекомендуют отказываться от reset.css.
    • 0
      Спасибо за ссылку!
  • +2
    Проверяется поиском по тексту css названий “Helvetica”,“Liberation”, “DejaVu”,”Meera”,”Monaco”, “ Century Schoolbook L”,” Nimbus Mono L”, “URW”. Хотя бы два из них должны быть.
    Наборы аналогов популярных шрифтов:

    Не согласен. Вообще ставить что-то кроме семейства шрифта, имхо, необходимо только тогда, когда это _действительно_ нужно. Обычно с головой хватает
    font-family: sans-serif;
    
    • 0
      Дело в том, что текст написанный разными шрифтами, имеет различную ширину и это может оказаться критичным для дизайна (например название пункта меню просто не влезет в отведённое ему место)
      • +1
        Тогда, наверное, для большинства сайтов следует ограничиться указанием конкретного шрифта только в критических местах (те же меню и другие элементы с фиксированным размером), а вот для основного контента указывать только семейство шрифтов.
  • 0
    target="_blank" == невалидность хтмла
    • +7
      В HTML5 target="_blank" снова разрешили.
  • +1
    Грамотно, нравится, но так из проекта в проект?
    Рассматривались ли возможности автоматизировать проверку, не говоря уже о процессе верстания?
    • 0
      Вёрстку автоматизируем за счёт максимального повторного использования кода. После вёрстки каждого нового проекта мы добавляем в коллекцию готовых решений те блоки, которых там ещё нет.

      Автоматизировать проверку бы очень хотелось, будем искать гуру-тестировщиков.
  • +2
    Вместо пиксел-перфекта пользуйте ModularGrid (http://habrahabr.ru/blogs/webdev/109988/). В разных браузерах макет может выглядеть по-разному.
    • +7
      Всё так. Ох уж этот пиксел-перфект — жечь его надо каленым железом. Очень часто PM требуют его, тратя драгоценное время разработчиков на статисфакцию никому ненужных пожеланий, когда они могли бы заняться чем-нибудь более полезным для проекта. Я о тех клинических случаях, когда приходят нервные письма с кучей скриншотов и гневными возгласами «Катастрофа! В FF шрифт больше на полпиксела! И вот input, у формы, не такой как в макете.» Особенно если речь про большие проекты, к презентационным сайтам это не относится (идиотизм пиксел-перфект в этих случаях вполне оправдан).
      • 0
        Согласен, многим не хватает здравого смысла в этом вопросе.

        Попросите вашего PM'а сверстать в HTML страницу своего резюме что ли =)
        • +2
          Стараюсь не сталкиваться с подобными PM.
      • 0
        Конечно во всём нужно знать меру.
        Тем более обязанность ПМа — не затягивать сдачу проекта, тратя время (а значит и деньги фирмы) на вылизывание каждого пикселя.
    • 0
      спасибо, дополнил
  • 0
    Да, и ещё, на главной странице ставить название компании в h1 можно только с разрешения оптимизатора.

    Вообще, в h1 лучше запихнуть текст ключевого запроса для сайта, или название ключевой услуги. Название компании прекрасно себя чувствует в strong, например.
    • +6
      СЕОшников забыли спросить, что ставить в h1 а что в strong :-)
      • +1
        Вы правда думаете, что мы верстаем сайты чтобы верстать сайты?
        • +6
          Я думаю, что большинство СЕОшников имеют довольно смутное представление о html и неимеют никакого представления о семантики. В первую очередь нужно помнить, что html — язык разметки web-документа, а не инструмент для СЕО
          • +3
            Мне кажется, что в первую очередь нужно помнить о цели создания сайта — ну это так, лирика. Я сдаюсь перед вашим упорством =)
  • 0
    спасибо.
    буквально вчера озадачился таким чеклистом
    спасили кучу времени
  • +3
    1.1, 1.2 — не профессиональная аргументация
    1.3, предпоследних версий тоже много установлено :)
    1.3 Проверка в IE7 и проверка в режиме IE7 — есть различия, плюс режим IE7 менялся некоторыми обновлениями Windows Update, так что… лучше просто в IE7

    2.2 Упоротая секретарша копипастит тексты из Word’а в визиг — это надо предусматривать, и чинить, и инструкцию секретарше писать, и теги лишние фильтровать где можно :)

    Начиная с 4го пункта, я так понимаю написано уже не для заказчиков?) Как проверять, опускаете, но пошли советы разработчикам :)
    • +1
      1.1, 1.2 — не профессиональная аргументация
      как на ваш взгляд нужно аргументировать 1.1 и 1.2?

      1.3, предпоследних версий тоже много установлено :)
      к счастью они быстро (пару месяцев) уходят со сцены благодаря автоапдэйту.

      1.3 Проверка в IE7 и проверка в режиме IE7 — есть различия, плюс режим IE7 менялся некоторыми обновлениями Windows Update, так что… лучше просто в IE7
      согласен, но учитывая что IE7 уже недолго осталось жить, можно ограничится режимом совместимости. Во всяком случае если в режиме совместимости с IE7 возникает баг — он будет возникать и в реальном IE7.

      Начиная с 4го пункта, я так понимаю написано уже не для заказчиков?) Как проверять, опускаете, но пошли советы разработчикам :)
      вроде бы везде написал как проверять, подскажите плиз где нехватает.
      • +1
        Не думаю, что IE7 осталось жить недолго. Кто ещё не обновился обновится, скорее всего, только при смене ОС. Кто ещё не обновил Висту и, тем более, XP обновят ОС, скорее всего, только при смене железа…
      • 0
        на мой взгляд:
        1.1 — универсальность, совместимость
        1.2 — пока не нужно аргументировать :)

        5й пункт — есть что плохо/хорошо, есть примеры, как проверять нету)

        кстати) как решаете вопрос с печатью спрайтов? (версия для печати, css background)
        • 0
          спасибо. дополнил.

          В версии для печати и должен печататься только контент, без иллюстративной графики. У нас там по сути картинок нет, ну кроме фото товаров у клиента.
    • 0
      2.2 Упоротая секретарша копипастит тексты из Word’а в визиг — это надо предусматривать, и чинить, и инструкцию секретарше писать, и теги лишние фильтровать где можно :)

      Прекрасно лечится jevix'ом и избавляет от лишней головной боли верстальщикам
      • 0
        оно то да, и в идеальном мире программеры не выводят картинки не того размера в шаблон, а визиг в админке — textarea где можно вбить только текст :)) вот, только бывает по всякому, хороший верстальщик должен делать свой код пуленепробиваемым.
  • 0
    Спасибо. В Избранное.
  • +4
    Ну и вопрос, в каких ценовых пределах находится создание сайта, удовлетворяющего этим требованиям?
    • +2
      Я верстаю по данным стандартам. Цена примерно в 3 раза выше рыночной. Но заказчики готовы платить, даже очень.
      • 0
        Под рыночной я имею ввиду среднюю цену на фриланс-сайтах.
        Заказчики платят за отсутствие головной боли в дальнейшем…
        • 0
          А вот по поводу html5 я не согласен. Слишком мало браузеров его нормально понимают, т.ч. пока верстаю по старинке в XHTML Strict.
      • +1
        Не-ве-рю! В смысле, не верю, что верстаете именно по всем стандартам. Чего только стоит сделать правильный сайт под WCAG/WAI/Section 508. Именно правильный для людей с ограниченными возможностями, а не для валидатора. Таких сайтов единицы на весь интернет.
        • 0
          Тут вы несомненно правы, это очень сложно, и за это оглашается дополнительная цена, если заказчик потребует.
    • +1
      $200-250 титулка, $50-60 внутряк.
      • +1
        SEOник отдельным пунктом у вас?

        потому что про микроформаты, карты и т.п. — я лично это считаю обязательным и очень важным, всегда делаю сам и от других требую, а кто-то считает баловством (категорически не согласен, есть печальные примеры)

        у вас очень грамотно, если вы действительно всё это внедрили в процесс разработки, — то честь вам и хвала

        отдельная благодарность за статьи, за то, что делитесь знаниями (я не знал 1 или 2 пункта всего, но они довольно интересные), за то, что дорабатываете посты и активно обсуждаете в каментах (конструктивно)

        ваши посты читаю, заношу в избранное, распечатываю, внимательно анализирую
        и потом ещё возвращаюсь за новыми комментариями
        • 0
          спасибо,

          Извиняюсь, не совсем понял вопрос «SEOник отдельным пунктом у вас?»

          Про организацию отдела вёрстки планирую сделать доклад этой весной/летом.
          • +1
            У вас всё хорошо написано именно с точки зрения SEO.

            Некая изначальная семантичность/оптимальность входит в базовый набор услуг и оговаривается в брифе/ТЗ?

            К верстальщикам есть требования SEO-грамотности, знания важных основ?

            Вы это как-то специально упоминаете в рекламе? (IMHO имеете право, если приведённый checklist — каждодневная, обычная практика)
            • 0
              1. да входит.
              2. наверно благодаря тому что пишут качественный код, оно само собой получается, знают что к чему, сами задумываются как лучше разметить, перенести ли контент в начало страницы (кстати! забыл-то упомянуть, сейчас допишу!) и т.п.
              3. да, упоминаем.
  • +2
    думаю что пункт о показе банеров даже с включенным адблокером лучше не упоминать
  • +2
    Отличная, полезная статья. Несколько замечаний:

    Есть несколько специфичных моментов. Вы пишете на PHP — у вас валидаци в PHP и расширение файлов — php, у кого-то будет другое. Вы пишете на Windows 0 вы ищете аналоги шрифтов на Mac/Linux, у кого-то ьбудет наоборот и т.д.

    > модный тренд

    Руки так и тянутся к топору. Пишите по-русски.

    • +1
      Вообще говоря, «тренд» это вполне себе русское слово. И совсем не потому, что недавно обрусело из-за массовости, а потому, что это термин математики и статистики.
      • 0
        Слова «тренд» и «мода» в каком-то смысле синонимы, и «модный тренд» это какое-то масло масляное получается.
  • –3
    Статья — полная чушь. Какая-то реклама HTML5. Большинство пунктов вообще можно оспорить.
    • +2
      Оспаривайте, интересно почитать
      • +6
        1.2. DOCTYPE: HTML5.
        Выбирать HTML5 из-за его актуальности и модности? Бред. Автору советуется почитать хотя бы Якоба Нильсена и узнать на что же нужно опираться, выбирая какую-нибудь технологию.

        1.3. Кроссбраузерность.
        Проверка веб-сайта лишь в последней версии браузера может быть черевата в некоторых случаях. Про IE6 — автору рекомендуется посмотреть видео «Кривое зеркало» Сергея Чикуёнка (http://2010.404fest.ru/video/item-23/). Ну и про мобильные браузеры — или автор не делал веб-сайты под них или делал, но очень простые и не понимает, почему в нынешнем уровне развития технологий гораздо лучше сделать специальную версию веб-сайта для мобильных устройств, поместив её на, допустим, поддомене.

        2.1. Не должно быть js-ошибок!
        Спаисбо, кэп!

        2.1. Микроформаты должны быть.
        Микроформаты должны быть, если их использование уместно. Бездумное набивание веб-сайта функционалом, микроформатами и прочего — яркий пример непрофессионализма. Здесь автору рекомендуется почитать Алана Купера.

        4.2. и 4.5.
        См. первый ответ.

        6. Правильная структура заголовков. Важна для SEO.
        Она не для SEO важна (и вообще хватит говорить об этом позоре), а для вас, когда вы будете писать стили для разных устройств.

        Пункты 8, 9, 10.
        Только если вы «Яндекс».

        Всё это обнаружилось беглым пробегом, уверен, что если поискать и попридираться, можно найти ещё. Но, прошу прощения, у меня тут не школьные каникулы :-)
        • +1
          > Пункты 8, 9, 10.
          >Только если вы «Яндекс».

          Вот так и остаются некоторые пользоватеи с Интернетом, в котором работает один Яндекс.
          • 0
            А, ну давайте теперь и поддержку IE5.5 обязательной делать. Иначе что, у них тоже один Янекс работать будет?
            • 0
              IE устарел, отсутствию js есть другие причины.

              Прочитайте статью внимательнее. Там всё есть.
        • +1
          1.2. DOCTYPE: HTML5.
          Выбирать HTML5 из-за его актуальности и модности? Бред.

          Нет, выбирать HTML5-доктайп из-за того, что это единственный разумный выбор сегодня.
          Аргументация здесь: Доктайп. Точка
          • 0
            спасибо, добавил ссылку на презентацию.
        • +2
          1.2 А почему ж не выбирать акутальную технологию? Какие есть объективные доводы против HTML5? Плюсов много.

          1.3 Каюсь, до сих пор не посмотрел то видео, обязательно посмотрю, но! Я считаю не стоит цепляться за старое, закопайте наконец стюардессу, доля IE6 уже меньше 4%. И явно часть этой доли — верстальщики, проверяющие в нём вёрстку :)
          За прошедший год, только 1 (один!) клиент попросил нас добавить поддержку IE6. Благодаря отказу от его поддержки мы можем писать более чистый, красивый, удобный в поддержке код. Значительно меньше времени уходит на разработку и поддержку. Сайты лучше и быстрее отображаются в современных браузерах.

          2.1 Чем помешают микроформаты? Они не бездумные, нам в любом случае писать html-разметку, почему же не использовать определённые стандарты кодирования? Это только ускоряет процесс, верстальщик точно знает — это пишем так, а это так.

          4.2 и 4.5 — чем плохи html5 формы? Какие проблемы с новыми типами input? Они обратносовместимы, старые браузеры просто покажут input[text]. Смена клавиатуры под формат ввода на iPhone — это очень удобно.

          6. Конечно в первую очередь это семантика документа, дополнил. Но согласитесь — стили для разных устройств можно написать и для сайта где кроме span class ничего не используется.

          8,9,10 — полезно всем. Дополнил что если уж впадлу делать — так хоть уведомление через noscript выведите.
          • +1
            >Я считаю не стоит цепляться за старое, доля IE6 уже меньше 4%.
            Доля IE7 IE8 = 25%. Они поддерживают HTML5?
            • +1
              graceful degradation для IE8 и тем более IE7 допустим.

              некоторые наиболее востребованные css3-свойства весьма клёва эмулируются через pie.htc (там через VML, всё кошерно).
          • 0
            1.2 По сути сейчас HTML5 поддерживает более-менее нормально только WebKit. Остальные должны игнорировать незнакомые элементы (вместе с содержимым). Всех пользователей пересаживаем на Хром(иум) и Сафари?
            • 0
              всё зависит от конкретных фич, которые вы используете в конкретном проекте, что именно из html5 и css3 вам нужно. обычно не так много то и надо :)

              смотрите плиз коммент чуть выше про graceful degradation.
              • 0
                Я про всякие section, article, header, footer и т. п. Свойства-то понятно, что если даже игнорируются, то не смертельно.
                • 0
                  Это ведь те же div, просто несущие доп. семантику.
                  Для IE есть маленький js-скрипт, позволяющий стайлить html5 элементы в css.
                  • 0
                    Ну вот и хочется эту семантику нести не в классах или ид, а в элементах, раз уж html5.

                    По-моему, дело одним IE не ограничивается, но это ладно, какие-нить хаки наверное есть, хотя что этот скрипт делает не понял, уж очень всё минимизировано, а вот насчёт гугла-яндекса вообще не уверен, парсят ли они html5 или нет.

        • 0
          Вы назвали статью чушью основываясь на своем субъективном мнении, а оспаривая, сами соглашаетесь с некоторыми выводами автора. Вы не там чушь увидели ;)
          Возвращайтесь, когда школьные каникулы начнутся :-)
      • +3
        >HTML5 – актуальней, да и это модный тренд сейчас
        HTML5 уже принят в качестве стандарта? Тыркните где об этом можно почитать.
        • 0
          Наверно этот комментарий не ко мне?
  • +7
    Очень много спорных заявлений. По поводу тренда и моды на доктайп, рекомендую посмотреть небольшой доклад Вадима Макеева Доктайп. Точка.
  • +3
    > IE7+ (для IE6 выводится уведомление о неподдержке и предложении скачать другой браузер, но с возможностью всё-таки просмотреть сайт)
    > Safari 3 (в нём «размытые Mac'овские» шрифты, они чуть большего размера, из-за этого бывает вылазят баги) + последний Safari

    Странные требования. Что-то мне подсказывает, что Safari 3 в разы меньше, чем IE 6
    • 0
      Ну, чтобы «поддерживать» Safari 3 никаких особых дополнительных усилий не надо, а вот IE6 — жесть.
      • +1
        Вообще-то, дизайнер/верстальщик должен следовать не мантре «мне так удобнее» или «это жесть», а хотя бы таблице graded browser support

        Правда, в первой четверти этого года IE6 переходит в C-grade, так что уже неважно
        • 0
          Ну вот о том и речь, никто и не говорит, что с IE6 вообще не надо заморачиваться, просто должно выводиться предупреждение о том, что браузер устарел и советовать его обновить.
        • +1
          В идеале верстальщик должен уметь поддерживать всё хоть как-то еще встречающееся — и IE6, и Safari 3. Но нормально объяснять клиенту (или ПМ-у, а тот — клиенту… нутыпонел) стоимость поддержки каждого динозавра.
          • 0
            Уметь — да, конечно, должен!

            Я отчасти понимаю ваше желание поддерживать 6-ку. Когда уже знаешь её баги и умеешь с ними бороться — чувствуешь себя круче других. «Я настоящий профи, я с лёгкостью поддерживаю IE6 в своих проектах, на радость клиентам, а те кто это не делают — неумёхи и не думаю про несчастных юзеров».
            Ещё недавно так всё и было. В 2009 году я для повышения скилов потребовал на одном проекте сделать поддержку IE5 :)

            Но сейчас есть вещи гораздо сложнее и круче чем zoom: 1; для hasLayout. А 6-тым IE скоро будут пользоваться только те кто в нём проверяют вёрстку, как в своё время было с NN4 :)
            Лучше повышать свои скилы изучая CSS3 и HTML5. Там много крутых вещей и возможностей порадовать пользователя.
            • 0
              Поддерживать IE6 — это было моё желание как руководителя (хотя я им никогда не был), а вот как верстальщику поддерживать IE6 мне не очень интересно. С другой стороны делал недавно одну страничку для себя на float-блоках… хаков для ie6+ie7 понадобилось гораздо больше, чем для одного ie6. Да, в strict mode.
              А что там в css3 такого?
              — навороченные селекторы уже использую в js.
              — веб2.0 рюшечки? Регулярно нападает желание сделать что-дь такое гламурное одним css3 без картинок. Например, нижнюю панель как в WinXP silver.
              ну и т.д.
              Впрочем, я был веб-программистом широкого профиля и вёрсткой занимался только частично, а сейчас перешёл практически чисто на js. Вкусно и питательно!
              • 0
                Вчера вот верстал под хром, слои фона очень понравились.
              • 0
                Страничку на float-блоках делать не надо. Я правильно понимаю что вы задавали почти всем блокам float: left? они тогда схлопываются до своего содержимого и друг за дружкой идут, похоже на ячейки таблицы. Это очень плохо, очень.

                Да, рюшечки и селекторы :)

                CSS3 gradients, rgba, box/text-shadow, border-radius — на самом деле очень большой шаг вперёд — прописать несколько правил, а не нарезать картинки и мучатся с их позиционированием.

                • 0
                  Нет, не всем. Все float-блоки у меня собраны внутри div с фиксированной шириной. Раньше там вообще таблицы были =)

                  Рюшечки css3 с приличной деградацией в IE6-8: imperion.kirilloid.ru/beta/
                  3 картинки + один спрайт на все иконки + спрайт с подписями к «лампочкам».
                  ЗЫ: индикаторы «врут» — ошибки нет )
    • 0
      Это всего-лишь способ проверить сглаживание шрифтов «как на Маке», дополнил статью пояснением.
    • 0
      ниже в комментах мне подсказали что маковское сглаживание можно включить и на 5-том Safari под win.
  • 0
    Pixel Perfect — офигенно удобная и полезная вещь!
  • +2
    Не «типографировать», а «оттипографить». Этот неологизм построен из самого названия лебедевского инструмента.

    Последний абзац порадовал :)
    • 0
      спасибо, поправил
  • +4
    Opera Mini (проверяется в Opera 9.64→Вид-Маленький экран)

    Плохой совет. А вот хороший: Opera Developer Tools — Opera Mini Simulator и Opera Mobile Emulator, иначе мини-режим в 9.64 это просто ужатая вёрстка. Это как проверять поведение в iOS на Safari, глупо же.
    • 0
      Opera Mini Simulator требует какой-то плагин, но при клике на «Хотите узнать подробнее об установке плагина» выводит страничку с кучей ссылок про разные плагины, так и не подсказав какой нужен.

      Мини-режим в 9.64 — это не ужатая вёрстка, подгружается handheld.css а не screen, внешний вид отображению в Opera Mobile на мобильнике.
      • +4
        хихи, расскажи Макееву про Оперу
        • 0
          уже рассказывал :)
          а что ж поделать, я сам Оперу очень люблю, но ни что не идеально
      • +2
        Симулятор Opera Mini — это Java-приложение, требует соотв. плагин. Java в обычных системах это вроде бы не бог весть какая редкость. Так что это не похоже на проблему. По меньшей мере, стоит тестировать в эмуляторе Opera Mobile, хотя соотношение пользователей Mini/Mobile — 85/15%.

        В любом случае, даже если подргузится handheld.css вы не вспомните про ограниченный JS, особенности рендеринга и потенциальные проблемы. Так что разумнее будет открыть страничку с симулятором, а не держать на машине 9.64.
        • 0
          ага, спасибо, отредактировал статью.
  • 0
    с версткой статьи все ок, но вот сетка поехала ;)
    • 0
      Вы имеете в виду что некоторые картинки меньшего размера по ширине? они некрасиво смотрелись в полную ширину, а я увы не нашел ничего лучше чем уменьшить их размер чтоб было симпатичней.

      А если вы про отступы у заголовков, списков — я боролся с хабра-парсером за красоту как мог :)
      • 0
        да картинки можно думаю все убрать только скачут, читать мешают, можно было пиктограммами html5 го все оформить, только размер их уменьшить раза в три
        • 0
          спасибо,
          уменьшил размеры картинок, сделал все одинаковыми слева
  • +6
    В целом хороший список, отражает, скажем так, «Best Practices» для работы с версткой, хотя тут и не все пункты и подпункты касаются именно верстки.

    Однако на практике некоторые пункты несут определенный «overhead» в объеме работ, и нужно уже смотреть по конкретным требованиям, а не пытаться сделать каждую и каждую страницу максимально доступной (accessible). Ну типа круто бы, конечно, чтоб даже при выключенном мониторе отображалась надпись «Включите монитор для полноценной работы сайта», но сделать — сложно, и не всегда нужно.

    Я бы добавил еще по пунктам:
    0. Не забываем, что есть еще весьма полезная штука — SuperPreview, особенно для тестирования в IE.

    3. В большинстве (абсолютном большинстве) я бы использовал или WYSIWYM-редактор, или простой текст с Markdown вместо этих TinyMCE, FCK и прочих. В любом случае — стили должен задавать дизайнер сайта, а не пользователь.

    15. > «Расширение страниц на сайте всегда должно быть ».html", а все созданные странички изначально должны иметь расширение .php, быть порезаны на шаблоны и работать через mod_rewrite."
    А зачем там вообще какое-то расширение. Ну и, конечно, ".php" совсем не «должны» :)

    Ну а заодно,
    16. Лого на главной должно быть активным и вести на главную же страницу. Вопреки расхожему мнению, лого-ссылка — это не обязательно лишь ссылка, а некоторый контекстный элемент с очень удобным поведением — на всех страницах это ссылка на главную, а на главной — это основной инструмент «рефреша» страницы. Особенно актуально для часто-обновляемых ресурсов.

    Ну и, в заключение добавлю, что львиную долю проверки перечисленного в топике можно автоматизировать.
  • +3
    Хотя я и 10 лет «верстаю» — и половины наверное не делаю. Это ужасно.

    «Skype-плагин не должен ломать вёрстку» — FFFFFFUUUUUUUUUUUU я бы на манагера накинулся наверное скажи он мне такое)))))) «Эти суки лезут в код ломают его а я должен теперь из-за них работать дополнительно!!!!»)
    • 0
      Думается, когда проекты стоят не 20-40 килорублей, а 1000-1500, такие вещи выслушиваются и делаются.
      • 0
        это вы про проекты из РосПила говорите?))))))

        вообще-то конечно да, я сам сторонник «заплати налоги и спи спокойно»
  • 0
    Если используем html5 доктайп, то можно ли использовать тэги, которые есть в html5, но нет в html 4? :)
    • 0
      да конечно
  • +5
    Статья хорошая, но немного спорная. И чуть смешано с программной частью разработки сайта.
    Если же вставляем хаки для IE в main.css, то их нужно фильтровать: (* html, *+html и т.д.).
    хаки такого типа отстой, мне больше:
    <!--[if lt IE 7 ]> <html class="no-js ie6"> <![endif]-->
    <!--[if IE 7 ]>    <html class="no-js ie7"> <![endif]-->
    <!--[if IE 8 ]>    <html class="no-js ie8"> <![endif]-->
    <!--[if (gte IE 9)|!(IE)]><!--> <html class="no-js"> <!--<![endif]-->
    
    Можно и body вместо html, но не забывая про lang=«ru» либо в body, либо в html. А лучше откройте для себя html5boilerplate.com.
    Насчёт №8 работоспособность при выключенном JavaScript вводить class, например, no-js — выше код.
    Лого на внутряках должно вести на титулку. На титулке logo = h1, на внутряках h1 = заголовок контента, а logo = div
    Иногда на главной есть CEO текст — там-то и используется h1.
    Для h1,h2,h3… Я еще добавляю классы, соответственно .h1,.h2,.h3, чтобы использовать стили заголовков, там где по CEO ненужно.
    №13 Оптимизация скорости загрузки. +Все скрипты перенести с head в конец страницы, для быстрой загрузки страницы.
    • 0
      Я как раз за Conditional Comments. Просто настолько привык к ним, что воспринимаю их как само собой разумеющееся, а в примерах приводил лишь «как не должно быть», спасибо, дополнил. Про html5boilerplate.com в курсе)
  • +1
    Со многим согласен. Некоторые вещи из выше написанного не знал. Конечно присутствует мое дилетантское ощущение — что слишком уж многое надо проверять.
    Огромное спасибо за расшаренный боевой опыт!

    P.S.
    Удивлен что ПМ должен выполнять работу тестера. Но как ни странно — на практике инициатива чек листов обычно исходит именно от ПМ.

  • +3
    воспользуйтесь Safari 3 под win

    — «маковское» сглаживание есть и в новых Safari под Windows.
    Ctrl + «,», закладка Appearance, меняем Font Smoothing из установленного Windows Standart в Medium.

    Как для моих глаз — сглаживание шрифтов точно такое же, как в Mac OS X. Или в Safari 3 какое-то более маковское сглаживание?
    • 0
      ух ты! спасибо огромное!
      отредактировал статью.
      • +1
        Вам спасибо за отличный пост. :)
  • 0
    hCard — не слишком ли упрощает жизнь спамерам?
    Для какихто внутренних вещей, CRM и пр., может и хорошо, но надо ли иметь hCard в каком-нибудь внешнем сайте?
  • +1
    Всё клёво, разве что смущает указание на конкретные инструменты для проверки. Почти везде указаны Fx, PHP, SVN и всё-такое, тогда как лучше было бы или привести по несколько вариантов или ограничиться более общими фразами:
    • «Все бекапы можно вытянуть из SVN» → «Все бекапы можно вытянуть из системы контроля версий»
    • «Ещё должна быть PHP-валидация формы» → «Ещё должна быть деградация на серверную валидацию форм» (хотя я тоже против этого пункта в этом списке :)
    Ну и т.п. Скажем, многие вещи, которые советуется проверять в Fx (вид без картинок, без яваскрипта) гораздо лучше делать, например, в опере — там это делается встроенными в браузер средствами, да и тот же вид без картинок «честнее». Ну а скорость загрузки и много чего ещё отлично проверяется в вебкитовском инспекторе.
    • 0
      спасибо, про php/svn — поправил.

      про FF — старался не плодить сущности, чтоб проверка была проще, согласен что что-то наверно можно лучше проверить другим средством.
  • 0
    Прекрасная статья!
    Еще заказчиков найти бы, готовых все это оплатить, самому было бы очень интересно.
    По некоторым пунктам с вами будут несогласны гуру.
    • +1
      буду рад замечаниям, в споре рождается истинна :)
  • 0
    Просто апплодирую стоя! Очень полезная статья. Именно ради таких топиков, которые позволяют повышать свой уровень, я и хожу на Хабр. Спасибо!
  • 0
    Очень плохо — презентационные классы (right, red).

    Объясните свою позицию. У меня всегда есть заготовки float: left/right; для случаев, когда больше ничего для элемента не нужно. Например для иллюстраций в тексте. Мне кажется, что это достаточно семантично.
    • 0
      ну для иллюстраций в тексте можно
  • +2
    Браво! Спасибо за чек-лист, все сам давно собирался сделать такой :)

    Вот только я не согласен с тем, что в стилях нужно писать теги. В стилях вообще не должно быть тегов, только классы (и иногда id)! (подразумеваются стилизированных элементов, а не глобальные a, p, table и т.д.).

    Т.е. вместо
    body.contacts div#content div#content-text div.entry div.somenamedblock
    пишем
    #content #content-text .entry .somenamedblock

    Аргументация: При программинге не редко приходится менять теги (сеошники тоже, порой, хотят что-то иное), если теги в CSS. Еще где-то было про внутренние требования яндекса к верстке, там тоже об этом говорили, но не могу найти, мб на яндекс.субботниках говорили.

    Ну и вообще, если в проекте придерживаются подхода верстки независимыми блоками, то там немного другой чек-лист будет.
    • 0
      Ах, ну и да, то что уже сказали выше — IE6 надо поддерживать.
      • 0
        ну я ж не запрещаю:)
        хотите — поддерживайте, я лишь поделился своим опытом, мы отказались по дефолту и все счастливы — мы делаем быстрее и быстрее вносим правки, клиент радуется лучшей работе сайта в современных браузерах.
    • 0
      спасибо за замечание, требования к написанию кода (стандарты кодирования) мы ещё не формировали официально, учтём.
    • 0
      У яндекса для атомарных блоков вроде как позволительно использовать теги и соответственно писать стили. В общем случае, конечно, лучше стараться через классы.
      • 0
        В смысле, использовать теги без классов/id и писать стили для них. Вот про простые блоки: clubs.ya.ru/bem/replies.xml?item_no=42
        • 0
          В данном случае теги i, b используются скорее как оформительские вспомогательные элементы (для допололнительных фонов, уголков или еще чего-нибудь). Для них, конечно, нет смысла задавать классы (подразумевается, что класс задается семантически осмысленной единице контента).
    • 0
      Когда код состоит из одних дивов, да спавнов, то перечислять тэги смысла нет, конечно. Но вот менять селектор вида
      #someblock ul li a img
      на
      #someblock .unordered_list .list_item .anchor .image
      , да ещё писать в коде
      <ul class="unordered_list"><li class="list_item"><a class="anchor" ...><img class="image" ...>...
      как-то глупо, по-моему.
      • 0
        Yep. Я говорю о ситуации, когда у вас тег может поменяться. ul/li не могут поменять — это законченный объект на странице. А вот h3 на h4 или даже на strong, p на div иди span — относительно часто могут меняться.
        То есть грубо говоря там где верстальщик уже прописал классы — не нужно в стилях ограничивать их каким-либо элементов.
        • 0
          *не нужно в стилях ограничивать их каким-либо тегом.
        • +1
          А, ну если прописаны, то грех не воспользоваться. Просто как-то видел страничку в портфолио у верстальщика, там фактически свёрстано на дивах с ид/клаасами, то есть в боди одни только дивы, почти ни одного другого тэга. Подпись была «верстаю дивами», но я так и не понял, шутка это была, или он серьезно так верстает.
  • 0
    Статья супер!
    Закос в P.S. под Касту — тоже классно.
  • 0
    >Все ссылки должны как-то реагировать на :hover
    ИМХО, все ссылки ДОЛЖНЫ быть подчёркнуты (если это, конечно, не новостной сайт)
    • 0
      Это не исключает того, что они должны реагировать на :hover, верно?
      • 0
        Ну, лично я бы сказал, что скорее могут и не всегда должны. :)
        • 0
          (когда подчёркнуты)
        • 0
          Я согласен про подчёркнутость, но одно другому не помеха.
          Лично я бы сказал, что реакция на :hover — это именно то действие, которое я жду от ссылки, в противном случае мне очень… некомфортно что-ли. :)
    • +2
      Подчёркивание очень часто некрасиво вписывается в меню и прочие навигации, которые обычно и так выделены отлично от всего остального сайта. Но вот реально бесит, когда подчёркивают то, что ссылкой не является :)
  • 0
    Представьте верстку под Андроид с разными dpi, под iPhone учетом ориентации окна(горзонтально или вертикально) а потом советуйте этот дурацкий PixelPerfect. За последние, примерно, 7 месяцев работы уже забыл что это такое расположение блоков 1:1. Прибъете размеры шрифтов в пикселях, и соотвественно отступы и посмотрите на разных андроид устройствах и iPhone/iPod/iPad — в целом статья классная, все гуд, но вот на счет пиксель перфект, и вообще прибивания чего-то гвоздями в верстке… я бы несоветовал.
    • 0
      конечно, при смене ориентации соответствия 1:1 макету уже не получится.
      но это ведь не значит что вообще не стоит сравнивать вёрстку с макетом? разве есть проблема расположить блоки как на макете? чтоб у них были такие же размеры, отступы.

      ясное дело что при изменениях контента, размеры блоков могут меняться (по высоте например), но это нормально, адекватный ПМ не должен затягивать сдачу проекта, тратя время (а значит и деньги фирмы) на вылизывание каждого пикселя.
      • +1
        Считаю что да. Я часто для своих проектов, делая верстку сталкивался с такой проблемой что на 1280-800 все классно а на 1024-768 не так уже смотретиться. И я искренне рекомендую всем клиентам(своим) что бы они прислушались и использовали относительные размеры и т.д. потому как важна то информация, если по части дизайна, и качество кода, если по части верстки. Но это имхо, и то часто приходиться прибивать гвоздями :) правда потом не редко клиенты просят переделать…

        Ну а поповоду вылизывания каждого пикселя, я как то думал что именно для этого всем так нужен пиксельперфект :)
        • 0
          спасибо что обратили внимание на эту двусмысленность, дополнить статью пояснением.
    • 0
      Что, так часто требуют верстать под мобильники?
      • 0
        более того — зачастую заказывают только мобильную версию. Ситуация когда обычный сайт у клиента давно есть, а теперь он хочет чтоб вёрстка и на айфончике красиво открывалось.
        В таких случаях конечно делается отдельная вёрстка, т.к. пытаться только стилями, не меняя порезки сделать мобильную версию из старого чужого говнокода нерационально.
      • 0
        Да… довольно. На аутсорсе цена верстки под дестопы от 9$ до 15$ в час под мобильники от 30$ в час но со знанием дела… Да и потом, посмотрите на мир реально, планшеты, Андроидфоны, Айфоны… вы думаете это не придет и к нам?
        • 0
          Хех, тут за сервер-сайд бы 10$ получать ))

          Не знаю, на мои сайты заходят с мобильников мизер, может ЦА не та. Аппараты-то уже пришли в принципе, но вот, по-моему, опсосы наши ещё долго будут держать мобильный интернет в чёрном теле.
  • +1
    Статья -однозначано избранное. Must have для любого верстальщика.
  • 0
    # Ещё хуже – чересчур детализированные глобальные стили. Например a {font: italic 10px Tahoma;} /* Ненависть! Ненависть! НЕНАВИСТЬ!!11 */ Потом приходится переопределять стиль ссылок для каждого блока.

    А если глобально не указать, разве не будете для каждого блока писать стили ссылок? Или пусть будут синенькие?
    • 0
      для ссылок глобально укажите цвет и всё.
      параметры шрифта они наследуют от родителя и ссылка не будет выглядеть в тексте инородно.

      А где необходимо (в меню; внутри какого-то блока например сайдбара) — уточните стиль, задайте особые параметры если необходимо.
      • 0
        Ну, я цвет и имел в виду. В общем, ненаследуемые свойства.
        • 0
          Плюс ещё классы есть
    • 0
      Собственно мне проще делать 2-мя путями, либо для всего body задать body {font: 90%/170% Aller, Arial, Verdana;} либо сделать спец класс .planetext {font: 90%/170% Aller, Arial, Verdana;} Потому что стандартный Arial не всегда и не для всех рулит, особенно сегодня, в мире просто дурдом с @font-face :)
  • +1
    Спасибо!!! Полезнейшая вещь!
    еще деталь — правила адресации ресурсов — картинок, цсс, js
    приятно видеть в статье сеошные тремины!)
    • 0
      вы имеете в виду что картинки должны быть в отдельной папке, css — в отдельной и js — в отдельной?
      разумеетя так и должно быть, неужели кто-то ещё делает иначе?
      спасибо, дополнил статью.
      • 0
        И еще как писать, точнее, с чего начинать, урлы в файлах макета:
        ../images/
        /images/
        images/
        .../images/

        в html, css, js файлах — везде могут накосячить (просто сделать по разному)…
        • 0
          /images/
  • 0
    Не скажу что это супер-эталон, но много полезного есть. Хотя и есть то с чем можно поспорить.
    • 0
      буду рад замечаниям, они делают статью лучше и повышают собственные скилы.
      • 0
        Сомневаюсь, конечно, как-то измените свой чек-лист из-за одного хабра юзера. Максимум можем развести холивар. Всё же.

        №0 Соответствие макету
        Расположение блоков должно быть 1:1 по сравнению с макетом

        Немного не согласен. Есть такие макеты, которые подразумевают по собой некую хаотичность. Как вот проверять на соответствие резиновый сайт? Ту уже на усмотрение верстальщика, и несомненно в действие вступает пункт 14.

        №1. Кроссбраузерность
        Если используются последние версии нормальных браузеров, то почему уведомление о неподдержке будет появляться только у IE6. Почему бы сразу не в IE7? Ведь глюки у IE6 и IE7 очень схожи.

        Потом у вас не сказано про цвет. Имхо, лучше номер цвета писать $ffffff, вместо $fff.

        Ещё иногда бывают проблемы с загрузкой фона у элементов. Пожалуй, это единственный случай где желательно описывать отдельным стилем такие параметры как background-color, background-image, background-position и background-repeat вместо одного background.

        Про :focus вот верно сказали, кстати.
        • 0
          для резиновых сайтов тоже ведь рисуют макеты. проверять на соответствие нужно под разрешение макета.

          Доля IE7 пока ещё не так мала, чтоб совсем с ней не считаться. А поддержка стандартов в 7-ке гораздо получше.

          Чем запись вида #ffffff лучше сокращенной #fff?

          В чём смысл прописывать стили background отдельно? background-color сработает вне зависимости от того прописан он отдельным свойством или внутри background.
          • 0
            Видимо не правильно выразился. Имелось ввиду не именно #fff (белый) или #000(чёрный), а любой другой цвет.

            Почему отдельно? Не помню точно на каком именно браузере, но был пару раз глюк то ли с позиционированием фона, то ли с повторением. Но он решился разделением этих параметров. С тех пор как бы всегда прописываю отдельно.
  • +1
    >Все ссылки должны как-то реагировать на :hover

    многие забывают также прописать :active и :focus — для клавиатуры и тач-скринов (которые не генерируют событие hover, в результате вид ссылки не меняется)

    еще на ссылках меню (если оно «красивое») можно задавать :focus { outline: 0; }, чтобы пунктирная обводка фокуса его не уродовала
    на обычных ссылках это не желательно — юзабилити и аксессибилити портятся :)
    • 0
      кстати, да, спасибо, дополнил! мы прописываем такие штуки, но в правила не внесли, теперь есть.
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    IE 6 — это до сих пор ~10%, а JavaScript отключен у 1%, так что решайте, что поддерживать, а что — нет
    • 0
      меньше 5% вообще-то.
  • 0
    кстати, css-ресет — это плохо, в битриксе, например, админка херится (только давайте без холиваров про битрикс)
    • 0
      А что тут холиварить… не хочешь ресет делать не делай.
    • 0
      Забыл основную мысль сказать: нельзя говорить что ресет это плохо только из-за одного Битрикса. ИМХО!
    • 0
      вообще-то у админки обычно свой отдельный css, не связанный с продакшеном.
      нет возможности — ну и не делайте там ccs reset.
    • +1
      CSS-ресет — это всегда хорошо для верстальщика. Гораздо ближе к стандартам все браузеров. Интересно сколько времени займёт у верстальщика кроссбраузерная вёрстка без него?
      • +1
        +1

        Я раньше непонимал смысла css-reset — зачем «все базовые стили мы сотрёт до основанья, а затем...», зачем? Считал что надо просто сразу прописать все стили для всех элементов.

        Писал, дополнял, смотрю, много получается, начал оптимизировать, выносить повторяющиеся стили в отдельные правила… И шо вы таки думаете? Смотрю — css-reset получается :)
        • 0
          Эволюция.
    • 0
      согласен, с оговоркой, цсс ресет — плохо, если не восстановили ожидаемое поведение элементов со сброшенными стилями (например отсутствие отступов ломет li ol/ul)
      • 0
        конечно после reset'a нужно выставлять базовые стили для всех элементов. reset — лишь оптимизация сброса умолчаний, чтоб меньше кода писать при прописывании дефолтов.
  • 0
    Статья хорошая только в одном не соглашусь.

    body.contacts div#content div#content-text h1
    body.contacts div#content div#content-text div.entry
    body.contacts div#content div#content-text div.entry div.somenamedblock

    За такое просто нужно бить по рукам, потому что вложенность селекторов не должна быть больше 2-3х уровней и лучше всего вообще не использовать теги и привязываться только к классам. Иначе это сильно уменьшает производительность обработки css. Исследование на эту тему делал Виталий Харисов.
    • 0
      Спасибо, убрал теги из примера.

      Но для обычных сайтов эти доли секунды абсолютно не критичны, а читабельность кода повышается. Вы же не будете БЭМ на небольших и средних сайтах использовать? :)

      У highload свои законы, там и семантика будет лишним тормозом.
      • 0
        Если использовать эту систему с умом и доработать под свои нужды то она сильно упростит жизни при верстке даже не очень больших сайтов из 3-4 макетов. Ну а на 20-30 это просто спасение.

        Если где то по макетам используется элемент идентичный по смыслу и немного изменяющийся или вообще не меняющийся внешне, я могу его вставить в любое место страницы на любом макете и буду уверен что он не подхватит еще какие то стили прописанные глобально. И в таких случаях верстка превращается в собирание конструктора:)

        >>Но для обычных сайтов эти доли секунды абсолютно не критичны
        Почему не стремиться сделать свою работу на все 100%?
        Тем более что кроме скорости рендеринга вы получаете довольно мощную систему которая просто упрощает жизнь и ускоряет разработку. А слова про читаемость вообще спорны
        вот пример с реального проекта:

        .list_terms{}
        .l_t_item{}
        .l_t_item:first-child{}
        .l_t_hline{}
        .l_t_text{}

        Мне кажется читабельность у данного кода лучше, но конечно это мое субъективное мнение.
        • +1
          Был неправ, покаялся: delka.name/blog/2013/04/bem-otkroveniya-prinyavshih-veru/
          • 0
            Приятно признавать что ошибался в прошлом. Это самая наглядная иллюстрация «роста» как специалиста и личности.
  • 0
    Добавил пояснения какие ошибки валидации допустимы
  • 0
    • добавил про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.
    • добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea.
  • 0
    Отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями.
  • +2
    • Добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS),
    • необходимости вписывания в экран моб. устройства,
    • заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css,
    • поправил пример где в рекомендации встречался длинный каскад,
    • упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
  • 0
    Давольно структурировання информация тема очень широкая и интересная. Как начинающий я много узнал и теперь начинаю понимать в какую сторону надо двигаться.
  • 0
    Добавлено требование использования препроцессоров и рекомендация использования систем сборки.
    • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        Я имею в виду саму идею использования мета-языков над CSS.
        Не уверен стоит ли делать сноску вида «а вообще вы можете генерить css не только с помощью sass». Чеклист ориентирован на устоявшиеся практики (во многом он систематизировал их и помог им стать стандартом де-факто), практики, которые можно рекомендовать всем и в первую очередь — менеджеру/клиенту, который проверяет работу или выставляет это чеклист как гайдлайн. Код на sass будет легко развивать и поддерживать.

        То что существуют постпроцессоры и их рекомендовано использовать — в чеклисте есть.
  • 0
    На GitHub подробней раскрыт пункт №12 «плохо»/«хорошо»
    Пункт №12 — актуализирован:
    — про хаки в css и как писать код для разных браузеров
    — что пустые блоки не запрещены, а нежелательны и их можно заменить на псевдоэлементы
    — добавлено пояснение, что нужно просто юзать Normalize для того, чтоб были базовые стили элементов (а не голые стили от CSS Reset)
    — объяснил что «последовательное уточнение стилей» — это для текста и не касается стилей для блоков (там используем БЭМ)
    — уточнил что не просто плохо, а нельзя вешать стили на селекторы вложенных элементов, без классов. И что именно вложенных элементов, а не одиночных, а для одиночных нужно юзать блок .b-text
    — переформулировано без описания технологий пожелание о разбиении верстки на шаблоны
    — добавлена рекомендация складывать иллюстрации в отдельную папку.
  • 0
    Актуализировал список исключений для CSSLint
  • 0
    Актуализировал рекомендации по оптимизации скорости загрузки.
    • 0
      Добавил требование поддержки Retina.
      Дополнил «18. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.