Какие приемы для именования переменных в css препроцессорах используете Вы?

Question

[Вячеслав Лебедев]

Доброе утро!
Давно задавался вопросом, как правильно или как удобнее именовать переменные в препроцессорах css?
Пример для которого нужно именовать переменные:

.card
  display block
  margin 0 auto
  padding 1px 4px
  line-height 14px

Спасибо!

Answer 1

[sim3x]

Типа bem на sass

// _variables.sass
$padding-vert: 1px
$padding-hor: 4px

$some-type__line-height: 14px

$card-super-reusable__display: block

// _common.sass
%card-super-reusable
  display: $card-super-reusable__display
  margin-left: auto
  margin-right: auto
  padding: $padding-vert $padding-hor
  line-height: $some-type__line-height

// main-style.sass
.card
  @extends %card-super-reusable

mathayward.com/modular-css-with-sass-and-bem

Comments

[Вячеслав Лебедев]

Вот мне почему то ближе бэмовская блочность (без особого фанатизма, как предлагает сам бэм :) ). Каждый сверстанный блок будет иметь свой css. Ну а чтобы селекторы не дублировали css, будем использовать умный компрессор, вроде csso.
.card, соответственно - блок:

// stylus
card__display = block
card__margin-left = auto
card__margin-right = auto
card__padding-top = 1px
card__padding-right = 4px
card__padding-bottom = 1px
card__padding-left = 4px
card__line-height = 14px

Со стороны другого фронтендера, как считаете, будет ли удобно читать и поддерживать такие переменные?

[teotlu]

Вячеслав Лебедев: мне кажется, что это не очень правильный подход в данном случае (хотя в вёрстке я сам приверженец извращённой смеси MCSS и БЭМ). Просто потому, что переменные-то вам нужны не только затем, чтобы совершать какие-то операции, но и затем, чтобы у разных блоков задавать одинаковые параметры. Так что, на мой взгляд, логичнее имена вроде "wrapper_padding-left" или "basic_font-size".

[teotlu]

Вячеслав Лебедев: в смысле, не привязанные к конкретному блоку, а привязанные к стилистическому смыслу переменной (но не завязанные на её значение).

[Вячеслав Лебедев]

teotlu: я понял Ваш подход к именованию :)
Вы правы, так будет логичнее использовать переменные.
Спасибо за Ваше мнение.
Создам переменные для общих элементов, а остальные буду именовать в контексте.
Но я до сих пор не могу понять логики, что стоит объединить под общую переменную, а что нет.

[teotlu]

Вячеслав Лебедев: это узнаётся посредством анализа конкретного дизайна, и больше никак, к сожалению :) Более того, эти данные могут измениться, если меняется дизайн. Вот был одинаковый отступ в сайдбаре и футере, к примеру. А потом стал разный (проект эволюционирует, дизайн меняется). И уже нужны разные переменные, и подход БЭМ для этих конкретных двух блоков стал логичнее моего. Так вот всё сложно.

[Вячеслав Лебедев]

teotlu: в таком случае, буду придерживаться бэмовскому подходу, он и проще и гибче.
Спасибо за разъяснение! :)

[sim3x]

Вячеслав Лебедев: да
тк за пределы блока они не просачиваются

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

[teotlu]

sim3x: если они не просачиваются за пределы блока, зачем им префикс "card"?

[Вячеслав Лебедев]

teotlu: я подозреваю для того, что бы было понятно, к чему относится эта переменная.
Все же, мне ближе придерживаться гибкости одного блока, так я считаю будет проще ориентироваться в css при каких либо изменениях. И достаточно будет открыть variables.styl, чтобы там быстро по классу найти кусочек, который требует правки.
Разделяете ли Вы мою точку зрения?
Или стоит еще поразмыслить об этом?) Какие трудности могут возникнуть при использовании описанного мною подхода? Как Вы считаете?

[sim3x]

teotlu:
издержки программирования на ИДЕ :)
пишем card__ и видим список

+ sass умеет поднимать переменные из других модулей

