Чеклист верстки

Источник: https://github.com/glivera-team

Основные требования

• Соответствие макету(особенное внимание обращается на выравнивание блоков относительно друг друга).
• Кроссбраузерность (ie10+, последние версии Chrome, Mozilla, Opera).
• Не должно быть JavaScript-ошибок.
• Кодировка: UTF-8.
• DOCTYPE: HTML5
• CSS и JavaScript в отдельных файлах.
• Все поля, содержимое которых приходит из CMS проверены на работу с разным вариантом контента: короткий, длинный, длинный без переноса.
• Сайт должен нормально смотреться во всех стандартных разрешениях от 1024 и выше, не иметь горизонтального скролла и вписываться в экран мобильных устройств.
• Корректная работа при вбивании реального текста, надёжность вёрстки.
• Отсутствует транслит в названиях классов, атрибутах, переменных препроцессора, названиях примесей и т.п.

Разметка HTML

• Документ проходит проверку на валидность http://validator.w3.org/
• Обязательное наличие label для input. Поля label и input/select в форме слинкованы.
• Каждый элемент на странице имеет класс(исключение составляет контент, приходящий из CMS).
• Таблицы используются только для создания таблиц.
• <img> отображает исключительно смысловую картинку, все элементы дизайна должны задаваться как background соответствующего элемента
• Применение тегов <footer>, <header>, <nav>, <artice>, <aside>, <main> для соответствующих блоков.
• Заглавие страницы должно быть внутри тега <h1>. ​На странице может  присутствовать только один тег <h1>. Если у страницы нет явного заголовка(например на главной) в качестве <h1> используется блок с логотипом.
• Для изображений с заголовком обязательно используются <figure>,<figcaption>.
• Внутри тега <section> первым элементом должен быть заголовок(h2,h3,h4,h5,h6).
• Для данных вида параметр-значение обязательно использовать <dl> <dt> <dd>.
• Для всех типов перечислений однотипных элементов обязательно  использовать <ul> <li>.
• Правильная логика следования заголовков по коду h1 ­> h2 ­> h3 ­> h4. Неправильно h1 ­> h3 ­> h2 ­> h4 (требование может нарушаться, если  по-­другому расположить блоки невозможно)
• Активно использовать :after :before атрибуты вместо написания служебных пустых блоков.
• Использование style внутри тегов разрешено только в случае динамических значений(Например - изменение позиционирования через javaScript).
• Сначала на странице должен идти основной контент, после него дополнительный(например aside).

Стилизация

