Урок 10. Препроцессор Sass. Директивы @for, @each и @while

Содержание материала:

Цикл for в Sass

July 18, 2014

Очень краткий пример работы с циклом в препроцессоре Sass.

С чего вдруг мне приспичило воспользоваться циклом в препроцессоре? Все, как всегда, просто — в предыдущей статье, посвященной плагину Smooth Scroll (Плагин Smooth Scroll), мне потребовался создать пример разметки HTML-документа с заголовками всех уровней, с первого (h1) до шестого (h6). Все бы ничего, но вручную создавать стили для заголовков всех уровней как-то утомительно.

HTML-разметка для цикла for

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

Базовые CSS-стили

Затем пропишу основные стили для этой разметки:

Использую цикл for в Sass

Теперь у меня стоит задача “покрасить” все заголовки в оттенки цвета, указанного в переменной . Для создания оттенков воспользуюсь функцией из препроцессора Sass.

Цвет будет меняться с шагом в 5% ( ):

Также будет изменяться размер шрифта (кегль) в заголовках уровней с первого ( ) до шестого ( ), с шагом 10px ( ):

Как видим, задача и вправду не для ленивых — это же надо тупо вбивать столько значений! Но мне поможет Sass и его циклы, а точнее — цикл .

Для этого создаю такую конструкцию цикла :

Небольшая расшифровка приведенного выше цикла. В данном случае используется цикл , в котором счетчик изменяет свое значение в диапазоне от 1 до 6 включительно. Конструкция называется экранированием в Sass и служит для того, чтобы значение счетчика подставилось в коде “как есть”, в виде текста.

В результате получается такой вывод:

Далее идут CSS-правила с использованием функции препроцессора Sass и переменных , , . Последние две строки производят увеличение значения переменных на указанный шаг:

Приведенный выше SCSS-код скомпилируется в готовый CSS-код подобного вида:

Смотрим результат в браузере и радуемся успеху:

Полный код примера цикла for в Sass

Полный код рассмотренного примера создания цикла в Sass приведен ниже:

Скомпилированный в CSS-код результат нашего кодинга:

RxJs — map

Первый «серьезный» метод в моей RxJs-копилке знаний. На самом деле все просто — этот метод получает на вход поток, обрабатывает каждый ev. … Continue reading

SASS для Начинающих: Скачивание и Установка

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

Что такое SASS?

SASS (Syntactically Awesome Style Sheets) — один из самых популярных CSS препроцессоров. Он представляет собой набор функций для CSS, которые позволяют кодить быстрее и эффективнее. SASS поддерживает интеграцию с Firefox Firebug. SassScript позволяет создавать переменные, вложенные стили и наследуемые селекторы.

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

Зачем нужен SASS?

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

Как использовать SASS?

Существует много приложений, которые позволяют легко и быстро начать использовать SASS: CodeKit, Compass, Koala и т.д. Вы узнаете о них в других частях туториала. В этой главе мы не будем использовать никаких приложений или инструментов кроме тех, которые необходимы для запуска SASS на компьютере. Вам не придется волноваться об операционной системе, потому что всё будет понятно всем пользователям.

Скачивание и Установка SASS

Установить SASS можно только на машину, на которой уже есть Ruby:

  • Ruby предустановлен на Mac, так что вы можете сразу установить Sass Macintosh;
  • Если вы работаете на Windows, то вам необходимо сначала скачать Ruby;
  • Ruby на Linux можно скачать через систему управления пакетами (apt package manager), rbenv или rvm.

После установки Ruby на вашу машину можно установить SASS. Давайте откроем командную строку Ruby и установим SASS на вашу систему:

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

Если вы хотите проверить версию SASS используйте следующую команду:

SASS установлен. Давайте создадим папку проекта и назовем ее sass-basic. Создайте базовый html файл со следующим кодом:

В этом html документе есть ссылка на style.css, так что теперь нужно создать файл style.scss (не .css) в папке. Давайте создадим файл style.scss со следующим кодом:

Теперь нужно компилировать этот файл используя командную строку/терминал. Давайте откроем командную строку в той же директории (возможно, придется использовать командную строку Ruby, если обычная командная строка не работает). Вбейте следующее и нажмите Enter:

Вы заметите, что сгенерировались новые файлы: style.css и style.css.map. Стоит отметить, что не нужно трогать map файл, также как и .css файл. Если вы хотите внести какие-то изменения, то это можно сделать через style.scss. Вам не понадобится повторять этот процесс при каждом изменении стилей. Компиляция SASS будет работать автоматически при внесении изменений в .scss файл.

В следующей главе мы рассмотрим SASS переменные, и почему они являются самой полезной функций SASS (и в любом другом CSS препроцессоре).

Циклы в Sass

Циклы позволяют последовательно изменять значение переменной в заданных пределах и подставлять полученное значение в имена классов, значения свойств, а также использовать в вычислениях. Для создания цикла в Sass предназначена команда @for .

Для примера возьмём цикл от 1 до 3, он будет записываться в следующем виде.

Здесь $i это переменная-счётчик, в которой хранится номер итерации, 1 — начальное значение, 3 — конечное. Не обязательно использовать именно эти цифры. Числа могут быть и отрицательными, а цикл начинаться и с большего числа, тогда значение счётчика будет последовательно уменьшаться, а не увеличиваться, как обычно.
Теперь у нас есть переменная $i, которую мы можем подставлять внутри цикла куда нам требуется. В вычислениях переменная так и пишется, а вот в именах классов или в значениях свойств мы уже должны писать как #<$i>.

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

Для этой картинки введём три класса, каждый из них соответствует фрагменту изображения. Отличаться стиль для каждого спрайта будет именем класса и значением background-image. Вот как запишется Sass.

Первый спрайт имеет нулевые координаты у значения background-image, поэтому цикл мы начинаем с нуля, чтобы не делать дополнительные вычисления. Высота каждого спрайта одинакова и равна 31 пиксель, так что получить нужную нам координату легко — достаточно умножить переменную $i на 31. Обязательно надо добавить к значениям px, иначе стили не будут поняты корректно.

Урок №22. Директивы препроцессора

Обновл. 10 Мар 2020 |

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

Директива #include

Вы уже видели директиву #include в действии. Когда вы #include файл, препроцессор копирует содержимое подключаемого файла в текущий файл сразу после строчки #include. Это очень полезно при использовании определённых данных (например, предварительные объявления функций) сразу в нескольких местах.

Директива #include имеет две формы:

#include , которая сообщает препроцессору искать файл в системных путях. Чаще всего вы будете использовать эту форму при подключении заголовочных файлов из стандартных библиотек C++.

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

Директива #define

Директиву #define можно использовать для создания макросов. Макрос — это правило, которое определяет конвертацию идентификатора в указанные данные.

Есть два основных типа макросов: макросы-функции и макросы-объекты.

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

Макросы-объекты можно определить одним из двух следующих способов:

#define identifier
#define identifier substitution_text

Верхнее определение не имеет никакого substitution_text , в то время как нижнее — имеет. Поскольку это директивы препроцессора (а не простые стейтменты), то ни одна из форм не заканчивается точкой с запятой.

Макросы-объекты с substitution_text

Когда препроцессор встречает макросы-объекты с substitution_text , то любое дальнейшее появление identifier заменяется на substitution_text . Идентификатор обычно пишется заглавными буквами с символами подчёркивания вместо пробелов.

Препроцессор SASS: пишем стили просто и быстро

Всем привет! Как быстро летит время. Я даже не заметил, как я перешел от написания стилей с обычного Css на препроцессор Sass. А ведь раньше не понимал — что за Sass, для чего он нужен, это наверно для супер продвинутых профи в верстке. Да, использование препроцессоров это шаг на новый уровень в веб-разработке, но здесь ничего страшного и сложного нет и вы убедитесь в этом сами, дочитав данную статью до конца.

И так, чем хорош препроцессор и конкретно Sass? Я сразу скажу, что есть и другие, такие, как Less, Stylus и др. Все они работают по одному принципу, но у каждого свои особенности. Sass получил большую популярность у профессионалов в следствие чего изучение значительно упрощается. Просто чем популярнее технология, тем больше сообщество и тем более развернута документация.

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

Документация

Разработчиком Sass является француз Hugo Giraudel, проживающий в Германии с определенного времени. Естественно документация на английском языке, но я лично в ней неплохо ориентируюсь (важно знать технический английский). Но также есть перевод и на русский. Я бы советовал все же английскую версию, это для того, чтобы привыкать и изучать все глубже английский. Но русская тоже ничем не хуже.

Компиляция Sass в Css

В качестве программного обеспечения для компиляции Sass в Css я использую плагин Sass для таск-менеджера Gulp. Вообще Sass является приложением (Gem) языка Ruby. Поэтому, если вы хотите обойтись без Gulp, то для компиляции в Css вам необходимо будет установить платформу языка программирования Ruby. Я не буду сейчас показывать как это делается, можете почитать об этом на официальном сайте.

Синтаксис — Sass, Scss

Сразу отмечу, что существует 2 синтаксиса написания кода: Sass и Scss.

Синтаксис Sass незначительно отличается от Scss. Scss похож больше на обычный код Css, а в Sass опущены фигурные скобки и точка с запятой между правилами. Также существует различие в написании некоторых функций и надо быть внимательным в том, какой синтаксис вы выбираете. Расширения файлов для Sass — *.sass, а для Scss — *.scss. Синтаксис Sass он более старый, а Scss появился позже, чтобы упростить изучение для новичков. Я сам начинал изучение данного препроцессора именно на Scss, так было проще его понять. Сейчас же я перешел на Sass, для меня он более удобен.

Если говорить о Sass, то его структура кода строится на основе отступов (ведь фигурных скобок в нем нет) и здесь следует быть внимательным, так как в качестве отступа может выступать, как табулятор (TAB — 4 пробела), так и обычные пробелы (обычно это двойной пробел). Я всегда использую табулятор.

Помните! Если вы используете табулятор в качестве отступа, то пробелы следует исключить, чтобы везде было одинаково. И наоборот — если используете пробелы, то табулятор следует исключить. Иначе, компилятор выдаст ошибку.

В большинстве редакторов кода (например, Sublime Text) есть разметка отступов в виде полос, что не дает нам запутаться. В примерах ниже я буду использовать синтаксис Sass.

Упрощаем жизнь с помощью Sass

Вложенность правил

Вот чем мне приглянулся Sass с самого начала, так это как раз вложенностью css-правил одних в другие. Это здорово экономит время, а код получается структурируемым и легкочитаемым. Например, если мы хотим написать стили элементам определенного родительского контейнера, то нам в Css необходимо каждый раз указывать родительский класс, например вот так:

То есть мы везде указываем родительский класс .main , а это в свою очередь не совсем удобно. Используя Sass, можно записать следующим образом:

Согласитесь так смотрится намного аккуратнее, да и писать код можно быстрее, ведь родительский класс .main мы пишем всего один раз. Если вы хотите повторить за мной, не устанавливая Ruby и всякое подобное ПО можно воспользоваться онлайн-компилятором для демонстрации.

Вложенные свойства

Помимо вложенности правил в Sass существует возможность вложенности свойств. Например, вот как можно записать значения margin :

Привязка к селектору или конкатенация — знак &

Написание нашего кода можно ускорить и сделать его еще компактнее, применив конкатенацию (соединение) посредством символа — &. Как это работает? Например, у нас есть такие классы, как: .main-title , .main-subtitle , .main-description . В Sass данные классы можно записать следующим образом:

Sass

Css

С помощью символа & мы соединяемся к корневому классу, то есть в данном случае нет необходимости постоянно повторять корень .main . В тоже время следует иметь ввиду, что мы не создали дочерние элементы.

Sass

Css

Иногда нужно указать цепочку селекторов до текущего элемента. Можно конечно вынести его в корень, но чтобы не нарушать вложенность можно написать следующим образом:

Sass

Css

Переместив & после селектора, мы поменяли порядок стыковки, т. е. класс .container в данном случае является родительским.

Топ-пост этого месяца:  Товарный арбитраж пошаговая инструкция для новичка

Привязка к родительскому селектору, но на уровнь выше

Выше для примера я демонстрировал Sass код:

Sass

