Стандарт качества на вёрстку

Стандарт качества

на вёрстку

версия 1.1

Оглавление

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

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

1.Кодировка: UTF-8....................................................................................................................... 4

2.DOCTYPE: HTML5......................................................................................................................... 4

3.Кроссбраузерность.................................................................................................................... 4

1.1)Chrome 13 ............................................................................................................................... 4

1.2)FireFox 4 ................................................................................................................................. 4

1.3)Safari 5 .................................................................................................................................... 5

1.4)Opera 11.................................................................................................................................. 5

1.5)Internet Explorer 8 и 9 (для IE6-7 выводится уведомление о не поддержке и предложении скачать другой браузер или установить Google Frame, но с возможностью всё-таки просмотреть сайт)............. 5

* Проверка в IE7 делается переключением IE8 в режим IE7 (F12→Режим обозревателя→Internet Explorer 7)....................................................................................................................................................... 5

* В IE6 можно посмотреть на ipinfo. info/netrenderer/ или на виртуальной машине (удобно использовать Windows XP Mode в Win7)........................................................................................................................... 5

1.6)Opera Mini.............................................................................................................................. 5

* проверяется в Opera Developer Tools→Opera Mini Simulator, нужно установить Java плагин к браузеру, или в крайнем случае: Opera 9.64→Вид-Маленький экран, но в 9.64 JS будет работать полноценно в отличие от настоящей Opera Mini, это нужно учитывать)............................................................................... 5

III. Валидность, доступность, микроформаты................................................ 5

1.Не должно быть js-ошибок........................................................................................................ 5

2.Титульная страница должна быть валидна в любом случае. Ошибки на внутренних страницах допустимы в следующих случаях:..................................................................................................................... 5

Для внесения контента использовался копипастит текстов из Word’а в визуальный редактор;.. 5

При использовании программистами некоторых кастомных атрибутов..................................... 5

3.CSS валидируется по версии 3.0, его валидность не требуется. Синтаксические ошибки (типа margin: 10xp) должны быть исправлены............................................................................................................ 5

4.Микроформаты должны быть. Как минимум – hCard. Желательно также hCalendar, XFN, hAtom. 6

IV. Корректность при разных вариантах разрешения.................................. 7

Сайт должен корректно отображаться и функуионировать во всех стандартных разрешениях от 1024 и выше и не иметь горизонтального скролла. Список классических разрешений:.......................................... 7

V. Надёжность вёрстки..................................................................................... 8

VI. Проверка и оптимизация скорости загрузки............................................ 9

VII. Наличие Win/Mac/Linux-аналогов шрифтов.......................................... 10

VIII. Доступность при выключенных (загружающихся) картинках............ 10

IX. HTML5 формы, линковка, валидация..................................................... 11

X. Семантичность. Единообразие, аккуратность в html и css,..................... 12

XI. Правильная структура заголовков (H1,H2,… и т. д. и TITLE)............... 13

XII. Работоспособность при выключенном JavaScript................................. 13

XIII. Работоспособность при выключенном Flash........................................ 13

XIV. Отсутствие багов при увеличенном шрифте......................................... 14

XV. Дополнительная информация................................................................. 14

XVI. Мелкие проверки................................................................................... 14

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

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

При изменениях контента, размеры блоков могут меняться (по высоте например).

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

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

1.  Кодировка: UTF-8

UTF-8 необходима для универсальности и совместимости.

Как проверяется: в Firefox Инструменты→Информация о странице, в появившемся окне должно быть написано «Кодировка: UTF8». Эта кодировка должна использоваться для всех файлов: html, css, js (если файлы в разных кодировках могут быть проблемы)

2.  DOCTYPE: HTML5

Наличие корректного doctype необходимо чтобы страницы отображались в соответствии со стандартами. Новый doctype позволяет использовать современные тэги (canvas, header, article,...) и старые проверенные решения. HTML5 — это современный стандарт, в нём можно писать и в строгом XHTML-синтаксисе.

Как проверяется: открываем исходный код страницы, первая строка должны быть <!DOCTYPE HTML>

3.  Кроссбраузерность

Все страницы должны корректно отображаться в браузерах:

.1.1)  Chrome 13

.1.2)  FireFox 4

.1.3)  Safari 5

* чтобы проверить не имея mac «размытые Mac'овские» шрифты (они чуть большего размера, из-за этого бывают баги), то установите в Preferences→Appearance, «Font Smoothing» в Medium (по дефолту там «Windows Standart»).

.1.4)  Opera 11

.1.5)Internet Explorer 8 и 9 (для IE6-7 выводится уведомление о не поддержке и предложении скачать другой браузер или установить Google Frame, но с возможностью всё-таки просмотреть сайт).

