├── README.md
└── example.css
/README.md:
--------------------------------------------------------------------------------
1 | # Чеклист верстки
2 |
3 | Для того чтобы отдавать вёрстку клиенту, достаточно соблюдения первых 5 пунктов.
4 | Для выдачи в продакшен — первых 6.
5 |
6 | *Подробности по каждому пункту: http://habrahabr.ru/post/114256/*
7 |
8 | 1. **Соответствие макету**
9 | 2. **Кроссбраузерность, кодировка и DOCTYPE**
10 | 3. **Валидность (включая CSSLint и JSHint), доступность (ARIA, WCAG), микроформаты (microformats 1 & 2, microdata)**
11 | 4. **Независимость блоков в CSS: минимизация каскада, использование техник БЭМ**
12 | 5. **Сайт должен нормально смотреться во всех стандартных разрешениях от 320 и выше, не иметь горизонтального скролла и вписываться в экран мобильных устройств**
13 | 6. Корректная работа при вбивании реального текста, надёжность вёрстки
14 | 7. CSS должен быть написан с использованием препроцессоров (LESS/Sass/Stylus). Желательно использование систем сборки (Grunt/Gulp) и построцессоров (PostCSS/Autoprefixer).
15 | 8. Проверка и оптимизация скорости загрузки: https://github.com/ihorzenich/WebPerformanceChecklist
16 | 9. Поддержка Retina
17 | 10. Наличие Win/Mac/Linux-аналогов шрифтов
18 | 11. Доступность при выключенных(загружающихся) картинках
19 | 12. HTML5 формы, линковка, валидация
20 | 13. Семантичность. Отсутствие глупостей в html и css, единообразие, аккуратность (смотри "Плохо/хорошо")
21 | 14. Правильная структура заголовков (H1,H2,… и т.д. и TITLE)
22 | 15. Работоспособность при выключенном (незагруженном) JavaScript
23 | 16. Работоспособность при выключенном Flash
24 | 17. Отсутствие багов при увеличенном шрифте
25 |
26 | 13. "Плохо"/"Хорошо"
27 | Важно понимать что семантика — может быть не только в используемых элементах, но и в именах классов. И БЭМ-иерархия классов — это новый уровень семантики.
28 |
29 | Плохо:
30 | - Самое страшное, к счастью уже редкое —
float: left для всех блоков. Безумный верстальщик эмулирует привычные ячейки таблиц, расставляя блоки как кирпичи друг за другом. Вон из профеcсии!
31 | Проверяется в extension для браузеров Web Developer → Outline → Outline Floated Elements, если всё в красных блоках, вёрстку нужно выкидывать на помойку.
32 | Так же, такая верстка получается при создании сайтов на Adobe Muse.
33 | Примеры: один - два - три
34 |
35 | - Отступы между блоками на сайте должны быть за счёт margin у блоков, а не выпирающих наружу margin у содержимого блоков.
36 | - Плохо — отсутствие тайтлов.
37 | - Плохо — отсутствие alt у картинок.
38 | - Плохо — хаки для браузеров внутри 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…)
39 | - Плохо — не проверять tabindex в формах.
40 | - Плохо — писать стили не думая о логике размещения элементов. Например, если элемент всегда находится сверху, у него должен быть большой z-index, нельзя надеяться на то что сейчас всё нормально смотрится — стили должны быть железобетонными. Если элемент всегда должен находится на каком-то месте, в независимости от окружающих его элементов — это position: absolute; а не float и т.д.
41 | Блоки независящие друг от друга не должны быть внутри одного блока (например телефон компании и поиск по сайту). Блоки независящие по расположению друг от друга должны быть position absolute, а не float’ится.
42 | - Очень плохо — презентационные классы (right, red).
43 | - Нежелательно когда вёрстка содержит пустые блоки для презентационных целей, для этого существуют псевдоэлементы
44 | - Плохо когда нет базовых стилей у стандартных элементов. Т.е. просто h1,h2,ul,table,etc без классов должны смотреться красиво и органично. Проще говоря — используйте Normalize, a не Reset CSS.
45 | - Плохо когда нет постепенного уточнения стилей для текста, когда стиль выписывается для каждого элемента отдельно, а за его пределами — внешний вид может быть кардинально другой. Речь о ситуации когда например текст, написанный без абзацев, имеет вообще не тот стиль что у всех элементов в блоке. Надо вести стили снизу вверх, постепенно уточняя их. Тут важно не путать стили для текста и стили для блоков. Для текста — каскад это добро, для блоков сайта — нужно использовать БЭМ.
46 | - Ещё хуже — чересчур детализированные глобальные стили. Например
a {font: italic 10px Tahoma;} /* Ненависть! Ненависть! НЕНАВИСТЬ!!11 */ Потом приходится переопределять стиль ссылок для каждого блока.
47 | - Размеры и позиционирование элемента должны указываться в одних единицах измерения. Т.е. высота/ширина блока в 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 (чтоб корректно увеличивать размер шрифта) .
48 | Плохо(недопустимо!) вешать стили на селекторы вложенных стандартных тэгов, без классов. Т.е. допустим пишем что-то типа h2 a span {какая-то крепкая штука, типа картинки с графикой, что закрывает текст в заголовке}, а потом клиент в визиге внезапно вбивает такое сочетание! И получаем невероятный баг. На просто одиночные теги для вывода текста из БД — можно, но используя блок .b-text (смотри BEM CSS).- Плохо — напрямую задавать визуальное отображение элементов через js:
$('.element').css(color,"#f00"). Это должно делаться через установку/смену классов.
50 |
51 | Хорошо:
52 | - БЭМ! Важно понимать что это методология, а не инструменты. Для обычных сайтов достаточно вёрстки по BEM CSS, без использования библиотеки блоков и bem-tools. Я долго считал что «BEM — это классная идея, но это чересчур, так категорично не надо, надо чуть по-другому, под себя...», так вот — это неверно! Нужно обязательно уходить от каскада, а БЭМ — это один из отличных вариантов решения.
53 | - Хорошо — структурировать код в блоки описывающие логику документа. Т.е. создавать div даже там, где он для презентационных целей не нужен. И наоборот — стараться не ставить лишний div там, где структура этого не требует, а это нужно лишь для визуальных эффектов.
54 | - HTML5 Boilerplate — замечательный стартовый шаблон от «отцов». Используйте и присоединяйтесь к разработке, добавляйте свои велосипеды туда!
55 | Раньше у нас был свой самописный framework-стартовый html, теперь используем Boilerplate как основу, а в него уже добавляем старые наработки.
56 | - Используйте наработанные решения, чужие модули, jQuery-плагины, не изобретайте велосипедов, а если изобретаете — поддерживайте их, ведите библиотеку кода (после каждого нового проекта добавляйте туда код, обновляйте старый).
57 | - Для текстовых блоков, что редактируются в админке, должна обеспечиваться атомарность текстовых стилей. Т.е. есть у нас страничка с каким-то текстовым блоком, примерно такой структуры:
58 | ```css
59 | .content-text h1
60 | .content-text .entry
61 | .content-text .entry .somenamedblock
62 | ```
63 | То .somenamedblock должен получать текстовые стили непосредственно —
.somenamedblock {font: …; color: …;}, т.к. иначе в визиге админки мы не сможем их застайлить.
64 | - одинаковый html-код для блоков на морде и внутряках, с идентичным контентом, но разным визуальным представлением данных. Реализуется через модификаторы блоков и элементов, но не через модификацию от родителя (каскад от body.pagename например!)
65 |
66 | Важные мелочи
67 |
68 | - Лого на внутряках должно вести на титулку. На титулке logo = h1, на внутряках H1=заголовок контента, а Logo=div
69 | - У каждой страницы должен быть свой уникальный TITLE формата
About Us — %CompanyName%
70 | - Все страницы должны быть слинкованы и проверены на наличие битых ссылок.
71 | - Все ссылки должны как-то реагировать на :hover, :active и :focus — показыванием/убиранием подчёркивания, сменой цвета, чем угодно. У всех ссылок, кроме пунктов меню, должна быть реакция на :visited
72 | - Проверять что все интерактивные элементы страницы что должны работать — работают.
73 | - «Контент в начале страницы» — содержимое страницы должно идти в начале кода, до всяких сайдбаров и прочего.
74 | - Все созданные странички изначально должны быть порезаны на шаблоны, чтоб программеру было легче их интегрировать.
75 | - Копирайт должен быть написан правильно.
76 | - Должны быть favicon.ico (желательно с включенными внутрь неё 32×32, 48×48 и 64×64 вариациями) и apple-touch-icon
77 | - В вёрстке не должны оставаться закомментированные «на всякий случай» куски кода, лишние неиспользуемые файлы, старые версии файлов и т.п. Все бекапы можно вытянуть из системы контроля версий (например Git или SVN), а на живом проекте «мусор» потом мешает разобраться как что работает.
78 | - Размеры для блоков, чьи размеры зависят от содержащегося в них текста, нужно задавать в em, а не px.
79 | - Если url ссылки неизвестен, то он должен быть равен её анкору, написанному латиницей с заменой пробелов/спецсимволов на тире.
80 | - Skype-плагин не должен ломать вёрстку
81 | - Ресайз textarea не должен ломать вёрстку
82 | - При проверке frontend в целом — 404-страница должна отдаваться с кодом 404 а не 200.
83 | - Нужно подстраховываться фиксируя в css размеры картинок, выводящихся программно.
84 | - Проверка орфографии Word’ом или Орфографом, желательно — оттипографить контент.
85 | - Ссылки на чужие сайты должны быть с
target="_blank", желательно выделять их иконкой «внешняя ссылка».
86 | - Разумеется картинки должны быть в отдельной папке, css — в отдельной и js — в отдельной. Графика, не являющаяся частью дизайна (всякие илююстрации, фото в новостях и т.д.) — нужно положить в отдельную папку, например userfiles.
87 | - Изображения должны масштабироваться в зависимости от размера окна
(max-width:100%; height:auto;)
88 |
89 |
--------------------------------------------------------------------------------
/example.css:
--------------------------------------------------------------------------------
1 | /*
2 | Examples of good css:
3 | - Naming conventions
4 | - Codestyle
5 | - BEM dialect
6 | */
7 |
--------------------------------------------------------------------------------