Несколько советов по CSS, основанных на работе с Sass экономия времени при разработке

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

4 возможности Sass, которые вы не использовали

25 Августа 2015

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

1. CSS и строчные комментарии

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

Sass дает возможность оставлять обычные CSS комментарии, начинающиеся с /* и заканчивающиеся */ . В такие комментарии можно включать несколько строчек текста и останутся в том же виде в итоговом CSS. Поэтому SASS откоментированный следующим образом:

Преобразуется в следующий CSS:

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

После компиляции в CSS, в коде останется только многострочный комментарий:

2. Локальные и глобальные переменные

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

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

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

В сгенерированном CSS переменная $color_success примет новое значение:

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

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

3. Плэйсхолдеры для расширений

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

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

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

Этот код генерирует CSS без каких либо упоминаний %prominent или %subtle , но с применением их стилей:

В данном примере мы не использовали селектор %subtle , поэтому он не оказался в скомпилированном коде и наш CSS не увеличился в размере.

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

В скомпилированном коде, переопределение экстенда в классе .notice не отражается:

4. Амперсанд для родительского селектора

Одна из базовых возможностей SASS, о которой узнают разработчики это амперсанд (&). Когда вы используете амперсанд перед селектором внутри набора правил, селектор прикладывается к родительскому, что особо удобно для псевдоклассов :hover или ::after . И код SCSS:

Дает следующий CSS:

Но это не единственное применение амперсанда. Когда вы помешаете амперсанд внутрь набора стилевых правил, стили класса , объявленного после амперсанда будут работать только если элемент с этим классом является потомком элемента, для которого написаны базовые правила. Иногда бывает нужно задать стиль, применяющийся лишь в определенных условиях. Например, мы хотим задать границу элементу .hoverable являющемуся потомком элемента .special :

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

Но с добавлением амперсанда мы делаем то же самое, не покидая пространство селектора .hoverable :

И соответствующий CSS:

Вы видите, что сделала всего одна строчка с амперсандом? Sass заменил амперсанд родительским селектором, задав таким образом стили для .hoverable внутри .special .

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

Использование CSS препроцессоров для экономии времени

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

Пункты для размышления

  • Что такое препроцессор?
  • Чем хороши препроцессоры?
  • Что означает, что препроцессор «компилирует в CSS»?
  • Что такое SASS/SCSS?
  • Как использовать SASS для создания вложенных CSS?
  • Как использовать SASS для работы с переменными в вашем коде?
  • Почему использование миксинов (mix-ins) с SASS так здорово?
  • Если вы не используете Rails, как настроить SASS?
  • Что такое LESS и чем он отличается от SASS?
  • Какие еще бывают препроцессоры?

Задание

  1. Прочитайте Введение в CSS препроцессоры от Стивена Бредли (Steven Bradley)
  2. Прочитайте 10 причин для использования препроцессоров
  3. Прочитайте про выбор правильного CSS препроцессора от Treehouse
  4. Просмотрите руководство по первым шагам в SASS, которое предоставляет краткий обзор интересных функциональных возможностей
  5. Обзор от A List Apart о том, как использовать SASS (большое количество лучших практик), прочитайте и наслаждайтесь!
  6. Почему стоит использовать препроцессоры (рус.яз.)
  7. Прочитайте Изучаем SASS: руководство для новичка или Руководство по SASS для абсолютных новичков на русском.
  8. Разбираемся в отличиях препроцессоров CSS (рус.яз.)

Дополнительные ресурсы

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

ТИПИЧНЫЙ ВЕРСТАЛЬЩИК

Если ты хочешь двигаться дальше, изучить что-то новое, ускорить свою верстку, отойти от метода only HTML/CSS, only hardcore, то изучение CSS-препроцессора — первый шаг к этому. Изучить CSS-препроцессоры, например SCSS не так сложно, как кажется.
«Окей, но с чего же начать?» — спросишь ты. Все просто:

Изучи основы синтаксиса

Заходишь на сайт sass-scss.ru/guide, просматриваешь основы синтаксиса для SASS и SCSS и выбираешь то, что тебе по душе. Например, SCSS максимально поход на CSS, однако SASS содержит в себе меньше символов.

Загляни в документацию

Для более подробной документации загляни сюда: sass-scss.ru/documentation

Установи программу или использую командную строку

Для работы с препроцессором у Вас есть выбор: установить программу (платную или бесплатную) или использовать командную строку для работы. Подробнее тут: sass-scss.ru/install Например, я использую программу Koala и вижу в ней множество плюсов.

Подготовь проект на своем компьютере

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

Создай файл

В своем текстовом редакторе создай файл, с которым ты будешь работать. Например присвой ему имя style.scss.

Скомпилируй файл

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

Верстаем

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

Основы Sass

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

Препроцессинг

Написание CSS само по себе весело, но когда таблица стилей становится огромной, то становится и сложно её обслуживать. И вот в таком случае нам поможет препроцессор. Sass позволяет использовать функции недоступные в самом CSS , например, переменные, вложенности, миксины, наследование и другие приятные вещи, возвращающие удобство написания CSS.

Как только Вы начинаете пользоваться Sass, препроцессор обрабатывает ваш Sass-файл и сохраняет его как простой CSS -файл, который Вы сможете использовать на любом сайте.

Самый простой способ получить такой результат — использовать терминал. После того, как Sass установлен, вы можете компилировать ваш Sass в CSS , используя команду sass . Вам всего лишь нужно сообщить Sass, где взять файл Sass и в какой файл CSS его скомпилировать. Например, запустив команду sass input.scss output.css в терминале, вы сообщаете Sass взять один Sass файл, input.scss , и скомпилировать в файл output.css .

Также, вы можете следить за изменениями только определенных файлов или папок, используя флаг —watch . Данный флаг сообщает Sass, что необходимо следить за изменениями указанных файлов и при наличии таковых производить перекомпиляцию CSS после сохранения файлов. Если вы хотите отслеживать изменения (вместо ручной перекомпиляции) вашего файла, например, input.scss , то вам необходимо просто добавить флаг в команду:

sass –watch input.scss output.css

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

Sass будет отслеживать все файлы в директории app/sass и компилировать CSS в директорию public/stylesheets .

Переменные

Думайте о переменных, как о способе хранения информации, которую вы хотите использовать на протяжении написания всех стилей проекта. Вы можете хранить в переменных цвета, стеки шрифтов или любые другие значения CSS , которые вы хотите использовать. Чтобы создать переменную в Sass нужно использовать символ $ . Рассмотрим пример:

SCSS Syntax

Sass Syntax

CSS Output

Когда Sass обрабатывается, он принимает значения, заданные нами в $font-stack и $primary-color и вставляет их в обычном CSS -файле в тех местах, где мы указывали переменные как значения. Таким образом переменные становятся мощнейшей возможностью, например, при работе с фирменными цветами, используемыми на всем сайте.

Вложенности

При написании HTML , Вы, наверное, заметили, что он имеет четкую вложенную и визуальную иерархию. С CSS это не так.

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

Чтобы понять что мы имеем ввиду, приведем типичный пример стилей навигации на сайте:

SCSS Syntax

Sass Syntax

CSS Output

Вы заметили, что селекторы ul , li , и a являются вложенными в селектор nav ? Это отличный способ сделать ваш CSS -файл более читабельным. Когда вы сгенерируете CSS -файл, то на выходе вы получите что-то вроде этого:

Фрагментирование

Вы можете создавать фрагменты Sass-файла, которые будут содержать в себе небольшие отрывки CSS , которые можно будет использовать в других Sass-файлах. Это отличный способ сделать ваш CSS модульным, а также облегчить его обслуживание. Фрагмент — это простой Sass-файл, имя которого начинается с нижнего подчеркивания, например, _partial.scss . Нижнее подчеркивание в имени Sass-файла говорит компилятору о том, что это только фрагмент и он не должен компилироваться в CSS. Фрагменты Sass подключаются при помощи директивы @import .

Импорт

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

Например, у вас есть несколько фрагментов Sass-файлов — _reset.scss и base.scss . И мы хотим импортировать _reset.scss в base.scss .

SCSS Syntax

Sass Syntax

CSS Output

Обратите внимание на то, что мы используем @import ‘reset’; в base.scss файле. Когда вы импортируете файл, то не нужно указывать расширение .scss . Sass — умный язык и он сам догадается.

Миксины (примеси)

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

SCSS Syntax

Sass Syntax

CSS Output

To create a mixin you use the @mixin directive and give it a name. We’ve named our mixin transform . We’re also using the variable $property ins >CSS declaration starting with @include followed by the name of the mixin.

Расширение/Наследование

Это одна из самых полезных функций Sass. Используя директиву @extend можно наследовать наборы свойств CSS от одного селектора другому. Это позволяет держать ваш Sass-файл в «чистоте». В нашем примере мы покажем вам как сделать стили оповещений об ошибках, предупреждениях и удачных исходах, используя другие возможности Sass, которые идут рука-об-руку с расширением, классами-шаблонами. Класс-шаблон — особый тип классов, который выводится только при использовании расширения — это позволит сохранить ваш скомпилированный CSS чистым и аккуратным.

SCSS Syntax

Sass Syntax

CSS Output

Вышеуказанный код сообщает классам .message , .success , .error и .warning вести себя как %message-shared . Это означает, что где бы не вызывался %message-shared , то и .message , .success , .error и .warning тоже будут вызваны. Магия происходит в сгенерированном CSS , где каждый из этих классов получает css-свойства, как и %message-shared . Это позволит вам избежать написания множества классов в HTML элементах.

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

Когда вы генерируете ваш CSS , то он будет выглядеть как пример ниже. Обратите внимание, %equal-heights не попадает в CSS , так как ни разу не был использован.

Математические операторы

Использовать математику в CSS очень полезно. Sass имеет несколько стандартных математических операторов, таких как + , — , * , / и % . В нашем примере мы совершаем простые математические вычисления для расчета ширины aside и article .

SCSS Syntax

Sass Syntax

CSS Output

Мы создали простую адаптивную модульную сетку, с шириной в 960 пикселей. Используя математические операторы, мы использовали полученные данные с пиксельными значениями и конвертировали их в процентные, причем без особых усилий. Скомпилированный CSS выглядит так:

  • Текущие версии:
  • Dart Sass1.20.1
  • LibSass3.5.5
  • Ruby Sass ⚰

Sass © 2006–2020 Hampton Catlin, Natalie Weizenbaum, Chris Eppstein, Jina Anne, и многочисленные участники. Доступно для использования и изменения по лицензии MIT.

Sass для самых маленьких — подробное руководство

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

Все примеры и настроенный проект данного урока вы можете скачать с нашего сайта

Sass — это один из наиболее развитых и стабильных CSS препроцессоров, а также один из самых популярных препроцессоров у профессионалов.

