HTML/CSS markup checklist
Switch branches/tags
Nothing to show
Clone or download
Latest commit 74de624 Dec 5, 2017
Permalink
Failed to load latest commit information.
README.md Fix formatting Dec 5, 2017

README.md

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

Для того чтобы отдавать вёрстку клиенту, достаточно соблюдения первых 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 например!)

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

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