Если все штатные специалисты заняты, то к работе подключается удалённый специалист. Такой подход используют компании, которые равномерно распределяют нагрузку с проектов по специалистам. Зачастую удалённым специалистам отдаются незначительные промежуточные работы, которые сможет потом проверить штатный специалист и продолжить работы. Вёрстка сайта - один их таких этапов. Имея большой опыт работы с удалёнными специалистами по вёрстке сайта, мы собрали чек-лист, по которому считаем правильным принимать работу верстальщика.

Случается так, что верстальщик забывает делать интерактивные элементы: слайдеры, карусели, всплывающие окна. Или, например, элементы, которые редактируются пользователем, по минимуму должны использовать классы. Необходимо так же учитывать, что названия элементов меню могут быть разной длины, а не только той, что указана в дизайн-макете. Верстку от этого рвать не должно.

Некоторые материалы заимствованы из других источников. Ссылки на источники указаны внизу статьи.

Требования и рекомендации к верстке сайтов

1. Кроссбраузерность
 Сайт должен нормально работать в IE9+, FF33+, Opera12+, Safari7+, Chrome последней версии (или в зависимости от условий договора с клиентом и года, в котором вы читаете эту статью).

2. Всегда описывайте цвет фона для body даже если он белый.

3. Если используете CSS хаки, комментируйте, что это и для какого браузера, а лучше используйте css_browser_selector.js. Заботьтесь о верстальщиках, которым придется работать с этим макетом после вас.

4. Названия классов и id должны по смыслу соответствовать применению
 например, header, menu, footer, news

5. Просьба разделять основные html блоки комментариями. Примерно так:
 <!--—BEGIN FOOTER -->
 <!--—END FOOTER -->

 Это нужно для создания из сверстанного html макета шаблонов для CMS, после чего комментарии будут удаляться.

6. Не пренебрегать возможностью использовать GIF/PNG с 8-битным альфаканалом вместо PNG-24, где это возможно.

7. Все что можно сделать без Javascript, делать без него.

8. Если Javascript кода много — нужно его выносить в отдельный файл. Обработчики событий тоже лучше отделить и объявлять в отдельном файле.

9. Если это еще не оговорено с заказчиком, предварительно оговорить, какие JavaScript библиотеки вы планируете использовать при верстке макета, чтобы потом не оказалось, что при верстке использовался, к примеру, PrototypeJS, а заказчик планирует в обязательном порядке внедрять на сайт jQuery.

10. Для резиновых макетов обязательно должна быть задана минимальная и максимальная ширина.

11. Если в Т.З. не сказано другое, макет обязательно должен помещаться без горизонтальных скроллбаров в развернутое на весь экран окно браузера при горизонтальной составляющей разрешения экрана 1024px, а если позволяет размер макета, то и 800px.

12. В папке с изображениями не должно быть картинок, не использующихся в верстке. Если что-то исключили из верстки или переделали — не забывайте удалять уже ненужные картинки.

13. Для всех элементов, которые могут содержать текст различной длины, который должен быть вписан в одну строку (например, для кнопок или заголовков, если в дизайне не предусмотрено, что они могут занимать больше одной строки), обязательно задавайте CSS свойство white-space:nowrap.

14. CSS файл должен быть разбит с помощью строк с комментариями на блоки по функциональному назначению, например:
/* ___________1. Сброс CSS____________________*/
 /* ___________2. Типовые элементы____________*/
 /* _______________2.1. Залоговки______________*/
 /* _______________2.2. Ссылки________________*/
 /* _______________2.3. Элементы форм_________*/
 /*___________3. HEADER (Шапка сайта) __________*/
 /*___________4. FOOTER (Подвал )_______________*/
 /*___________5. SIDEBAR (Справа)_______________*/

 Как именно структурировть стили — вопрос немного холиварный, но главное — как-то это делать.

15. Если сдача верстки производится более чем одним этапом (например, верстальщик отправляет страницы по одной, или если ему возвращаются на доработку уже сверстанные страницы) и вы не используете систему контроля версий для верстки, исполнитель должен в обязательном порядке прикрепить файл с описанием изменений в макете примерно такого содержания:

• Добавил новые картинки в папку img,
• Картинки btnHome.jpg и btnFeedback.jpg уже не нужны, можно удалять
• Изменил html-код в секции файла anketa.html
• Добавил в конец файла main.css новые стили (начиная с .form_row и ниже).

16. Оговорить, в какой кодировке должен быть html-макет. CSS и JS файлы должны быть в той же кодировке, что и макет, иначе вероятность долгой и утомительной охоты на баги критически возрастает.

17. Если в макете присутствует JS, изменяющий DOM — внимательно следить, чтобы все корректно работало в Опере, т. к. этот замечательный браузер при нажатии на кнопочку назад страницу не перезагружает, а отдает закешированный документ, причем очень важный момент: документ не просто закешированный, а еще и с учетом всех модификаций DOM, которые были выполнены с помощью JS

18. Не забывайте прописывать cursor:pointer для кнопок, сделанных не с помощью input. Если вы не знаете, будет на эту кнопку повешен обработчик событий с помощью JS или это будет ссылкой, лучше в любом случае использовать тег <a>.

19. Если вы делаете обработку событий при нажатии на ссылки, следите за тем, чтобы обработчики событий возвращали false, или же используйте href='javascript:void(0)' вместо популярного href='#', чтобы страница не скроллилась вверх.

20. Верстайте формы правильно: метки полей должны находиться в тегах label, имеющих правильно заполненный атрибут for. Предусматривайте при верстке форм элементы для вывода ошибок валидации и стили для неправильно заполненных полей. Если это не предусмотрено в т.з. и дизайне, обязательно обсудите это с заказчиком.

21. Если в макете используются нестандартные шрифты, обязательно оговорите, можно ли элементы с нестандартным шрифтом делать картинками, если нельзя — обсудите, с помощью какой технологии будет реализовано их отображение (sIfr, Cufon, etc.)

22. Если не оговорено обратное для частных случаев, все блоки, высоту которых ничего в дизайне не мешает сделать динамической, должны иметь именно динамическую (т. е. зависимую от содержания) высоту, а иногда, чтобы ничего не могло потенциально поломать дизайн, нужно задавать и минимальную высоту. Если хотите сделать блок фиксированной высоты — сначала спросите у заказчика.

23. В макетах, где высота страницы зависит от контента (а таких, как правило, большинство), предусматривайте, чтобы футер был прибит к низу браузера при отсутствии/малом количестве контента, если не оговорено обратное.

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