Преимущества Sass

  • Совместимость с различными версиями CSS, благодаря которой вы можете использовать любые CSS библиотеки в вашем проекте;
  • Огромное количество разнообразных функций на любой случай жизни. Таким богатым функционалом могут похвастаться немногие CSS препроцессоры;
  • Sass — это один из самых старых CSS препроцессоров, вобравший большой опыт за долгие годы своего существования;
  • Замечательная возможность использовать Sass фреймворки, упрощающие жизнь разработчику. Один из таких фреймворков — Bourbon, который мы используем в некоторых выпусках Джедая верстки при написании Sass;
  • Синтаксис. Вы можете выбрать один из двух синтаксисов, который вам ближе — упрощенный (SASS) и развернутый CSS-подобный (SCSS).

Когда я только знакомился с CSS препроцессорами, мне, как и многим другим начинающим веб-разработчикам, была не до конца понятна сама идея использования CSS препроцессоров. Зачем делать дополнительную прослойку, использовать какие-то инструменты, усложнять CSS, думал я. Но со временем начал понимать, что изо дня в день написание CSS становилось пыткой, серой рутиной, многие действия приходилось повторять, копировать селекторы, свойства и даже целые блоки CSS кода для достижения необходимого результата. Сегодня, на примерах, я покажу вам, как можно упростить работу, используя препроцессор Sass, разнообразить разработку и даже немного поразвлечься при написании каких-то более или менее сложных функций.

Настройка окружения

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

Убедитесь, что у вас установлена последняя версия Node.js и Gulp. Если Node.js не установлен, скачайте его и установите. После установки Node.js установите gulp командой «npm i -g gulp» (Windows) или «sudo npm i -g gulp» (Linux, OS X). Почитать: Подробное руководство Gulp.

В папке вашего проекта выполните команду npm init и заполните пошагово информацию о вашем новом проекте. Пример, также, есть на странице руководства Gulp.

Далее установим в проект пакеты gulp и gulp-sass командой:

Далее в папке проекта создадим gulpfile.js следующего содержания:

Обратите внимание на строку 6 — здесь мы используем один из стилей вывода в результирующий файл: nested — вложенный, по умолчанию; expanded — развернутый; compact — компактный, когда селектор и его свойства в фигурных скобках выводятся в одну строку; compressed — сжатый. Кроме того, благодаря обработке .on(‘error’, sass.logError), если возникнет ошибка, нам не придется перезагружать команду выполенния Gulpfile и мы будем видеть, в какой строке Sass файла у нас ошибка. В примерах я буду использовать стиль вывода expanded для наглядности.

У вас должна быть следующая структура проекта в вашей файловой системе:

    myproject/

      css/

        common.css

      sass/

        common.sass

      node_modules/gulpfile.jspackage.json

Запускаем выполнение Gulpfile командой gulp в терминале папки проекта.

Здесь мы берем все Sass файлы из директории sass/ вашего проекта и выгружаем готовый CSS результат в папку css/. Кроме того, здесь мы устанавливаем наблюдение watch за изменениями в Sass файлах и автоматическую компиляцию в CSS, если такие изменения имеют место быть. Результирующий css файл подключается в верстку.

Если вам что-то не понятно по настройке Gulp пакетов в данном примере, прочтите руководство Gulp.

После того, как наше окружение настроено и Sass успешно преобразуется в CSS при сохнанении *.sass файлов в директории sass/, можно спокойно продолжать обучение и выполнять примеры, которые мы будем сегодня разбирать, на практике.

Синтаксис Sass

Есть 2 варианта написания Sass, 2 синтаксиса: SASS и SCSS. Самый старый вариант написания Sass — это синтаксис отступов. Именно этот вариант написания мы будем использовать в нашем уроке. Расширение файлов для такого синтаксиса — *.sass. Второй вариант — это синтаксис, расширяющий синтаксис CSS, Sassy CSS. SCSS пишется как обычный CSS, но расширен дополнительными возможностями Sass. Расширение файлов с SCSS синтаксисом — *.scss.

Очень важно! Синтаксис отступов требует очень четкого соблюдения отступов у вложенных свойств и если у вас возникают ошибки при запуске Gulp или неявные ошибки без указания строки в консоли — скорее всего, ошибка именно в неправильных отступах. Еще важная деталь — если у вас в качестве отступов используются табы, компилятор выдаст ошибку при попытке конвертировать Sass, в котором помимо табов, также, исвользуются пробелы в качестве отступов. Либо вы используете только табы, либо только пробелы.

SASS и SCSS синтаксис:

SASS — синтаксис отступов SCSS — синтаксис расширения

Кроме базовых правил написания (фигурные скобки, точка с запятой в конце строк), SASS и SCSS различаются также написанием некоторых функций. Так что будьте внимательны при использовании каких-либо примеров из интернета, проверяйте, какой именно синтаксис используется. Если довольно большой пример из интернета выполнен в SCSS стиле, а ваш проект написан в SASS, вы можете его импортировать в ваш основной файл, не меняя синтаксис и расширение файла посредством директивы @import, например, если вы скачали файл carousel.scss, то можете подключить его в ваш main.sass строкой @import «carousel». Также можно поступить в обратной ситуации, когда необходимо импортировать *.sass файлы в файл main.scss. В нашем примере с Гитхаба, мы импортируем все _x.x.sass файлы в один common.sass, где x.x — это номер заголовка примера из данной статьи.

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

1. Расширение возможностей CSS с помощью Sass

1.1 Правила вложения

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

Sass CSS — готовый результат
Sass CSS — готовый результат

1.2 Привязка к родительскому селектору

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

Sass CSS — готовый результат
Sass CSS — готовый результат

Обратите внимание на правило body.firefox &, которое позволяет нам получить новую цепочку от любого элемента до текущего, если установить в конце &.

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

Sass CSS — готовый результат

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

Для удобства, вы можете разбивать суффикс пространства имен свойства на вложения. Например, margin-top, margin-bottom, margin-left, margin-right имеют общую основу margin и могут быть разбиты на вложения следующим образом:

Sass CSS — готовый результат

1.4 Селекторы-шаблоны

Иногда возникает ситуация, когда несколько элементов на странице используют одинаковую CSS базу, одинаковый набор свойств, характерный только для них. Данные базовые CSS правила можно оформить в виде селектора-шаблона для использования в нескольких местах Sass. Селекторы-шаблоны выводятся посредством директивы @extend.

Sass CSS — готовый результат

2. SassScript

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

2.1 Переменные в Sass

Это действительно замечательная возможность — определять переменные, которые можно использовать в любом месте вашего Sass файла. Цвета, дефолтные значения, единицы, все это можно взять в переменную и использовать в дальнейшем. Переменная определяется так: $название: значение.

Sass CSS — готовый результат

2.2 Операции с числами и строками + интерполяция

Sass дает возможность использовать стандартные арифметические операции над числами, такие как сложение (+), вычитание (-), деление (/) и остаток от деления по модулю (%). Операторы сравнения ( , =, ==, !=) также поддерживаются для чисел.

Кроме того, в Sass есть возможность конкатенировать (соединять) строки.

Sass CSS — готовый результат

Как видим из примера $summ: 10 + 20 / 2, соблюдается приоритет в выполнении арифметических операций — сначала деление, потом сложение. Для определения порядка действий, можно использовать круглые скобки, как в математике. Обратите внимание, что при сложении 12px + 8px, мы получим 20px.

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

Интерполяция — это получение нового значения, используя другие.

Чаще всего интерполяция в Sass используется для получения нового значения переменной, благодаря «интегрированию» в значение другой переменной, посредством конструкции #<>, например:

Sass CSS — готовый результат

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

2.3 Операции с цветами

Цвета в Sass можно складывать, вычетать, делить и умножать. Все арифметические операции выполняются для каждого цвета отдельно: красного, зеленого и синего.

Sass CSS — готовый результат

Обратите внимание, что при сложении rgba цветов, последний параметр непрозрачности 0.75 не должен отличаться от других в выражении, иначе произойдет ошибка сложения. Вместо этого, можно регулировать альфа-канал rgba, используя opacify и transparentize или управлять непрозрачностью HEX цвета, посредством функции rgba.

Sass CSS — готовый результат

3. Директивы и правила

3.1 @import

Вы можете импортировать в ваш Sass файл sass, scss и css файлы с помощью директивы @import, при этом все миксины и переменные будут работать в основном файле, в который происходит импорт.

@import сработает как обычный CSS @import, если:

  • в пути к файлу присутствует http://;
  • файл вызывается через url();
  • или в импорте присутствуют медиапараметры.

Для того, чтобы другой файл был полноценно импортирован в основной Sass файл, необходимо, чтобы расширение файла было *.sass, *.scss или *.css.

Давайте рассмотрим некоторые примеры.

Следующие файлы импортированы не будут:

Sass CSS — готовый результат

Следующие файлы будут импортированы:

Sass CSS — готовый результат

Внимание! В новых версиях gulp-sass для импорта CSS файлов в Sass необходимо указывать расширение .css

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

Файлы, которые начинаются с нижнего подчеркивания, называются фрагменты и при импорте не требуют указания подчеркивания и расширения. Например, файл _header.sass можно импортировать так: @import «header».

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

3.2 @at-root

Директива @at-root поднимает содержимые в ней правила в корень, отменяя цепочку от родителя. Тут все просто:

Sass CSS — готовый результат

Мы рассмотрели не все директивы, которые есть в Sass, а только самые используемые на практике. Если вас интересует более глубокое изучение Sass директив, обратитесь к документации.

4. Выражения

Sass поддерживает использование выражений и функций для различных условий, реализации циклов и т.д.

4.1 Директива @if()

Директива @if() позволяет осуществить выполнение SassScript с определенными условиями и имеет следующий синтаксис:

Sass CSS — готовый результат

4.2 Директива @for

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

Sass CSS — готовый результат

Вы можете указать through вместо to, если требуется пройтись от 1 до 11 включительно, а не только до 10, как в примере.

4.3 Директива @each

Если требуется пройтись по списку значений, а не просто чисел, можно использовать директиву @each:

Sass CSS — готовый результат

4.4 Директива @while

@while циклично выводит блоки стилей, пока выражение является true.

Sass CSS — готовый результат

5. Миксины

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

Миксин объявляется директивой @mixin, после объявления должно быть указано имя миксина. Вызывается миксин директивой @include, которая принимает имя миксина и передаваемые аргументы, если такие имеют место быть.

Sass CSS — готовый результат

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

Сразу отвечу на вопрос — как работать с Sass стилями на готовом сайте, неужели нужно править готовый CSS и заливать по FTP? Нет, так делать нельзя. Вы должны иметь локальную копию ваших Sass стилей или даже целого сайта и после окончания работы деплоить (выгружать) по FTP готовые стили. Для этого, вы можете использовать Gulp пакет vinyl-ftp. Или настроить Sass окружение на вашем сервере для компиляции загружаемых по FTP/sFTP файлов.

Премиум уроки от WebDesign Master

Создание контентного сайта на Jekyll от А до Я

Создание современного интернет-магазина от А до Я

