EN
Виталя Харисов
Виталя Харисов
15 апреля 2009
Read-only

«Много маленьких файлов лучше, чем мало больших» © Сергей Бережной

Блоки в отдельной директории

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

Каждому блоку по директории

Под каждый блок создаём директорию с именем блока. Блок описывается минимум одним файлом: b-blah.css

block/
    b-round/
        b-round.css

В этом случае пример HTML-разметки приводится в комментарии в начале файла.

Пример вёрстки блока удобнее класть рядом с его стилями:

block/
    b-round/
        b-round.css
        b-round.html

Дополнительные стили

Дополнительные стили выносим в отдельные файлы

block/
    b-blah/
        b-blah.optional-styles.css

Дополнительные стили: ie

Если для блока есть исправления под MSIE7- добавляем файл b-blah.ie.css.

block/
    b-round/
        b-round.css
        b-round.ie.css

Внутри этого файла пишем стили для MSIE по следующим правилам

.b-round { … } /* Все MSIE */
* html .b-round { … } /* MSIE 6 */
[class].b-round { … } /* MSIE 7 */

Дополнительные стили: reset

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

Ситуации когда это надо

  • блок используется на проекте который написан без использования глобального reset (старый проект)
  • на проекте невозможно использовать глобальный reset из-за того, что в нем используется любой HTML, который написал пользователь (хороший пример HTML-письма, которые показываются в webmail)

Для сброса стилей в умолчальное состояние добавляем файл b-blah.reset.css (и/или b-blah.reset.ie.css в случае необходимости)

block/
    b-round/
        b-round.css
        b-round.reset.css

Альтернативно есть мысли отказаться от global reset и всегда использовать local reset. Есть подозрения (пока не проверенные), что * { margin: 0 } замедляет работу брузера. Надо делать тесты.

Вложенные элементы

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

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

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

block/
    b-popup/
        shadow/
            b-popup.shadow.css
            b-popup.shadow.ie.css

В b-popup.shadow.css пишем

/* Popup: Тень (begin) */ /**/
    .b-popup .shadow
    {
        width: 100%;
    }

    .b-popup .shadow .form
    {
        margin: -14px -7px -7px;
    }

    .b-popup .shadow .l, .b-popup .shadow .r,
    .b-popup .shadow .lt, .b-popup .shadow .rt,
    .b-popup .shadow .lb, .b-popup .shadow .rb
    {
        font: 0/0 a;

        width: 14px;
        height: 14px;

        background: url(b-popup.shadow.png);
    }

    ...
/* Popup: Тень (end) */ /**/

Обратите внимание, что на файловой системе .b-popup.shadow.css, а в файле .b-popup .shadow. Логично и удобно для запоминания.

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

Модификации классом

Модификации классом и внутри контекстного блока выносятся в отдельную директорию с именем _тип-модификации, в которой лежат файлы b-blah_модификатор.css (.ie и .reset в случае необходимости).

block/
    b-round/
        _radius/
            b-round_2.css
            b-round_3.css
            ...
        _border/
            b-round_3a3a3a.css
            b-round_3a3a3a.ie.css
            b-round_ff0000.css
            b-round_ff0000.ie.css
            ...
        b-round.css
        b-round.ie.css
        b-round.html

Блоку можно задавать только один модификатор определённого типа. Почему? Мы используем xml-описание блока, где модификаторы указываются атрибутами, а двух атрибутов с одним именем быть не может.

<yacf:b-roundyacf:radius="2"yacf:border="ff0000"></yacf:b-round>

Об xml-описании блоков в другой раз.

Модификации внутри конкретного блока

Модификации внутри конкретного блока делаются по аналогии с вложенными элементами. Создаём папку модифицируемого блока внутри папки родительского блока.

block/
    b-dropdown/
        b-pseudo-link/
            b-dropdown.b-pseudo-link.css

Сводим всё вместе на примере

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

Поиск Яндекса

У него есть основные стили, которые используются во всех поисковых шапках

block/
    b-head-search/
        b-head-search.css
        b-head-search.ie.css

Есть модификация с двумя полями ввода

block/
    b-head-search/
        _type/
            b-head-search_double.css

Маршруты на Картах

И есть опциональная разметка, например, ссылка на расширенный поиск:

block/
    b-head-search/
        advanced/
            b-head-search.advanced.css

На Картинках есть, на Маркете нет.

или пример:

block/
    b-head-search/
        sample/
            b-head-search.sample.css
            b-head-search.sample.ie.css
            b-head-search.sample.reset.css

На Маркете есть, на Поиске нет.

Неудобно создавать все эти файлы и директории!

Неудобно, но мы работаем над этим. Хотим в IDEA добавить поддержку создания блока, элементов и модификаторов. А так же (sic! sic!) переименования блока (вот это реальная проблема, если делать это руками надо переименовать кучу файлов в случае развесистого блока).

#veged
15 апреля 2009
Блоку можно задавать только один модификатор определённого типа. Почему? Мы используем xml-описание блока, где модификаторы указываются атрибутами, а двух атрибутов с одним именем быть не может.
лучше уж сказать просто "для простоты" -- а то выглядит так, как будто это в xml-е никак не выразить
#veged
15 апреля 2009
последний абзац -- очередной повод задуматься над другими исходниками
#yvelious
25 мая 2009
Немного не понял про структуру на файловой системе. Если Вы делаете куча папок и блоков в которых лежат отдельные сss, и к примеру в каком то классе будет свойство к которому прописисывается бэкграунд. то получается примерно такие пути ../../i/pic.png или ../../../i/pic.png взависимости от вложенности папки с css. И после того когда в основном сss иморты заменяются на сам сss, то пути такие ../../../i/pic.png уже не будут работать. Получается что программа, которая собирает все стили сss в основной сss должна еще менять и пути в таких свойствах как background: url (...) ???