Простые правила простой вёрстки

Отличная статья для новичков и тех кто считает что уже все умеет, но вопросов появляется все больше и больше

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

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

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


Логика кода — универсальные классы


Регулярно встречающаяся проблема — отсутствующая или искореженная во время довёрстки логика кода. Я говорю не о грубых ошибках, вроде пересекающихся и незакрытых тегов, а о совершенно отмороженном подходе большого количества начинающих верстальщиков к дальнейшей судьбе их работы. Мои слова могут показаться крамольными, но вёрстку небольших проектов, вроде сайтов-визиток, 30-60-ти страничных корпоративных сайтов и им подобных, нет нужды строить на базе css-«фреймворков», и модульная сетка для верстки таких сайтов тоже не требуется. Это современно, это показывает уровень ваших навыков и это действительно часто оправдано, но в данном случае это лишь усложнит чтение кода и увеличит дерево DOM. Как говорил старик Резо, не преумножай сущности сверх надобности.

Типовая ситуация — блок новостей:

HTML:

<!-- news -->
<div class="news">
	<div class="item">
		<span class="date">16.07.12</span>
		<a href="#" title="" class="title"><strong>Создание продающих сайтов</strong></a>
 
		<p>Текст новости</p>
	</div>
 
	<div class="item">
		<span class="date">16.07.12</span>
		<a href="#" title="" class="title">Создание продающих сайтов</a>
 
		<p>Текст новости</p>
	</div>
 
	<div class="item">
		<span class="date">16.07.12</span>
		<a href="#" title="" class="title">Создание продающих сайтов</a>
 
		<p>Текст новости</p>
	</div>

Куда проще и понятнее? Имена классов могут быть любыми, но крайне желательно, чтобы они не выбивались из общего стиля. Зачем писать news-box, homenewsletter? Особенно удивляет, если в следующем типовом блоке, например статей, класс называется articles-list или даже all_articles.

Обратите внимание на универсальный класс item. Каждый волен обзывать его по разному, скажем box, это не принципиально, мне item кажется абсолютно нейтральным и понятным по смыслу всем, кому предстоит работать с кодом в дальнейшем — это просто блок из списка других таких же, как он.

Update. Рекомендуется ознакомиться с комментариями, чтобы понять минусы такого подхода.
Ветка обсуждения.

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

PHP:

<!-- //-------------- FOOTER --------------// -->

Другой часто используемый универсальный элемент — wrapper. В основном используется для ограничения размеров блока, находящегося внутри тянущегося контейнера. Простейший пример — резиновый футер с контентной частью фиксированной ширины внутри него.

Код:

<div id="footer">
	<div class="wrapper">
		Контент
	</div>
</div>

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



В данном случае внутри контейнера у нас лежит картинка с float: left, и wrapper с контентом внутри, которому надо запретить обтекание(overflow: hidden). Не будем заострять на этом внимание, напомню лишь на всякий случай, что универсальным классам нужно обязательно указывать родителей в CSS или использовать селектор > для ограничения радиуса действия стиля, чтобы в вёрстке не случился массакр:

Код:

.news .item { }
.news > .item { }
#footer .wrapper { }

Логика кода — забота о программистах


Сначала о формах, совсем немного.

Код:

<form action="">
	<input type="text" name="s1" value="Поле" tabindex="1" /><br />
	<input type="checkbox" name="s2" id="s2" tabindex="2" checked="checked" /> <label for="s2">Чекбокс</label><br />
	<input type="submit" name="s3" value="Кнопка" tabindex="3" />
</form>

Так как подавляющее большинство верстальщиков средней руки, которых в избытке на фрилансерских сайтах даже не заглядывали в спецификации, пара уточняющих моментов. Оборачивайте область формы в тег <form>(action нужен для нормальной валидации), не гнушайтесь использовать лейблы для чекбоксов и радиокнопок, проставляйте табиндексы и нумеруйте или давайте понятные имена элементам формы. Это залог аккуратности и плюса в карму от программистов, которым предстоит работать с вашей вёрсткой.


Немного о подключении скриптов:

Код:

<script src="js/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/libs/jquery-1.7.1.min.js"><\/script>')</script>
 