Я — фрилансер! — Руководство успешного фрилансера

Преимущества использования препроцессора (Sass) при написании CSS

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

Тем не менее, по мере разрастания проекта поддержка и читаемость CSS становится всё труднее. Разработчики тратят больше времени при работе с тысячами строк CSS-правил, из-за чего повышается стоимость проекта. Поскольку проект становится больше, CSS вызывает некоторые проблемы, такие как:

  • Большие усилия для внесения небольших изменений
  • Трудности при структурировании кода
  • Избыточность кода
  • Бесконечные строки CSS-классов и правил

Препроцессор помогает нам справиться с этими проблемами. Он имеет некоторые преимущества перед обычным CSS. Прежде чем мы погрузимся глубже в тему, для начала стоит выяснить, что же такое CSS-препроцессор…

Что такое CSS-препроцессор?

Это программа/инструмент, имеющая свой собственный синтаксис, который затем компилируется в стандартный CSS-код.

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

Существуют различные препроцессоры, такие как Sass, Less и Stylus. В этой статье я расскажу о некоторых преимуществах Sass.

Что такое Sass?

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

FAQ: Sass или SCSS

Это часто задаваемый вопрос. На самом деле, они оба являются Sass-препроцессором, просто имеют разный синтаксис. Проще говоря, SCSS — это новый синтаксис Sass 3 версии.

Пример синтаксиса Sass:

Пример синтаксиса SCSS:

Как мы можем видеть, SCSS (Sassy CSS) имеет CSS-подобный синтаксис, который намного легче читается. Он является расширением CSS, в то время как синтаксис Sass имеет более существенные отличия. Они также имеют разное расширение файла: .sass и .scss .

Подробнее об этом можно прочитать здесь. А теперь давайте перейдем к особенностям Sass.

Особенность #1: Переменные

В одном проекте разные CSS-классы могут содержать одинаковое правило или группу правил. Например, на странице у нас есть 20 блоков с разным цветом фона:

Позже наш клиент передумал и захотел блоки большего размера. Поэтому мне нужно поменять значения свойств width and height один за другим для каждого класса. А классов может быть и 50. В реальном программировании это может занять много времени. Как я уже упоминал выше, это пример больших усилий для небольших изменений.

Как можно сделать это более эффективно?

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

Возвращаясь к примеру выше, можно задать переменные для свойств width и height :

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

CSS теперь также поддерживает переменные, но они не работают в IE и старых версиях других браузеров:

Особенность #2: Вложенность

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

Например, создадим ниже в HTML навигационное меню с гиперссылками:

HTML поддерживает вложенный код. Но CSS без вложенности будет выглядеть так:

Нам приходится добавлять класс nav для каждого тега, даже для псевдокласса hover, потому что nav является родительским тегом для всех элементов. Однако, Sass поддерживает вложенность:

Используя Sass, мы можем писать более структурированный код, как в HTML. Больше не нужно добавлять nav для каждого класса, что также предотвращает избыточность кода.

Особенность #3: Mixins (миксины)

Выше мы узнали, как применять переменные для CSS-правил. Но что, если нам нужно использовать несколько правил вместе? Для этих целей у Sass есть миксины.

Что такое миксин?

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

Миксин создается с помощью команды @ mixin и названия миксина:

Также можно создать миксин в виде функции и добавлять к ней параметры:

После создания миксина мы можем воспользоваться им в любом классе при помощи команды @ include. Таким образом, мы можем подключить миксин my-font вместо того, чтобы каждый раз писать 4 строки правил для шрифта. Такой подход упрощает код.

Использование миксинов — это хороший способ предотвратить избыточность кода.

Особенность #4: Импорт

Наконец, мы можем разбить наши огромные CSS-файлы на более мелкие с помощью Sass-функции импорта. Гораздо проще читать и поддерживать маленькие файлы, а не один большой файл с бесконечными строками.

Вообще, CSS сейчас тоже имеет функцию импорта. Но там это работает по-другому. Чтобы импортировать файл, CSS каждый раз посылает HTTP-запрос к серверу. Sass делает это без HTTP-запросов, а значит процесс происходит быстрее.

Всё, что требуется сделать — это импортировать один Sass-файл в другой, используя команду @ import:

При указании пути к файлу не нужно добавлять расширение .scss, Sass найдет его и без этого.

Проблема с CSS-препроцессорами

22 декабря 2014

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

Я обдумывал использовать CSS-препроцессоры такие как Sass, LESS, Stylus и другие, достаточно долго. Каждый раз, когда меня спрашивали, использую ли я какие-то из этих инструментов, я отвечал, что я привык к моему текущему рабочему процессу и не вижу причины его менять, поскольку проблемы, которые решают эти инструменты, — не те проблемы, что есть у меня в CSS. Но вчера я прочитал две статьи, которые заставили меня пересмотреть свой взгляд, и я решил потратить немного времени изучая альтернативы и перенести часть кода, чтобы посмотреть, помогут ли препроцессоры сохранить мой код более организованным/удобным в обслуживании и/или сможет ли это сделать процесс разработки проще (с учётом того, развивались ли эти инструменты в последние несколько лет).

Для опытного разработчика изучение большинства возможностей препроцессоров занимает пару часов (после того, как вы изучили первую пару, следующие идут легче). Но если у вас нет навыков программирования кроме как CSS/HTML и/или вы не знаете основной логики программирования (циклы, функции, области видимости), это, возможно, займёт больше времени. Командная строка — это ещё одно препятствие для CSS/HTML разработчиков. Но не в этом цель статьи, я буду конкретно говорить о злоупотреблении этими возможностями. Я попробую объяснить большую часть основных проблем, которые я вижу, когда каждый раз кто-то показывает мне пример кода, или я вижу проект, написанный с использованием любого из этих препроцессоров.

Примеси

Что такое примеси?

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

Глупое дублирование кода является глупым

Следуя синтаксису SCSS (Sass), примеси могут быть описаны и использованы следующим образом:

Что компилируется в:

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

Эта проблема не является специфичной для Sass, она также существует в LESS, и в Stylus, и в любом другом препроцессоре, который поддерживает эту возможность. Используя новый слой абстракции, разработчик не осознаёт, что он создаёт сильно дублирующийся код. Всегда сжимайте файлы CSS и JavaScript. Gzip очень хорошо сжимает дублирующиеся данные, так что эта проблема может быть несущественной на продакшене. Только учтите, что сгенерированный CSS-код будет тяжелее поддерживать в случае, если ваши будущие разработчики по каким-то причинам решат прекратить использование препроцессора и просто обновят сгенерированный CSS (может, у них не будет доступа к исходным файлам или не будет опыта работы с препроцессорами).

Расширение

LESS и Stylus не поддерживают ничего похожего на расширение, поэтому я выбрал SCSS (Sass) для написания примеров. Расширение — это что-то наподобие «более умной» примеси: вместо копирования и вставки свойств оно единожды установит множественный селектор для этих свойств.

Что компилируется в:

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

Расширения недостаточно

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

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

Я действительно желаю, чтобы Sass улучшил способ работы @extend (а также другие препроцессоры унаследовали бы аналогичную возможность), чтобы мы могли создавать много базовых классов для повторного использования в коде и не экспортировали бы их без необходимости. Что-нибудь наподобие:

Что компилируется в:

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

Другой проблемой будет совмещение вложенных селекторов и @extend . Это может привести к нежелательным побочным эффектам.

Расширение и примеси могут быть неудобны в обслуживании

Вопреки общим знаниям, расширение других классов или создание примесей могут ухудшить обслуживание. Из-за того, что место, где вы использовали свойства, находится далеко от места, где они были определены, есть больше шансов, что вы измените свойства, не замечая, что затрагиваете множество объектов сразу, или не осознавая, к каким элементам эти изменения применятся. Это называется «тесная связь»:

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

  • Изменение в одном модуле обычно создаёт волновой эффект в изменениях в других модулях.
  • Группа модулей может потребовать больше усилий и/или времени в связи с увеличением межмодульной зависимости.
  • Конкретный модуль может быть труднее использовать и/или тестировать из-за необходимости включать зависимые модули.

Википедия

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

Максимально избегая редактирования базовых классов, следуйте «принципу открытости/закрытости» насколько это возможно (дополняйте базовые классы, не редактируйте их).

Вложенность

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

Что компилируется в:

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

Называйте меня странным, но я также считаю вложенный код тяжёлым для восприятия (так как я писал невложенным CSS более 7 лет).

Заключение

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

Моё отношение к этим препроцессорам такое же как и к CoffeeScript: отличный синтаксис и возможности, но слишком много накладных расходов для не такой реальной выгоды. Синтаксис в JavaScript это не проблема для меня, точно так же как и в CSS (и в большинстве языков). Вам всё равно необходимо понимать, как работает блочная модель, специфичность, каскадирование, селекторы, обтекание и так далее. Вы всего лишь добавляете абстрактную прослойку между собой и интерпретируемыми таблицами стилей, создаёте ещё один барьер для будущих разработчиков и увеличиваете шанс появления чрезмерного проектирования. Разметка может стать проще (с меньшим количеством классов/идентификаторов), но она приходит с большим количество недостатков.

Для меня главной проблемой являются разработчики, которые пишут на CSS без знаний необходимых для построения легко сопровождаемых масштабируемых структур. Таблицу стилей полную примесей, операций сравнения, циклов, переменных, функций будет так же тяжело поддерживать, как и раздутую вручную созданную таблицу стилей, а может даже и сложнее. Разработчики унаследовали желание быть «умными», а это обычно как красный флаг.

«Каждый знает, что отлаживание программы в два раза сложнее, чем её написание. Так если вы проявили максимум своих возможностей, когда писали эту программу, как же вы тогда вообще её отладите?» Брайан Керниган

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

«Пришло время упразднять браузерные префиксы. Они стали решением для несуществующей проблемы и активно вредят веб-стандартам» Питер-Пол Кох

Я использовал подход OOCSS на большинстве моих последних проектов и, скорее всего, продолжу использовать его, пока не найду лучшего. Для тех вещей, которыми я занимаюсь, важнее иметь возможность быстро верстать и вносить обновления на этапе разработки, нежели поддерживать/развивать проект в течение многих месяцев/лет. Мне кажется маловероятным, что придётся делать значительные изменения в дизайне без правки разметки. На моих последних 100 проектах это случилось 2-3 раза. CSS zen garden — классный концепт, но не очень практичный. Такая возможность, как desaturate(@red, 10%) крутая штука, но обычно дизайнеры предоставляют мне цветовую палитру, которую надо использовать на всём сайте, и я не так часто дублирую одни и те же значения. Если значения дублируются, я везде могу их поменять, используя «поиск и замену» внутри всех CSS-файлов и закончить на этом. Используя функцию генерирующую цвет (где вы понятия не имеете, какое значение получится) вы не сможете так просто сделать поиск и замену, поскольку вы не знаете, какое значение ищете в исходном коде (я предпочитаю просто использовать Color Picker).

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