Ну и самое главное -- ето решение
Второй
Самой
Главной
Проблемы
Программирования
= Именования переменных

[teotlu]

Вячеслав Лебедев: просто я понял так, что переменные определяются внутри блока .card и имеют соответствующую область видимости: если это так, то префикс "card" является для них избыточным, потому что они и так работают только в контексте блока .card. Более того, в этом случае с точки зрения программирования наличие префикса будет плохой практикой, поскольку, если изменится название блока, придётся ещё и менять префикс у всех переменных. Если я что-то понял неправильно, извините :)

[teotlu]

sim3x: а, вот видите, мне не хватает опыта работы с препроцессорами. Откровенно говоря, я только начинаю ими пользоваться. У нас в компании как-то так сложилось, что двигать весь фронтенд вперёд приходится мне одному (начиная с момента, как я пришёл сюда работать практически без знаний), поэтому стараюсь постепенно внедрять новые технологии. Вот буквально только что настроил себе сборщик через Node.js + Gulp, до этого использовал всяческие велосипеды самописные для этих целей. Только-только лезу в ReactJS и Angular :)

[teotlu]

Вячеслав Лебедев: в общем, с уточнениями sim3x выходит, что это таки имеет смысл, конкретно для препроцессоров.

[sim3x]

teotlu:
>если они не просачиваются за пределы блока, зачем им префикс "card"?
фигово я как-то написал. Лучше я обьясню по-другому
Есть переменная $cart__width
Есть файл _user-page.sass и стиль .user-page__avatar
Так вот переменную $cart__width не стоит использовать в данном файле
А если нужно установить зависимость между переменными с префиксами cart__ и user-page__ , то вынесем их в _vars.sass и там

$cart__width: 100px
$user-page__avatar-width: $cart__width

не у всех препроцессоров есть понятная "область видимости"
sass специфическое
less +
stylus ?
потому можно напороться на странное поведение

stackoverflow.com/questions/5469931/sass-variable-...

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

[teotlu]

sim3x: вот теперь всё понятно :)

Answer 2

[Дмитрий Филимонов]

Не использую БЭМ и мощный препроцессор, почти всегда хватает LESS, поэтому супер-архитектуры предложить не могу, но есть вариант, который не доставляет геморроя лично мне.

Для вашего кода, если значения для класса уникальны, я бы их вбил в тот же файл с аналогичными свойствам названиями. Если эти значения используются где-то еще, то вынес бы их в обособленный файл с переменными, но добавил бы префикс, который бы указывал на кусок дизайна, в котором они используются (типа card_padding-top, card-sidebar_padding-top, etc). Этих обособленных файлов может быть много, это может быть как тотальный файл для всего проекта (и, допустим, там отступы от хидера, от сайдбара или что-то в таком духе), так это может быть файл настроек для конкретного модуля, страницы, части, унифицированного элемента и логика такая же. Т.к. не использую БЭМ, приходится постоянно следить за иерархией, но если следить, то получается неплохо.

Кроме того, наверное, имеет место сказать: я вынес все шрифты в отдельные миксины вместе с line-height и все встречающиеся цвета в переменные, позволяет менять цветовую гамму, например, на Новый Год правкой в один файл.

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

Comments

[Вячеслав Лебедев]

Спасибо за развернутость!
Начинаю подозревать, что удобное именование приходит с годами.
И этому невозможно научить. Так как читал множество статей, но не разу не натыкался на: "Удобное именование переменных". :)
ps: возможно, плохо искал, раз не нашел :(

[Дмитрий Филимонов]

Вячеслав Лебедев: еще сильно зависит от задач, что конкретно верстаете. Но независимо от архитектуры, думаю, существует пара истин: если переменная уникальна, то просто дать ей то же имя, а если не уникальна, то дать префикс, который отразит, к какой части дизайна она отнесется. И, думаю, не важно, что использовать, хоть лапшовый CSS, хоть БЭМ, хоть костыли, с таким подходом все будет поддерживаемое :)

[Вячеслав Лебедев]

Дмитрий Филимонов: к такому же выводу и я пришел :)
Спасибо за помощь!)))