Пользователь
0,0
рейтинг
22 августа 2012 в 10:24

Разработка → Руководство по форматированию CSS перевод

По мере того как мы подводим итоги недавнего опроса по сортировке CSS свойств у нас появляется более серьезные вопросы о стиле форматирования CSS. Сортировка свойств это всего лишь один шаг на вашем пути к завершенной стратегии форматирования стилей. Название класса — это часть стратегии. Распределение — часть стратегии. Комментарии, отступы, структура файла… все это формирует руководство по форматированию CSS.

Давайте рассмотрим существующие практики форматирования.

Но сначала… Мы не будем говорить о библиотеках.


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

Список


Я перечислю некоторые понравившиеся мне пункты ниже.

Github



Руководство по форматированию CSS от GitHub →

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

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


Google



Руководство по форматированию HTML/CSS от Google →

Задавайте имена ID и классам как можно короче, но делайте их настолько короткими пока они несут смысл.
Например, используйте #nav вместо #navigation, .author вместо .atr

В качестве символа конкатенации используйте только дефис, не используйте другие спецсимволы. Это улучшит читаемость и понимание кода.
Например, .demo-image вместо .demoimage или .demo_image


Idiomatic CSS



Руководство по идиоматическому CSS от Nicolas Gallagher →

Настройте свою IDE на отображение «скрытых символов». Это позволит вам устранить пробелы в конце строк, устранить непреднамеренный пробел в пустой строке, тем самым вы избавитесь от мусора в ваших коммитах.

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

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


CSS Wizardry



Руководство по форматированию CSS от Harry Robert →

Я полностью отказался от использования ID в CSS. Использовать их просто нет смысла плюс они часто стают причиной проблем.

В комментариях к коду, перед заголовком раздела, я всегда добавляю символ $. Так стоит делать потому, что когда я буду искать эту секцию, я найду именно её (по ключевому слову $MAIN, а не MAIN).

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


Smashing Magazine



«Улучшение читаемости кода с помощью руководства по форматированию CSS» от Vitaly Friedman →

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

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


ThinkUp



Руководство по форматированию CSS от ThinkUp →

Если значение свойства width или height равно 0, то не стоит добавлять к нему единицу измерения.

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


WordPress



Стандарты программирования на CSS от Wordpress →

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

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

Магические числа — это плохо. Они используются как быстрые фиксы на разовой основе.
Например: .box { margin-top: 37px }.


SMACSS



Масштабируемая и модульная архитектура для CSS от Jonathan Snook →

Будет трудно выдрать из этого монстра пару цитат. Но…

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

Если все сделано правильно — модули можно с легкостью перемещать в любую часть документа не поломав его.

Используйте только семантические элементы.


Больше?


А ваша организация использует публичные рекомендации по форматированию стилей? Поделитесь ими!