Теперь представьте, что в блоке .main-title существует еще один элемент которому нужно явно указать стили, используя всю цепочку родителей. Я долго время просто указывал корневое название (в данном случае — .main ), но это не очень удобно. Я стал ковырять документацию Sass и нашел решение. На самом деле все просто — нам необходимо объявить ссылку на родителя и использовать ее, там, где нужно.

Вот так я делал раньше:

А теперь можно сделать так:

Если заметили мы объявили ссылку на родителя — $self: & . Мне это чем-то напоминает ссылку на объект (this), который вызвал событие в javaScript. Теперь в нужно месте мы можем просто его вызвать # <$self>. Вот оказывается как все просто, а я голову ломал и думал, что нет решения этой проблемы в Sass.

Css

Шаблоны-заготовки

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

Sass

Css

Шаблоном выступает в данном случает селектор %button (об этом говорит знак — %). Это удобно тем, что сам селектор шаблона нигде не участвует, а его стили наследуются другими селекторами посредством директивы — @extend. Данный шаблон можно использовать сколько угодно раз, сокращая тем самым количество кода.

SassScript

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

Переменные

Переменная в Sass начинается со знака $, а имя пишется латиницей, например: $color . Следует отметить, что знаки: «» и «_» взаимозаменяемы. К примеру, если назвали $color-red , то можно вызвать и $color_red . Определяется переменная следующим образом: $название: значение, например: $color: #f6f6f6 .

Переменная объявленная вне каких либо уровней вложенности, доступна глобально, т.е. можно использовать везде. Если же вы определили переменную в каком либо уровне вложенности селектора, то она будет доступна только на данном уровне. Чтобы она работала глобально во всем документе необходимо указать ключевое слово !global.

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

Директивы

@extend

Данную директиву мы затронули выше, когда изучали шаблон-заготовку. Закрепим еще раз знания. С помощью @extend мы можем скопировать правила любого селектора. Например, при верстке может быть так, что элемент «А» и элемент «Б» могут быть схожи по внешнему виду. В данном случае можно написать правила элементу «А», а для «Б» просто скопировать стили элемента «А», слегка переопределив нужные свойства.

Sass

Css

В данном примере мы сверстали 2 одинаковых квадрата. У квадрата «Б» мы переопределили только отступ padding: 15px . Вот так работает @extend. Я довольно часто пользуюсь данной директивой.

@import

Данная директива позволяет объединять несколько файлов стилей в один. Это очень удобно, тем более, если проект большой. Не стоит путать с директивой, которая существует в Css — @import. В Css обязательным атрибутом является — url().

На самом деле удобнее писать стили в разных файлах и предназначение у каждого свое. Например, весь каркас страницы можно разделить на регионы: header.sass, sidebar.sass, footer.sass. Собрать все можно в главном файле main.sass, как раз используя @import. Файлы регионов можно указать также через нижнее подчеркивание в начале имени файла, например так: _header.sass, _sidebar.sass, _footer.sass. Такие файлы называются фрагментами. При импорте фрагментов не обязательно указывать расширение файла.

Файлы фрагментов могут быть с расширениями: *.sass, *.scss или *.css. Например, главный файл может быть с расширением *.sass, а шапка сайта, к примеру с расширением *.scss. То есть не важно какое у вас расширение главного файла. Следует отметить, что при импорте переносятся все переменные и миксины (о них поговорим ниже) в главный файл, в который происходит импорт.

Также, можно указать импорт нескольких файлов через запятую: @import «header», «sidebar», «footer».

Имейте ввиду, что импорт происходит в том месте, где вы указали директиву @import. Обычно это делают в начале документа.

@at-root

Директива @at-root говорит сама за себя и если переводить на русский, то будет звучать так — «от корня». Иными словами мы переносим селектор в корень, отменяя цепочку родительских селекторов. Тут конечно можно задать вопрос — «А зачем нужна эта директива, если можно перенести селектор в корень в ручную?». Ответ прост — удобство написания кода, не нарушая структуру. Когда вы научитесь работать с Sass в полной мере вы это поймете.

Управляющие директивы и выражения

Директива @if

Данная директива выполняет стили, если выражение, заключенное в ней возвращает любое значение кроме false и null.

Sass

Css

Те, кто знаком хотя бы с основами языка программирования (например, javaScript или Php) разобраться будет не сложно. Здесь суть та же самая, главное знать синтаксис написания кода.

Директива @for

В языке программирования (опять же в Javascript или Php) с помощью For можно задать цикл. В Sass данная директива выполняет тоже самое — создает цикл. Для каждой итерации (повторения) используется переменная-счетчик, которая изменяет данные вывода.

Директива имеет 2 формы написания: 1. @for $var from through и 2. @for $var from to . Если вы хотите, чтобы последняя цифра была включена в цикл, то используйте «through«. Давайте рассмотрим пример:

Sass

Css

Для указания конечного значения я использовал ключевое слово «to«. При таком раскладе цикл заканчивается на цифре — 5. Обратите внимание насколько компактным выглядит код Sass.

Директива @each

Директива @each также, как и @for выводит значения в цикле и удобен тем, что помимо цифр можно перебирать конкретные значения. Давайте возьмем вышеприведенный цикл и изменим его на какие либо значения.

Sass

Css

В данном случае не создается переменная-счетчик, а количество итераций зависит от количества созданных значений после ключевого слова «in«. Значения выводятся через переменную (в данном примере — $bgItem), название которой может быть произвольным.

Миксины (функции)

Миксины (примеси) — это своего рода функция, как в языке программирования, которая призвана избавить от повторяющегося кода. Миксины могут содержать целые фрагменты стилей, разрешенные в Sass. Давайте рассмотрим пример, для большей наглядности.

Создается миксин директивой @mixin , далее через пробел следует имя миксина, а также опционально передаваемые параметры. Сразу отмечу, что знаки дефиса (-) и нижнего подчеркивания (_) в имени миксина взаимозаменяемы. Миксин может содержать в себе не только правила, но и селекторы. Выше я привел пример элементарного миксина без параметров.

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

Теперь давайте рассмотрим миксин с параметрами (аргументами).

Sass

Css

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

