Главная » 2012 » Сентябрь » 5 » Чек-лист вёрстки. Что можно отдавать клиенту, а что надо переделывать-2
19:31
Чек-лист вёрстки. Что можно отдавать клиенту, а что надо переделывать-2

№5 Оптимизация скорости загрузки


Page Speed
  • для мелких картинок связанных логически должны использоваться CSS-спрайты (например набор буллетов или вариации отображения пункта меню: дефолтный, активный)
  • Base64-encode для мелких отдельный картинок;
  • CSS3CSS3 border-radius, gradient, box-shadow, text-shadow вместо использования графики;
  • Оптимизация PNG и JPG файлов;
  • JS максимально должен быть вынесен во внешние файлы, внешние js-файлы разумно объединены для уменьшения кол-ва запросов. JS-библиотеки, например jQuery нужно грузить с Google CDN. Постарайтесь включить отложенную загрузку для большинства JS.

Зачем это нужно:
скорость загрузки оказывает ключевое влияние на доступность сайта (больше психологическую, чем фактическую), активность пользователей на сайте (медленными сайтами люди предпочитают не пользоваться) и его конверсию (медленным сайтам не доверяют).
© sunnybear.
В целом скорость загрузки проверяется так:


  • Наличие 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 – запустить готовые скрипты оптимизации графики для картинок вашей вёрстки и сравнить результат с исходными файлами – если размер почти не измениться – значит всё ок. Недавно (март 2012) Yandex выпустил свой инструмент для этих целей — imgo, но он под Linux или Mac.
  • Если js не объединены в один файл, то Page Speed скажет вам об этом: "Combine external JavaScript”.


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

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



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


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

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

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




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


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

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


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


HTML5 Forms
  1. Label и input/select должны быть слинкованы.
    Это нужно для удобства юзеров. Также это очень облегчает жизнь пользователям с ограниченными физическими возможностями.
    Проверяется кликом по label – должен активироваться соответствующий ему элемент ввода.
  2. HTML5 валидация заполнения формы.
    Практическая ценность пока-что невелика, ведь серверная проверка ввода данных тоже может быть реализована без перезагрузки страницы (через ajax), но это говорит о проф. уровне исполнителя — у редкого числа юзеров современных браузеров с отключенным javascript, проверка ввода данных произойдёт средствами браузера, а не сервера.
    Проверяется в Opera: выключаем 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-адресов.


Уведомления об ошибках должны быть не js-alert’ом, а текстом в дизайне сайта!
Всё оформление в формах должно быть повешено на классы, id — только для линковки с label (a то потом программеры прикручивают, пишут свои id и ломается внешний вид).


№9 Семантичность. Отсутствие глупостей в html и css, единообразие, аккуратность


SemanticsПожалуй единственный пункт, где нельзя дать чётких критериев. Про то, что такое плохо можно почитать в моей статье «Вредная вёрстка».
Как ориентир – наиболее частые ошибки:
  • Самое страшное, к счастью уже редкое — float: left для всех блоков.Безумный верстальщик эмулирует привычные ячейки таблиц, расставляя блоки как кирпичи друг за другом. Вон из профеcсии! Проверяется: 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;} /* Ненависть! Ненависть! НЕНАВИСТЬ!!11 */ Потом приходится переопределять стиль ссылок для каждого блока.
  • Размеры и позиционирование элемента должны указываться в одних единицах измерения. Для текстовых блоков это в 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"). Это должно делаться через установку/смену классов.


Примеры хорошего:
  • БЭМ! В чистом виде тяжеловат, но идеи — крайне верные!
  • Хорошо — структурировать код в блоки описывающие логику документа. Т.е. создавать div даже там, где он для презентационных целей не нужен. И наоборот — стараться не ставить лишний div там, где структура этого не требует, а это нужно лишь для визуальных эффектов.
  • HTML5 Boilerplate — замечательный стартовый шаблон от «отцов». Используйте и присоединяйтесь к разработке, добавляйте свои велосипеды туда! 
    Раньше у нас был свой самописный framework-стартовый html, теперь используем Boilerplate как основу, а в него уже добавляем старые наработки.
  • Используйте наработанные решения, чужие модули, jQuery-плагины, не изобретайте велосипедов, а если изобретаете — поддерживайте их, ведите библиотеку кода (после каждого нового проекта добавляйте туда код, обновляйте старый).
  • Для текстовых блоков, что редактируются в админке, должна обеспечиваться атомарность текстовых стилей. Т.е. есть у нас страничка с каким-то текстовым блоком, примерно такой структуры:
    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: ...;}, т.к. иначе в визиге админки мы не сможем их застайлить.
  • одинаковый html-код для блоков на морде и внутряках, с идентичным контентом, но разным визуальным представлением данных.



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


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

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



http://habrahabr.ru/post/114256/ 


Просмотров: 375 | Добавил: Сусанин | Рейтинг: 0.0/0
Всего комментариев: 0
Имя *:
Email *:
Код *: