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

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

887

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

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

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

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

Итак что же это за перечень?

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

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

2013/04/25: добавлены анализаторами свойства кода: CSSLint и JSHint, указан веб-сайт подбора css font stack (спасибо @fliptheweb), маленькие уточнения (работу интерактивных частей странички, что не теряется фон на больших разрешениях, не обязано быть пустых презентационных блоков, при проверках контента — пробовать удалять заглавия, поменять местами блоки)
устройства, заменил ссылку на проверочный текст отображения обычного html на код с normalize.css, поправил пример где в советы встречался длиннющий каскад, упомянул про Opera на Presto и новейший уровень семантики — в именах классов BEM. 2013/04/24: добавил пункт о минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб.
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. Соответствие макету
Кроссбраузерность, шифровка и DOCTYPE
Валидность, доступность, микроформаты
Независимость блоков в CSS: минимизация каскада, внедрение техник БЭМ/MCSS/SMACSS
Веб-сайт должен нормально смотреться во всех обычных разрешениях от 1024 и выше, не иметь горизонтального скролла и вписываться в экран мобильных устройств
Корректная работа при вбивании настоящего текста, надёжность вёрстки
Проверка и оптимизация скорости загрузки
Наличие Win/Mac/Linux-аналогов шрифтов
Доступность при выключенных(загружающихся) картинах
HTML5 формы, линковка, валидация
Отсутствие глупостей в html и css, единообразие, аккуратность Семантичность.
и TITLE) Верная структура заголовков (H1,H2,… и т.д.
Работоспособность при выключенном JavaScript
Работоспособность при выключенном Flash
Отсутствие багов при увеличенном шрифте
И крайний пункт – маленькие проверки (ниже подробней)

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

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

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

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

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

Проверка: открываем начальный код странички, 1-ая строчка должны быть <!DOCTYPE HTML>.
Кроссбраузерность:

Firefox (крайний)
Chrome (крайний)
Safari (крайний) и раз у вас нет Mac чтобы проверить «размытые Mac’овские» шрифты (они чуток большего размера, из-за этого бывает вылазят баги) то установите в Preferences→Appearance, «Font Smoothing» в Medium (по дефолту там «Windows Standart»).
Здесь принципиально чтобы верстальщик не запамятовал указать верный viewport. вертикально и горизонтально) + Android. iPhone (смотрим в landscape и portrait режимах, т.е.
Opera (крайняя) Имеет смысл также поглядеть на 12-версии с движком Presto, раз там есть баги в отображении — это признак возможных заморочек в качестве кода
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 Валидность, доступность, микроформаты

Не обязано быть js-ошибок!
Ошибки на внутряках простительны в последующих вариантах: Титулка обязана быть валидна в любом случае.

Упоротая секретарша копипастит тексты из Word’а в визиг;
Программисту ну чрезвычайно необходимы какие-то кастомные атрибуты (хотя для этого в HTML5 ввели особые пользовательские атрибуты «data-*»).

CSS валидируется по версии 3.0, его валидность не требуется (да и валидатор ещё кривоват), а вот синтаксические ошибки (типа margin: 10xp) исправлять нужно.
Микроформаты должны быть. Лучше также hCalendar, XFN, hAtom. Как минимум – hCard.
Проверка статическими анализаторами свойства кода: CSSLint и JSHint

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

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

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

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

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

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

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
По-умолчанию валидатор 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%)
и т.п.

Валидатор считает ошибкой указание вендорных префиксов
Потому допустимы ошибки такового рода:
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
и т.п.

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

Опции CSSLint:
Выключить функции:
— Beware of broken box sizing
— Disallow adjoining classes
— Disallow empty rules

Опции JSHint:
Выключить:
— When code is not in strict mode

Включить:
+ jQuery

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

№4 Веб-сайт должен нормально смотреться во всех обычных разрешениях от 1024 и выше, не иметь горизонтального скролла и вписываться в экран мобильных устройств
Проверяется в FF через плагин Web Developer→Resize
Перечень классических разрешений:

1024×600
1024×768
1152×864
1280×800
1280×1024
1440×900
1680×1050
1920×1080

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

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

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

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

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

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

для маленьких картинок связанных логически должны употребляться CSS-спрайты (к примеру набор буллетов либо варианты отображения пт меню: дефолтный, активный)
Base64-encode для маленьких отдельный картинок;
CSS3 border-radius, gradient, box-shadow, text-shadow заместо использования графики;
Оптимизация PNG и JPG файлов;
JS очень должен быть вынесен во наружные файлы, наружные js-файлы уместно объединены для уменьшения кол-ва запросов. JS-библиотеки, к примеру jQuery необходимо грузить с Google CDN. Постарайтесь включить отложенную загрузку для большинства JS.

© sunnybear. Для чего это необходимо: скорость загрузки оказывает ключевое влияние на доступность веб-сайта (больше психическую, чем фактическую), активность юзеров на веб-сайте (медленными веб-сайтами люди предпочитают не воспользоваться) и его конверсию (медленным веб-сайтам не доверяют).
В целом скорость загрузки проверяется так:

по панели Net в Firebug
Нужно инспектировать, как отображается страничка при загрузке на малых скоростях (хотя бы 64 КБ). Чрезвычайно нередко в такие моменты юзер лицезреет разъехавшуюся верстку.
Сервисами PageSpeed Insights и WebPageTest, основанными на Google PageSpeed Service
Page speed и YSlow аддонам в Firebug (учитывайте что значимая часть советов: включение сжатия, установка определённых headers, minifying кода – относится к серверным работам, а не вёрстке)

Наличие css-спрайтов проверяется поиском по коду блоков объявлений вида:
… {background-position: 0 -30px}
… {background-position: 0 -60px}
… {background-position: 0 -90px} (числа могут быть любые)
Наличие base64-encode проверяется поиском по коду блоков объявлений вида url(data:image/png;base64,iVBOR… )
Border-radius, gradient, box-shadow, text-shadow проверяются поиском этих слов в css 🙂
Самый обычный метод проверить оптимизацию png/jpg – запустить готовые скрипты оптимизации графики для картинок вашей вёрстки и сопоставить итог с начальными файлами – раз размер практически не поменяться – означает всё ок. Не так давно (март 2012) Yandex выпустил собственный инструмент для этих целей — imgo, но он под Linux либо Mac.
Раз js не объединены в один файл, то Page Speed произнесет для вас о этом: “Combine external JavaScript”.

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

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

№7 Наличие Win/Mac/Linux-аналогов шрифтов
Это может быть не лишь некрасиво, но и даже поломать отображение веб-сайта. Раз другие шрифты не прописаны, то у юзеров у которых отсутствует используемый в вёрстке шрифт, заместо него отобразится обычный.
Нередко запамятывают прописывать кандидатуры для Myriad Pro, Arial Narrow.

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

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

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

Complete Guide to Pre-Installed Fonts in Linux, Mac, and Windows
CSS font matching: Windows, Mac and Linux
Codestyle: Combined font survey results
Common fonts to all versions of Windows & Mac equivalents

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

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

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

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

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

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

Принципиально осознавать что семантика — может быть не лишь в используемых элементах, но и в именах классов. И BEM-иерархия классов — это новейший уровень семантики.

Как ориентир – более нередкие ошибки:

Самое ужасное, к счастью уже редкое — float: left для всех блоков. Проверяется: Web Developer Outline → Float elements, раз всё в бардовых блоках, вёрстку необходимо выкидывать на помойку. Вон из профеcсии! Сумасшедший верстальщик эмулирует обычные ячейки таблиц, расставляя блоки как кирпичи друг за другом.
Отступы меж блоками на веб-сайте должны быть за счёт margin у блоков, а не выпирающих наружу margin у содержимого блоков.
Плохо — отсутствие тайтлов.
Плохо — отсутствие тайтлов.
Плохо — отсутствие alt у картинок.
Плохо — стили для IE снутри main.css без фильтров. будет применяться ко всем IE, а не лишь к тому, в котором неувязка. Т.е. плохо, т.к. когда просто пишем {zoom: 1;} — это оч. Необходимо фильтровать: HTML5 Boilerplate-стили (html.ie7, html.ie8,…), применять Conditional Comments, ну либо на худой конец (* html, *+html и т.д.).
Плохо – не инспектировать tabindex в формах.
К примеру, раз элемент постоянно находится сверху, у него должен быть большой z-index, нельзя надеятся на то что на данный момент всё нормально смотрится – стили должны быть железобетонными. Плохо — писать стили не думая о логике размещения частей. Раз элемент постоянно должен находится на каком-то месте, в независимости от окружающих его частей — это position: absolute; а не float и т.д.
Блоки независимые друг от друга не должны быть снутри 1-го блока (к примеру телефон компании и поиск по веб-сайту). Блоки независимые по расположению друг от друга должны быть position absolute, а не float’ится.
Чрезвычайно плохо — презентационные классы (right, red).
Также вёрстка не обязана содержать пустых блоков (для презентационных целей)
Т.е. Плохо когда нет базисных стилей у обычных частей. просто h1,h2,ul,table,etc без классов должны смотреться прекрасно и органично.
Нужно вести стили снизу ввысь, равномерно уточняя их. Плохо когда нет постепенного уточнения стилей, а стиль выписывается для каждого элемента раздельно, а за его пределами — наружный вид может быть кардинально иной. Речь о ситуации когда к примеру текст, написанный без абзацев, имеет вообщем не тот стиль что у всех частей в блоке.
НЕНАВИСТЬ!!11 */ Позже приходится переопределять стиль ссылок для каждого блока. Ещё ужаснее – чересчур детализированные глобальные стили. К примеру a {font: italic 10px Tahoma;} /* Ненависть! Ненависть!
Line-height — как правило коэффициентом (1/1.2/1.4… т.е. У текстовых частей (абзацей, ячеек таблиц) задаём padding и height в em (чтобы корректно наращивать размер шрифта) . Размеры и размещение элемента должны указываться в одних единицах измерения. Классический пример: перечень dl-dt-dd, где dt и dd ставятся друг на против друга с помощью подтягивания dd отрицательным margin ввысь. задали font-size/height в em — означает задаём и margin/padding тоже в em. без указания единицы измерения — это цифра на которую множится font-size и получится межстрочный интервал). Либо — выделили padding’ом место под position: absolute какого-то текстового блока. Для текстовых блоков это в 90% случаев — em. Т.е.
Т.е. Все стили частей снутри #content непременно должны навешиваться на элементы с классом. допустим пишем что-то типа h2 a span {какая-то крепкая штука, типа рисунки с графикой, что закрывает текст}, а позже клиент в визиге в один момент вбивает такое сочетание! Плохо вешать стили на обычные тэги, без классов. И получаем неописуемый баг.
Плохо — впрямую задавать зрительное отображение частей через js: $(“elementid”).css(styleName,"something"). Это обязано делаться через установку/смену классов.

Примеры неплохого:

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

То .somenamedblock должен получать текстовые стили конкретно — .somenamedblock {font: …; color: …;}, т.к. по другому в визиге админки мы не сможем их застайлить.
однообразный html-код для блоков на морде и внутряках, с схожим контентом, но различным зрительным представлением данных.

и TITLE) №11 Верная структура заголовков (H1,H2,… и т.д.
Это забота о семантичности кода, заглавия структурируют веб-сайт, делают его корректным документом. Корректный Document Outline важен для SEO.

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

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

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

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

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

№13 Работоспособность при выключенном Flash
В эталоне весь критически принципиальный функционал веб-сайта был доступен без Flash. В настоящей жизни необходимо:

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

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

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

№14 Отсутствие багов при увеличенном шрифте
Проверяется в FF:

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

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

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

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

№16 Принципиальные мелочи:

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

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

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

Чек-лист вёрстки. Что можно отдавать клиенту, а что нужно переделывать from pepelsbey on Vimeo. habrahabr.ru