SCSS: пара полезных техник

[Niksg]

Через несколько лет все эти циклы и переменные войдут в сам CSS

[M1nstrel]

Дай Бог, если это сделает веб лучше!
Поддерживаемость проектов — это беда. Иногда попадаются такие экземпляры CSS ­- файлов, что комментарии излишни.
Такие конструкции зачастую (но только в умелых руках), позволяют сделать код немного более лаконичным и понятным.

[Ag47]

возможности быстро включать старые CSS файлы в проект посредством директивы import.

В sass можно подключать scss файлы, собственное ничто не мешает style.css переименовать в style.scss и подключить.

Просто css файл он не подключит, это правда, если указать import «style» он его не найдет, если import «style.css», то будет использован css-вский импорт, что не то же самое и не хотелось бы.

[M1nstrel]

Да, вы правы, забыл упомянуть, что надо переименовывать в .scss чтобы работать через import.

[Ag47]

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

        }
    }
}

[zayko]

<holywar> единственное место где не могу отказаться от скобок — SCSS. Мне нравится в нем писать {}, без этого CSS перестает быть CSS-ом.</holywar>

[Renius]

Он перестает быть каскадной таблицей стилей?

[firstrow]

Поддержка самое трудное наверное. Очень часто у меня бывают проекты где есть all.css на 6000 строк стилей и даже больше с которым работать трудно. Не знаю как верстальщики потом с этим работают, но лично мне обновлять и вносить свои правки в такое трудно. Сейчас в одном из проектов использую sass — совсем другое дело.

[roman01la]

Попробойту дополнить процесс использованием техник OOCSS или SMACSS, мне очень помогает. Статья сравнение обеих техник и классического CSS.

Так же в продакшене я начал разбивать CSS по модулям. Например structure --> home-page --> header + main + footer, skin --> home-page --> header + main + footer. Каждый модуль — отдельный файл.

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

[M1nstrel]

Попробойте дополнить процесс использованием техник OOCSS или SMACSS

OOCSS и SMACSS — поправьте, если я не прав, но не подразумевают ли эти техники присвоения одному элементу множества классов? Это получается что-то вроде описания поведения, присущего интерфейсам. Для чего такой полиморфизм в CSS? Путаница не возникнет?

Так же в продакшене я начал разбивать CSS по модулям. Например structure --> home-page --> header + main + footer, skin --> home-page --> header + main + footer. Каждый модуль — отдельный файл.

А общие классы и ресеты? Отдельные CSS ­- файлы?

[roman01la]

А общие классы и ресеты? Отдельные CSS ­- файлы?

Ресет — отдельный файл. Общие классы — это объекты (objects.css) этот файл содержит часто повторяющиеся элементы и их скини (иногда несколько скинов).

OOCSS и SMACSS — поправьте, если я не прав, но не подразумевают ли эти техники присвоения одному элементу множества классов? Это получается что-то вроде описания поведения, присущего интерфейсам. Для чего такой полиморфизм в CSS? Путаница не возникнет?

OOCSS использует только классы, поэтому да — классов будет миллион. SMACSS немного проще, он скорее работает по принципу описания, а не объектов. Для себя я скомбинировал эти две техники, но доля OOCSS все же больше. За счет объектов (классов), CSS код становится легко редактируемым и понятным. Минусы: HTML тяжелеет на 20% и требуется больше времени на написание CSS.

Вот набросок модулей CSS, документ в процессе редактирования.

[KidsKilla]

<troll>Король умер. Да здравствует король!</troll>

[Zelgadis]

И мы получили sass, не?
Stylus может похвастаться thoughtbot.com/bourbon/?

[KidsKilla]

Не, совсем-совсем не.
Стилус вышел позже сасс и лесс и на мой взгляд у него потенциал на порядок больше и синтаксис куда чище.
Вместо бурбона у стилуса есть стандартный nib.

[M1nstrel]

Почитал доки, но так и не понял: он медиа-запросы соединяет в единые блоки?

