CSS GuideLines, часть 1. Синтаксис и форматирование

Original author: Harry Roberts
  • Translation
  • Tutorial


Введение


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

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

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

Важность руководства по оформлению кода

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

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

Хорошее руководство по оформлению кода позволит добиться следующего:
  • Установление стандарта качества кода для всех исходников;
  • Обеспечение согласованности между исходниками;
  • Следование стандартам всеми разработчиками;
  • Увеличение продуктивности.

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

Дисклеймер

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

Синтаксис и форматирование


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

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

В идеале разработчики должны использовать:
  • 4 пробела для отступов. Именно пробелы, а не таб;
  • Строки не длиннее 80 символов;
  • Мультистрочный CSS;
  • Эффективное использование пустого пространства.

Давайте последовательно рассмотрим правила, относящиеся к форматированию кода.

Разбиение на несколько файлов

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

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

Таблица содержимого

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

Например, самый простой вариант оглавления — добавить название раздела и его описание:

/**
 * CONTENTS
 *
 * SETTINGS
 * Global...............Globally-available variables and config.
 *
 * TOOLS
 * Mixins...............Useful mixins.
 *
 * GENERIC
 * Normalize.css........A level playing field.
 * Box-sizing...........Better default `box-sizing`.
 *
 * BASE
 * Headings.............H1–H6 styles.
 *
 * OBJECTS
 * Wrappers.............Wrapping and constraining elements.
 *
 * COMPONENTS
 * Page-head............The main page header.
 * Page-foot............The main page footer.
 * Buttons..............Button elements.
 *
 * TRUMPS
 * Text.................Text helpers.
 */

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

Ширина строки в 80 символов

По возможности желательно ограничивать строки в CSS-файлах 80 символами. Причины делать так:
  • Возможность держать перед собой сразу несколько открытых файлов, размещенных друг возле друга;
  • Возможность просматривать CSS на таких сайтах, как Github, или в окне терминала;
  • Обеспечение комфортной длины строки для добавления комментариев.

/**
 * Я — очень длинный комментарий. Я детально описываю CSS-код подо мной. Я
 * настолько длинный комментарий, что я превышаю лимит в 80 символов, 
 * поэтому я разбит на несколько строк.
 */

Следует отметить, что есть и исключения для этого правила — например, строки с длинными URL-адресами.

Именование секций кода

Каждый крупная секция CSS-кода должна начинаться так:

/*------------------------------------*\
    #SECTION-TITLE
\*------------------------------------*/

.selector {}

Добавление символа "#" в начале названия секции позволит нам выполнять поиск по файлу намного быстрее. Есть вероятность того, что запрос «SECTION TITLE» вернет много результатов, в то время как запрос с решеткой в начале вернет нам только один нужный результат. Также стоит оставлять пустую строку между названием секции и первым селектором.

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

/*------------------------------------*\
    #A-SECTION
\*------------------------------------*/

.selector {}





/*------------------------------------*\
    #ANOTHER-SECTION
\*------------------------------------*/

/**
 * Comment
 */

.another-selector {}


Анатомия CSS-правил

Прежде чем поговорить о том, как разработчикам следует писать CSS-правила, давайте уточним используемую терминологию:

[селектор] {
    [свойство]: [значение];
    [<--объявление--->]
}

Например:

.foo, .foo--bar,
.baz {
    display: block;
    background-color: green;
    color: red;
}

В этом куске кода вы можете видеть:
  • Связанные селекторы на одной строке, несвязанные селекторы на разных строках;
  • Пробел перед открывающей скобкой ({);
  • Свойства и их значения на одной строке;
  • Пробел после двоеточия, относящегося к свойству;
  • Каждое объявление свойства и его значения на новой строке;
  • Открывающая скобка находится на той же строке, что и последний селектор;
  • Первое объявление свойства находится на новой строке после открывающей скобки;
  • Закрывающая скобка находится на отдельной строке:
  • Каждое объявление имеет отступ в 4 пробела;
  • Точка с запятой находится сразу после значения свойства, без пробела.

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

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

.foo, .foo--bar, .baz
{
	display:block;
	background-color:green;
	color:red }

Проблемы из этого примера:
  • Табы вместо пробелов;
  • Несвязанные селекторы на одной строке;
  • Открывающая скобка на отдельной строке;
  • Закрывающая скобка на той же строке, что и последнее объявление;
  • Точка с запятой (кстати говоря, необязательная именно в последнем объявлении) в конце последнего объявления не стоит;
  • Нет пробелов после двоеточий.

Мультистрочный CSS

CSS-код всегда должен писаться в несколько строк, за исключением очень специфичных обстоятельств. Преимущества:
  • Снижение риска появления конфликтов при слиянии объявлений за счет того, что каждое объявление находится на отдельной строке;
  • Более надежные и читаемые diff'ы, потому что одна строка несет только одно изменение.

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

.icon {
    display: inline-block;
    width:  16px;
    height: 16px;
    background-image: url(/img/sprite.svg);
}

.icon--home     { background-position:   0     0  ; }
.icon--person   { background-position: -16px   0  ; }
.icon--files    { background-position:   0   -16px; }
.icon--settings { background-position: -16px -16px; }

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

Отступы

Так же, как вы делаете отступы для объявлений, делайте и отступы у связанных наборов правил:

.foo {}

    .foo__bar {}

        .foo__baz {}

Благодаря этому разработчик сразу увидит, что .foo__baz располагается внутри .foo__bar, который, в свою очередь, находится внутри .foo. Такой способ имитации DOM многое рассказывает разработчикам о том, где класс располагается, благодаря чему не приходится каждый раз открывать разметку и искать нужный кусок кода.

Отступы в Sass

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

.foo {
    color: red;

    .bar {
        color: blue;
    }

}

… мы получим следующий скомпилированный CSS:

.foo { color: red; }
.foo .bar { color: blue; }

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

Выравнивание

По возможности, выравнивайте схожие строки со свойствами:

.foo {
    -webkit-border-radius: 3px;
       -moz-border-radius: 3px;
            border-radius: 3px;
}

.bar {
    position: absolute;
    top:    0;
    right:  0;
    bottom: 0;
    left:   0;
    margin-right: -10px;
    margin-left:  -10px;
    padding-right: 10px;
    padding-left:  10px;
}

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

Разумное использование пустого пространства

Так же, как и при использовании отступов, мы можем дать разработчику много информации, правильно используя пустое пространство между правилами.
Используйте:
  • Одну пустую строку между связанными наборами правил;
  • Две пустые строки между несвязанными наборами правил;
  • Пять пустых строк между секциями.

Пример:

/*------------------------------------*\
    #FOO
\*------------------------------------*/

.foo {}

    .foo__bar {}


.foo--baz {}





/*------------------------------------*\
    #BAR
\*------------------------------------*/

.bar {}

    .bar__baz {}

    .bar__foo {}

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

.foo {}
    .foo__bar {}
.foo--baz {}

HTML

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

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

Этот код будет работать:

<div class=box>

Но предпочтительно использовать такой код:

<div class="box">

При записи нескольких значений в атрибут, разделяйте эти значения двумя пробелами:

<div class="foo  bar">

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

<div class="[ box  box--highlight ]  [ bio  bio--long ]">

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

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

<header class="page-head">
    ...
</header>





<main class="page-content">
    ...
</main>





<footer class="page-foot">
    ...
</footer>

Разделяйте независимые, но близко связанные части разметки одной пустой строкой:

<ul class="primary-nav">

    <li class="primary-nav__item">
        <a href="/" class="primary-nav__link">Home</a>
    </li>

    <li class="primary-nav__item  primary-nav__trigger">
        <a href="/about" class="primary-nav__link">About</a>

        <ul class="primary-nav__sub-nav">
            <li><a href="/about/products">Products</a></li>
            <li><a href="/about/company">Company</a></li>
        </ul>

    </li>

    <li class="primary-nav__item">
        <a href="/contact" class="primary-nav__link">Contact</a>
    </li>

</ul>

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

Материалы для дополнительного изучения



Продолжение: CSS GuideLines, часть 2. Комментирование кода

Only registered users can participate in poll. Log in, please.

Интересен ли вам перевод следующих частей?

Share post

Comments 36

    +15
    Холивар Табы vs Пробелы объявляется открытым! :D
      +2
      Было бы интересно увидеть аргументы для табов и пробелов.

      Аргументы в пользу табов:
      — по ним удобнее перемещаться, чем по каждому пробелу, хотя в современных IDE для пробелов такое тоже поддерживается;
      — фактически в любой IDE настраивается размер под себя (мне привычен 4), но при этом символ всего 1;
      — если код не минифицируется, то он будет весить меньше, по сравнению с пробелами.

      Если код встраивается в качестве примера (например, в блогах), то лучше было бы задать свойство tab-size.
        –2
        если код не минифицируется, то он будет весить меньше, по сравнению с пробелами.

        O RLY?
        У меня с приятелем был такой холивар как-то, закончилось тем, что он побежал в phpstorm менять \r\n на \n, тк ничего лучше аргумента о весе исходника он не нашел.
        Единственный аргумент в пользу табов — размер отступов. Но на него есть отличный контр-аргумент — то что у Васи на 80 символов, у Пети — на 120.
        Пробелы же дают возможность выравнивать код ровно так, как будет удобно его читать, и код будет читаться в любом редакторе одинаково. А норм редакторы, как вы выше заметили позволяют по пробелам перемещаться также легко, как по табам.
          0
          Сам использую очень давно пробелы, но время от времени вижу много исходников, где вместо таба (4 пробела) используется 2 а то и 1 пробел (github к примеру рекомендует в css использовать 2 пробела). Такой код очень сложно читать. А если бы использовались табы, то пользователь не заметил бы этого даже. А так приходится мучатся. И в итоге в проекте часть файлов использует 2 пробела, часть файлов 4, и часть 8 (встречал и такое часто).
            +2
            Кто-то еще спорит об этом? Разве есть разница объективная между этими двумя подходами? Договорились один раз вначале (проголосовали, взяли готовый гайдлайн, лидер зафорсил) и все. Че тут разводить холиворы?
              +1
              Ну вот пример. Я использую табы шириной 4 пробела, коллега — 2 пробела. В результате после моих правок отступы ему кажутся слишком большими (и тут он может в настройках саблайма поменять ширину таба на комфортные ему 2 пробела), а вот после его правок для меня всё слипшееся и его 2 пробела я никак на 4 не растяну. Приходится подстраиваться под коллегу. А юзали бы табы — каждый настроил любимую ширину и видел бы то, что хотел
                0
                Все эти «кажутся слишком большими» надуманны. В реальности разницы нету, дело привычки. Если бы табы были однозначно лучше пробелов, никто бы не спорил.
                  0
                  Ну и вы описываете ситуацию, когда на проекте один человек юзает табы, а другой пробелы. Это ИМХО нездорово, конечно. Надо уже как-то определиться с единым стилем отсупов и следовать ему. Другое дело, что какой это будет стиль — не важно.
                    0
                    Можно абстрагироваться от данного примера: ситуация когда все используют табы разной ширины в пробелах комфортнее (ввиду настраиваемости этой ширины в современных редакторах), чем ситуация, когда все используют отступ с разным количеством пробелов.
                      0
                      Вам комфортнее, кому-то нет. Как вы можете навязывать табы всем прям вообще? Не каждый редактор умеет правильно делать SmartTabs.
          +7
          Да понятно, что тут только вопрос договорённости и стиля кодирования. До чего договорились, то и используем.

          Лично для себя закрыл этот вопрос в пользу табов.
          Главное преимущество таба для отступов в том, что он семантичен: он предназначен для отступов, в отличие от пробела.
          Думаю, большинство разумных людей раздражают абзацные отступы в Ворде, сделанные по нерадивости пробелами, а не абзацными отступами. А практически то же самое в своём коде, никого почему-то не раздражает :-)

          Разумеется, если вы решили использовать табуляцию, то нужны именно смарт-табы.
          0
          Почти во всех примерах свойства элемента идут не в алфавитном порядке. Это не правильно. Куда удобнее искать нужное свойство по алфавиту.

          Хотя я и сам пренебрегаю данным правилом, но для Style Guide это недопустимо.
            +2
            Куда правильней сортировать и группировать по значению свойств
              +1
              В алфавитном порядке с вендорскими префиксами будет не очень удобно.
              Гораздно удобнее группировать по их назначению.
              Например, вот так
              .declaration-order {
                  /* Позиционирование */
                  position: absolute;
                  z-index: 100;
                  top: 0;
                  right: 0;
                  left: 0;
                  bottom: 0;
              
                  /* Отступы */
                  margin-top: 20px;
                  margin-left: auto;
                  margin-right: auto;
                  padding: 8px 16px;
              
                  /* Блочная модель */
                  display: block;
                  float: left;
                  width: 100px;
                  height: 100px;
              
                  /* Типографика */
                  font-family: 'Helvetica Neue', sans-serif
                  font-size: 14px;
                  line-height: 24px;
                  text-align: center;
              
                  /* Оформление */
                  color: #333;
                  background-color: #f5f5f5;
                  border: 1px solid #e5e5e5;
                  border-radius: 3px;
                  opacity: 1;
              
                  /* Прочее */
                  transition: .25s ease-out;
                  transform: scale(.75);
              }
              

                0
                Сколько времени у вас уйдет на поиск того или иного свойства?
                А где находится text-decoration?
                А background-position это Оформление или Позиционирование?

                Ну а в целом я согласен и на такое, но и такого нет в статье.

                Префиксы я отделяю и пишу либо в начале описания элемента, либо в конце.
                Также их можно и в том месте, где безпрефиксная запись.
                  0
                  Время на поиск свойства практически не затрачивается, если ты уже привык писать в таком порядке.
                  В том примере лишь малая часть свойств, все свойства описывать здесь нет смысла.
                  Большинство разработчиков, работая в командах, придерживаются их внутреннему стандарту, в котором задекларирован порядок этих свойств, и все пишут как один.
                  Кстати, для причесона порядка свойств можно использовать CSScomb, у него же есть и заготовки, которые можно использовать как есть или же подогнать под себя.
                    0
                    практически не затрачивается, если ты уже привык писать в таком порядке.
                    А если не привык, то по алфавиту будет любому удобно искать, достаточно ему понять, что всё отсортировано в алфавитном порядке.

                    Кстати, для причесона порядка свойств можно использовать CSScomb, у него же есть и заготовки
                    Да-да-да, равно как и табов с пробелами, так и скобочек и многого другого.
                0
                нуу не скажите… я например за годы для себя выработал схему (очень удобно разбивать по логике блоки стилей):

                .foo {
                    width
                    height
                    line-height
                    background
                
                    display
                    border
                    margin
                    padding
                
                    position
                    top, left, right, bottom
                
                    text-transform
                    text-decoration
                    color
                    font
                    ...
                }
                
                  0
                  Кто-то любит пробелы, а кто-то табы. Это из той же оперы.
                  Даже тут, сделанное мной замечание, которое казалось бы является нормой — вызывает холивар.
                  Я думал Style Guide пишутся чтобы избежать холиваров и прийти к единому мнению.
                  Но видимо это особенный случай.

                  Процитирую статью
                  Руководства по оформлению кода должны осваиваться и применяться всеми разработчиками, а любые отклонения от правил должны быть обоснованы.

                  На данный момент Вы и пару комментаторов выше привели самый весомый аргумент «я (мне) так удобнее», что и не поспоришь.

                  Давайте так поступим. Я предлагаю вам двоим (с GC92) сначала прийти к единому мнению (какие блоки будут, что к чему относится), а потом продолжим разговор.

                  PS А на каком этапе надо применять блочный вариант? Вот так вот выглядит глупо и не удобно читать будет простыню из подобного
                  .foo {
                      width
                   
                      border
                   
                      font
                  }

                  А если добавить сюда ещё и комментарии, как в примере GC92…
                    0
                    Не заметил сначала его «простыни») ну там все логично и понятно, а вы предлагаете стили писать в строчку (для сохранности места)? =/

                    ЗЫ я против всяких холиваров, просто среагрировал на ваше:
                    Куда удобнее искать нужное свойство по алфавиту.

                    ЗЗЫ я всегда за импрувинг скиллов) так что если кто-то предложит какой-то интересный вариант, почему бы не использовать его…
                    ЗЗЗЫ к таким дичайшим гайдлайнам как в статье я всегда скептически относился — местами там жуткие примеры
                      0
                      Не заметил сначала его «простыни») ну там все логично и понятно, а вы предлагаете стили писать в строчку (для сохранности места)? =/
                      Зачем так сильно передергивать? Вы предложили разбивать на блоки и разбивать отбивками (пустыми строками). А если там всего два-три свойства из разных блоков? Я предлагаю без отбивок и в алфавитном порядке (сам я лично отбиваю только вендорные свойства, делаю блоком). И даже если человек работал всегда с блоками, то ему надо будет 10 секунд (ну может побольше, если процессор слабенький (я про мозг если что)) на то, чтобы понять, перестроится, адаптироваться. А учитывая что многие препроцессоры, файрбаги и IDE именно так строят код… именно поэтому я и сказал, что это должно быть нормой и должно упоминаться в Style Guide.

                      .foo {
                          border
                          font
                          width
                      }

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

                      Отдельный разработчик, если ему угодно, может и на блоки разбить и делать всё «назло» Style Guide. Но статья то не про «мне так удобно, мне так нравится».

                      Я например, ради эксперимента, как-то пробовал писать колонками:
                      Скрин, код не форматируется тут нормально
                      image

                      Это замечательное извращение и кому-то может понравится (мне не понравилось).
                      Особенно если разбить на колонки по блокам. У кого широкоформатный монитор и пару сотен символов умещается — это вообще красота будет — колонка позиционирования, колонка типографики и т.д. Ведь удобно, когда знаешь заранее в какой колонке искать. :D
                +1
                Таблица содержимого

                Зачем? Современные IDE имеют отличный поиск, переход к селектору прямо из html, плагины позволяют прямо из браузера это делать.
                Именование секций кода

                Секции — в отдельные файлы.
                .foo {
                    -webkit-border-radius: 3px;
                       -moz-border-radius: 3px;
                            border-radius: 3px;
                }

                Такое вообще выкинуть из своего кода вместе с миксинами для префиксов, подрубить autoprefixer и перестать об этом задумываться.
                  +1
                  Вы видимо не очень внимательно читали статью. В ней сказано, что таблица содержимого предназначена не для поиска каких-то кусков кода, а для того, чтобы разработчик мог ознакомиться со структурой файла / файлов и с предназначением отдельных разделов.
                  По поводу именования секций, в статье, опять же, сказано, что не всегда имеется возможность разбивать код на файлы. А если и есть такая возможность, то все равно название секции желательно добавить в начале файла.
                  По поводу префиксов согласен, стоит использовать автопрефиксер, но этот кусок кода был дан для того, чтобы показать, как можно расставлять отступы.
                    +2
                    Скажите, вы из тех людей, кто для конструктора в классе пишет комментарий «Constructor.»?
                    Если секция называется «ANOTHER-SECTION», почему бы файл не назвать another-section.css и не городить капитанства?
                    Ровно как и структура файлов — она очевидна как только ее видишь, если код разбит на, как вы называете, секции. github.com/twbs/bootstrap/tree/master/less — над проектом почти 600 контрибьюторов трудились, никакого оглавления там нет.
                    А можно конкретные причины невозможности использовать разбиение на файлы? Я представляю себе только демку в jsfiddle, или аналогах.
                    По поводу префиксов — по моему вообще надо о них забыть и не использовать ни в каких примерах.
                • UFO just landed and posted this here
                    0
                    Может уже все гайды как то систематизировать и пронумеровать, чтобы не было бесполезных войн тупоконечников с остроконечниками?
                      +2
                      Удивлен, что проблема еще существует. У меня пока глаза на месте и я могу читать любой css от любого извращенца и мне все будет понятно. Зачем создавать человеку правила? Пускай пишет как ему угодно. А если вы сами очень чувствительны в восприятии чужого кода, то для этого есть множество инструментов, которые перебьют табы на пробелы и обратно, отсортируют все хоть в алфавитном порядке наоборот и вообще как угодно.
                        +1
                        Все идет по нарастающей. Простое усложняется.
                        Я удивлен, что еще нет паттернов проектирования для ксс. Хотя подождите. БЭМ вполне подходит.
                        0
                        Пишу в один ряд
                          0
                          Спасибо за статью.
                            +1
                            По-моему, некоторые правила плохие. Например, отступы в «логически связанных» свойствах или выравнивание цифр, лошадиные комментарии и, конечно, оглавление.
                              0
                              По мне так, комментарии в css нужны только в ОЧЕНЬ специфических местах, где не очевидно что вообще происходит. CSS же декларативный. А то начинается
                              width: 200px /* это высота */
                              ... /* это стул на нем сидят; это стол, за ним едят */
                              
                                0
                                Ну, иногда всё же они бывают полезными. Блок можно подписать.
                                Не всегда на больших проектах получается придумывать разнообразные хорошие названия.
                                Иногда, скажем, в коммент можно запихнуть zen-coding-разметку
                                  0
                                  В следующей части как раз сказано о том, что не стоит комментировать очевидные вещи, и в целом рассказано о том, что и как комментировать.
                                –2
                                Расскажите кто-нибудь автору про BEM и CSScomb.

                              Only users with full accounts can post comments. Log in, please.