На этом я хочу завершить свой небольшой обзор препроцессора Sass. Почему небольшой? Да потому что это далеко не все, что я вам поведал. Вообще, используя вышеизложенное, вы можете смело уже сейчас начать пользоваться Sass вместо Css. Более подробнее вы сможете изучить Sass, прибегнув к документации, которую я приводил выше.

Ну что ж, всем спасибо за внимание! Как всегда, вопросы задаем в комментариях и подписывайтесь либо на телеграм канал, либо на рассылку по email (форма в сайдбаре справа), чтобы не пропустить ничего интересного.

До встречи в других моих постах…

Заур Магомедов

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

Препроцессор Sass. Полное руководство и зачем он нужен

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

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

Сразу обратите внимание, что если вам нужен простой функционал, такой как перменные, то в простом CSS они уже появились и не нужно загружать себя таким инструментом как Sass. Вот статья — Руководство по работе с переменными в CSS

Синтаксис

Для Sass доступно два синтаксиса. Первый, известный как SCSS (Sassy CSS) и используемый повсюду в этой статье — это расширенный синтаксис CSS. Это означает, что каждая валидная таблица стилей CSS это валидный SCSS файл, несущий в себе туже самую логику. Более того, SCSS понимает большинство хаков в CSS и вендорные синтаксисы, например такой как синтаксис фильтра в старом IE. Этот синтаксис улучшен Sass функционалом описанным ниже. Файлы использующие этот синтаксис имеют .scss расширение.

Второй и более старый синтаксис, также известный как краёный синтаксис или иногда просто Sass, даёт более сжатую возможность работы с CSS. Он использует отступы вместо скобок, что отделить вложения селекторов и новые строки вместо точек с запятой для разделения свойств. Иногда люди находят такой способ проще для понимания и быстрее для написания, чем SCSS. По факту, такой синтаксис имеет тот же функционал, хотя некоторые из них имеют слегка другой подход. Файлы используемые этот синтаксис имеют расширение .sass .

Любой синтаксис может импортировать файлы, написанные в другом. Файлы могут быть автоматически сконвертированы из одного в другой, используя sass-convert команду:

Использование Sass

Sass может быть использован тремя способами: как командной строкой, как отдельный модуль Ruby и как плагин для rack-фреймворка, включая Ruby on Rails и Merb. Первым делом для всего этого надо установить Sass гем:

Если вы на Windows, то возможно вам надо установить сначала Ruby.

Для запуска Sass из командной строки просто используйте:

sass input.scss output.css

Вы также можете указать Sass следить за файлом и обновлять CSS каждый раз, когда Sass файл меняется:

sass —watch input.scss:output.css

Если у вас есть директория с множеством Sass файлов, то вы также можете указать Sass следить за всей директорией:

sass —watch app/sass:public/stylesheets

Используйте sass —help для полной документации.

Sass — условия и циклы (@if, @for, @each, @while)

15.03.2020
И
Комментариев нет

uWebDesign Обзор #4 — Sass, глубины CSS препроцессора. В этом ролике я рассмотрел контрольные директивы условного оператор, циклов и другие.

В этом скринкасте я рассказал еще и о директивах для дебаггинга: @debug и @warn, а также директиву @function для определения собственных функций, которые будут возвращать значения.

Так же я рассмотрел работу с контрольными директивами: условный оператор @if и циклы @for, @each, @while. Остановился на отличиях и сходствах этих циклов и продемонстрировал несколько практических примеров использования.

Сайт проекта Sass: http://sass-lang.com
Документация: http://goo.gl/AlXkSL
Документация по функциям: http://goo.gl/ZhnxAG

uWebDesign это:
• Паблик на ВК: http://vk.com/uwebdesign
• Лента в Twitter: http://twitter.com/uwebdesgn
• Канал на YouTube: https://youtube.com/user/uwebdesign

uWebDesign

Вы находитесь на невероятном канале uWebDesign, Вашем путеводителе в мире web разработки! Здесь вы найдете лучшие обзорные ролики и подкасты про web технологии на русском языке: web и ux дизайн, инструменты для разработки, языки программирования и многое другое. Больше всего мы концентрируемся на различных CSS модулях, работе с SVG, разработке WordPress сайтов и языке программирования PHP. Приятного просмотра! Расписание роликов: • По вторникам выходит подкаст «Суровый веб». • По пятницам на нашем втором канале выходят игровые стримы: https://youtube.com/uwdgames • От случая к случаю на канале выходят обзорные ролики про Web технологии, а также уроки про Adobe Illustrator.

Последние сообщения

5 полезных сервисов для бесплатного образования и поиска работы
127 полезных и бесплатных онлайн академий
Ресурсы для objective-C программистов

КАРЬЕРА В КАРМАНЕ

МЫ РЕКОМЕНДУЕМ

→ CAREERBOX.RU – ПРОЕКТ: “КАРЬЕРА В КАРМАНЕ”

→ YOUTUBE.COM – ВИДЕОБЛОГ “ВРЕМЯ ВПЕРЕД!”

→ SMMBOX.COM – ОТЛОЖЕННЫЙ ПОСТИНГ И ПОИСК КОНТЕНТА

КАТЕГОРИИ

Мы в соц. сетях

ПОДПИСЫВАЙСЯ НА НАС

ВКОНТАКТЕ

ОДНОКЛАССНИКИ

О НАС

Онлайн Академия создана для решения актуальных проблем существующей образовательной системы. Мы стремимся помочь молодым специалистам получить те знания, которые им необходимы для успешного трудоустройства и продуктивной работы. Мы рады, что Вы выбрали электронное образование!

Как правильно использовать переменные в препроцессорах LESS и SASS

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

Предыстория

В 2014 году в компании начали редизайн проекта и в основу вёрстки мы положили свежий на тот момент Bootstrap 3.0.1. Использовали мы его не как отдельную стороннюю библиотеку, а тесно заинтегрировали с нашим собственным кодом: отредактировали переменные под наш дизайн и компилировали кастомизированный Бутстрап из LESS исходников самостоятельно. Проект оброс собственными модулями, которые использовали бутстраповские переменные и добавляли в файл с настройками свои новые переменные.

В тот момент я думал, что это правильный подход.

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

