Требования К Html-Верстке

1. Планировка, аутсорсинг и технические характеристики

Верстка — относительно самостоятельный этап веб-разработки и, например, в небольших веб-студиях часто является первым кандидатом на аутсорсинг в условиях ограниченности трудовых ресурсов.
Так получилось, что мне часто приходилось отдавать эту работу субподрядчикам и, несмотря на предполагаемую уверенность в результате, иногда верстальщики меня очень удивляли.
И чаще – в отрицательном смысле.
Чтобы сэкономить трудовые ресурсы штатных верстальщиков, недостаточно просто переложить эту работу на плечи первого понравившегося фрилансера.
Все гораздо проще, если постоянно отдавать работу на аутсорсинг одним и тем же исполнителям – в процессе долгосрочного сотрудничества всегда складывается некий негласный свод стандартов и требований, выполнение которых входит в привычку.
Но если вы работаете с человеком впервые, лучшее портфолио и рекомендации не гарантируют желаемого результата и тем более даже не предполагайте, что исполнитель вообще вас правильно поймет. Поэтому необходимо подробное техническое задание на компоновку.
И этот момент игнорируется.
Часто это происходит из-за предположения, что трудозатраты на написание детального технического задания в сочетании со стоимостью аутсорсинга не компенсируются сэкономленным временем штатного верстальщика.
В конце концов, планировка — это не так уж и сложно, считает среднестатистический менеджер проекта.
И, как правило, это действительно работает, хвала человеческому интеллекту, профессиональные верстальщики в большинстве своем ограничивают буйство экспериментального духа и заранее знают, какие технические решения в верстке могут вызвать геморрой у заказчика, не так уж и адски как забанить верстальщика, но все равно исключая радость и восхищение красивой html версткой.
Однако вероятность факапов, как показывает практика, не настолько мала, чтобы ею можно пренебречь.
И главное заблуждение здесь в том, что детальное техническое задание – это сложно и требует много времени.
В любом случае приходится описывать какие-то конкретные требования к макету, а общие требования и рекомендации обычно игнорируются.

2. О, велико мое горе!

Недавно я получил макет, который менеджеры отдали на аутсорсинг, и я просто не знал, смеяться или плакать.

Если бы мне не пришлось интегрировать этот макет в систему шаблонов CMS, я бы, наверное, до сих пор смеялся.

Табличная раскладка и стили, не включенные в CSS-файл, и стандартный скрипт Dreamweaver для подсветки кнопок даже не воспринимаются как недостатки после того ада, что я видел.

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

Классы CSS имели названия на кириллице, причем не осмысленные, а типа «.

style1,.

style2».

Большинство элементов формы были стилизованы каким-то малоизвестным и жутко кривым jQuery-скриптом, некоторые элементы имели одинаковые ID и между ними находился JS-код, который оперировал только этими элементами и получал их по ID, и верх безумия был использование метода в конце документа jQuery.сss для установки стилей, что ну ничего не мешало просто записать их в CSS-файл.

А шапка сайта вместе с кучей ссылок (шрифтом Tahoma и без сглаживания) была сделана одним изображением, на которое были наложены элементы MAP и AREA. Не буду еще больше травмировать вашу психику описанием провалов в этой замечательной планировке, ведь их было еще бесчисленное множество.

Требования к HTML-верстке

В общем, поверьте товарищи, это был ППЦ, который тоже подкрался чуть ли не раньше срока.

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

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

Многие из перечисленных вещей вполне очевидны, но вы можете извлечь выгоду из того, что все они собраны в одном месте.

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

3. Требования и рекомендации

1 .

Кроссбраузерная совместимость Сайт должен нормально работать в IE7+, FF3+, Opera9+, Safari4+, Chrome последней основной версии (или в зависимости от условий договора с клиентом и года, в котором вы читаете эту статью).

2 .

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

3 .

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

Позаботьтесь о верстальщиках, которым после вас придется работать с этим макетом.

4 .

Имена и идентификаторы классов должны быть значимыми для приложения.

например, заголовок, меню, нижний колонтитул, новости 5 .

Пожалуйста, разделяйте основные блоки html комментариями.

Как это: Это необходимо для создания шаблонов для CMS из HTML-верстки, после чего комментарии будут удалены.

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. НИЖНИЙ ФОТЕР (Цокольный этаж)_______________*/ /*___________5. БОКОВАЯ ПАНЕЛЬ (Справа)_______________*/

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

15 .

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

Добавлены новые картинки в папку img.

Картинки btnHome.jpg и btnFeedback.jpg больше не нужны, их можно удалить.

Изменен html-код в разделе файла anketa.html.

Добавлены новые стили в конец файла main.css (начиная с .
form_row и ниже).

16 .

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

17 .

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

Не забудьте указать курсор:указатель для кнопок, созданных не с помощью ввода.

Если вы не знаете, будет ли к этой кнопке прикреплен обработчик событий с помощью JS или это будет ссылка, лучше использовать метод тег все равно.

19 .

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

20 .

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

Если это не предусмотрено техническим заданием.

и дизайн, обязательно обсудите это с заказчиком.

21 .

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

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

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