• Стили сайта соответствуют стандарту CSS3, за исключением хаков и вендорных свойств.
• CSS3 border-radius, gradient, box-shadow, text-shadow вместо использования графики.
• Обязательно использование препроцессора sass в форме scss.
• Независимость блоков в CSS: минимизация каскада, использование техник БЭМ.
• Сайт должен корректно отображаться при любом разрешении экрана вне зависимости от устройства.
• Footer всегда прижат к низу экрана.
• Для свойств margin и padding всегда использовать короткую запись.
• Обозначение цвета либо в hex (#000), либо в rgba если есть прозрачность, никаких ключевых слов.
• Всегда задавать значения для позиционирования бэкграунда(background-position), и задавать их без ключевых слов.
• При верстке не использовать id, только классы.
• Использовать сброс стилей по Э. Мейеру (reset).
• Изображение(img) всегда должно иметь элемент обертку, с указанием для этой обертки размеров и overflow:hidden;
• Раскладка блоков на странице сделана с помощью flexbox(без float,inline-block).
• В CSS отсутствует !important. Допускается использование !important при обосновании его необходимости в комментарии.

Именование классов

• Только маленькие буквы
• Если класс из нескольких слов – между словами подчеркивание: slider_block, bread_crumbs и т.п.
• Если нужно добавить обработчик js к какому-то элементу ему дается дополнительный класс в стиле camelCase.
• Не использовать презентационные классы(fz-15,color-green,block-left).
• Подробнее

Доступность

• Выделяется текст в текстовых блоках; кликаются кликабельные элементы (ссылки/кнопки).
• Устанавливается ли фокус в поля форм.
• Кликабельные элементы должны иметь указатель "курсор", перетаскивающиеся - "лапка" или "ресайз", активные/недоступные - курсор default.
• Все активные элементы должны реагировать на наведение, не доступные/неактивные - не должны.
• Клик по label должен переводить фокус в связанное поле;
• Использованы input type="email,tel,password" для соответствующих полей.

Оптимизация

• Растровая графика сжата
• Для иконок используется иконочный шрифт, либо svg-спрайт. При невозможности получить иконки в векторном формате используетcя data-uri.
• CSS- файлы минифицированны и сконкатенированны, подключены в теге <head>.
• JavaScript-файлы минифицированны и сконкатенированны, подлючены перед закрытием тега <body>.
• Удалены лишние стили, неиспользуемые в проекте(например, с помощью gulp).

Шрифты

• Подключённые шрифты, их размеры и жирность соответствуют размерам в макетах и ТЗ.
• Указаны альтернативные варианты шрифта и тип семейства в конце перечисления font-family.
• Шрифты подключаются асинхронно.

Как придумать название для класса

Здесь приведены идеи для именования классов типовых элементов верстки.

Раскладка

wrap(от слова wrapper) - обертка, может быть у секции, картинки и т.д. Как правило добавляется к смысловому названию. Пример:

section - секция, может быть как самостоятельным названием класса(с модификатором), так и дополнением. Пример:

block - конкретный блок, дополнение к смысловому классу. Пример:

in(от слова inner) - внутреннее содержимое. Иногда нужно, чтобы обернуть внутренности блока/секции для стилизации. Пример:

header,footer - шапка и подвал страницы/блока. В случае со страницей можно использовать как самостоятельный класс, а у блока как дополнение. Пример:

nav(от слова navigation) - навигация. Чаще всего является дополнением. Пример:

Перечень элементов

list - список.

item - элемент списка. Пример меню:

Картинки

i(от слова image) - довольно короткое название, но удобное. Добавляется к смысловому названию. Пример использования:

Комбинация с оберткой - очень частый случай:

Текст

title - заголовок, чаще всего является дополнением.

link- ссылка. Пример:

text - текст. Удобно давать такой класс блоку с текстом, который содержит в себе контент.

Разное

desc(от слова description) - описание чего-либо.

def(от слова definition) - определение чего-либо(часто используется в списках dl-dt-dd).

user - пользователь.

author - автор(статьи например).

btn(от слова button) - кнопка.

meta - главная информация о чем-либо.

Пример:

trigger - переключатель(например меню).

logo - логотип.

aside ,sidebar - боковая колонка.

cell - ячейка чего-либо.

Не очевидные, но вынужденные сокращения в нашей команде, принятые за стандарт

form_cell - ячейка формы.

form_c_hline - название ячейки формы.

f_c_field(form_cell_field) - поле ячейки формы.

form_c_f_w(form_cell_field_wrapper) - обертка поля ячейки формы.

lbl_rb_ch_block(label_radiobutton_checkbox_block) - блок лейбла радиокнопок и чекбоксов.

lbl_inp_rb_ch - чекбокс или радиокнопка.

lbl_rb_ch_text - текст чекбокса или радиокнопки.

Еще одни чеклист

Источник: https://github.com/ihorzenich/html5checklist/

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

Подробности по каждому пункту: http://habrahabr.ru/post/114256/

1. Соответствие макету
2. Кроссбраузерность, кодировка и DOCTYPE
3. Валидность (включая CSSLint и JSHint), доступность (ARIA, WCAG), микроформаты (microformats 1 & 2, microdata)
4. Независимость блоков в CSS: минимизация каскада, использование техник БЭМ
5. Сайт должен нормально смотреться во всех стандартных разрешениях от 320 и выше, не иметь горизонтального скролла и вписываться в экран мобильных устройств
6. Корректная работа при вбивании реального текста, надёжность вёрстки
7. CSS должен быть написан с использованием препроцессоров (LESS/Sass/Stylus). Желательно использование систем сборки (Grunt/Gulp) и построцессоров (PostCSS/Autoprefixer).
8. Проверка и оптимизация скорости загрузки: https://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. Отсутствие багов при увеличенном шрифте

13. Подробнее: "плохо"/"хорошо"

Важно понимать что семантика — может быть не только в используемых элементах, но и в именах классов. И БЭМ-иерархия классов — это новый уровень семантики.

Плохо:

• Самое страшное, к счастью уже редкое — float: left для всех блоков. Безумный верстальщик эмулирует привычные ячейки таблиц, расставляя блоки как кирпичи друг за другом. Вон из профеcсии!
  Проверяется в extension для браузеров Web Developer → Outline → Outline Floated Elements, если всё в красных блоках, вёрстку нужно выкидывать на помойку.
  Так же, такая верстка получается при создании сайтов на Adobe Muse.
  Пимеры
  один - два - три
• Отступы между блоками на сайте должны быть за счёт 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-плагины, не изобретайте велосипедов, а если изобретаете — поддерживайте их, ведите библиотеку кода (после каждого нового проекта добавляйте туда код, обновляйте старый).
• Для текстовых блоков, что редактируются в админке, должна обеспечиваться атомарность текстовых стилей. Т.е. есть у нас страничка с каким-то текстовым блоком, примерно такой структуры: css .content-text h1 .content-text .entry .content-text .entry .somenamedblock То .somenamedblock должен получать текстовые стили непосредственно — .somenamedblock {font: …; color: …;}, т.к. иначе в визиге админки мы не сможем их застайлить.
• одинаковый html-код для блоков на морде и внутряках, с идентичным контентом, но разным визуальным представлением данных. Реализуется через модификаторы блоков и элементов, но не через модификацию от родителя (каскад от body.pagename например!)

18. Важные мелочи

• Лого на внутряках должно вести на титулку. На титулке 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;)

Видео доклада https://www.youtube.com/watch?v=0dWcdpr3fxM

И еще один чеклист (устарел)

Источник: http://jetstyle.github.io/html-guidelines/checklist.html

Задачи по html/css