Через год с небольшим редизайн закончился, проект вышел в продакшн, и мы взялись за технический долг. При попытке обновить Бутстрап до версии 3.6.x выяснилось, что смержить новый variables.less с нашим файлом настроек будет нелегко. В Бутстрапе переименовали или убрали часть переменных, добавили новые. Собственные компоненты Бутстрапа обновились без проблем, а вот наши компоненты падали при компиляции из-за этих изменений.

Проблемы

Мы проанализировали ситуацию и сформулировали проблемы.

Слишком связанный код.

Сами компоненты лежали в отдельных файлах. Это создавало иллюзию, что компоненты независимые. Но компоненты использовали переменные, объявленные во внешнем файле variables.less, и без этого файла не работали. Нельзя было просто так взять и переместить компонент в другой проект. Приходилось тянуть за собой файл с настройками, который со временем превратился в помойку.

Слишком много глобальных переменных.

У Бутстрапа было ≈400 переменных. Мы отключили неиспользуемые компоненты Бутстрапа, но переменные оставили в конфиге на случай, если снова понадобятся. Еще мы добавили сотню или полторы своих переменных. Все названия не запомнить, трудно быстро находить нужные. Даже с правилами именования и комментариями ориентироваться в конфиге из 500+ переменных тяжело.

Имена глобальных переменных вышли из-под контроля.

Одна и та же переменная могла использоваться в разных файлах и отслеживать все её появления в коде было долго и трудно. Когда меняли значение переменной в одном компоненте, был риск поломать другие компоненты. Разработчики хардкодили, создавали новые переменные с похожими названиями и значениями и уже не следили за логикой именования.

Топ-пост этого месяца:  Как показать программные и исходные коды в статьях WordPress

Как решать

Я придумал три правила, которые помогли побороть наши проблемы:

Переменная используется только в том файле, в котором объявлена.

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

Все переменные внутри компонента — локальные.

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

Глобальные переменные используются только внутри файла настроек.

Благодаря первым двум правилам мы сильно сократим количество глобальных переменных, но они всё равно нужны. Глобальные переменные объявляются в главном файле проекта или в файле типа config.less. К ним тоже применяется правило №1 — переменные не используются за пределами своего файла. Это значит, что нельзя использовать глобальные переменные внутри файлов компонентов. Но существует способ не нарушая первого правила прокинуть значение глобальной переменной внутрь компонента. Как это сделать мы рассмотрим на примерах далее.

Третье правило избыточное. Соблюдая первые два, вы автоматически соблюдаете третье. Но в реальной жизни есть очень большой соблазн пойти по простейшему пути, не создавать локальную переменную, а по-быстрому использовать глобальную. Третье правило напоминает, что так делать вредно, что это создаёт ненужные зависимости и приводит к связыванию кода.

Применим правила на практике.

Реализация на LESS

Представим простейший компонент для стилизации страницы. Согласно правилу №1 создадим переменные внутри файла компонента.

Правило 1
Переменная используется только в том файле, в котором объявлена.

Было. Пример кода компонента.

Стало. Переменные объявлены в глобальной области видимости и у них слишком общие имена. Это плохо.

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

Локальные переменные

Область видимости — это «пространство» между фигурными скобками селектора: < и >. Объявленные внутри фигурных скобок переменные работают только внутри этих скобок и внутри дочерних скобок, но их нельзя использовать снаружи.

Если скобок вокруг нет, то это самый верхний уровень — глобальная область видимости.

У переменной из дочерней области видимости приоритет выше, чем у одноименной переменной из родительской области видимости. У глобальных переменных самый низкий приоритет при совпадении имён.

По правилу №2 сделаем переменные локальными — переместим их внутрь селектора.

Правило 2
Все переменные внутри компонента — локальные.

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

Теперь конфликта имен с другими компонентами не будет. Мы решили первую и вторую проблемы: получился изолированный сниппет без внешних зависимостей. Но я не знаю способа переопределить локальные переменные компонента в таком виде извне. Поэтому, чтобы кастомизировать компоненты глобальными переменными проекта, придумал другую форму записи.

Миксины как функции

В LESS можно использовать миксины как функции. Если внутри миксина создать переменные, а потом вызвать миксин внутри селектора, то переменные будут доступны в области видимости этого селектора.

Вынесем объявление переменных внутрь миксина .page-settings() , а потом вызовем его внутри селектора .page :

Миксин доставляет переменные в зону видимости селектора.

Переменные локализованы внутри глобального миксина. Когда мы вызвали миксин в коде, переменные стали доступны в области видимости селектора .page , но по прежнему остались локальными.

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

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

Слияние миксинов

В LESS существует «ленивое вычисление» переменных: не обязательно объявлять LESS-переменную перед её использованием, можно объявить после. В момент компиляции парсер LESS найдет определение переменной и отрендерит значение этой переменной в CSS.

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

Итак, переменные можно объявлять и до, и после использования, а миксины — это разновидность переменных. Если создать два миксина с одним и тем же именем и разным содержанием, то они объединяют свои внутренности. А если внутри миксинов есть переменные с одинаковыми именами, то происходит переопределение. Приоритет выше у последнего миксина.

Рассмотрим три файла:

Главный файл. Импортируем компоненты и конфиг. Конфиг — последним.

Компонент. Все переменные локальные и хранятся в миксине.

Конфиг проекта. Переопределяем параметры компонента с помощью миксина настроек.

Всё самое интересное происходит в конфиге. Мы создали глобальные переменные и использовали их в этом же файле для кастомизации компонента.

Миксин .page-settings() объявлен два раза. Первый раз внутри файла page.less с дефолтными значениями, второй раз в файле config.less с новыми значениями. На этапе компиляции миксины склеиваются, новые переменные переопределяют дефолтные и CSS рендерится с новыми значениями из файла конфигурации.

Правило 3
Глобальные переменные используются только внутри файла настроек.

Обратите внимание, что config.less инклюдится последним в списке. Это нужно, чтобы объявление миксина в конфиге имело больший приоритет, чем исходное объявление в файле самого компонента. Настройки не применятся, если поставить config.less до компонента, потому что на миксины тоже действуют правило «последнее определение — самое сильное».

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

  1. переменные использовались только в своём файле, даже глобальные переменные не вызывались за пределами файла config.less ;
  2. переменные компонента остались локальными и не засорили глобальную область видимости;
  3. глобальные переменные не использовались внутри компонента напрямую, но значения глобальных переменных хитрым способом попали внутрь компонента.