<script src="js/plugins.js"></script>
<script src="js/script.js"></script>
 
<!-- Anything Slider -->
<script src="js/anythingslider/js/jquery.anythingslider.js"></script>
<script>
	$(function(){
		$('#slider').anythingSlider();
	});
</script>
</body>
</html>

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

• Минимизируйте дерево DOM не в ущерб удобству и здравому смыслу. Минимизуйте количество классов. Не забывайте о :first-child, :nth-child или их js-аналогах.
• Хорошим тоном считается сброс значения поля по клику. Используйте placeholder или js.
• Меню в подавляющем большинстве случаев верстается ненумерованными списками ul. Подменю в подавляющем большинстве случаев верстается без div внутри li.
• Поп-апы и другие невидимые изначально блоки, не привязанные к конкретному контейнеру удобно размещать перед закрывающим body — это не мешает чтению кода с начала.
• Таблицы, как ни странно, удобно верстать таблицами, иногда помогая блоками. Не забывайте о tr:hover, thead, tbody и tfoot. Чередующиеся строки с разными стилями верстайте через CSS-селекторы или с помощью классов even и odd
• Имена основных папок корня проекта и названий страниц должны быть стандартизированы. Обычно это css для файлов стилей, images или img для изображений(и подпапка tmp для временных изображений, которые не будут использоваться на живом сайте), js для js, fonts для шрифтов. Имена страниц я для удобства беру из названий файлов макетов, предоставленных заказчиком.

Немного о CSS


Не мне учить кого-либо, как ему оформлять таблицу стилей, я лишь покажу известный способ, который относительно редко используется, зато повышает читаемость CSS до запредельных высот и избавляет от необходимости использования заклинания Ctrl+F.



Древовидная однострочная структура CSS на мой взгляд по всем пунктам дает фору такой форме записи:

Код:

.fmenu_text {
  overflow: hidden;
  vertical-align: top !important;
}
.font_medium .fmenu_item {
  font-size: 11px;
}
.fmenu_item:hover {
  text-decoration: none;
  opacity: 1;
}
.fmenu_item_over {
  opacity: 1;
  background-color: #597DA3;
  color: #FFF;
}
#fmenu_fr {
  background-position: 100% -6px;
}

Читабельность повышает также последовательность написания селекторов в строку. Некоторые пользуются своей логикой записи, кто-то упорядочивает свойства по алфавиту, часть верстальщиков вообще пишет от балды. Я предпочитаю в первую очередь описывать свойства, описывающие поведение контейнера(position, top/right/bottom/left, float, затем свойство display, если оно присутствует, далее следуют всевозможные маргины и паддинги, outline, cursor и border-ы, после чего идут шрифты и их свойства, за ними — background и наконец свежие CSS3-свойства с префиксами или без).

Update. В комментариях проясняются серьезные минусы однострочного написания таблицы стилей. Рекомендую ознакомиться.
Ветка обсуждения.
CSS — Общие рекомендации

• Используйте сокращенную круговую форму записи маргинов и паддингов(margin: 0 0 0 0). В противном случае ваши строки будут гигантской длины, что ухудшит читаемость.
• Не выносите reset в отдельный файл, подключайте его в начале общего файла стилей. Надо экономить на запросах к серверу. Внешние шрифты, font-face-kit's можно подключать сразу после reset.
• Это же касается изображений. Нет необходимости создавать отдельный файл, например, со всеми иконками сайта. Его будет неудобно редактировать, если у одной из иконок вдруг увеличится размер. Но в разумных пределах спрайты необходимы — link/visited/active/hover подложки для ссылок делать спрайтами нужно обязательно, чтобы при наведении на ссылку hover-подложка не подгружалась в течение пусть и 15-20 миллисекунд.
• Крупные блоки кода также как и в html рекомендуется предварять комментарием — /* comment */.
• По хакам для IE — у меня нет однозначного мнения. В основном я размещаю их в конце общего файла стилей. Если их больше 5-10, подключаю с помощью условных комментариев.

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

Из литературы могу порекомендовать отличную книгу Эрика Мейера "CSS — Подробное руководство", брошюру от авторов проекта webo.in "Разгони свой сайт" и собственно спецификации CSS.

Источник