Организация верстки большого проекта

[Игорь Ермаков]

Товарищи, у кого есть опыт верстки больших проектов поделитесь.

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

[npofopr]

эм. несколько psd макетов, всех типов страниц. и все.

какая разница какой проект. отрисовано все должно быть)

можно отдельный макет с менюшечкой там, различные ховеры на нем показать.

ссылками, загаловками, видами списков. ну и т.д.

[Игорь Ермаков]

эм. несколько psd макетов, всех типов страниц. и все.

какая разница какой проект. отрисовано все должно быть)

можно отдельный макет с менюшечкой там, различные ховеры на нем показать.

ссылками, загаловками, видами списков. ну и т.д.

Да, это все есть.

А теперь о верстке.

[klierik]

Посмотри тут: http://vitaly.harisov.name/article/independent-blocks.html

и тут: http://vitaly.harisov.name/css-code-style.html

осилит проект практически любой сложности

[Игорь Ермаков]

Прочитал, познавательно. Что есть еще?

[panig]

Мне тоже интересно

Многостраничными занимался, несколько правил отметил, небольших.

Картинки можно называть почти также как и классы (тоесть сокращать там) но дописывать -bg, -img, -icon… В последнее время не стал так делать, кроме -bg и -icon.

У каждого отдельного блока нужен класс, а внутри него тоже всем элементам давать классы, только содержащие класс родителя.

Тоесть не comment(родитель) и avatar(внутренний), а comment и comment-avatar.

Для li например, почти не делаю. Просто бывает где-нибудь совпадет, а css не маленький, искать долго (:

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

Кажется это все стандартное, но я бы тоже хотел советы послушать.

На счет

Посмотри тут: http://vitaly.harisov.name/article/independent-blocks.html

и тут: http://vitaly.harisov.name/css-code-style.html

пробовал и таким способом, но лично мне не очень удобно, особенно с h- (я про названия)

а последовательность свойств в css, тоже вроде везде должно быть)

[npofopr]

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

а вообще надо верстать и верстать и тогда выработается своя схема.

и на других особо смотреть не надо я считаю.

обычно верстают как для себя удобно и обычно это становится со временем удобным и всем.

думаю все делят css'ку на основные блоки. а уж последовательность самих стилей не критична.

и тем более в алфавитном порядке расстановка стилей совсем считаю не к чему.

еще частично верстка зависит от той системы управления к которой затем подключится ваш html (html -> php)

если у вас уже есть свой global.css, то наверно у вас уже есть своя структура.

[Great Rash]

klierik, отличные статьи, спасибо!

Именно к этому и стремлюсь когда верстаю. Правда сильно время работы увеличивает, поэтому если времени на верстку мало отведено, то этого идеала не удается достичь.

Зато потом если менять структуру страницы время экономится в разы! Жаль начальство этого не понимает.

Игорь Ермаков

Ну я к примеру создаю специальные вспомогательные классы, которые стоят у меня в самом низу .css, они примерно такие:

/* Helpers */
.fl {float: left;}
.fr {float: right;}
.text-center {text-align: center;}
.text-right {text-align: right;}
.overflow {
	overflow: hidden;
	//zoom: 1; /* это правило выношу через кандишнл камментс */
}
/* end Helpers */

Это позволяет зафлоатить некоторые блоки если надо, не изменяя общий класс, или порулить расположением текста.

[klierik]

2Great Rash,

на базе указанных статей вырисовал свою методику написания разметки и стилей.

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

внести изменения в рамках сугубо этих страниц, а тем более элементов, не имеет никакой сложности

а что касается:

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

не совсем понимаю из-за чего

[Great Rash]

не совсем понимаю из-за чего

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

[s0rr0w]

Хах.. тема такая, что за несколько статей не расскажешь.

Большие проекты верстаются следующим образом.

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

2. Составляем логику построения CSS и HTML-кода.

Если в одном месте можно описать дизайн, например двумя блоками

<div class="someBlock">
 <div class="someBox">
  Some content
 </div>
</div>

а во втором достаточно одного

<div class="otherBlock">
 Other content
</div>

То все равно лучше добавлять еще одну пустую структуру, чтобы была идентичность кода.

<div class="otherBlock">
 <div class="otherBox">
  Other content
 </div>
</div>

Как видно, я использую логическую вложенность block>box и повторяю ее.

Если в блоке несколько боксов, так и делаем

<div class="otherBlock">
 <div class="otherBox">
  Other content1
 </div>
 <div class="otherBox">
  Other content2
 </div>
</div>

Если у блока есть заголовок, то лучше перенести логику внутрь бокса, разделив все на уровни

<div class="myBlock">
 <div class="myBox">
   <h4 class="myBoxHeader">
     My box header
   </h4>
   <div class="myBoxContent">
     My box content
   </div>
 </div>
</div>

Такую структуру легко понимать, легко программировать, легко описывать в CSS

Далее, модификаторы. Лучше 5 модификаторов, чем 5 различных видов блоков.

<div class="myBlock newsBlock">
   <div class="myBox">
     <ul class="myList newsList">
       <li>News Item</li>
     </ul>
   </div>
 </div>

Если убрать модификатор newsList, а надеяться только на newsBlock, то в итоге можно напороться на проблемы со специфичностью и тоннами непонятного CSS

А так у нас есть конкретный список, конкретный модификатор списка, и если этот список куда-то перенести, то он останется все тем же списком.

Есть еще одна тактика, которая тоже дает выигрыш. Это тактика первого использования. Например, у вас есть список новостей. Но очень похожий список - список статей. Можно делать список новостей базовым, а список статей - модификатором. Что это дает? Это дает точное указание, откуда растут ноги у списка статей, и что он основывается на списке новостей, но только с видоизменениями. И если меняется базис (список новостей), то всегда понятно, какой блок нужно проверить дополнительно, чтобы не поломать ничего. Этот вариант проще всего выискивать при помощи того же grep.

Модификаторы лучше всего делать уникальными. Если у вас красным цветом выделяется важная новость, сообщение об ошибке или еще что-то, то лучше всего сделать три, пять, десять модификаторов, чтобы потом не думать, почему у вас на сообщении об ошибке стоит class="important", а не class="error". Это все очень сильно сбивает с толку при модификации кода, особенно через месяца три после сдачи.

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

4. Не бояться длинных и понятных имен классов.

Пока, думаю, хватит.