Ограничения

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

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

Правильно. У глобальных переменных свой префикс glob-, что исключает совпадение имён.

Реализация в SASS

SASS отличается от LESS и больше похож на скриптовый язык программирования: нет «ленивых вычислений» и переменная должна быть обязательно объявлена до её использования в коде. Если определить переменную и использовать её в коде, а потом переопределить и использовать ещё раз, то в первый вызов получим исходное значение в CSS, а во второй вызов новое значение. Трюк с миксинами, как в LESS, не пройдет. Но есть другие пути решения.

Наборы переменных для настройки компонента удобно хранить в map-объектах. Это массив из пар «ключ: значение». Метод map-get извлекает конкретное значение из массива, метод map-mergeобъединяет два массива в один, дополняя или переписывая исходный массив.

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

Настройки хранятся в map-объекте и вызываются в коде с помощью map-get

Чтобы настраивать компонент из другого файла, нужно предусмотреть возможность смержить внешний конфиг с исходными настройками. Рассмотрим три файла:

Главный файл.
Сначала импортируем конфиг, потом компоненты.

Настройки.
Создаём глобальные переменные и переопределяем параметры компонента.

Компонент.
Добавили проверку: а не существуют ли уже настройки, чтобы переопределить компонент?

[1] — В компоненте мы сначала объявили переменную с пустым массивом $page-override .

[2] — Потом проверили, а не существует ли уже переменная $page-settings . И если она уже была объявлена в конфиге, то присвоили её значение переменной $page-override .

[3] — И потом смержили исходный конфиг и $page-override в переменную $page-settings .

Если массив $page-settings был объявлен ранее в глобальном конфиге, то $page-override перепишет настройки при слиянии. Иначе в переменной $page-override будет пустой массив, и в настройках останутся исходные значения.

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

В результате, мы получаем всё те же преимущества, только в отличие от LESS нам приходится переопределять все настройки заранее, перед их использованием в коде.

Выводы

Не важно на чем вы пишете — на LESS, SASS, CSS c кастомными свойствами или Javascript — глобальных переменных должно быть как можно меньше.

С CSS препроцессорами используйте три правила, которые помогут избежать хаоса:

  1. Переменная используется только в том файле, в котором объявлена.
  2. Все переменные внутри компонента — локальные.
  3. Глобальные переменные используются только внутри файла настроек.

Чтобы прокинуть глобальные настройки внутрь компонента, собирайте переменные в миксин (LESS) или map-объект (SASS).

Переопределяйте настройки в правильном месте: в LESS — после инклюда, в SASS — перед инклюдом.

Реальные примеры

Я сформулировал эту методику в декабре 2015 года для LESS и с тех пор применяю её на рабочих и личных проектах.

За полтора года появилось несколько публичных npm-пакетов. Посмотрите исходный код для лучшего понимания, как это работает в реальных ситуациях.

bettertext.css — типографика для сайтов. Настраивается при помощи 11 переменных, остальные 40 вычисляются по формулам. Вычисления идут отдельными миксином, чтобы была возможность переопределять формулы. У компонента нет ни одного класса, все стили применяются к тегам. Чтобы создать локальную область видимости, я поместил все селекторы по тегам в переменную — в LESS это называется «detached ruleset».

links.less — стили для ссылок с фокусом, анимацией и бледным подчеркиванием. У компонента кроме миксина с настройками есть дополнительные глобальные миксины для раскрашивания ссылок внутри ваших собственных селекторов.

flxgrid.css — генератор HTML-сеток на флексах. Настраивается при помощи 5 переменных, генерирует классы для адаптивной сетки с любыми брейкпоинтами и любым количеством колонок. В компоненте вычисления и служебные миксины спрятаны внутрь локальной области видимости. Глобально виден только миксин с настройками.

space.less — инструмент для управления отступами в вёрстке. Создан, чтобы работать в паре с сеткой flxgrid.css. Адаптивность у них настраивается одинаково, но space.less использует собственный миксин настройки и собственные локальные переменные — в коде space.less никак не связан с flxgrid.css.

«Бонус-трек»

Если бы мне сейчас понадобилось использовать на новом проекте Bootstrap 3.x.x — тот, который на LESS, — я бы все импортируемые модули Бутстрапа завернул в переменную (в «detached ruleset»), а все настройки из файла variables.less в миксин bootsrtap-settings . Глобальные переменные Бутстрапа перестали бы быть глобальными и их невозможно было бы использовать внутри собственного кода. Настройки Бутстрапа я бы кастомизировал по мере необходимости, вызывая миксин bootsrtap-settings в конфиге проекта, так же как в примерах выше. Тогда при обновлениях Бутстрапа пришлось бы поправить только миксин с кастомизированными настройкам.

Читают сейчас

Похожие публикации

  • 28 января 2015 в 10:21

Sass-архитектура вашего проекта

Цвета и разница между ними в LESS / Sass

+(AppStore *) Timera: архитектура приложения и особенности разработки

Вакансии

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Комментарии 13

Эээм… а зачем копипастить свою же статью еще и на хабр?

Спасибо за статью!

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

С точки зрения Sass, логичней было использовать флаг !default , это позволило бы избежать использование объектов в целом и связанной с ними проблемы склеивания, а также весьма громоздкий способ извлечения данных из этого самого объекта, и вообще приличного количества boilerplate-кода только для того, чтобы это работало в каждом компоненте.

Кроме того, с точки зрения оптимизации, в Sass все эти склейки, проверки на присутствие переменной, а также map-get в больших количествах неприятно отразятся на скорости компиляции в больших проектах, и это так даже, увы, с libsass .

