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

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

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

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

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

История обновлений:

• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

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

---

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

    0. Соответствие макету

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

---

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

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

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

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

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

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 (последняя)
   • IE7+ (для IE6 выводится уведомление о неподдержке и предложении скачать другой браузер или установить Google Frame, но с возможностью всё-таки просмотреть сайт)
   • Opera Mini (проверяется в Opera Developer Tools→Opera 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).

№2 Валидность, доступность, микроформаты

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

Ошибки js проверяются просмотром сайта в IE – в левом нижнем углу не должно быть значка «есть js-ошибки».

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

© rossomachin

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

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

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

• HTML: validator.w3.org/ (или  Web Developer →Инструменты →Проверить HTML)
• CSS: jigsaw.w3.org/css-validator/ (или  Web Developer →Инструменты →Проверить CSS)
• Наличие микроформатов проверяется плагинами  Operator и  Tails Export.
  Валидаторы микроформатов:
  
  • microformatique.com/optimus/
  • www.google.com/webmasters/tools/richsnippets
  • webmaster.yandex.ru/microtest.xml
  • hcard.geekhood.net/

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

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

• Check a Site: scan web sites for over 450 quality problems
• Total Validator: (X)HTML validator, an accessibility validator, a spell checker, and a broken links checker
• Validación de accesibilidad de acuerdo a las WCAG 2.0 con PISTA

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

• www.w3.org/TR/WCAG20/#guidelines
• и детальнее: www.w3.org/WAI/WCAG20/quickref/

Некоторые ошибки в валидации допустимы.

• HTML

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

• 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
     и т.п.

     
     

№3 Сайт должен нормально смотреться во всех стандартных разрешениях от 1024 и выше и не иметь горизонтального скролла

Проверяется в FF через плагин  Web Developer→Resize
Список классических разрешений:

• 1024x600
• 1024x768
• 1152x864
• 1280x800
• 1280x1024
• 1440x900
• 1680x1050
• 1920x1080

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

Вёрстка должна тянутся, не разваливаться и не терять дизайнерский вид при изменении контента на странице. Его может быть больше или меньше чем на макете, он может быть обёрнут во всякие <p> из визига и т.п.

1. Проверка ввода и удаления данных.
   Проверяется: на странице с контентом, пробуем добавлять и удалять содержимое – «что будет когда текста много?», «а когда мало?».
2. Проверка корректности работы стилей.
   Проверяется: на страницы с контентом вбиваем текст с абзацами и без абзацев (важно! бывает горе-верстальщики прописывают стили только для абзацев), со списками и картинками, таблицами и заголовками разных уровней.

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

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

http://habrahabr.ru/post/114256/