Comments 21
Через несколько лет все эти циклы и переменные войдут в сам CSS
+2
возможности быстро включать старые CSS файлы в проект посредством директивы import.
В sass можно подключать scss файлы, собственное ничто не мешает style.css переименовать в style.scss и подключить.
Просто css файл он не подключит, это правда, если указать import «style» он его не найдет, если import «style.css», то будет использован css-вский импорт, что не то же самое и не хотелось бы.
0
Да, вы правы, забыл упомянуть, что надо переименовывать в .scss чтобы работать через import.
0
Поддержка самое трудное наверное. Очень часто у меня бывают проекты где есть all.css на 6000 строк стилей и даже больше с которым работать трудно. Не знаю как верстальщики потом с этим работают, но лично мне обновлять и вносить свои правки в такое трудно. Сейчас в одном из проектов использую sass — совсем другое дело.
0
Попробойту дополнить процесс использованием техник OOCSS или SMACSS, мне очень помогает. Статья сравнение обеих техник и классического CSS.
Так же в продакшене я начал разбивать CSS по модулям. Например structure --> home-page --> header + main + footer, skin --> home-page --> header + main + footer. Каждый модуль — отдельный файл.
В данный момент пытаюсь найти наилучший метод для себя, и подобная модульность пока устраивает.
Так же в продакшене я начал разбивать CSS по модулям. Например structure --> home-page --> header + main + footer, skin --> home-page --> header + main + footer. Каждый модуль — отдельный файл.
В данный момент пытаюсь найти наилучший метод для себя, и подобная модульность пока устраивает.
0
Попробойте дополнить процесс использованием техник OOCSS или SMACSS
OOCSS и SMACSS — поправьте, если я не прав, но не подразумевают ли эти техники присвоения одному элементу множества классов? Это получается что-то вроде описания поведения, присущего интерфейсам. Для чего такой полиморфизм в CSS? Путаница не возникнет?
Так же в продакшене я начал разбивать CSS по модулям. Например structure --> home-page --> header + main + footer, skin --> home-page --> header + main + footer. Каждый модуль — отдельный файл.
А общие классы и ресеты? Отдельные CSS - файлы?
0
А общие классы и ресеты? Отдельные CSS - файлы?
Ресет — отдельный файл. Общие классы — это объекты (objects.css) этот файл содержит часто повторяющиеся элементы и их скини (иногда несколько скинов).
OOCSS и SMACSS — поправьте, если я не прав, но не подразумевают ли эти техники присвоения одному элементу множества классов? Это получается что-то вроде описания поведения, присущего интерфейсам. Для чего такой полиморфизм в CSS? Путаница не возникнет?
OOCSS использует только классы, поэтому да — классов будет миллион. SMACSS немного проще, он скорее работает по принципу описания, а не объектов. Для себя я скомбинировал эти две техники, но доля OOCSS все же больше. За счет объектов (классов), CSS код становится легко редактируемым и понятным. Минусы: HTML тяжелеет на 20% и требуется больше времени на написание CSS.
Вот набросок модулей CSS, документ в процессе редактирования.
0
И мы получили sass, не?
Stylus может похвастаться thoughtbot.com/bourbon/?
Stylus может похвастаться thoughtbot.com/bourbon/?
0
Для меня самое полезное в SCSS, ну и в принципе что его выгодно отличает от LESS — @extend
0
Особо не возражаю против less/scss/и тд, но имхо, ваш пример с циклом гораздо сложнее чем пять css правил.
А что касается respond-to, то вас видимо не сильно волнует размер результируешего css? Предполагаю там будет огромное количество @media, хотя все правила можно было бы сгрупировать в три (в вашем случае) @media блока.
А что касается respond-to, то вас видимо не сильно волнует размер результируешего css? Предполагаю там будет огромное количество @media, хотя все правила можно было бы сгрупировать в три (в вашем случае) @media блока.
0
но имхо, ваш пример с циклом гораздо сложнее чем пять css правил
Почему же сложнее? 7 строк кода кода всего, при том, что не надо 5 раз писать один и тот же код. И в случае изменения цвета в списке, во всем файле пройдет подстановка цветов — я же не в одном месте этот список использую, а постоянно, так как сайт весь в этой палитре. И потом, я не претендую на то, что пример идеален — это лишь техника, которая мне помогает.
вас видимо не сильно волнует размер результируешего css?
Понимаю вас, но считаю, что читаемость и поддерживаемость важнее, чем сравнительно небольшое увеличение размера файла. Respond-to позволяет в одном правиле описать полностью поведение объекта для всех состояний — и это замечательно!
Особенно на фоне тех примеров, которые приходилось видеть и поддерживать.
Кстати, вот еще пара ссылок по использованию respont-to в sass.
0
Я не уловил как переиспользуется ваш цикл для других случаев.
На случай изменения цвета достаточно использовать переменные или тот же список
К тому же если везде используются классы вида .red/.green и т.д. с одним и тем же значением — не проще тогда сделать их глобальными (можно с некоторым префиксом типа palette-color1).
Ну и из занудного: вспомним, что по правилом хорошего тона в css считается, что класс не должен в имени содержать описание того как будет выглядеть элемент — так если вы поменяете цвет в $colors то класс red может уже не быть красным ;)
Насчет размера… Ваш пример это 166байт на правило (если убрать содержимое блока @media и незначащие пробелы). Так что если у вас правил с respond-to около 100 (а это наверное средний проект), у вас будет 300 @media правил и 16,5 кб оверхеда на ровном месте. Конечно, критичность всего этого зависит от проекта.
Было бы круто если бы это все группировалось (а еще лучше в отдельные файлы) и не плодилось @media правил.
На случай изменения цвета достаточно использовать переменные или тот же список
nth($colors, 1)
— разве нет?К тому же если везде используются классы вида .red/.green и т.д. с одним и тем же значением — не проще тогда сделать их глобальными (можно с некоторым префиксом типа palette-color1).
Ну и из занудного: вспомним, что по правилом хорошего тона в css считается, что класс не должен в имени содержать описание того как будет выглядеть элемент — так если вы поменяете цвет в $colors то класс red может уже не быть красным ;)
Насчет размера… Ваш пример это 166байт на правило (если убрать содержимое блока @media и незначащие пробелы). Так что если у вас правил с respond-to около 100 (а это наверное средний проект), у вас будет 300 @media правил и 16,5 кб оверхеда на ровном месте. Конечно, критичность всего этого зависит от проекта.
Было бы круто если бы это все группировалось (а еще лучше в отдельные файлы) и не плодилось @media правил.
0
Я не уловил как переиспользуется ваш цикл для других случаев.
Он и не переиспользуется, а лишь позволяет компактно один раз пройтись по списку. Фактически — это попытка превратить for → foreach, конечно, без встроенного итератора и цвета приходится передавать вручную. Да, возможно — это не столь канонично, но ведь SASS/SCSS — всего лишь препроцессоры, а не полноценные языки.
На случай изменения цвета достаточно использовать переменные или тот же список nth($colors, 1) — разве нет?
У меня в проекте так и делается — есть переменные, привязанные к элементам списка. В статье об этом не написано, т.к. не по теме. И опять же — это вопрос, кому как удобней.
не проще тогда сделать их глобальными (можно с некоторым префиксом типа palette-color1).
Опять же, для удобства. Я всегда в коде смогу быстро что-то сделать «красным» и все будет в гамме. А вспомнить, что означает palette-color1 — не так просто.
класс не должен в имени содержать описание того как будет выглядеть элемент — так если вы поменяете цвет в $colors то класс red может уже не быть красным ;)
Никто не обязывает использовать цикл для цветов — это просто демонстрация инкремента.
правил с respond-to около 100 (а это наверное средний проект), у вас будет 300 @media правил и 16,5 кб оверхеда на ровном месте.
Вот здесь абсолютно согласен, для больших проектов, рассчитанных под множество разрешений — это может стать критичным. Но это решать каждому. Я просто счел эту методику удобной и поделился.
Было бы круто если бы это все группировалось (а еще лучше в отдельные файлы) и не плодилось @media правил
Да, с этим вообще беда. Запрос уже давно висит, но пока это не внедрили.
0
Sign up to leave a comment.
SCSS: пара полезных техник