Преимущества многострочного CSS

Вячеслав Олиянчук 13 декабря 2010

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

Для начала определимся в терминологии. В CSS-коде у нас есть: блок правил — селектор и список правил для него; каждое правило состоит из свойства и его значения.

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

	.example { position:absolute; top:10px; display:block; width:10px; height:10px; background:url(icon.png) no-repeat }

Многострочное форматирование, каждая пара свойство:значение на новой строке:

	.example {
	    position:absolute;
	    top:10px;
	    display:block;
	    width:10px;
	    height:10px;
	    background:url(icon.png) no-repeat;
	    }

Однострочный способ хорош в «наборах», «батареях» селекторов с одинаковыми свойствами. Например, там, где одно свойство принимает разные значения:

	.tag-cloud .xs    { font-size:0.5em }
	.tag-cloud .s     { font-size:0.75em }
	.tag-cloud .m     { font-size:1em }
	.tag-cloud .l     { font-size:1.25em }
	.tag-cloud .xl    { font-size:1.5em }
	.tag-cloud .xxl   { font-size:1.75em }

Многострочный: перфекционистский, безопасный, наглядный. Давайте разберем по порядку все его преимущества.

Анализ

Работа с кодом — это операции написания, поиска и редактирования текста. Чтобы работать результативно, нужно преследовать две цели:

Цель №1: минимизация шанса на ошибку

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

Цель №2: скорость восприятия свойств

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

Разве вам нужно следить за огромным количеством строк одновременно? Посмотрите, например, как думает программист, пишущий новую функцию. Его внимание сосредоточено только на этой функции. Так и у верстальщика — работа идет одновременно только с одним селектором. Столбик — самая наглядная запись. Он является потомком примитивного списка в столбик. Вы же не будете отрицать, что вытянутые в строку элементы списка теряют в доступности?

Например, довольно трудно найти отдельный элемент этого списка:

	Я полюбил { Машеньку:болтушку; Юшечку:тихоню; Лизоньку:умницу; Алиночку:скромницу }

Гораздо проще найти нужный нам пункт в таком виде:

	Я полюбил {
	    Машеньку:болтушку;
	    Юшечку:тихоню;
	    Лизоньку:умницу;
	    Алиночку:скромницу
	    }

Не нужно думать, что HTML-верстка это нечто обособленное в плане написания кода. Обратите внимание на практики, которые используют программисты, пишущие на JavaScript, PHP или Perl. Пара свойство:значение в CSS — это объявление той же переменной, только с ограниченным вариантом значений.

Пример JavaScript-кода:

	function example() {
	    var position = 'absolute', display = 'block', width = 10, height = 10, background = 'icon.png';
	
	}

То же самое, но в традиционном для JavaScript стиле форматирования:

	function example() {
	    var position = 'absolute',
	        display = 'block',
	        width = 10,
	        height = 10,
	        background = 'icon.png';
	
	}

Теперь давайте вернёмся и еще раз перечитаем как сформулирована цель №2: ключевое слово «свойства». Нам не так часто приходится править селектор или расположение блоков с селекторами, но очень часто приходится править набор правил, иметь ввиду значение свойств, следить, какие уже объявлены, а каких еще нет. Именно поэтому важно сконцентрировать свое внимание на наборе правил.

Автоматизация

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

Среди автоматических способов решения проблем первым стоит упомянуть построчную валидацию CSS-свойств в рамках селектора. Пусть машина помогает вам находить опечатки и проблемные фрагменты кода:

При многострочном форматировании сложнее пропустить:

  • переопределение одного правила другим и уже объявленное правило;
  • пропущенную ; в последовательности правил;
  • незаметные опечатки, вроде height и heigth;
  • хаки.

Визуализация цветов

У каждой строки с использованием цветового кода мой редактор визуализирует цвет. Это нагляднее. Привлекает внимание быстрее. Еще один способ быстро найти нужное.

Порядок свойств, селекторов, решений

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

Я рекомендую разбить ваш CSS на три части. Это может быть как в прямом смысле разделение по файлам, так и просто мысленное принятие этого правила. Первая часть — это сброс умолчаний, так называемый reset.css, вторая — правила для HTML-тегов, третья — объявления классов и уникальных идентификаторов. Любой из этих частей может и не быть, но так можно организовать порядок на верхнем уровне. В каждой из этих частей всё тоже можно организовать: теги сгруппировать по функциональному признаку, классы и идентификаторы по решениям.