P.S. Если вы заметили ошибки/неточности в переводе — напишите в ЛС, поправлю.
Перевод: Chris Coyier
Виталий @vermilion1
карма
62,5
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (44)

  • +3
    Форматируется аналогично всему остальному коду. В первую очередь учитывая принцип DRY, а посему CSS отправляется на помойку, и работа ведётся с SASS+compass с максимальным использованием их возможностей.
    В каком порядке css свойства будут писаться — это уже имхо фанатизм, хотя лично я делаю всегда алфавитный, т.к. вим это умеет нажатием пары кнопок.
    • 0
      Да, я никогда не понимал подобных руководств. Как открыл для себя LESS/SASS(SCSS) — больше об этом можно не задумываться, он все делает за тебя.

      Другое дело, если речь идет о производительности, но большинство перечисленных рекомендаций этого не касаются.
      • +9
        Ну открыли вы для себя LESS/SASS и можете писать как вам хочется? Должны быть какие-то стандарты, если вы работаете в команде. И даже если вы рабатоете один, это тоже не помешает.
        • –1
          Открыл для себя = работаем с ним. Я имею ввиду прозрение. :) У нас он используется во всех проектах. Стандарты — да, но многие из перечисленных выше просто несостоятельны, когда используется что-то вроде sass/
        • –1
          Хотя та, там дальше есть пункты, которые скорее общие подходы описывают. Я имел ввиду советы, вроде:
          «Улучшение читаемости кода с помощью руководства по форматированию CSS» от Vitaly Friedman →
          Вообще не актуально для sass.
  • –7
    Использую SASS, но если нужно написать чистый CSS, то пишу все правила для одного селектора в одну линию… никогда не понимал, зачем писать каждое правило на новой строке?
    • +14
      Как по мне, запись в одну строку неудобна для чтения.
      • –5
        Часто вы правила читаете? Я куда чаще их ищу… а искать их в перебое с правилами куда сложнее.
        • +3
          А ищите, наверное, чтобы полюбоваться. Я ищу правила, чтобы что-то в них изменить или добавить. И в этом случае столбик намного удобнее. А сворачивать правила умеет любой программерский редактор.
          • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      А если нужно будет удалить правило, поменять сортировку? Гораздо проще удалить строчку или поменять пару строк местами, чем шарить курсором по длиннющей строке в поисках начало и окончания правила, да и нагляднее видеть столбик правил, чем одну строку, которая зачастую обрезается на трети длины шириной экрана.
      • 0
        И удобнее закомментировать правило, если оно на одной строке.
    • 0
      Привет, сложности навигации по ченджлогу!
  • 0
    Для LESS я как-то делал руководство: wiki.max-3000.com/pmwiki.php?n=Main.Rules-codes-less
  • +3
     .box { margin-top: 37px }
    

    Разве всегда это магические числа? Мне частенько приходят psd в которых у элемента реальный отступ не очень ровное число, думаю дизайнеры не особо уделяют внимание ровным числам.
    • –1
      Если дизайнер так ратует за пиксели, то можно воспользоваться Pixel Perfect и подгонять отступы и размеры по картинке — по-большей части отпадает работа с числами.
  • +3
    Настройте свою IDE на отображение «скрытых символов». Это позволит вам устранить пробелы в конце строк, устранить непреднамеренный пробел в пустой строке, тем самым вы избавитесь от мусора в ваших коммитах.

    Куда лучше настроить IDE на удаление лишних пробелов (например, Netbeans это умеет, думаю, многие другие тоже), тогда и цель та же достигается, и глаза эти визуализированные пробелы не мозолят.
  • –1
    Советы ни о чём.

    Нормальные советы:
    • использовать БЭМ/SMACSS
    • сортировать свойства согласно ZenCoding (т.е. по их смыслу)
    • использовать CSSDoc для комментариев
    • использовать пробелы вместо табов
    • 0
      «использовать пробелы вместо табов»
      Возвращение, старого холивара..., но всё же почему вы так считаете?
      • 0
        Да вы шутите? А потом начинается плач о том, какое наши соотечественники быдло, что в ответ на вопросы посылают в гугл.
        А табы я люблю. До слёз i.minus.com/i8vQho0FX30a0.png
        • 0
          Да, да, да я именно о тех хабра-топиках, не очень хочется к ним возвращаться, к табам, тоже не ровно дышу :), но всё же заявление комментатора, для меня, прозвучало несколько категорично вот и захотел узнать — «почему».
        • 0
          Картинка по ссылке — наглядно показывает к чему приводят табы.
      • +1
        Ну например с пробелами можно сделать так:
        .class {
            attr: value;
           -webkit-attr2: value;
                   attr2: value;
        

        Заметьте выносной дефис.
        • +1
          Да для случаев префиксов это конечно гуд, но правда less/sass нивелирует этот «способ применения».
          • –1
            Не вижу никакого смысла в less/sass. С префиксами и Zen Coding (ныне Emmet) прекрасно справляется.
            • 0
              Возможно, я к тому что набор префиксов на все случаи жизни можно скрыть (например, взять библиотеку) в «черный ящик» и тогда правиле у нас вместо «зверинца» — одно правило и никаких префиксов.
            • 0
              хелперы для кроссбраузерности css3 свойств это лишь малая часть, основные плюшки в sass или less идут от вложенных блоков стилей, миксинов и переменных
              • 0
                И зачем это всё в CSS?
                • +3
                  Зачем расширять язык, созданный почти двадцать лет назад, когда почти все веб сайты были простыми, а все их стили умещались в один маленький файл?
                  Ну, наверное потому, что он в нынешнем виде изжил себя — убог донельзя и не представляет никаких абстракций для избежания дублирования кода. По-моему очевидно.
                  • 0
                    «убог донельзя» — это просто слова, не дающие ответа на вопрос «зачем?» Есть ответ кроме «это модно»?
                    • +1
                      «не представляет никаких абстракций для избежания дублирования кода» по-вашему не является ответом на вопрос? Подробнее?
                      О том, что не круто прописывать color: #ABCDEF в двадцати файлах, а потом во всех этих файлах руками менять цвет на другой? И с цветом это лишь простейший случай.
                      А вриант «избежания» этой проблемы путём ввода десятков css классов на каждый чих и навешивание на элементы в шаблонах по 15 классов — это такой же, если не худший, говнокод, но вынесенный из стилей в шаблоны.
                      Или то, что в селекторах не рекомендуют использовать более трёх уровней вложенности, т.к. страница будет ренедериться на 1мс дольше. Только есть и другой мотив, зачастую более важный — css файлы будут просто нечитаемы при селекторах большой вложенности.

                      Могу ещё и про яндексовский БЭМ упомянуть, часть практик которого существуют с целью компенсировать недостатки css, и с переходом на sass/less они становятся просто бессмысленными.
                      • +2
                        О том, что не круто прописывать color: #ABCDEF в двадцати файлах, а потом во всех этих файлах руками менять цвет на другой? И с цветом это лишь простейший случай.
                        И часто вы меняете цвета? Раз в два года и sed прекрасно справиться.
                        А вриант «избежания» этой проблемы путём ввода десятков css классов на каждый чих
                        В CSS вообще на всё классы нужны. Но это только общие слова.
                        Или то, что в селекторах не рекомендуют использовать более трёх уровней вложенности, т.к. страница будет ренедериться на 1мс дольше.
                        Это всего лишь рекомендация. При методологии вроде БЭМ особых проблем быть не должно. Да и три класса фигня по сравнению со звёздочки или div/span справа.
                        Могу ещё и про яндексовский БЭМ упомянуть, часть практик которого существуют с целью компенсировать недостатки css, и с переходом на sass/less они становятся просто бессмысленными.
                        Путаете. Наоборот, нормальная методология делает костыли излишними.
      • +1
        Потому что табы создают очень много проблем и не дают никаких преимуществ.
        Это не только я так считаю, это написано во всех нормальных style-guide:


        Причина проста — в мире эльфов табы удобны, а в реальном мире, когда с кодом работают разные разработчики, они создают лишние проблемы, которых просто не должно быть. Проблемы которые стоят времени и денег.
        • +3
          «Потому что табы создают очень много проблем и не дают никаких преимуществ.» Основное преимущество и об этом уже много где говорилось — возможность управлять его длиной на уровне редактора не внося изменения в листинг кода.

          «Причина проста — в мире эльфов табы удобны, а в реальном мире, когда с кодом работают разные разработчики, они создают лишние проблемы, которых просто не должно быть. Проблемы которые стоят времени и денег.»
          Видимо последние лет 5-6 живу в мире эльфов, ну что же никто из нашей «лесной братии» пока не жаловался, а даже совсем наоборот…
          • –3
            Основное преимущество и об этом уже много где говорилось — возможность управлять его длиной на уровне редактора не внося изменения в листинг кода.

            Измените отступ:
            image
            • +3
              В данном случае это пример, неправильного использования табов + хаотичное комбинирование их с пробелами. В таком случае я врубаю на весь листинг сначала автоформатирование и привожу тем самых хаос к порядку в последствии уже используя табы для определения уровней вложенности — один на один уровень вложенности.
              • –3
                Т.е. тратите время впустую. Если бы использовались только пробелы этой проблемы бы не было. Что и требовалось доказать.
                • +4
                  По правде, если бы использовались только табы, этой проблемы тоже не было бы.
                  • +1
                    Да, были бы немного другие проблемы, но тем не менее это проблемы: www.prog.org.ru/index.php?topic=17796.msg119377#msg119377
                    • 0
                      Код-сниффер хуком на коммите спасает, чтобы не повадно было. Автоформат спасает так же. Вообще все равно, кто как наформатировал, если есть редактор, настроенный на определенный стиль (проектный или предложенный сторонней организации типа Zend, Google и т.д.), нормальный редактор все сам сделает.

                      P.S. Дал бы ссылку на питоновский док, там доступно разжевано, но эта тоже хороша.
                • +1
                  Не хотелось бы начинать, а точнее продолжать начавшийся уже давно холивар, но…
                  Потеря времени в описанной мной схеме секунды, аналогичная той когда адепт пробелов врубал бы автоформатирование чтобы избавиться от табов или любой другой, чтобы просто привести код в очередной раз в в порядок.
                  Я привел довод — «возможность управления длиной» отступа. Представим ситуацию, а она надо сказать при работе с большими объемами кода встречается достаточно часто, отформатированный структурированный код с множеством уровней вложенности (должен ли быть код очень «глубоким» или нет — это совсем другой разговор, не касающийся данной темы) и есть желание не затрагивая его структуру вложенности быстро перестроить его в более компактном виде, чтобы видеть не только структуру, но и содержание блоков.
                  При использовании табов достаточно в редакторе выбрать оптимальный размер одного таба (1,2,3,4 и тд). Сколько займет времени и каким способом вы бы решили эту задачу пробелами?
                  Второй вариант есть набор строк отбитый пробелами, часть из них по два пробела некоторые по три — как выяснить без анализа кода является ли отступ в три пробела структурным (определяющим вложенность) или он сделан «чтобы было красиво»?
      • 0
        По остальным пунктам замечаний нет? :)
        Давайте без холивара про табы, а по существу code style.

        В топике — не выжимка, а фигня какая-то. Лучше бы просто дали ссылки на спеки и обсудили.
        Где например пожелание про использование px вместо em? А это важно для независимых блоков.
  • –2
    Парни (и девчонки), я вам накинул ссылок, никакой выжимки или сравнительного описания нет, вы уж извините, разбирайтесь сами!
  • 0
    Пишем код так: clip2net.com/s/2ekEe
    Видимо это уже свой стандарт? Или был такой среди перечисленных?

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