С большой силой приходит большая ответственность дядя Бен

В чем сила SASS кроме букв препроцессор

10.01.2020, 19:28

Неполадки с GULP. Error: watching app/sass/*.sass: watch task has to be a function
Подскажите, в чём дело? Запускаю данный код, выдает такую ошибку: PS D:\Web.

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

В чем сила OpenOffice?
Попробовал OpenOffice (сначала 3.2, а теперь и 3.3). Нормальная программа, хотя в ней еще.

Движущая сила прогресса! В чем она?
В чем движущая сила прогресса? Сегодня много современных программ позволяющих выполнять например.

10.01.2020, 19:49 2

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

Банальный пример, вам нужно создать 10 классов типа .mb_n (где n — число с шагом в 5, т. е 5, 10, 15, 25. ) Вы в CSS будете руками создавать эти 10 классов, в SCSS есть циклы, и запись будет занимать пару строк

10.01.2020, 20:07 [ТС] 3 10.01.2020, 20:20 4

Вся разница в восприятии: чем по Вашему мнению являются CSS-препроцессоры?
Если вы считаете, что SASS — это новый CSS с кучей наворотов, — Вы ошибаетесь. Браузеры по-прежнему понимают только CSS. Ничего не изменилось. SASS — это всего лишь инструмент для быстрого и удобного написания CSS-правил. Ни единой новой фичи в сам CSS SASS не привнес.

Если использовать аналогии, то CSS — это отдельный рабочий на заводе, а SASS — это механический конвеер.

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

Лично я еще ни разу не работал с SASS, ибо не занимался разработкой и поддержкой проектов типа Эльдорадо ))

10.01.2020, 20:20
10.01.2020, 20:23 [ТС] 5
10.01.2020, 21:25 6
10.01.2020, 23:44 7

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

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

11.01.2020, 11:01 8

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

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

вы что бы картинки вырезать и со слоями работать фотошоп же устанавливаете, а это так-то малая часть его возможностей, так в чем разница, все эти модули и есть программы для работы компилятора и много чего ещё. 50mb?) На мой взгляд экономить место на жестком диске в 2020 году, ну это как-то странно)

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

11.01.2020, 19:23 9

Для использования SASS gulp не нужен, ровно как и папка в 50метров. Ну а в силу sass я уверовал после просмотра какого то ётайб ролика мастера ёды. И да SASS всё комилирует в чистый ксс, но при этом, если грамотно построить структуру кода на sass то в ксс у вас получиться более сжатый код, нежели бы вы его писали в чистом ксс, ну или меньше времени бы заняло, пока вы думали как бы написать его более лаконично, за вас в случае с SASS это думает и делает SASS.

Вещи, которые мне нравятся:

1) Миксины, вроде всяких уголоков и прозрачностей, одна строка и поехали дальше.
2) Переменные, наппример для шрифтов, что бы 2 буквы вставить и не таскать экран туда сюда что бы скопировать название шрифта, так же удобно задавать переменным цвета, допустим, если у вас стилизованные сайт всего из 5 цветов, и когда заказчик говорит, что это не тот оранжевый, который я видел на дизайне, вы идёт менять шетсеричный код цвета в переменную, а не в 100500+ элементах сайта.

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

Sass Guidelines

Руководство по написанию разумного, поддерживаемого и масштабируемого Sass.

You are viewing the Russian translation by Даниил Пронин, Pavel Demyanenko, Tim Arbaev of the original Sass Guidelines from Hugo Giraudel.

This version is exclusively maintained by contributors without the review of the main author, therefore might not be completely up-to-date.

Об авторе

Меня зовут Hugo Giraudel, я frontend-разработчик из Франции, проживаю в Берлине (Германия) с 2015 года, сейчас работаю в N26.

Я пишу на Sass на протяжении нескольких лет и являюсь автором множества Sass-проектов, таких как SassDoc, SitePoint Sass Reference и Sass-Compatibility. Если вы хотите узнать больше о моем вкладе в Sass сообщество, то ознакомьтесь с этим списком.

Я также являюсь автором книги о CSS (на французском) CSS3 Pratique du Design Web (Eyrolles editions) и книги о Sass (на английском) Jump Start Sass (Learnable editions).

Сотрудничество

Sass Guidelines – открытый проект, которым я руковожу в свободное время. Излишне говорить, что это довольно большой объем работы – держать всё задокументированным в последней версии. К счастью, мне помогает множество участников, особенно когда речь заходит о поддержании десятков разных переводов. Обязательно поблагодарите их!

Теперь, если вы чувстствуете, что готовы к сотрудничеству – пожалуйста, было бы здорово твитнуть, рассказать об этом или открыть Pull Request с исправлением ошибок в репозитории на GitHub!

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

О Sass

Вот так Sass описывает сам себя в своей документации:

Sass — это расширение CSS, которое добавляет силу и элегантность к основному языку.

Основая цель Sass — исправить недостатки CSS. Как мы все знаем, это не самый лучший язык в мире [указать источник] . Являясь довольно простым для освоения, он может быстро стать запутанным, особенно на больших проектах.

Вот тут-то и вступает в свою роль Sass как метаязык, который улучшает синтаксис CSS, чтобы предоставить дополнительные возможности и удобные инструменты. Между тем, Sass остаётся консервативным в отношении языка CSS.

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

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

Ruby Sass или LibSass

Первый коммит в Sass был сделан в конце 2006, более 10 лет назад. Излишне говорить, что с тех пор проект прошёл долгий путь. Изначально разработанный на Ruby, он получил множество портов. Самый популяный – LibSass (написан на С/C++), сейчас близок к полной совместимости с оригинальной Ruby-версией.

В 2014 году команды Ruby Sass и LibSass решили подождать синхронизации версий, прежде чем двигаться дальше. С тех пор LibSass активно выпускает версии, чтобы догнать старшего брата. Последние оставшиеся несоответствия собраны и перечислены мной в проекте Sass-Compatibility. Если вы знаете о несовместимости между этими двумя версиями, которой нет в списке, пожалуйста, создайте соответствующий issue.

Вернёмся к выбору компилятора. На самом деле, всё зависит от вашего проекта. Если это Ruby on Rails, вам лучше использовать Ruby Sass, который идеально подходит для такого случая. Также следует помнить, что Ruby Sass — это эталонная реализация и всегда будет обгонять LibSass. А если вы хотите перейти c Ruby Sass на LibSass, то эта статья для вас.

В не-Ruby проектах, LibSass, вероятно, будет лучше, поскольку он в основном предназначем для интеграции. Так что, если вы хотите использовать, скажем, Node.js, node-sass — ваш выбор.

Sass или SCSS

Существует довольно много путаницы относительно семантики имени Sass, и не зря: Sass означает как препроцессор, так и свой собственный синтаксис. Не очень удобно, не так ли?

Как видите, Sass первоначально описал синтаксис, определяющей характеристикой которого является его чувствительность к вложености. Вскоре в Sass решили сократить разрыв между Sass и CSS, реализовав CSS-подобный синтаксис под названием SCSS или Sassy CSS. Девиз: “если это правильный CSS, то это правильный SCSS”.

С тех пор, Sass (препроцессор) предоставляет два различных синтаксиса: Sass (не все буквы заглавные, пожалуйста), также известный как синтаксис с отступами, и SCSS. Какой из них использовать, в значительной степени зависит от вас, так как оба строго равны по возможностям. Это лишь вопрос эстетики.

Cинтаксис Sass опирается на отступы, чтобы избавиться от скобок, точки с запятой и других символов пунктуации, что приводит к более компактному и более короткому синтаксису. Между тем, SCSS проще в обучении, так как он лишь дополняет CSS.

Лично я предпочитаю SCSS вместо Sass, потому что он близок к CSS и более дружелюбен для большинства разработчиков. Поэтому я буду использовать SCSS в этом руководстве. Вы можете переключиться на Sass-синтаксис в боковой панели .

Другие препроцессоры

Sass — это препроцессор, коих много. Самый серьёзный соперник — это Less, написанный на Node.js, который стал весьма популярен благодаря CSS-фреймворку Bootstrap (до 4-й версии). Также есть Stylus, который довольно много позволяет, но несколько сложнее в использовании, и к тому же имеет меньшее сообщество.

Почему стоит выбрать Sass, а не другой препроцессор? — действительно, актуальный вопрос. Не так давно мы рекомендовали использовать Sass для проектов на Ruby, потому что Sass был создан в Ruby и хорошо работает с Ruby on Rails. Теперь, когда LibSass догнал (в основном) оригинальный Sass, это уже не актуальный совет.

То, что мне нравится в Sass, так это его консервативный подход к CSS. Дизайн Sass основан на строгих принципах: большая часть проектного подхода приходит из мнений команды о том, что: а) добавление новых возможностей не должно вносить существенного усложнения, но быть адекватно полезным, и б) должно быть достаточно беглого взгляда на блок стилей, чтобы понять, что он делает. Кроме того, Sass более внимательно относится к деталям, чем другие препроцессоры. Насколько я могу судить, ведущие разработчики уделяют много внимания обеспечению совместимости с CSS и тщательно следят, чтобы поведение было предсказуемым. Иначе говоря, Sass – это программное обеспечение, предназначенное для решения актуальных задач; привносит полезную функциональность в CSS там, где CSS не справляется.

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

PostCSS обычно (и неправильно) называют «постпроцессором». Предполагаю, что это связано с не совсем удачным названием, а так же тем, что PostCSS парсит CSS, который уже был обработан препроцессором. Хоть PostCSS и можно так использовать, но это не обязательно, так что это скорее просто «процессор».

Он позволяет получать доступ к «токенам» таблиц стилей (таким, как селекторы, свойства и значения), обрабатывать их с помощью JavaScript, выполнять какие-либо операций и компилировать результаты в CSS. Например, популярная библиотека Autoprefixer работает на основе PostCSS. Она парсит каждое правило, проверяя нужны ли вендорные префиксы, сверяясь с базой CanIUse, после чего удаляет или добавляет необходимые префиксы.

Это невероятно мощный инструмент для создания библиотек, которые работают с любым препроцессором (а также ванильным CSS), но PostCSS не так прост в использовании. Для работы с ним нужно знать JavaScript, а API иногда может сбить с толку. В то время как Sass предоставляет лишь набор полезных возможностей для написания CSS, PostCSS предоставляет прямой доступ к CSS AST (абстрактное синтаксическое дерево) и JavaScript.

Короче говоря, Sass проще и может решить большинство ваших задач. С другой стороны, с PostCSS сложнее совладать (если вы не достаточно хорошо разбираетесь в JavaScript), но он невероятно мощный. Нет причин, чтобы не использовать и то и другое. PostCSS даже предоставляет для этого официальный SCSS-парсер.

Спасибо Cory Simmons за помощь в работе над этим разделом.

Введение

Почему стайлгайд

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

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

Гарри Робертс очень хорошо об этом говорит в CSS Guidelines:

Стайлгайд (заметьте, не визуальный) является ценным инструментом для команд, которые:

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

Дисклеймер

Во-первых: это не CSS-стайлгайд. В этом документе не будут обсуждаться именование CSS-классов, модульный подход и вопрос об ID в мире CSS. Это руководство направлено только на работу с Sass.

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

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

Ключевые принципы

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

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

Между тем, CSS является простым языком. Sass, предназначенный для написания CSS, не должен стать значительно сложнее обычного CSS. Принцип KISS (Keep It Simple Stupid, делай это проще, тупица) является ключевым моментом и в некоторых случаях может даже взять верх над принципом DRY (Don’t Repeat Yourself, не повторяйся).

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

Кроме того, позвольте мне еще раз процитировать Гарри Робертса, прагматизм – козырь совершенства. В какой-то момент, вы, вероятно, пойдёте против правил, описанных здесь. Если это имеет смысл — сделайте это. Код – просто средство, а не цель.

Расширение стайлгайда

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

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

Пример расширения стайлгайда можно найти в репозитории SassDoc:

Это расширение для Node Styleguide от Felix Geisendörfer. Все, что определяет этот документ, описано в Node Styleguide.

Синтаксис и форматирование

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

Когда несколько разработчиков участвуют в написании CSS проекта(ов), то лишь вопрос времени, когда один из них начнёт делать вещи по-своему. Руководство стилей способствуют не только в согласованности, но и помогает, когда приходит время читать и обновлять код.

Грубо говоря, мы хотим (бесстыдно вдохновлён CSS Guidelines):

  • двойные (2) отступы пробелом, никаких табов;
  • в идеале, 80-символьную ширину строк;
  • правильно написанные многострочные CSS правила;
  • осмысленное использование пробелов.

Строки

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

Кодировка

Чтобы избежать потенциальных проблем с кодировкой символов, крайне рекомендуется использовать кодировку UTF-8 в основной таблице стилей, используя директиву @charset . Убедитесь, что она идёт первой строкой в таблице стилей и перед ней ничего нет.

Кавычки

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

Из-за этого, Sass также не требует помещения строк в кавычки. Более того (и, к счастью, согласитесь), строка в кавычках является точным соответствием её двойника без кавычек (например, строка ‘abc’ строго равна abc ).

Языки, которые не требуют, чтобы строки были в кавычках, определенно, в меньшинстве, так что строки должны всегда быть обёрнуты в одинарные кавычки в Sass (одну проще набрать, чем двойную, на QWERTY-клавиатуре). Кроме того, для согласованности с другими языками, в том числе с двоюродным братом CSS – JavaScript’ом, есть несколько причин для такого выбора:

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

Как указано в спецификации CSS, директива @charset должна быть объявлена в двойных кавычках чтобы считаться валидной. Однако, Sass позаботится об этом во время компилирования, так что финальный результат будет всегда правильный. Можете спокойно использовать одинарные кавычки даже для @charset .

Строки как значения CSS

Специальные значения CSS (идентификаторы), такие как initial или sans-serif требует не быть закавыченными. В самом деле, объявление font-family: ‘sans-serif’ потерпит неудачу, потому что CSS ожидает идентификатор, а не строку с кавычками. Именно поэтому, мы не оборачиваем в кавычки эти значения.

Следовательно, можно провести различие между строками, которые должны использоваться как значения CSS (идентификаторы CSS), как в предыдущем примере, и строками, которые привязаны к типу данных Sass, например, к ключам мапы.

Первое без кавычек, а второе в одинарных кавычках.

Строки, содержащие кавычки

Если строка содержит одну или несколько одинарных кавычек, можно воспользоваться оборачиванием строки в двойный кавычки ( » ), чтобы избежать применение эскейп-последовательностей в строке.

URL тоже должны быть в кавычках, по тем же причинам, что и выше:

Числа

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

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

В Sublime Text и других редакторах с поддержкой поиска и замены регулярными выражениями очень легко добавить незначащий нуль в начало (большинства, если не всех) чисел с плавающей точкой. Просто замените \s+\.(\d+) на \ 0.$1 . Обратите внимание на пробел перед 0 .

Единицы измерения

При работе с длинами, 0 (нуль) никогда не должен иметь единицу измерения.

Внимательно, эта практика относится только к длинам. Нуль без единиц измерения для свойств времени, таких как transition-delay не допускается. Теоретически, если нуль без единиц измерения указан для продолжительности, это объявление признаётся недействительным и отбрасывается. Не все браузеры столько строги, но некоторые да. Короче говоря: опускать единицу измерения только для длин.

Самая распространённая ошибка о числах в Sass, которую можно только представить – это думать, что единицы измерения – всего лишь строки, которые можно запросто прилагать к числу. Хотя это и звучит как правда, но единицы измерения работают совсем не так. Думайте о единицах измерения в контексте алгебраических символов. Например, в реальном мире, умножение 5 дюймов на 5 дюймов даст вам 25 квадратных дюймов. Та же логика применима и к Sass.

Чтобы добавить единицу измерения в число, нужно умножить это число на 1 единицу измерения.

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

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

Чтобы убрать единицу измерения из значения, нужно разделить его на одну единицу этой же меры.

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

Вычисления

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

Магические числа

“Магическое число” — это термин старой школы программирования для неименованных числовых констант. В принципе, это просто случайное число, которое просто работает™ и ещё не привязано к какому-либо логическому объяснению.

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

По теме у CSS-Tricks есть потрясающая статья о магических числах в CSS, которую я призываю вас прочитать.

Цвета

Цвета занимают важное место в языке CSS. Естественно, Sass является ценным союзником, когда дело доходит до управления цветами, в основном – путём предоставления мощных функций.

Sass настолько полезен, когда приходится манипулировать цветами, что интернет прямо зацвёл от обилия статей на эту тему. Позвольте порекомендовать несколько хороших:

Цветовые форматы

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

  1. Обозначение HSL;
  2. Обозначение RGB;
  3. Шестнадцатеричная нотация. Предпочтительно в нижнем регистре и по возможности укороченная.

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

Представление HSL – не только самое простое для человеческого мозга [указать источник] , но у него и самый лёгкий способ настройки цвета путём регулировки цветового тона, насыщенности и яркости индивидуально.

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

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

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

Цвета и переменные

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

Теперь вы можете использовать эту переменную, когда захотите. Однако, если ваше использование сильно привязано к теме, я бы не советовал использовать переменные как есть. Вместо этого, храните их в других переменных с именем, объясняющим, как она должна быть использована.

Так вы воспрепятствуете изменениям темы, ведущим к чему-то вроде $sass-pink: blue . Эта статья здорово объясняет, почему важно учитывать ваши цветовые переменные.

Осветление и затемнение цветов

Обе функции lighten и darken манипулируют цветами пространства HSL, добавляя или вычитая в пространстве HSL. В принципе, они ни что иное, как алиасы для параметра $lightness в функции adjust-color .

Дело в том, что эта функция часто не даёт ожидаемого результата. С другой стороны, функция mix является хорошим способом осветлить или затемнить цвет, смешивая его либо с white , либо с ` black`.

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

Иллюстрация разницы между функциями lighten / darken и mix в Sass от KatieK

Если вы не хотите писать функцию mix каждый раз, вы можете создать две простых в использовании функции tint и shade (которые также являются частью Compass), чтобы сделать то же самое:

Функция scale-color разработана, чтобы изменять свойства более плавно, принимая во внимание, насколько они уже изменены. Результат так же хорош, как и от mix , но с более удобным вызовом. Хотя, множитель масштабирования – не совсем то же самое.

Списки

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

Списки должны соблюдать следующие правила:

  • либо в одну строку, либо многострочный;
  • многострочный необходим, если не помещается в 80-символьную строку;
  • если используется для целей CSS, всегда разделяется запятой;
  • всегда оборачивается круглыми скобками;
  • в многострочном списке ставится запятая после последнего элемента.

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

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

Карты

С помощью Sass, авторы таблиц стилей могут создавать карты (maps) – термин Sass для связных массивов, хэшей или даже объектов JavaScript. Карта – это структура данных, сопоставляющая ключи со значениями. И ключ и значение может быть любым типом данных, включая карты, хотя я это не рекомендую использовать сложные типы данных как ключи карты, просто во имя здравого смысла.

Код карт следует писать следующим образом:

  • пробел после двоеточия ( : );
  • открывающая скобка ( ( ) на той же строке, что и двоеточие ( : );
  • ключи в кавычках, если это строки (а это так в 99% случаев);
  • каждая пара ключ/значение на своей строке;
  • запятая ( , ) на конце каждой пары ключ/значение;
  • закрывающая запятая ( , ) на последней паре, чтобы легче добавлять, удалять или переставлять пункты;
  • закрывающая скобка ( ) ) на своей новой строке;
  • без пробела или новой строки между закрывающей скобкой ( ) ) и точкой с запятой ( ; ).

Записей о картах Sass не столь много, сколь ожидаема была эта возможность. Вот три статьи, которые я рекомендую: Using Sass Maps, Extra Map functions in Sass, Real Sass, Real Maps.

Набор правил CSS

На данный момент, это, в основном, пересмотр того, что все и так знают, но вот как набор правил CSS должен быть написан (по крайней мере, по мнению большинства руководств, в том числе CSS Guidelines):

  • связанные селекторы на одной строке; не связанные селекторы на новой строке;
  • открывающая скобка ( < ) отделяется от последнего селектора одним пробелом;
  • каждое объявление на собственной новой строке;
  • пробел после двоеточия ( : );
  • завершающая точка с запятой ( ; ) в конце всех объявлений;
  • закрывающая скобка ( > ) на своей новой строке;
  • новая строка после закрывающей скобки > .

Дополняя те руководства по CSS, мы должны обратить внимание на:

  • локальные переменные объявляются перед любыми объявлениями, потом отделяются от деклараций новой строкой;
  • вызовы примесей без @content идут перед любым объявлением;
  • вложенные селекторы всегда идут после новой строки;
  • вызовы примесей с @content идут после вложенных селекторов;
  • без новых строк перед закрывающей фигурной скобкой ( > ).

Порядок объявлений

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

  • придерживаться алфавитного порядка;
  • упорядочивание по назначению (position, display, colors, font, miscellaneous…).

Есть плюсы и минусы в обоих вариантах. С одной стороны, сортировка в алфавитном порядке является универсальной (по крайней мере, для языков, использующих латинский алфавит), поэтому нет никаких споров о сортировке свойств. Тем не менее, мне весьма странно видеть свойства, такие как bottom и top , не рядом друг с другом. Почему анимации должны быть перед display ? Есть много странностей с алфавитным упорядочиванием.

С другой стороны, сортировка свойств по типу имеет смысл. Каждые объявления, относящиеся к шрифтам, располагаются рядом, как top и bottom , и чтение набора правил отчасти становится похожим на чтение рассказа. Но пока вы строго не придерживаетесь определённых соглашений, типа >white-space – рядом со шрифтами или с display ? Где расположить overflow ? Что такое порядок свойств в группе (может быть в алфавитном порядке, о ирония)?

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

Должен сказать, я сам не могу определиться. Недавний опрос на CSS-Tricks установил, что более 45% разработчиков упорядочивают свойства по их назначению, против 14% в алфавитном порядке. Кроме того, 39% об этом вообще не думают, и я в том числе.

График, показывающий, как разработчики упорядочивают свой CSS

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

Недавние исследования показали, что использование CSS Comb (которое использует упорядочивание по типу) помогает уменьшить общий размер файла на 2.7% при сжатии Gzip, в сравнении с 1.3%, когда происходит упорядочение по алфавиту.

Вложенность селекторов

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

Общие правила

Например, такая вложенность Sass:

…создаст такой CSS:

Начиная с Sass 3.3 можно использовать ссылку на текущий селектор, используя & , чтобы создать дополнительные селекторы. Например:

…сгенерирует такой CSS:

Этот метод часто используется в методологии BEM для генерации селекторов .block__element и .block—modifier , основанных на базовом селекторе (т.е. .block в данном примере).

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

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

Это утверждение становится правдивее, когда селекторы становятся длиннее и ссылки на текущий селектор ( & ) более частыми. В какой-то момент риск потерять след и не суметь понять, что происходит, становится настолько высок, что не стоит того.

Для предотвращения таких ситуаций, мы много говорили о правиле Начала несколько лет назад. Оно советует избегать вложенности более трёх уровней, отсылая к сюжету фильма «Начало» Кристофера Нолана. Я буду более резок и рекомендую избегайте вложенности селекторов, насколько это возможно.

Тем не менее, есть, очевидно, несколько исключений из этого правила, и как мы увидим в следующем разделе, это мнение кажется довольно популярным. Вы можете прочитать об этом детальнее в статьях Beware of Selector Nesting и Avoid nested selectors for more modular CSS.

Исключения

Для начала, допускается, и я даже рекомендую, вкладывать псевдоклассы и псевдоэлементы в родительский селектор.

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

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

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

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

Если вам понравился Sass Гайдлайн, пожалуйста, поддержите его.

Соглашения по именованию

В этом разделе мы не будем иметь дело с лучшими соглашениями по именованию в CSS для сопровождения и масштабирования; не только потому, что это остаётся за вами, а также потому, что они из области Sass Styleguide. Я предлагаю те, что рекомендованы в CSS Guidelines.

Вот чему можно присвоить имена в Sass, и очень важно, чтобы эти имена были хорошими, чтобы весь код выглядел последовательным и легко читался:

Плейсхолдеры Sass ( %placeholder ) намеренно исключены из этого списка, так как их можно рассматривать как обычные селекторы CSS и использовать теже принципы именования, что и для классов.

Что же касается переменных, функций и примесей, то мы будем придерживаться чего-то очень CSS-ного: нижние подчеркивания и дефисы, и, прежде всего – смысл.

Константы

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

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

Если вы действительно хотите покумекать над идеей констант в Sass, вам стоит почитать эту специальную статью.

Пространство имён

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

Например, если вы работаете над проектом Sassy Unicorn, который предназначен для использования разработчиками по всему миру, вы можете рассмотреть возможность использования префикса su- как пространство имен. Это достаточно верно, чтобы предотвратить любые споры в именах, и достаточно коротко, чтобы не испытывать боль при написании кода.

Обратите внимание, что автоматическое создание пространств имён, безусловно, цель для предстоящего проекта @import из Sass 4.0. И так как приход его всё ближе и ближе, то использование библиотек с пространством имён, написанным вручную, может стать сложнее в использовании.

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

CSS является сложным языком, полным хаков и курьёзов. Из-за этого его стоит подробно комментировать, особенно, если вы или кто-то ещё собирается читать и обновлять код спустя полгода или год. Не ставьте себя или кого-нибудь другого в положение я-не-писал-этого-о-боже-почему.

Для комментариев в CSS есть обширное поле деятельности. Они могут пояснять:

  • структуру и/или роль файла
  • цель набора правил;
  • смысл использования волшебного числа;
  • причину объявления CSS;
  • порядок объявления в CSS;
  • ход мысли, почему это было сделано так, а не иначе.

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

Написание комментариев

В идеале, любой набор CSS правил должен предшествовать комментарию в стиле Си, объясняя цель блока CSS. Этот комментарий также принимает пронумерованные объяснения по поводу конкретных частей набора правил. Например:

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

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

Заметьте, что такой же способ поддерживается и Гайдлайном CSS в его разделе Комментирование.

Документирование

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

Необходимо три слеша ( / ).

SassDoc выполняет две основные задачи:

  • обходит стандартные комментарии, используя систему аннотации на основе всего, что является частью открытого или закрытого API;
  • позволяет создавать HTML-версию документации API с помощью любого инструмента генерирования SassDoc (CLI tool, Grunt, Gulp, Broccoli, Node…).

Документация, сгенерированная в SassDoc

Вот пример примеси, обширно документированной в SassDoc:

Архитектура

Разработка архитектуры CSS-проекта, вероятно, одна из самых сложных задач, которую придётся сделать в жизни проекта. Сохранять архитектуру последовательной и значимой – ещё сложнее.

К счастью, одно из главных преимуществ использования CSS-препроцессоров – в возможности разделить кодовую базу на несколько файлов без ущерба для производительности (в отличие от CSS-правила @import ). Благодаря @import в Sass, совершенно безопасно (и на самом деле рекомендуется) использовать столько файлов, сколько необходимо в разработке, все они потом будут собраны в одну таблицу стилей и так попадут на продакшен.

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

Существует много популярных архитектур для CSS проектов: OOCSS, Atomic Design, Bootstrap, Foundation и тому подобные… все они имеют свои достоинства, плюсы и минусы.

Я сам использую подход, который очень похож на SMACSS от Джонатана Снука, который фокусируется на сохранении простоты и очевидности.

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

Компоненты

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

Компоненты могут быть чем угодно, до тех пор, пока они:

  • делают одну и только одну вещь;
  • могут быть повторно используемы;
  • независимы.

Например, форма поиска должна рассматриваться в качестве компонента. Она должна иметь возможность быть используемой повторно на разных страницах, в различных ситуациях. Она не должна зависеть от положения в DOM (в подвале, в боковой панели, в основном содержимом…).

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

Структура компонента

В идеале, компоненты должны располагаться в своих собственных файлах (partial) (в папке components/ , как описано в главе 7-1 pattern), например components/_button.scss . Стили, описываемые в каждом компоненте должны быть связаны только с:

  • стилем самого компонента;
  • стилем вариантом компонента, его модификаторами и состояниями;
  • стили потомков компонента (то есть детей), если это необходимо.

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

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

Вот пример компонента кнопка:

Благодарю David Khourshid за помощь и экспертизу этой главы.

Шаблон 7-1

Возвратимся к архитектуре? Я обычно использую так называемый Шаблон 7-1: 7 папок, 1 файл. Обычно весь наш код можно распределить в 7 папок и один файл в корневом каталоге (обычно с именем main.scss ), который импортирует их все.

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

В идеале, в конечном итоге у нас получится что-то такое:

Файлы с тем же соглашением по именованию, что и выше, начинаются с нижнего подчеркивания.

Папка Base

Папка base/ содержит то, что мы можем назвать общим шаблоном проекта. Там вы можете найти файл сброса, некоторые типографские правила, и, вероятно, стили (я привык их называть _base.scss ), определяющие некоторые стандартные стили для часто используемых элементов HTML.

Если в проекте много CSS анимации, то, возможно, стоит добавить файл \_animations.scss , который будет содержать определения @keyframes всех анимаций. Если же в проекте всего пара таких штук, оставьте их рядом с селекторами, использующие их.

Папка Layout

Папка layout/ содержит всё, что принимает участие в постройке раскладки сайта или приложения. Эта папка может содержать стили для основных частей сайта (шапка, подвал, навигация, боковая панель…), сетка или даже CSS-стили для всех форм.

  • _grid.scss
  • _header.scss
  • _footer.scss
  • _sidebar.scss
  • _forms.scss
  • _navigation.scss

Папка layout/ может быть названа partials/ , на ваше усмотрение.

Папка Components

Для маленьких компонентов существует папка components/ . В то время, как layout/ – основные (определяют общий каркас), код внутри components/ больше сфокусирован на виджетах и содержит все модули, вроде слайдера, загрузчика и тому подобных виджетов. Обычно файлов в components/ много, если приложение или сайт состоит из множества мелких модулей.

  • _media.scss
  • _carousel.scss
  • _thumbnails.scss

Папка components/ может называться modules/ , на ваше усмотрение.

Папка Pages

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

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

Папка Themes

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

Это очень зависит от проекта и не сильно распространено.

Папка Abstracts

Папка abstracts/ собирает все инструменты и хелперы Sass в проекте. Каждая глобальная переменная, функция и примесь должна быть помещена сюда.

Правило для этой папки в том, что она не должна создавать CSS при компиляции сама по себе. Это не что иное, как Sass хелперы.

  • _variables.scss
  • _mixins.scss
  • _functions.scss
  • _placeholders.scss (часто называется _helpers.scss )

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

Папка abstracts/ может также быть названа utilities/ или helpers/ , на ваше усмотрение.

Папка Vendors

И последнее, но не менее важное, большинство проектов будут иметь папку vendors/ , содержащую все CSS-файлы из внешних библиотек и фреймворков – Normalize, Bootstrap, jQueryUI, FancyCarouselSliderjQueryPowered и так далее. Нахождение этих файлов в этой папке – хороший способ сказать: “Эй, это не я писал, не мой код, не моя ответственность”.

  • _normalize.scss
  • _bootstrap.scss
  • _jquery-ui.scss
  • _select2.scss

Если вы хотите что-то переопределить в файлах любого вендора, то я рекомендую вам ввести восьмую папку vendors-extensions/ , в которой вы будете хранить файлы с точно такими же именами, что и файлы, которые они переопределяют.

Например, файл vendors-extensions/_boostrap.scss , содержит все CSS-правила, переопределящие стандартные CSS-правила Bootstrap. Это сделано для того, чтобы не править сами внешние модули, что является совсем не здоровской идеей.

Файл Main

Главный файл (обычно называемый main.scss ) должен быть единственным файлом Sass, который не начинается с нижнего подчеркивания. Этот файл не должен содержать ничего, кроме @import и комментариев.

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

Чтобы улучшить читаемость, главный файл должен следовать этим рекомендациям:

  • один файл на один @import ;
  • один @import на строку;
  • не вставлять пустую строку между файлами из одной папки;
  • вставлять пустую строку после последнего импорта из папки;
  • не писать расширения файлов и нижние подчеркивания.

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

  • один @import на папку;
  • разрыв строки после @import ;
  • каждый файл на отдельной строке;
  • пустая строка после последнего импорта файла из папки;
  • не писать расширения файлов и нижние подчеркивания.

О глобинге

В программировании, глоб шаблоны определяют набор файлов через символы подстановки, такие как *.scss . В общем, глоббинг означает определение набора файлов на основе выражения вместо списка имен файлов. Применимо к Sass, это означает импортирование составных файлов в основной файл main file с глоб шаблоном, а не перечислением их по отдельности. Таким образом, основной файл будет выглядеть так:

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

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

При использовании Ruby Sass, есть Ruby гем, который называется sass-globbing который включает именно эту возможность. Если разработка на node-sass, остаётся полагаться либо на Node.js, либо на любой сборщик, который позаботится о подобной сборке (Gulp, Grunt и т.д.).

Файл позора

Это интересная идея, которая стала популярна благодаря Гарри Робертсу, Дэйву Руперту и Крису Койеру и состоит в том, чтобы складывать все хаки и код, которым вы не гордитесь, в файл позора. Поэтому этот файл и имеет такое драматическое название – _shame.scss , и импортируется в самом конце.

Адаптивный веб-дизайн и точки останова

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

Именование точек останова

Я думаю, что медиа-запросы не должны быть привязаны к специальным устройствам. Например, определённо плохая идея – специально нацеливаться на iPad или устройства на Blackberry. Медиа-запросы должны обслуживать диапазон размеров экрана, пока нет перехода к следующему медиа-запросу.

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

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

В предыдущем примере используются вложенные карты для определения точек останова, но по большому счёту, всё зависит от способа управления точками останова, на который вы опираетесь. Вы можете выбрать строки, а не внутренние карты для большей гибкости (например ‘(min-width: 800px)’ ).

Управление точками останова

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

Очевидно, что это довольно упрощенный менеджер точек останова, который не будет работать, когда надо обрабатывать произвольные или множественные точки остановки. Если вам нужно управление отзывчивостью с расширенными настройками, могу порекоммендовать вам не изобретать колесо, а воспользоваться отличными решениями: Sass-MQ, Breakpoint или include-media.

Если вы хотите больше узнать о том, как разобраться с медиа-запросами в Sass, то и SitePoint, и CSS-Tricks имеют отличные статьи на эту тему.

Использование медиа-запросов

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

Это создаст следующий CSS:

Вы могли слышать, что это правило приводит к дублированию медиа-запросов в получаемом CSS. Это, безусловно, верно. Хотя, были сделаны тесты, которые говорят о том, что это не имеет особого значения, если за дело берётся Gzip (или аналог):

… мы выяснили, были ли влияния на производительность комбинированных и рассеяных медиа-запросов, и пришли к выводу, что различие является минимальным в худшем случае, а по существу и не существует.
— Сэм Ричардс относительно Breakpoint

Теперь, если вы действительно обеспокоены дублированием медиа-запросов, вы всё ещё можете использовать инструмент, чтобы объединить их, например, этот gem, однако я должен вас предупредить о возможных побочных эффектах перемещения CSS-кода. Вы остаетёсь без представления о порядке кода, что является важным.

Если вам понравился Sass Гайдлайн, пожалуйста, поддержите его.

Переменные

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

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

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

  • значение повторяется хотя бы дважды;
  • значение скорее всего будет обновлено хотя бы один раз;
  • все вхождения значения привязаны к переменной (т.е не по стечению обстоятельств).

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

Области видимости

Области видимости переменных в Sass с годами менялись. До недавнего времени, объявленые переменных в пределах наборов правил и других областей видимости были локальными по умолчанию. Однако, если уже была глобальная переменная с тем же именем, изменение значения локальной переменной изменило бы глобальную. Начиная с версии 3.4, Sass правильно отрабатывает задумку областей видимости и создаёт новую локальную переменную вместо перезаписи глобальной.

Документация говорит о затенении глобальной переменной. При объявлении переменной, уже существующей в глобальной области видимости, во внутренней области видимости (селектор, функция, примесь…), локальная переменная называется затенённой глобальной. В общем, она перезаписывается только для локальной области видимости.

Следующий фрагмент кода объясняет задумку затенения переменных.

Флаг !default

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

Благодаря этому, разработчик может определить свою собственную переменную $baseline перед импортом вашей библиотеки, при этом она не будет переопределена.

Флаг !global

Флаг !global следует использовать только тогда, когда вы переопределяете глобальную переменную из локальной области видимости. При определении переменной на корневом уровне, флаг global должен быть опущен.

Много переменных или карты

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

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

Extend

Директива @extend – одна из возможностей, которая сделала Sass таким известным несколько лет назад. Напомню: она позволяет Sass оформить элемент A именно так, как будто бы он также соответствует селектору B. Разумеется, эта возможность является ценным союзником при написании модульного CSS.

Однако настоящее предназначение @ extend заключается в поддержании отношений (соединений) в расширенных селекторах между наборами правил. Что именно это значит?

  • Селекторы имеют соединения (например, .bar в .foo > .bar должны иметь родителя .foo );
  • Эти соединения соотносятся на расширенный селектор (например, «.baz < @extend .bar; >будет создавать .foo > .bar, .foo > .baz`);
  • Объявления расширенного селектора будут использоваться совместно с расширяемым селектором.

Учитывая это, нетрудно увидеть, как расширение селекторов с мягкими соединениями могут привести к взрыву селектора. Если .baz .qux расширяет .foo .bar , то результирующий селектор может быть .foo .baz .qux или .baz .foo .qux , так как .foo и .baz являются общими предками. Они могут быть родителями, дедушками и далее.

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

Для наследования стилей используйте только @extend , если расширяется селектор .class или %placeholder — это своего рода расширенный селектор. Например, .error своего рода .warning , так что .error может расширять .warning .

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

  • Используйте указание @extend исключительно на %placeholder ‘ы, а не на обычные селекторы.
  • Когда расширяете классы, делайте это только с другим классом и никогда с составным селектором.
  • Убедитесь, что %placeholder , который вы расширяете, присутствует как можно реже в таблице стилей.
  • Избегайте расширять общие селекторы предков (т.е. .foo .bar ) или общие селекторы-сиблинги (одного уровня) (т.е. .foo

.bar ). This is what causes selector explosion. Это и вызывает селекторный взрыв.

Говорят, что @extend уменьшает размер файла, так как комбинирует селекторы, а не дублирует код. Это правда, однако разница нивелируется, если используется сжатие Gzip

Таким образом, если вы не можете использовать Gzip (или любой аналог) то применение @extend может и имеет смысл, особенно если вес таблицы стилей является узким местом производительности проекта.

Extend и медиа-запросы

Расширять селекторы стоит только в пределах одной медиа-видимости (директива @media ). Думайте о медиа-запросе как о другой области.

По поводу @extend мнения чрезвычайно полярны, до такой степени, что многие разработчики, включая меня, выступают против него, о чём вы можете прочитать в следующих статьях:

Подводя итог вышесказанному, я советую использовать @extend только для обслуживания взаимосвязи между селекторами. Если два селектора имеют схожие характеристики, то это идеальный случай для применения @extend . Если они независят друг от друга, но у них совпадают несколько свойств, то @mixin может подойти здесь лучше. Лучше понять как выбрать что-то из этих двух вариантов в этой статье.

Благодарю David Khourshid за его помощь и экспертизу этой главы.

Примеси (Миксины)

Примеси – одна из самых важных частей из всего языка Sass. Они являются ключом к повторному использованю и DRY компонентам. Они позволяют авторам определить стили, которые будут повторно использоваться по всей таблице стилей, без надобности к использованию таких неосмысленных классов, как .float-left .

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

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

Основы

Как было сказано, примеси чрезвычайно полезны, и вы должны их использовать. Правило гласит, что если вам случится встретить набор свойств CSS, которые всегда появляются вместе по какой-либо причине (то есть не случайно), то вы можете поместить их в примесь. Хак Micro-clearfix от Николаса Галлагера заслуживает быть помещенным в примесь (без аргументов), например.

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

Безаргументные примеси

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

В таких случаях, можно безопасно опустить скобки при их вызове. Ключевое слово @include (или знак + в синтаксисе на отступах) уже действует как индикатор что это вызов примеси; нет необходимости в скобках в данном случае.

Список аргументов

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

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

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

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

Примеси и вендорные префиксы

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

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

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

Делайте это по-умному.

Использование этой примеси будет очень простым:

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

Условные операторы

Вы уже, наверное, знаете, что Sass предоставляет условные операторы, такие как @if и @else . Пока в вашем коде нет сложной логики, нет необходимости и в условных операторах. Фактически, они в основном нужны для библиотек и фреймворков.

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

  • Никаких скобок, покуда они не обязательны;
  • Всегда пустая строка перед @if ;
  • Всегда разрыв строки после открывающей фигурной скобки ( < );
  • @else на одной строке с предыдущей закрывающей скобкой ( > );
  • Всегда новая пустая строка после последней закрывающей скобки ( > ), если на следующей строке не стоит закрывающая скобка ( > ).

При тестировании на отрицающее значение, всегда используйте ключевое слово not , а не проверки на false или null .

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

При использовании условных операторов внутри функции для возврата другого результата, основанного на некоторых условиях, убедитесь, что @return находится вне условных операторов.

Если вам понравился Sass Гайдлайн, пожалуйста, поддержите его.

Циклы

Благодаря предоставленным в Sass комплексным структурам данных, таких, как списки и карты, не удивляет и возможность перебора по этим объектам.

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

Цикл @each , безусловно, наиболее часто используемый из трёх циклов, предусмотренных Sass. Он предоставляет чистый API для перебора списка или карты.

При переборе карты всегда используйте имена переменных $key и $value ради последовательности.

Также соблюдайте следующие принципы, чтобы сохранить читаемость:

  • Всегда пустая строка перед @each ;
  • Всегда пустая строка после закрывающей скобки ( > ), если на следующей строке нет закрывающей скобки ( > ).

Цикл @for может быть полезным, когда скомибинирован с псевдоклассом CSS :nth-* . Исключая сценарии, когда предпочтительнее использовать цикл @each , если вам надо пройтись по какому-нибудь объекту.

Всегда используйте $i как переменную для соблюдения соглашения, пока у вас нет веских причин изменить её, никогда не используйте ключевое слово to , используйте through . Многие разработчики даже и не знают, что Sass предоставляет такие варианты; использование разных может привести к путанице.

Также следуйте следующим принципам, чтобы сохранить читаемость:

  • Всегда пустая строка перед @each ;
  • Всегда пустая строка после закрывающей скобки ( > ), если на следующей строке не закрывающая скобка ( > ).

While

Цикл @while не имеет абсолютно никакого применения в реальном проекте Sass, особенно из-за того, что нет способа остановить цикл изнутри. Не используйте его.

Ошибки и предупреждения

Если и есть возможность, которая часто упускается из виду разработчиками, использующих Sass, то это возможность динамически выводить предупреждения и ошибки. Sass поставляется с тремя указаниями для вывода содержимого в стандартной системе вывода (CLI, компилятор…):

Отложим @debug в сторону, так как очевидно, что он нацелен на отладку SassScript, который не является нашей целью здесь. Нам остаются @warn и @error , которые с виду одинаковые, за исключением того, что один останавливает компилятор, а другой нет. Позволю вам самим додумать, какой из них что делает.

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

Предупреждения

Возьмём функцию из Sass-MQ, предполагающую конвертирование из px в em , например:

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

Ошибки

Ошибки, в отличие от предупреждений, предотвращают компилятор от дальнейшей работы. Обычно они останавливают сборку и выводят сообщение в поток вывода, также как и в stack trace, что весьма удобно для отладки. Из-за этого ошибки должны быть выведены только тогда, когда уже нет возможности для выполнения программы. Когда есть возможность, попробуйте обойти эту проблему и вывести вместо этого предупреждение.

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

Больше информации, как эффективно использовать @error , в этом введении в обработку ошибок.

Инструменты

Здорово, что такие пополярные CSS-препроцессоры, как Sass, поставляются с экосистемой фреймворков, плагинов, библиотек и инструментов. После восьми лет существования мы приближаемся к точке, где всё, что может быть написано на Sass, будет написано на Sass.

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

Compass

Compass – основной фреймворк Sass, разработанный Крисом Эппстейном, одним из ключевых разработчиков Sass, и я не вижу веских причин для снижения его популярности в последнее время, если вам интересно моё мнение.

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

Дело в том, что мы используем очень малую часть фреймворка. Compass огромен. Кросс-браузерная поддержка – лишь вершина айсберга. Математические функции, помощники изображений, спрайты… Есть ещё много того, что может быть сделано этим фреймворком.

К сожалению, это всё сахар, и каких-либо уникальных возможностей в нём нет. Исключение – лишь механизм построения спрайтов, который по-настоящему хорош, но Grunticon и Grumpicon тоже отлично справляются и более выгодны в том, что могут быть подключенны в процессе сборки.

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

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

Системы сеток

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

Позвольте сказать прямо: я не большой поклонник систем сеток. Конечно, я вижу их потенциал, но я думаю, что большинство из них полностью излишни и в основном используются для рисования красных столбцов на белом фоне в презентациях дизайнеров. Когда в последний раз вы думали, что слава-Богу-что-я-использовал-этот-инструмент-для-построения-этой-сетки-2-5-3.1-π? Всё верно, никогда. Потому что в большинстве случаев вы просто хотите обычную 12-колоночную сетку и ничего больше.

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

Если вы не привязаны к особой системе сеток, то вам будет приятно знать, что есть два первоклассных движка модульных сеток для Sass: Susy и Singularity. Обе делают гораздо больше, чем вам когда-нибудь понадобится, так что вы можете выбрать тот, который вы предпочитаете между этими двумя, и убедитесь, что все ваши крайние случаи – даже самые изящные из них – будут покрыты. Если вы спросите меня, то я отвечу: Susy имеет немного лучшее сообщество, но это лишь моё мнение.

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

SCSS-lint

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

SCSS-lint инструмент для сохранения читаемости и чистоты вашх файлов CSS. Он полностью настраиваемый и легко встраивается в ваш существующий набор инструментов.

К счастью, рекомендации SCSS-lint очень похожи на те, что описаны в данном документе. Для того, чтобы настроить SCSS-lint в соответствии с Sass Guidelines, я рекомендую следующие настройки:

Если вы не уверены в необходимости использования SCSS-lint, то советую прочитать эти замечательные статьи: Clean Up your Sass with SCSS-lint, Improving Sass code quality on theguardian.com и An Auto-Enforceable SCSS Styleguide.

Если вы хотите подключить SCSS-lint в процесс сборки Grunt, вам будет приятно знать, что есть расширение Grunt для этого – grunt-scss-lint.

Кроме того, если вы в погоне за приложением, которое работает с SCSS-lint и тому подобным, ребята из Thoughtbot (Bourbon, Neat…) работают над Hound.

Слишком длинно; Не читал

Это руководство по написанию стилей весьма длинное и часто полезно иметь под рукой краткие итоги. Ниже представлен такой конспект.

Ключевые принципы

  • Любое руководство по стилю предназначено для поддержания постоянства. Если вы не согласны с какими-то правилами из Гайдлана Sass, это будет справедливо только пока вы постоянно не согласны с ними. ↩
  • Код Sass должен быть как можно более простым. Избегайте построения сложным систем, пока таковая не будет совершенно необходима. ↩
  • Помните, что иногда KISS (Keep It Simple, Stup >@charset первой строкой таблицы стилей. ↩
  • Когда применяются как идентификаторы CSS, строки должны быть заключены в одинарные кавычки. УРЛы также должны быть заключены в кавычки. ↩

Numbers

  • Sass не различает числа, целые и с точкой, так что незначащие нули в конце следует опустить. А вот нуль перед точкой улучшает читаемость и должен ставиться. ↩
  • Нулевая (0) длина не должна содержать единицу измерения. ↩
  • Манипуляции с единицами измерения следует рассматривать как арифметические действия, а не строковые операции. ↩
  • Для улучшения читаемости, вычисления оборачиваются круглыми скобками. Также, сложные математические операции могут быть разбиты на меньшие фрагменты. ↩
  • Магические числа драматически ухудшают поддержку кода и их следует избегать всегда. Если уж используете их, подробно комментируйте их сомнительную полезность в каждом случае. ↩

Colors

  • Цвета должны указываться по возможности в HSL, затем RGB, только затем шестнадцетиричное представление (в нижнем регистре и укороченной форме). Ключевые слова цветов использовать не следует. ↩
  • Когда осветляется или затемняется цвет, предпочтительно использовать mix(..) вместо darken(..) и lighten(..) . ↩

Списки

  • Списки должны разделяться запятыми, кроме случая прямой передачи значений CSS строкой с разделителями-пробелами. ↩
  • Оборачивание в круглые скобки также служит улучшению читаемости кода. ↩
  • Списки в строку не должны иметь завершающей запятой, а многострочные — должны. ↩

Карты

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

Порядок объявлений

  • Не имеет значения, какого порядка объявления свойств придерживаться (по алфавиту, по типу и т.д.), лишь бы использовался постоянно какой-то один. ↩

Вложенность селекторов

  • Избегайте вложенность селектором, если это не необходимо (то есть в большинстве случаев). ↩
  • Применяйте вложенность селекторов для псевдоклассов и псевдоэлементов. ↩
  • Медиа-запросы также могут вкладываться в селектор, к которому они относятся. ↩

Соглашения по именованию

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

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

  • CSS — хитроумный язык; не стесняйтесь писать подробные комментарии о коде, который выглядит (или является) странным. ↩
  • Для переменных, функций, примесей и плейсхолдеров, расположенных в публичном API, используйте комментарии SassDoc. ↩

Переменные

  • Обязательно используйте флаг !default для любых переменных публичного API, чтобы их можно было безопасно изменить. ↩
  • Не используйте флаг !global на корневом уровне, так как это может привести к нарушению синтаксиса Sass в будущем. ↩

Extend

  • Применяйте расширение плейсхолдеров, а не существующих CSS селекторов. ↩
  • Расширяйте плейсхолдеры по возможности по очереди, чтобы избежать побочных эффектов. ↩

Если вам понравился Sass Гайдлайн, пожалуйста, поддержите его.

Что такое Sass

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

HTML (или HyperText Markup Language) – это стандартизированный язык разметки документов в интернете. Вопреки расхожему заблуждению, HTML – это не язык программирования. Он используется для того, чтобы все элементы на странице (тексты, рисунки, таблицы…) были расположены правильно; за его чтение отвечают специальные программы, которые всем знакомы – браузеры (или веб-обозреватели).

HTML использует для разметки документов теги — именно они определяют, как и где элемент будет отображаться на странице. Теги бывают парными (

В самом базовом виде структура документа выглядит вот так:

Теперь перейдем к CSS.

CSS (или Cascading Style Sheets) – это формальный язык, который определяет внешний вид документа, написанного с использованием HTML.

Разница между HTML и CSS заключается в том, что HTML отвечает за структуру документа, а CSS – за оформление, форматирование.

Естественно, HTML тоже имеет возможность задавать стиль страницы, но с появлением CSS разработчики смогли:

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

Часто свойства совпадают в HTML и CSS. Цвет фона можно задать в HTML:

В общем виде структура CSS такая:

Познакомившись с основами, перейдем к главной теме статьи.

Sass (или Syntactically Awesome Stylesheets) — это скриптовый метаязык, разработанный для упрощения файлов CSS. Этот модуль входит в Haml ( HTML abstraction markup language), который используется для упрощения HTML.

Как Haml компилируется в HTML, так и Sass компилируется в обычные CSS-стили.

Выпуск Sass состоялся в ноябре 2006 года, актуальная стабильная на момент написания статьи версия — 3.5.6 от 23 марта 2020 года.

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

  • .sass — известный как синтаксис с отступами, через которые реализованы вложенные элементы; фигурных скобок нет;
  • .scss — Sassy CSS, где используются фигурные скобки.

Так как Haml был написан Ruby-разработчиками, то и Sass унаследовал Ruby-подобный синтаксис, который значительно отличается от CSS. Поэтому в 2010 году был презентован новый синтаксис — SCSS, который приблизил синаксис Sass к CSS и сделал его более совместимым.

Каждый из этих синтаксисов имеет свои особенности и преимущества.

Синтаксис Sass

Этот синтаксис короче, в нем отсутствуют скобки и точки с запятой, поэтому набирать его проще.

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

Такой синтаксис определенно понравится тем, кто в разработке использует Ruby или Python.

Синтаксис SCSS

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

Синтаксис SCSS — это более читаемый код, в котором проще разобраться. Поэтому все больше разработчиков выбирают именно его; на нем разрабатываются инструменты и плагины для Sass.

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

Основные преимущества Sass

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

1. Использование переменных

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

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

В коде ниже задана переменная $width:

А после компиляции код будет выглядеть вот так:

2. Вложенные правила

Sass дает возможность вкладывать правила CSS друг в друга. Благодаря этому становится намного проще редактировать стили.

Вложенные правила нужны не только для минимизации кода, но и для структурирования кода (наподобие HTML).

3. Использование дополнений

Дополнения позволяют следовать прекрасному правилу DRY: Don’t Repeat Yourself. Вместо того, чтобы копировать и множить куски одинакового кода, Sass предлагает сохранить его в переменную, а затем использовать там, где необходимо. При компиляции переменная будет преобразована в нужную часть кода.

4. Наследование

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

Заключение

Sass — это полезный инструмент, который значительно упрощает работу с CSS. В нем легко разобраться, поэтому время, потраченное на освоение, наверняка окупится потом при разработке веб-сайта.

Топ-пост этого месяца:  Категории функций — Добавлениеудаление юзеров — WordPress
Добавить комментарий