После того, как сделано всё вышесказанное, возникает вопрос: как организовать свойства в рамках одного селектора — по алфавиту, по длине записи, по частоте использования? Эти методы не годятся потому, что организация, навязываемая ими, не отвечает нашим целям. Вот, например, всё отсортировано по алфавиту, и чтобы увидеть какой z-index у абсолютно позиционированного блока, нужно выискивать его вдалеке от position:absolute, а свойство left совершенно неочевидно будет соседствовать с letter-spacing.

Наиболее правильный метод — это функциональная группировка. Например: позиционирование, поведение блока, размеры, цвета и т.д. Один из наиболее продуманных вариантов сортировки есть в документации к проекту Zen Сoding.

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

Дополнительное окно

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

Сравнение содержимого построчно

Вы можете писать однострочный CSS, но вполне вероятно что вы вырастете до работы над большими проектами с множеством файлов и большим объемом CSS. Вам придётся работать с системой контроля версий, построением проекта и другими разработчиками в вашей команде. Обратите внимание на то, что разница между двумя файлами вычисляется именно построчно, и при однострочной записи вам будет труднее выявить различия, так как строка будет различаться сразу несколькими свойствами:

Доступ по селектору через поиск

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

Доступ к свойству конкретного селектора по номеру строки

Номер строки можно найти так: проинспектировать нужный блок в верстке с помощью Firebug, Web Inspector или Dragonfly, затем найти нужный селектор, который срабатывает для данного блока и подсмотреть номер строки и имя файла. Далее дело техники и знания горячих клавиш вашего любимого редактора. Объем CSS-кода и его растянутость (излишняя, как считают некоторые) не имеет никакого значения в этом случае.

Комментирование

При построчной записи удобнее комментировать конкретное свойство. Например напомнить, что оно переопределено в файле ie6.css. Или указать, что эта ширина может меняться в зависимости от наличия другого класса.

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

При должной сноровке и знании горячих клавиш вашего любимого редактора закомментировать одно свойство на одной строке — легко. Комментарий /* … */ автоматически обхватит свойство в многострочной записи. В однострочной записи вам недоступна такая роскошь. А я комментирую, ломая имя свойства иксиком или другим символом — детский сад, и к тому же небезопасно для обработки браузером дальнейшего кода. Не стоит испытывать на прочность CSS-парсеры.

А у меня CSS меньше и быстрее

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

Версия в разработке и версия в бою — разные вещи. Версия для разработки должна быть максимально заточена под нужды разработчика и способствовать минимизации шансов на ошибку или опечатку из-за невнимательности. Для боевой версии актуальны совсем другие вещи: количество запросов к серверу, объем кода, актуальность загрузки всего кода сразу либо по частям, обфускация.

В итоге

Рекомендую пересилить себя и в целях повышения продуктивности, как личной, так и вашего проекта в целом, задуматься: почему вы пишете именно так? Может дело в простой привычке? Если вы преследуете цель №1 и цель №2, то настоятельно рекомендую переходить на многострочный стиль.

Дополнительное чтение

Теги: , ,

Комментарии +

  1. Андрей Ситник 13 декабря 2010 в 12:10

    А зачем пробелы после : убирать? Вообще, пробелы и другие лишние символы должен убирать asset-менеджер, например Jammit http://documentcloud.github.com/jammit/

  2. extempl 13 декабря 2010 в 12:18

    Честно говоря, в течении чтения статьи пару раз сложилось впечатление, что вы рекламируете свою любимую ide, поскольку есть моменты недоступные в иных средах программирования (ничего, я тоже люблю именно эту ide, но это стоило бы писать в обзоре оной) и несколько раз терял связь между текстом и заголовком. Было бы неплохо, если вы систематизируете, порой, бессвязные и непоследовательные мысли.
    P.S.Только здравая критика, не более.

  3. Вячеслав Олиянчук 13 декабря 2010 в 12:24

    Андрей, я пробелы не убираю. Я их просто не пишу.

  4. Вячеслав Олиянчук 13 декабря 2010 в 12:34

    extempl, что именно кажется бессвязным?

    То, что я рассказываю о редакторе кода, в котором работаю? Я хочу показать почему он мне помогает.

    Про поиск и дополнительное окно? Так это методы, которые обезоруживают сторонников однострочного CSS. Я часто слышу, что им хочется видеть как можно больше кода сразу и как результат все вытягивается в строку.

    Все части этой статьи так или иначе взвешивают плюсы/минусы однострочного и многострочного подходов. Остальное — инструменты и методы.

  5. kwinchy 13 декабря 2010 в 12:44

    Организация свойств, селекторов драматическим образом поможет вам изменить понимание…

    Что за калька с английского? «Will dramatically change» можно перевести, как «очень поможет», но никак не «драматическим образом поможет».

  6. Вадим Макеев 13 декабря 2010 в 12:46

    kwinchy, вы правы — но уже поправлено :)

  7. silentimp 13 декабря 2010 в 14:37

    Мне наверное повезло, CSS в одну строку я давно уже вижу разве что на продакшене.

    P.S. "Глупые" ошибки проще отлавливать валидатором.
    P.S.P.S. Лично я противник IDE. Тяжелые, некоторые имеют наглость править мой код. Текстовые редакторы вроде notepad++,aditor,emeditor,sublime text (win) textmate (mac) намного приятнее. Все что надо (поиск и замена (многострочные, с регулярными выражениями), работа с кодировками корректная, менеджер проектов, подсветка кода) там есть. Под win советую обратить внимание на sublime text. Он платный ... но с легальным, бесконечным триалом.

  8. Вадим Макеев 13 декабря 2010 в 15:06

    silentimp, к валидатору ещё нужно не забыть сходить — а тут всё сразу в процессе разработки, не ошибёшься. Тот же TextMate какбе тоже умеет это делать, но CSS-бандл с языковым модулем настолько давно не обновлялся, что это уже почти не работает. А IDE я тоже на дух не переношу :)

  9. Ti 13 декабря 2010 в 15:15

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

  10. muhas 13 декабря 2010 в 16:00

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

     function compress($buffer) {
        /* remove comments */
        $buffer = preg_replace('!/\*[^*]*\*+([^/][^*]*\*+)*/!', '', $buffer);
        /* remove tabs, spaces, newlines, etc. */
        $buffer = str_replace(array("\r\n", "\r", "\n", "\t", '  ', '    ', '    '), '', $buffer);
        return $buffer;
      }
    
  11. fiskus 13 декабря 2010 в 16:06

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

  12. Вячеслав Олиянчук 13 декабря 2010 в 16:33

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

    А всё, что Вы описываете выглядит так, будто Вы не верстаете, а выступаете посредником между Firebug'ом и файлом-складом для CSS-кода.

  13. Ti 13 декабря 2010 в 16:48

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

  14. silentimp 13 декабря 2010 в 20:38

    Касательно менеджмента CSS — доклад Вадима Макеева, пожалуй, самое толковое. Правда определять порядок правил в рамках селектора — перебор. Если у вас такое большое количество правил для селектора, что в них теряешься без сортировки и не можешь сразу охватить взглядом ... то скорее всего вы делаете что то круто не так.

  15. Аянами 14 декабря 2010 в 1:21

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

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

  16. Panya 14 декабря 2010 в 1:25

    Ну ребят, ну вроде солидный сайт, а в статье пользуетесь неверной терминологией. То, что вы называете правилом на самом деле не правило, а декларация. Правило — это селектор и блок деклараций ({ ... }). Декларация — это пара «свойство: значение».

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

  17. demiazz 28 февраля 2011 в 15:04

    Я наверное слоу, но думал, что однострочным стилем пользуются только при "сжатии" css. Даже как то представить не мог, что это кому то может быть еще и удобно Оо

  18. Greg 17 марта 2011 в 16:08

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

  19. Вячеслав Олиянчук 17 марта 2011 в 16:31

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

  20. AndSS 2 апреля 2011 в 0:09

    это ж как надо писать что бы допустить кучу ошибок и потом для вылавливания ошибок придумать для себя оправдание в виде многострочного развернутого селектора?

    я в css коде размером эдак так 50кб делают реальных ошибок 1-3 именно ошибки. Намного главнее как тут уже заметили писать однострочно с отступами и выделениями, а ещё комментировать и выделять отдельные блоки, тогда ориентироваться в css станет раз 20 легче, а это самое главное. Но конечно если для вас самое главное не допустить ошибку то многострочный вариант лучше.

Перейти к началу