Соответствие макету - korshu.ru o_O
Главная
Поиск по ключевым словам:
страница 1
Похожие работы
Соответствие макету - страница №1/1



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

на вёрстку

версия 1.1



Оглавление


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

2.DOCTYPE: HTML5 3

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

1.1)Chrome 13 3

1.2)FireFox 4 3

1.3)Safari 5 3

1.4)Opera 11 4

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

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

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

1.6)Opera Mini 4

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

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

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

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

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

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

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

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




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


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

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


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



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

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


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



    1. DOCTYPE: HTML5


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


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

        2. FireFox 4

        3. Safari 5


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

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

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

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


netrenderer.com – проверка в IE
        1. Opera Mini

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


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

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


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

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

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

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


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

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

  • CSS: jigsaw.w3.org/css-validator/ (или  Web Developer →Инструменты →Проверить CSS)
    1. Микроформаты должны быть. Как минимум – hCard. Желательно также hCalendar, XFN, hAtom.


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

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

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

    • microformatique.com/optimus/

    • www.google.com/webmasters/tools/richsnippets

    • webmaster.yandex.ru/microtest.xml

    • hcard.geekhood.net/



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

(или  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%)

и т.п.



    1. Валидатор считает ошибкой указание вендорных префиксов

Поэтому допустимы ошибки такого рода:
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

и т.п.


    1. Раньше проприентарные свойства 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



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

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


  • 1024x600

  • 1024x768

  • 1152x864

  • 1280x800

  • 1280x1024

  • 1440x900

  • 1680x1050

  • 1920x1080


Как проверяется: Проверяется в FF через плагин  Web DeveloperResize
  1. Надёжность вёрстки


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

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


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

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


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


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

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

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


  • Для мелких картинок связанных логически должны использоваться 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-стилей может и не быть по причине ненужности (макет очень простой).


  1. Наличие 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


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


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

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




Как проверяется: в FF через плагин  Web Developer→Images→Replace Images With Alt Attributes.
  1. HTML5 формы, линковка, валидация


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

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

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

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

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


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


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

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


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


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

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

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


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

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



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

  1. Семантичность. Единообразие, аккуратность в 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"). Это должно делаться через установку/смену классов.

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



  • Хорошо — структурировать код в блоки описывающие логику документа. Т.е. создавать 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-код для блоков на главной и внутренних страницах, с идентичным контентом, но разным визуальным представлением данных.
  1. Правильная структура заголовков (H1,H2,… и т.д. и TITLE)


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

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


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


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

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



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