* Проверка в IE7 делается переключением IE8 в режим IE7 (F12→Режим обозревателя→Internet Explorer 7).

* В IE6 можно посмотреть на ipinfo. info/netrenderer/ или на виртуальной машине (удобно использовать Windows XP Mode в Win7).

– проверка в IE

.1.6)Opera Mini

* проверяется в Opera Developer Tools→Opera Mini Simulator, нужно установить Java плагин к браузеру, или в крайнем случае: Opera 9.64→Вид-Маленький экран, но в 9.64 JS будет работать полноценно в отличие от настоящей Opera Mini, это нужно учитывать)

Как проверяется: Проверяется просмотром сайта в вышеперечисленных браузерах.

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

1.  Не должно быть js-ошибок

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

2.  Титульная страница должна быть валидна в любом случае. Ошибки на внутренних страницах допустимы в следующих случаях:

·  Для внесения контента использовался копипастит текстов из Word’а в визуальный редактор;

·  При использовании программистами некоторых кастомных атрибутов.

3.  CSS валидируется по версии 3.0, его валидность не требуется. Синтаксические ошибки (типа margin: 10xp) должны быть исправлены.

Как проверяется валидность: С помощью онлайн-валидаторов:

·  HTML: validator. w3.org/ (или  Web Developer →Инструменты →Проверить HTML)

·  CSS: jigsaw. w3.org/css-validator/ (или  Web Developer →Инструменты →Проверить CSS)

4.  Микроформаты должны быть. Как минимум – hCard. Желательно также hCalendar, XFN, hAtom.

Как проверяется: С помощью онлайн-валидаторов:

·  Наличие микроформатов проверяется плагинами  Operator и  Tails Export.

·  Валидаторы микроформатов:

ü  /optimus/

ü  www. /webmasters/tools/richsnippets

ü  webmaster. yandex. ru/microtest. xml

ü  hcard. /

5. В идеале вёрстка должна соответствовать стандарту доступности: WCAG.

Как проверяется: Самый просто способ проверить что скорей всего WCAG1 Priority A соблюдён — www. /

(или  Web Developer →Инструменты →Проверить WAI).

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

· HTML

Стандарт HTML5 находится в активной разработке: вносятся изменения, что-то добавляется, что-то исключается. Валидатор HTML5 меняет правила проверки в соответствии с этим.
То что было валидным вчера, сегодня может выдавать ошибку, например такая ситуация сейчас сapple-touch-icon и XFN.

· 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

и т. п.

IV.  Корректность при разных вариантах разрешения

Сайт должен корректно отображаться и функуионировать во всех стандартных разрешениях от 1024 и выше и не иметь горизонтального скролла. Список классических разрешений:

·  1024x600

·  1024x768

·  1152x864

·  1280x800

·  1280x1024

·  1440x900

·  1680x1050

·  1920x1080

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

  V.  Надёжность вёрстки

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

1.  Проверка ввода и удаления данных.

Как проверяется: на странице с контентом, пробуется добавлять и удалять содержимое – когда текста много и мало.

2.  Проверка корректности работы стилей.

Как проверяется: на страницы с контентом вносится текст с абзацами и без абзацев, со списками и картинками, таблицами и заголовками разных уровней.

* Правки содержимого страницы делаются в FF через плагин  Firebug: HTML→Edit – меняем/добавляем/удаляем текст.

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

VI.  Проверка и оптимизация скорости загрузки

· Для мелких картинок связанных логически должны использоваться CSS-спрайты (например, набор буллетов или вариации отображения пункта меню: дефолтный, активный)

· Base64-encode для мелких отдельных картинок;

· CSS3 border-radius, gradient, box-shadow, text-shadow вместо использования графики;

· Оптимизация PNG и JPG файлов;

· JS максимально должен быть вынесен во внешние файлы, внешние js-файлы разумно объединены для уменьшения количества запросов. JS-библиотеки, например jQuery нужно грузить с Google CDN. Постарайтесь включить отложенную загрузку для большинства JS.

Как проверяется скорость загрузки в целом:

·  по панели 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 : запустить готовые скрипты оптимизации графики для картинок вашей вёрстки и сравнить результат с исходными файлами – если размер почти не измениться – значит всё ок.

· Если js не объединены в один файл, то Page Speed скажет вам об этом: “Combine external JavaScript”.

Рекомендации:

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

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

VII.  Наличие Win/Mac/Linux-аналогов шрифтов

Должны быть прописаны альтернативные стандартные шрифты.