Что касается глобальных переменных, то их было бы достаточно именовать с префиксами, как уже было сказано в статьи, ( global или именим фреймворка, как у нас. Это эффективно изолирует их от локальных переменных, в следствии чего в локальных файлах можно смело использовать переменные без каких-либо префиксов и хитрых оберток в виде объекта — они ничего не сломают, потому что с глобальными переменными конфликтовать никогда не будут, а если такая же локальная переменная ( $padding ) встретится в другом компоненте, это тоже ничего не сломает, при условии что все используемые в данном файле локальные переменные всегда будут объявляться в начале файла:

Вот пример как компонент Kotsu устанавливает локальное значение $padding , которое по умолчанию устанавливается на глобальное значение ekzo-space() . Просто и без каких-либо излишеств.

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

Пример такого миксина:

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

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

Мне тоже не нравится медленный boilerplate-код в Sass, но !default не работает так, как мне надо. Смотрите, почему.

Мы объявляем локальные переменные внутри компонентов с флагом !default. Пока мы не пытаемся их переопределить извне, всё хорошо — переменные локальные, соседним компонентам не мешают.

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

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

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

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

Значения общих переменных было менять слишком опасно — они использовались во многих местах. Каждый раз надо было лезть в файл с переменными, искать среди сотен переменных нужную, а потом проверять, а не используется ли эта переменная ещё в каких-нибудь компонентах. И если используется, то создавать новую переменную. Вменяемые имена переменных быстро закончились. Проблемы росли как снежный ком.

Далее, в вашем примере:

$padding — объявлена в глобальной области видимости и без префикса. Значит в компоненте №3, №4 и так далее паддинг будет равен 20px. Это уже ошибка.

В примере «компонент Kotsu» переменная $wrapper-padding не локальная, она объявлена в глобальной области видимости. Кроме этого, для её определения использована переменная из другого файла. Т.е. ваш компонент не сможет скомпилироваться самостоятельно без внешнего файла, в котором объявлена переменная ekzo-space().

Я стараюсь этого избежать, мне нужно, чтобы компоненты были по-настоящему независимыми.

С мэпами новый объект полностью переопределяет дефлотный объект. Если в дефолтном конфиге три переменные, а мы переопределяем только две, то одна переменная теряется. Т.е. чтобы такой вариант переопределения работал, нужно переобъявлять все переменные. Мне такой вариант не нравится: если мы добавили в компонент новую переменную, нужно сходить в конфиг и повторно объявить её там — слишком легко ошибиться.

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

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

Ремарка: буду продолжать говорить исключительно о Sass, поскольку с Less у меня опыт не полноценный и там скоупинг работает иначе.

Мы объявляем локальные переменные внутри компонентов с флагом !default. Пока мы не пытаемся их переопределить извне, всё хорошо — переменные локальные, соседним компонентам не мешают.

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

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

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

Как я уже говорил, неймспейсить нужно только глобальные переменные, это нормальная практика для большинства языков программирования. Неймспейсить «локальные»» переменные (даже если они в глобальном скоупе, но используются только локально) — затея, как вы уже сами сказали, болезненная, но она и не нужная. Она ничего не дает. В том же Ruby и Python так не далают. В JavaScript иногда тоже можно встречаться с этой проблемой, но и в этом случае ничего неймспейсить не нужно — последний let myVar перезапишет переменную с нужным нам значением в текущем скоупе.

В Бутстрапе на Less так и сделано, есть переменные общего назначения без префикса, а также у каждого компонента есть свои глобальные переменные с префиксом. Но переменные всех компонентов хранятся в одном внешнем файле и общие не отличаются от компонентных по формату написания имени.
Мы запутались и не справились с поддержанием порядка в именовании. Сначала использовали общие переменные в своих компонентах, потом по невнимательности стали использовать переменные из соседних компонентов.

Если я правильно понял из описание, то вот как раз это «инвертированное» или «всеобщее» прифексирование в Бутраспе и создает эти неприятные запутывания.

Там где нужны были действительно глобальные переменные — нужно было префексировать. В остальных случаях было логичней инкапсулировать параметры как дефолтные в миксины.

Для простых случаев можно помещать «локальные» переменные прямо в файл, без префиксов и скоупинга в классе, но это будет подходить только для стилей сайтов. В остальных случаях — миксины и дефолтные значения.

Значения общих переменных было менять слишком опасно — они использовались во многих местах. Каждый раз надо было лезть в файл с переменными, искать среди сотен переменных нужную, а потом проверять, а не используется ли эта переменная ещё в каких-нибудь компонентах. И если используется, то создавать новую переменную. Вменяемые имена переменных быстро закончились. Проблемы росли как снежный ком.

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

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

$padding — объявлена в глобальной области видимости и без префикса. Значит в компоненте №3, №4 и так далее паддинг будет равен 20px. Это уже ошибка.

Именно так, я это и пытался подчеркнуть в своем посте выше.

Переменная $padding действительно является глобальной, но используется только локально.

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

Кроме этого, для её определения использована переменная из другого файла. Т.е. ваш компонент не сможет скомпилироваться самостоятельно без внешнего файла, в котором объявлена переменная ekzo-space().

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

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

Значит в компоненте №3, №4 и так далее паддинг будет равен 20px

Этой проблемы не должно возникать, поскольку если компонент №3 и №4 используют ту же «локально-глобальную» переменную $padding , она должна всегда объявляться в начале файла. Я не могу себе представить компонент, который без объявления переменной вдруг с бухты-барахты начнет использовать неизвестную переменную $padding .

Нужно понимать, что Sass во многом наследует Ruby, а в нем, как и в Python, скоупинг переменных работает иначе, чем в JavaScript. К примеру, ситуация когда по скоупу выше будет встречаться по своей сути глобальная переменная с весьма общим названием padding = 10 , а потом глубже — padding = 20 абсолютно нормальная, в этом нет никакой проблемы. Проблемы могут быть разве что у разработчика, который почему-то забывает объявить нужные переменные, чтобы случайно не использовать глобальное значение.

Так это работать, конечно, не будет. !default нужен для других случаев. И, в общем-то, глядя на ваши примеры, я бы сказал что случай этот не ваш.

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

В этом нет никаких проблем. Миксин — это по сути своей функция, как раз форма инкапсуляции. И я уже писал выше о том, что во многих языках это нормально вызвать функцию после импорта, и это как раз ожидаемое поведение. Необходимость что-либо импортировать, а потом внезапно вызвать какие-то другие непонятные миксины (а в случае Sass еще и прописывать внезапную переменную $*-override ) для конфигурации другого миксина — это это как раза не ожидаемое поведение.

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

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

Да, но для этого у вас целый свой огород с велосипедами. Если в Less-версии они смотрятся по крайней мере приемлимо, сам язык предрасположен к таким манипуляциям, то по Sass явно видно как он сопротивляется всему этому и результат не просто для конечного восприятия и использования. Это как-то уже намекает на то, что в подходе что-то не так.

Я пишу в основном на Less и методику сформулировал изначально для Less. Реализация на Sass — это калька с Less методики. Да, Sass сопротивляется и то, как всё это выглядит на Sass, мне не нравится.

Я согласен, что в Sass проще избежать проблем, с которыми я встретился в Less. Достаточно обнулять переменные в начале каждого компонента. В Less так не получится. Правило №1 по прежнему в силе и для Less, и для Sass: объявлять переменные в том же файле, в котором они используются.

Урок 10. Препроцессор Sass. Директивы @for, @each и @while

CSS препроцессор это профессиональный инструмент который должен освоить каждый web-разработчик.

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

Однажды, попробовав использовать CSS препроцессор, вы поймете, как давно вам этого не хватало. Вы больше не сможете работать без него, а поможет вам в изучении препроцессора SASS данный видеокурс от команды WebForMySelf.

Урок 0. Препроцессор Sass. Введение

Урок 1. Препроцессор Sass. Установка и настройка окружения

От автора: в данном видеоуроке мы начнем подготовительную работу для дальнейшего изучения CSS препроцессора SASS, немного поговорим об автоматизации и настроим для работы таcк раннер Gulp.

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

Урок 2. Препроцессор Sass. Компиляция при помощи приложения

От автора: Компилировать код можно несколькими способами. В данном уроке мы рассмотрим еще одну возможность компиляции кода препроцессора SASS посредством использования приложения Koala.

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

Урок 3. Препроцессор Sass. Переменные и вложенность

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

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

Урок 4. Препроцессор Sass. Импорты и фрагментация

От автора: в текущем уроке мы познакомимся с директивой @import, поговорим о некоторых отличиях данной директивы от CSS правила import, а также обсудим, каким образом препроцессор SASS предоставляет нам возможность создавать scss или sass файлы, которые не компилируются в CSS код.

По результатам видеоурока вы увидите, как работает и каким образом мы можем подключать файлы при помощи директивы @import в препроцессоре SASS. Узнаете, что такое фрагменты и в чем их отличие от обычных scss файлов.

Урок 5. Препроцессор Sass. Наследование и селектор расширения

От автора: продолжая изучение препроцессора SASS, мы познакомимся с одним из способов, как избавиться от дублирования кода при помощи использования директивы @extend и рассмотрим селектор расширения, который применяется при использовании данной директивы.

По результатам урока вы узнаете, каким образом происходит компиляция при использовании директивы расширения, сможете использовать множественные расширения, а также изучите новый шаблонный селектор в препроцессоре SASS, который не компилируется в css код.

Урок 6. Препроцессор Sass. Миксины. Часть 1

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

По результатам урока вы узнаете, что такое миксины, познакомитесь с синтаксисом их создания и объявления. Помимо этого мы попробуем использовать вложенные миксины, а также поговорим о директиве @content, которая позволяет размещать стили внутри подключаемого миксина.

Урок 7. Препроцессор Sass. Миксины. Часть 2

От автора: в данном уроке мы продолжаем изучение миксинов, где обсудим все возможности переда-чи параметров, которые в дальнейшем можно использовать внутри самого миксина.

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

Урок 8. Препроцессор Sass. Операторы и директива условия @if

От автора: в данном уроке мы познакомимся с некоторыми встроенными операторами в препроцессор SASS, а именно: сложением, вычитанием, умножением и делением. Помимо операторов будет рассмотрена директива условия @if, которая позволяет устанавливать определенные стили в зависимости от различных условий.

Из урока вы узнаете основные особенности и недостатки при работе с встроенными операторами, после чего разберетесь с возможным применением условной директивы @if, которую мы используем на небольшом практическом примере при создании миксина кнопки.

Урок 9. Препроцессор Sass. Функции

От автора: в текущем уроке мы поговорим о возможности создания собственных функций в препроцессоре SASS, а также рассмотрим несколько встроенных функций, которые постоянно применяются на практике.

По результатам урока вы научитесь создавать собственные функции, которые при необходимости можно использовать во всех будущих проектах. Мы рассмотрим практический пример создания функции, которая будет производить перевод значений межсимвольного интервала из photoshop в единицы измерения CSS. После чего перейдем к изучению встроенных функций darken и lighten.

Урок 10. Препроцессор Sass. Директивы @for, @each и @while

От автора: в заключительном уроке будут рассмотрены директивы @for, @each и @while, при помощи которых мы можем выводить некоторый набор стилей определенное количество раз.

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

Циклы в Sass

Циклы позволяют последовательно изменять значение переменной в заданных пределах и подставлять полученное значение в имена классов, значения свойств, а также использовать в вычислениях. Для создания цикла в Sass предназначена команда @for .

Для примера возьмём цикл от 1 до 3, он будет записываться в следующем виде.

Здесь $i это переменная-счётчик, в которой хранится номер итерации, 1 — начальное значение, 3 — конечное. Не обязательно использовать именно эти цифры. Числа могут быть и отрицательными, а цикл начинаться и с большего числа, тогда значение счётчика будет последовательно уменьшаться, а не увеличиваться, как обычно.
Теперь у нас есть переменная $i, которую мы можем подставлять внутри цикла куда нам требуется. В вычислениях переменная так и пишется, а вот в именах классов или в значениях свойств мы уже должны писать как #<$i>.

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

Для этой картинки введём три класса, каждый из них соответствует фрагменту изображения. Отличаться стиль для каждого спрайта будет именем класса и значением background-image. Вот как запишется Sass.

Первый спрайт имеет нулевые координаты у значения background-image, поэтому цикл мы начинаем с нуля, чтобы не делать дополнительные вычисления. Высота каждого спрайта одинакова и равна 31 пиксель, так что получить нужную нам координату легко — достаточно умножить переменную $i на 31. Обязательно надо добавить к значениям px, иначе стили не будут поняты корректно.

Добавить комментарий