[KidsKilla]

Не знаю, но скорее всего нет.

[loat]

Для меня самое полезное в SCSS, ну и в принципе что его выгодно отличает от LESS — @extend

[lahmatiy]

Особо не возражаю против less/scss/и тд, но имхо, ваш пример с циклом гораздо сложнее чем пять css правил.
А что касается respond-to, то вас видимо не сильно волнует размер результируешего css? Предполагаю там будет огромное количество @media, хотя все правила можно было бы сгрупировать в три (в вашем случае) @media блока.

[M1nstrel]

но имхо, ваш пример с циклом гораздо сложнее чем пять css правил

Почему же сложнее? 7 строк кода кода всего, при том, что не надо 5 раз писать один и тот же код. И в случае изменения цвета в списке, во всем файле пройдет подстановка цветов — я же не в одном месте этот список использую, а постоянно, так как сайт весь в этой палитре. И потом, я не претендую на то, что пример идеален — это лишь техника, которая мне помогает.

вас видимо не сильно волнует размер результируешего css?

Понимаю вас, но считаю, что читаемость и поддерживаемость важнее, чем сравнительно небольшое увеличение размера файла. Respond-to позволяет в одном правиле описать полностью поведение объекта для всех состояний — и это замечательно!
Особенно на фоне тех примеров, которые приходилось видеть и поддерживать.
Кстати, вот еще пара ссылок по использованию respont-to в sass.

[lahmatiy]

Я не уловил как переиспользуется ваш цикл для других случаев.
На случай изменения цвета достаточно использовать переменные или тот же список nth($colors, 1) — разве нет?
К тому же если везде используются классы вида .red/.green и т.д. с одним и тем же значением — не проще тогда сделать их глобальными (можно с некоторым префиксом типа palette-color1).
Ну и из занудного: вспомним, что по правилом хорошего тона в css считается, что класс не должен в имени содержать описание того как будет выглядеть элемент — так если вы поменяете цвет в $colors то класс red может уже не быть красным ;)

Насчет размера… Ваш пример это 166байт на правило (если убрать содержимое блока @media и незначащие пробелы). Так что если у вас правил с respond-to около 100 (а это наверное средний проект), у вас будет 300 @media правил и 16,5 кб оверхеда на ровном месте. Конечно, критичность всего этого зависит от проекта.
Было бы круто если бы это все группировалось (а еще лучше в отдельные файлы) и не плодилось @media правил.

[M1nstrel]

Я не уловил как переиспользуется ваш цикл для других случаев.

Он и не переиспользуется, а лишь позволяет компактно один раз пройтись по списку. Фактически — это попытка превратить for → foreach, конечно, без встроенного итератора и цвета приходится передавать вручную. Да, возможно — это не столь канонично, но ведь SASS/SCSS — всего лишь препроцессоры, а не полноценные языки.

На случай изменения цвета достаточно использовать переменные или тот же список nth($colors, 1) — разве нет?

У меня в проекте так и делается — есть переменные, привязанные к элементам списка. В статье об этом не написано, т.к. не по теме. И опять же — это вопрос, кому как удобней.

не проще тогда сделать их глобальными (можно с некоторым префиксом типа palette-color1).

Опять же, для удобства. Я всегда в коде смогу быстро что-то сделать «красным» и все будет в гамме. А вспомнить, что означает palette-color1 — не так просто.

класс не должен в имени содержать описание того как будет выглядеть элемент — так если вы поменяете цвет в $colors то класс red может уже не быть красным ;)

Никто не обязывает использовать цикл для цветов — это просто демонстрация инкремента.

правил с respond-to около 100 (а это наверное средний проект), у вас будет 300 @media правил и 16,5 кб оверхеда на ровном месте.

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

Было бы круто если бы это все группировалось (а еще лучше в отдельные файлы) и не плодилось @media правил

Да, с этим вообще беда. Запрос уже давно висит, но пока это не внедрили.