Если альтернативные шрифты не прописаны, то у пользователей у которых отсутствует используемый в вёрстке шрифт, вместо него отобразится стандартный. Это может быть не только некрасиво, но и даже поломать отображение сайта.

* Часто забывают прописывать альтернативы для Myriad Pro, Arial Narrow.

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

Наборы аналогов популярных шрифтов:

·  CSS font matching: Windows, Mac and Linux

·  Complete Guide to Pre-Installed Fonts in Linux, Mac, and Windows

·  Codestyle: Combined font survey results

·  Common fonts to all versions of Windows & Mac equivalents

VIII.  Доступность при выключенных (загружающихся) картинках

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

Картинки часто отключают при использовании дорогого инета, тарифицируемого по траффику (GPRS, роуминг).

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

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

1.  Label и input/select должны быть слинкованы.
Это нужно для удобства пользователей. Также это очень облегчает жизнь пользователям с ограниченными физическими возможностями.

Как проверяется: Проверяется кликом по label – должен активироваться соответствующий ему элемент ввода.

2.  HTML5 валидация заполнения формы.

Серверная проверка ввода данных может быть реализована без перезагрузки страницы (через ajax), но тем не менее. У редкого числа пользователей современных браузеров с отключенным javascript, проверка ввода данных происходит средствами браузера, а не сервера.

Как проверяется: выключаем javascript, не заполняем форму, кликаем Submit – должны появится уведомления о необходимости заполнить поля.

3.  JS-валидация формы.
Пользователи привыкли, что если они неправильно заполнят форму, им не дадут её отправить, а укажут на ошибки.

Как проверяется: в Opera/Safari/Chrome: включаем javascript, не заполняем форму, жмём Submit – должны появится уведомления о необходимости заполнить поля.

4.  Если проверяется frontend в целом — должна быть серверная валидация формы.

Как проверяется: в Firefox 3.6: выключаем javascript, не заполняем форму, жмём Submit – должны появится уведомления о необходимости заполнить поля.

5.  Правильные input type=”email/url/tel”

Практическая ценность для пользователя заключается в том, что на iPhone будет показываться клавиатура соответствующая формату поля ввода.

Как проверяется: на iPhone — в зависимости от типа поля ввода он должен показывать различную клавиатуру: стандартную/цифровую/для набора web/email-адресов.

6.  Уведомления об ошибках должны быть не js-alert’ом, а текстом в дизайне сайта

Всё оформление в формах должно быть «повешено» на классы,

id — только для линковки с label.

  X.  Семантичность. Единообразие, аккуратность в html и css,

1.  Наиболее частые ошибки:

· float: left для всех блоков.

Как проверяется: Web Developer Outline → Float elements, если всё в красных блоках, вёрстку нужно переделывать.

· Отступы между блоками на сайте должны быть за счёт margin у блоков, а не margin у содержимого блоков.

· Плохо — отсутствие тайтлов.

· Плохо — отсутствие тайтлов.

· Плохо — отсутствие alt у картинок.

· Плохо — стили для IE внутри main. css без фильтров. Т. е. когда просто написано {zoom: 1;} — это очень плохо, т. к. будет применяться ко всем IE, а не только к тому, в котором проблема. Нужно фильтровать: HTML5 Boilerplate-стили (html. ie7, html. ie8,...), использовать Conditional Comments, ну или на крайний случай (* html, *+html и т. д.).

· Плохо – не проверять tabindex в формах.

· Плохо — писать стили, не думая о логике размещения элементов. Например, если элемент всегда находится сверху, у него должен быть большой z-index. Если элемент всегда должен находится на каком-то месте, в независимости от окружающих его элементов — это position: absolute; а не float и т. д.

· Блоки независящие друг от друга не должны быть внутри одного блока (например, телефон компании и поиск по сайту). Блоки независящие по расположению друг от друга должны быть position absolute, а не float.

· Очень плохо — презентационные классы (right, red).

· Плохо когда нет базовых стилей у стандартных элементов. Т. е. просто h1,h2,ul, table, etc без классов должны смотреться красиво и органично.

· Плохо когда нет постепенного уточнения стилей, а стиль выписывается для каждого элемента отдельно, а за его пределами — внешний вид может быть кардинально другой. Речь о ситуации когда, например, текст, написанный без абзацев, имеет вообще не тот стиль что у всех элементов в блоке. Надо вести стили снизу вверх, постепенно уточняя их.

· Плохо – чересчур детализированные глобальные стили. Например, a {font: italic 10px Tahoma;}. В последствии приходится переопределять стиль ссылок для каждого блока.

· Размеры и позиционирование элемента должны указываться в одних единицах измерения. Для текстовых блоков это в 90% случаев — 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 {какая-то картинка с графикой, которая закрывает текст}, а потом клиент в визуальном редакторе нечаянно вбивает такое сочетаниеклавиш - получается невероятный баг. Все стили элементов внутри #content обязательно должны навешиваться на элементы с классом.

· Плохо — напрямую задавать визуальное отображение элементов через js:$(“elementid”).css(styleName,"something"). Это должно делаться через установку/смену классов.

2.  Примеры хорошего:

· Хорошо — структурировать код в блоки описывающие логику документа. Т. е. создавать div даже там, где он для презентационных целей не нужен. И наоборот — стараться не ставить лишний div там, где структура этого не требует, а это нужно лишь для визуальных эффектов.

· Для текстовых блоков, что редактируются в админке, должна обеспечиваться атомарность текстовых стилей. Т. е. есть страничка с каким-то текстовым блоком, примерно такой структуры:

body. contacts #content #content-text h1

body. contacts #content #content-text. entry

body. contacts #content #content-text. entry. somenamedblock

div. somenamedblock должен получать текстовые стили непосредственно — div. somenamedblock {font: ...; color: ...;}, т. к. иначе в визуальном редакторе CMS мы не сможем задать им стиль.

· одинаковый html-код для блоков на главной и внутренних страницах, с идентичным контентом, но разным визуальным представлением данных.

XI.  Правильная структура заголовков (H1,H2,… и т. д. и TITLE)

Заголовки структурируют сайт, делают его корректным документом. Корректный Document Outline важен для SEO.

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

XII.  Работоспособность при выключенном JavaScript

JS может быть выключен согласно корпоративных требований безопастности. В Opera Mini он работает только методом перезагрузки страницы. 

А также — сайт должен сохранять нормальный вид, пока он грузится на медленном 3G и js-скрипты ещё не выполнились.

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

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

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

XIII.  Работоспособность при выключенном Flash

В идеале весь критически важный функционал сайта был доступен без Flash. Нужно:

· выводить фоновую графику в блок, где должен отображаться презентационный flash;

· выводить хотя-бы просто тестовую информацию в блок где через flash выводится какая-то информация;

· выводить кнопку “Get Adobe Flash Player” и предлагать Express Install если без флеша никак не обойтись.

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

XIV.  Отсутствие багов при увеличенном шрифте

Как проверяется: в FF

·  Шрифты – включением View→Zoom→Zoom Text Only и последовательным нажатие клавиш Ctrl + — (или View→Zoom→Zoom In).

·  120 dpi – настраивается отдельным приложением в Control Panel (Vista/Seven) или в свойствах драйвера видеокарты в XP.

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

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

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

XV.  Дополнительная информация

При получении вёрстки желательно получить также описание, какие CSS/JS фреймворки будут использованы и пожелания по использованию jquery

XVI.  Мелкие проверки

· Лого на внутренних страницах должно вести на главную страницу сайта. На главной странице logo = h1, на внутренних H1=заголовок контента, а Logo=div

· У каждой страницы должен быть свой уникальный TITLE формата <title>About Us - %CompanyName%</title>

· Все страницы должны быть слинкованы и проверены на наличие битых ссылок.

· Все ссылки должны реагировать на :hover, :active и :focus — показыванием/убиранием подчёркивания, сменой цвета,. У всех ссылок, кроме пунктов меню, должна быть реакция на :visited.

· «Контент в начале страницы» — содержимое страницы должно идти в начале кода, до сайдбаров и прочего.

· Расширение страниц на сайте должно быть ".html" а не ".php", а все созданные странички изначально должны быть порезаны на шаблоны и работать через mod_rewrite.

· Должны быть favicon. ico (желательно с включенными внутрь неё 32x32, 48x48 и 64×64 вариациями) и apple-touch-icon

· В вёрстке не должны оставаться закомментированные «на всякий случай» куски кода, лишние неиспользуемые файлы, старые версии файлов и т. п.

· Размеры для блоков, чьи размеры зависят от содержащегося в них текста, нужно задавать в em, а не px.

· Если url ссылки неизвестен, то он должен быть равен её анкору, написанному латиницей с заменой пробелов/спецсимволов на тире.

· Skype-плагин не должен ломать вёрстку

· Изменение размера textarea не должен ломать вёрстку

· При проверке frontend в целом — 404-страница должна отдаваться с кодом 404 а не 200.

· Нужно подстраховываться фиксируя в css размеры картинок, выводящихся программно.

· Ссылки на чужие сайты должны быть с target=«blank», желательно выделять их иконкой «внешняя ссылка».

· Картинки должны быть в отдельной папке, css — в отдельной и js — в отдельной.