8 советов, которые помогут вам правильно составлять Sass


Оглавление (нажмите, чтобы открыть):

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

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

Что такое SASS?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основы Sass: Вложенность

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

Что такое вложенность

Вложенность позволяет записывать селекторы, имитирующие структуру HTML. Это дает возможность использовать сокращения при написании стилей. Например:

Это простейший пример вложенности, элемент div содержит элемент p. Скомпилированный результат:

Элементу div мы можем задать собственные свойства:

Этот пример скомпилируется в два разных правила, одно для элемента div, другое — для p.

Как использовать вложенность

Использовать вложенные стили достаточно просто: нужно всего лишь записать селектор (или селекторы) между фигурными скобками другого селектора.

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

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

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

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

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

Ссылки на родитеский селектор

В страшном примере выше мы использовали &, который должен замещаться на родительский селектор. Символ : использовался для создания псевдо-классов для ссылок.

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

Вложенность свойств

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

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

Заключение

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

Нашли опечатку? Orphus: Ctrl+Enter

© getinstance.info Все права защищены. 2014–2020

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

Основы 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/Scss

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

Если вы уже знакомы с Sass/Scss, установили его и готовы начать пользоваться им, то вы можете прочитать вот эту запись — «Основы Sass/Scss». В ней я описываю все тонкости препроцессора, а так же как правильно пользоваться им.

Что такое Sass?

Sass — это разновидность препроцессора, который поможет вам во время разработки front-end части. Факт в том, что CSS файлы становятся все больше и больше и через некоторое время с ними становится сложнее работать.

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

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

Как установить Sass?

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

  1. Устанавливаем Ruby. Заходим на официальный сайт в раздел загрузки, выбираем билд (версию) Windows и скачиваем. Например, я использую Windows 7 (64 битовую), поэтому я буду скачивать Ruby 2.2.4 (x64).
  2. Следуйте всем указаниям установщика.
  3. После успешной установки Ruby откройте Windows консоль и пропишите gem install sass и после этого запустится процесс установки Sass. Если во время установки у вас выдает ошибку, то попробуйте поменять gem на sudo и в итоге у вас должна получиться вот такая строка sudo gem install sass .

Тестируем

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

  1. Откройте командную строку Windows
  2. Пропишите туда sass -v . Если вы все правильно установили, то у вас должно появиться что-то вроде такой строки Sass 3.4.19 (Selective Steve) .

PS. Если у вас ничего не выводиться, возможно вы не находитесь в правильной директории. Для начала вам нужно прописать cd и дальше путь до того места куда вы установили Ruby. В моем случае это будет вот так cd D:\Programs\Ruby22\bin\ . После того как вы попадете в эту директиву, вам нужно прописать sass -v . Если у вас все равно ничего не показывает, то повторите процесс установки с самого начала и после чего вернитесь снова сюда.

Применяем Sass в работе

Для начала давайте создадим простой файл, который будет называться style.scss и внутри мы напишем следующее:

Обратите внимание, что формат файла .scss, а не .css. Для .scss используется немного другой синтаксис, но он элементарный и вполне понятный с самого начала (если вы раньше когда-либо использовали css). А если вы читаете эту статья, я ожидаю, что вы уже знакомы с ним.

И так продолжим с style.css:

  1. Откройте Windows консоль, с помощью cd команды вам нужно переместиться в папку с Ruby, которая называется bin , (выше я уже описывал как это можно сделать)
  2. Внутри консоли пропишите sass —watch и далее перетащите файл style.scss в консоль и она автоматически вставить путь до style.scss файла и уже после нажмите Enter.
    В итоге должно получиться примерно так же как показано на скриншоте выше.

    PS.
    Конечно же у вас папки и путь могут различаться.
  3. После ввода команды из второго этапа, на экрана у вас должно появиться что-то похожее на это:

Это будет означать, что Sass скомпилировал SCSS файл, создал из него два других. Первый это style.css и второй — style.css.map. И теперь вы можете зайти в папку где лежит style.scss и проверить наличие этих файлов и если вы откроете style.css, то вы должны увидите следующее:

Как вы можете заметить, Sass взял все содержимое файла style.scss и сделал из него обычный CSS файл.

Так же обратите внимание, что в scss, все стили пишутся в древовидном виде (то есть класс внутри класса).

Конечно же SCSS намного удобнее.

Вот некоторые из плюсов SCSS:

  • Группирование стилей
  • Возможность быстро найти нужный класс/id
  • Использование одних и тех же стилей в нескольких местах

Вы намерное спросите, а что такое —watch ? Данная команда принуждает Sass следит за каждым изменением style.scss. То есть каждый раз, когда вы будите сохранять новую копию этого файла, Sass обратит на это внимание и скомпилирует свежую версию CSS.

PS. Если у вас уже имеется скомпилированая версия CSS в той же папке где и style.scss, то он их перезапишет на более новую.

Важные моменты

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

Совет 1

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

Совет 2

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

Препроцессор SASS. Изучаем SASS для быстрой верстки. CSS компилятор для быстрой верстки шаблонов и макетов сайта.

Особенности использования SASS. Настройка SASS компилятора

Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжим рубрику Верстка сайтов и ее раздел Препроцессор SASS и SCSS. В этой записи мы поговорим про технические особенности использования SASS и разберемся с настройкой SASS компилятора через командную строку. Настроив SASS компилятор, мы поймем как он работает и будем лучше представлять, как происходит процесс конвертации SASS файла в файл CSS, что, в свою очередь, поможет нам писать более качественный SASS код.

Особенности использования SASS. Настройка SASS компилятора

Итак, в этой записи мы поговорим про использование SASS на сайтах и в других проектах. Посмотрим, как «прикрутить» SASS к различным библиотекам Ruby. Поговорим о том, как SASS кэширует код для ускорения работы. Для корректной работы HTML страниц важно, чтобы была указана кодировка, поэтому необходимо разобраться с тем, как SASS работает с кодировкой. И еще мы посмотрим команды компилятора SASS для его настройки.

Использование SASS в проектах и на сайтах

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

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

Если вы хотите установить SASS на Windows, то сперва нужно установить Ruby, мы об этом уже говорили ранее.

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

Номер Команда для компиляции SASS и ее описание
1 sass input.scss output.css
Этой командой вы запустите компилятор SASS, который сконвертирует SCSS файл в файл CSS
2 sass watch input.scss:output.css
Эта команда запускает SASS компилятор и конвертирует SASS в CSS при каждом сохраненном изменение в указанном файле с расширением .scss или .sass
3 sass watch app/sass:public/stylesheets
Это командой вы можете посмотреть каталог с файлами SASS или SCSS, данная команда полезна, если у вас много таких файлов.

Обратите внимание на то, что эти команды выполняются в командной строке операционной системы.

Плагин SASS для Rack. Плагин SASS для Rails. Плагин SASS для Merb

SASS можно легко использовать с плагином Rack. Я не очень силен в языке Ruby, о чем очень сожалею, возможно, когда-нибудь я наверстаю упущенное, но сейчас скажу, что изначально Rack – это серверная стойка. В контексте языка Ruby: Rack – это библиотека или фреймворк, которая упрощает работу с HTTP протоколом и позволяет с легкостью обрабатывать веб-серверу HTTP запросы клиента.

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

Так же использование SASS возможно с Ruby on Rails. SASS можно подключить к библиотеки Ruby on Rails. Данная библиотека была разработана для облегчения создания веб-приложений и реализует архитектуру MVC, библиотека облегчает разработчиком взаимодействие с веб-серверами и серверами баз данных. Чтобы подключить плагин SASS к библиотеке Rails 3 воспользуйтесь командой:

Если вы хотите включить плагин SASS в приложение Rack, то добавьте следующие строки в файл config.ru, который присутствует в корне приложения:

Библиотека Merb позволяет использовать SASS. Разработчики Merb вдохновились библиотекой Rails. Merb позволяет упростить работу с HTTP серверами и при этом не ограничивает разработчиков в выборе JavaScript библиотек и движков HTML шаблонов. Если вы хотите подключить плагин SASS к Merb, то вам необходимо внести строку в конфигурационный файл dependencies.rb:

Мы рассмотрели, как можно использовать SASS с языком Ruby и его библиотеками, давайте теперь поговорим про опции SASS при компиляции.

Механизм кэширования SASS компилятора

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

Для ускорения работы SASS разработчики используют следующий прием:

  1. Создают общий SASS файл.
  2. Создают несколько небольших SASS файлов, в которых прописывают стили для различных элементов HTML документа.
  3. Импортируют маленькие файлы в большой.

Такой подход значительно ускоряет компиляцию SASS в CSS. SASS компилятор создает кэш-файлы при каждой компиляции, если вы удалили файл с кэшем, то при следующей компиляции он будет создан вновь. Если вы не используете ни один из фреймворков, то кэш-файлы SASS найдете в папке sass-cache.

Если вам не нужна возможность кэширования в SASS, то ее можно отключить, задав параметру :cache значение false.

Настройка SASS компилятора

Вы можете произвести настройку SASS компилятора. Для этого есть специальные опции SASS или параметры SASS, как вам удобно, так и называйте. Чтобы настроить SASS компилятор в Rail или Rack, добавьте строку кода, как показано ниже в конфигурационный файл приложения:

Настроить SASS можно и для библиотеки Merb, используя следующий пример:

Давайте посмотрим, что мы можем настроить в SASS при помощи параметров или опций SASS.

Номер Настройки для SASS и их описание
1 :style
Данный параметр SASS позволяет задать стиль выходного файла.
2 :syntax
Данная опция SASS позволяет указать компилятору синтаксис SASS кода. Соответственно, для того чтобы использовать синтаксис SASS, нужно написать :sass, чтобы синтаксис был SCSS, напишите :scss. Значение по умолчанию :sass.
3 :property_syntax
Данная настройка SASS компилятора задает правила для написания CSS правил в синтаксисе SASS и не работает в синтаксисе SCSS.
4 :cache
Этот параметр SASS позволяет настроить кэширование. Если параметр cache имеет значение true, то SASS компилятор будет кэшировать фрагменты кода, которые импортируются в исходный SASS-файл. Параметры кэширования в SASS чем-то похожи на поле HTTP заголовка Cache-Control.
5 :read_cache
Эта опция SASS компилятору говорит о том, что тот не должен кэшировать код при новой компиляции, а может использовать только старый кэш при условии, что параметр :cache не указан.
6 :cache_store
В SASS можно настроить папку с хранилищем кэша. Если опция установлена на подкласс Sass::CacheStores::Base, то хранилище кеша будет использоваться хранения и извлечения кешированных результатов компиляции.
7 :never_update
SASS компилятор можно настроить так, чтобы он никогда не обновлял CSS файлы, если передать этому параметру значение true.
8 :always_update
SASS компилятор можно настроить так, чтобы он всегда обновлял CSS файлы при обновлении и сохранении исходных файлов, если передать этому параметру значение true.
9 :always_check
Эта опция SASS компилятора используется в том случае, когда необходимо перекомпилировать все SASS файлы в CSS при запуске сервера.
10 :poll
Когда значение опции true, всегда используйте опрос серверной части для Sass::Plugin::Compiler#watch, а не стандартной файловой системы.
11 :full_exception
Данная настройка SASS компилятора позволяет задать отображение ошибок, если ей передать значение true, то ошибки будут показаны. При этом это будет показан номер строки, в которой компилятор нашел ошибку.
12 :template_location
Данный параметр позволяет задать путь к каталогу с шаблонов SASS.
13 :css_location
Эта опция указывает месторасположение CSS файлов
14 :unix_newlines
Перенос строки в Windows CRLF, перенос строки в Unix CR, данный параметр позволяет изменять в файле переносы строк с Windows на Unix.
15 :filename
Компилятору можно указать файл, в котором будет вестись лог ошибок.
16 :line
Эта опция SASS определяет первую строку шаблона SASS, от которой будет вестись отсчет для указания номера строк при обнаружении ошибки.
17 :load_paths
Этот параметр используется для подключения файла SASS при использование @import директивы.
18 :filesystem_importer
Этот параметр используется для импорта файлов из файловой системы usesSass::Importers::Base
19 :sourcemap
Этот параметр помогает браузеру найти стили SASS, данный параметр может использовать три значения:· :auto:это значение используется для указания месторасположения файла при помощи относительного URI (URI в HTTP).· :file: это значение служит для указания локального пути к файлу и не используется для работы с удаленными серверами.· :inline:это значение содержит в себе текст sourcemap.
20 :line_numbers
Это опция нужна для отображения номера ошибок в CSS файле, ошибки будут отображаться если задать значение true.
21 :trace_selectors
Компилятор SASS можно настроить так, чтобы он помогал отслеживать CSS селекторы импорта и примеси. Компилятор будет помогать в том случае, когда данной опции будет передан параметр true.
22 :debug_info
Данная опция помогает настроить SASS компилятор для отладки кода.
23 :custom
Если вы хотите использовать код SASS в разных приложения, то эта опция вам поможет.
24 :quiet
Вы можете отключить предупреждения, которые выдает SASS компилятор этой опцией.

Кодировка SASS файлов. Настройка кодировки SASS компилятора

Настраивать кодировку SASS компилятора не имеет особого смысла, поскольку SASS определяет ее автоматически. Изначально для определения кодировки SASS смотрит на CSS спецификацию и возвращает полученное значение Ruby: SASS считывает порядок байтов Unicode после директивы @charset, если SASS не может понять кодировку, то он кодирует файлы в UTF-8.

Чтобы явно задать кодировку для SASS компилятора используйте директиву @charset.

Как компилятор SASS определяет синтаксис файла

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

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

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

Руководство написание стилей на Sass, как писать CSS лучше

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

Что такое Sass И почему вы должны его использовать?

Для тех из вас, кто еще не знает, что такое Sasss, лучше будет отправиться на официальный сайт Sass. Sass является аббревиатурой Syntactically Awesome Style Sheets, и является продолжительность CSS, что увеличивает мощность и элегантность основного языка.

Sass является CSS препроцессором с большим количеством функций. Наиболее заметные это: переменные, расширения и миксины.

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

Зачем нужно руководство стилей CSS

К сожалению, даже препроцессор не может все исправить, и помочь написать хороший CSS. Каждый разработчик сталкивается с тем, что веб-приложения становятся все больше и больше. Вот поэтому нужно держать код в чистоте, и избегать так званых spaghetti code (дословно Спагетти код). Чтобы избежать указанные проблемы вашей команде нужен общий стиль написания кода как CSS так и PHP. «Спагетти код» — названия плохого, медленного и повторяющегося кода, который к тому же не читабельный. Это возникает как правило, когда команда состоит из многих человек, и в компании нету общих принципов по написанию кода. Кроме того, как дело доходит до исправления ошибок, как правило это нужно сделать быстро и разработчик не имеет времени на написания хорошего кода. В таких случаях код может повторятся в разных местах что не есть хорошо. Еще одна ситуация когда нужно исправить быстро код, разработчику приходится использовать !important что приводит к очень плохому и нестабильному коду, поведения которого очень трудно предугадать.

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

Руководство стилей

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

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

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

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

SCSS — немного практики, часть I


Статей про SASS ( SCSS ), Less на хабрахабре уже полно, но на мой взгляд не хватает такой, в которой было бы немного реальной практики. Я постараюсь восполнить этот пробел. Около года назад одна из SASS -статей меня «зацепила», и с тех пор я полюбил эту технологию настолько, что ручной набор обычного CSS кода представляется мне лишней тратой времени. Сия статья посвящается тем верстальщикам (или web-программистам), которые про SCSS ещё не слышали, или же ещё не пробовали в деле. Более опытным товарищам, полагаю, в ней ловить нечего.

Что такое SCSS

SCSS — «диалект» языка SASS. А что такое SASS? SASS это язык похожий на HAML (весьма лаконичный шаблонизатор), но предназначенный для упрощения создания CSS-кода. Проще говоря, SASS это такой язык, код которого специальной ruby-программой транслируется в обычный CSS код. Синтаксис этого языка очень гибок, он учитывает множество мелочей, которые так желанны в CSS. Более того, в нём есть даже логика (@if, each), математика (можно складывать как числа, строки, так и цвета). Возможно, некоторые возможности SCSS покажутся вам избыточными, но, на мой взгляд, лишними они не будут, останутся «про запас».

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

И тоже самое на SCSS:

Я выбрал SCSS в виду того, что он проще для восприятия коллегам с ним ещё не знакомым. Ещё стоило бы отметить что обычный CSS код вполне вписывается в SCSS синтаксис.

Установка и использование

Для начала нужно установить ruby. После чего нужно установить sass-gem ( gem install sass в консоли ). Если всё прошло гладко, то теперь вам доступна консольная программа sass . О всех нюансах её использования вы можете прочесть здесь ― sass —help . Я расскажу лишь о двух базовых возможностях:

—watch

Если запустить sass с ключом —watch , то программа будет следить за указанными вами файлами. В случае их изменения, она автоматически пересоберёт все необходимые css-файлы (не все вообще, а только связанные с изменёнными).

Предположим, что у вас есть следующая структура проекта:

Необходимо чтобы sass отслеживал все изменения в css/scss/* и результат сохранял в css/*.css . В таком случае запускаем sass так ― sass —watch css/scss:css/. . Т.е. sass —watch [что]:[куда] .

—update

Если вам нужно единожды обновить css-файлы, то в место —watch применяем —update . Никакой слежки проводится не будет, так же как и проверок на необходимость обновления.

Стоит отметить, что в отличии от Less , SASS не умеет компилировать свой код прямо в браузере. На мой взгляд, такой подход (компиляция на сервере или ПК-верстальщика) является единственно верным.

Практика

Итак, мы подошли к самому главному. Начнём с @import .

@import

Изначально, до использования SCSS, весь CSS код движка, с которым мне по долгу службы приходится работать, находился в 1-ом огромном style.css файле. Моя IDE (Netbeans (кстати, вот плагин для подсветки синтаксиса)) работала с ним с существенными тормозами. Разбивать же его на множество файлов поменьше, и, при необходимости, склеивать их в 1 ― никто не хотел. SCSS решает этот вопрос автоматически.

Стоит отметить 1 нюанс. Если скормить sass не конкретный файл-источник, а директорию, то css файлы не будут генерироваться для файлов начинающихся с _ . Т.е. наличие файла style.scss приведёт к созданию style.css , а наличие файла _some.scss ― нет.

Итак, для того, чтобы включить содержимое файла _template.scss или template.scss пишем

В конечном счёте, вместо 1-го большого style.css файла у меня получилось более сотни мелких scss -файлов. С первого взгляда может показаться, что такое количество слишком велико и приведёт к страшным мукам. Однако, нужный мне файл я нахожу сразу исходя из удобной структуры каталогов. К тому же, я полагаю, что благодаря кешированию такая «схема» более производительна.

@вложенность

Одна из самых желанных «фич» для CSS ― вложенность селекторов. Пример:

Символ & равносилен родительскому селектору. Допустим тег у нас имеет класс ie_7 , в случае если в качестве обозревателя у нас Internet Explorer 7 . Следующий код позволяет избавиться от всех «хаков» и спец.комментариев:

$variables

Переменные ― удобная штука. Определяются они так:

Переменные ― не константы, их можно менять по ходу кода 🙂 Одна из первых моих мыслей вылилась в _const.scss файл, который заключает в себе все базовые цвета, размеры шрифтов и пр.

Предполагается, что цвет ссылок на сайте ― $link .

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

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

@математика

Разделим математику на 2 категории ― цвета и числа. Начнём с чисел. Простой пример:

При желании можно и padding с border-ом задавать переменными. Всё зависит от сложности вёрстки.

Хочу отметить, что подобного рода манипуляции применяются очень часто. Без них я как без ног.

А теперь цвета. Цвета можно складывать, перемножать:

Довольно удобная штука, когда лень подбирать цвета. Также доступны такие функции как opacify и transparentize (более подробно).

@строки

SASS умеет складывать строки, а также поддерживает конструкцию #<>

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

Статья

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

  • @mixin ― пользовательские функции
  • @if ― условия
  • @each ― циклы
  • Несколько дизайнов для одного сайта
  • По желанию читателей

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 Гайдлайн, пожалуйста, поддержите его.

Директива @import языка SASS

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

В обычном CSS, директива @import должна находиться в самом начале CSS-файла, перед ней не должно быть никаких стилей, иначе браузеры могут ее проигнорировать. На заре web-a данная директива помогала разработчикам разбивать большие таблицы стилей на более мелкие, тем самым они структурировали проект. Представьте, что у вас крупный интернет-магазин. Вам нужно сделать множество правок к какому-нибудь празднику (новый год, 8 марта, 23 февраля и тд), или к какому-нибудь мероприятию (черная пятница, день рождения интернет-магазина, или любая другая акция) и у вас одна большая CSS-ка строчек так на 8 — 10 тысяч. Такие правки займут много времени. Если же CSS структурирован, то понятно, что в «header.css» находятся стили шапки документа, а не стили корзины или каталога. В файле «basket.css» лежат стили для корзины, общих стилей для сайта там быть не может. Это удобно. Единственный минус, так это лишние запросы на сервер, соответственно производительность вашего сайта просядет.

Поскольку SASS относится к препроцессорным языкам, то в директиву @import были добавлены новые возможности. Раз компилятор все равно из SCSS-файла компилирует CSS-ку, то он вполне сможет через директиву @import напрямую включить стили наших SCSS-файлов. Если правильно настроить компилятор, то можно на выходе получить один CSS-файл. Таким образом SCSS-файлы будут структурированы, у нас будут «header.scss«, «basket.scss» и тд, а на выходе мы получим один CSS-файл. Некоторые разработчики называют данный процесс фрагментированием, или разбиением на блоки. Раз все равно происходит включение SCSS-файлов, то директиву @import не обязательно подключать только в начале файла, ее можно подключить в любом месте. Итак начнем:

После компиляции мы получим файл «main.css» со стилями из файла «header.scss«. Для подключения SCSS-файла не обязательно указываеть его расширение. Например:

После компиляции мы получим как и в прошлый раз файл «main.css» со стилями из файла «header.scss«. Поскольку мы пользуемся компилятором, то мы может отойти от стандартных правил CSS и подключать файлы следующим образом:

@import » header «, » basket «, » catalog «;

После компиляции мы получим файл main.css со стилями из файла «header.scss«, «basket.scss«, «catalog.scss«.

Включения SCSS-файла через директиву @import не произойдет (@import будет выведен по правилам CSS) если:

  • мы подключаем файл с расширением CSS;
  • путь к подключаемому файлу начинается с http://;
  • мы подключаем файл через url();
  • если директива @import подключается для каких-то устройств, те вызывается с медиазапросами (это напрямую говорит компилятору не включать файл, а сгенерить @import по правилам CSS).

@import url ( footer );

@import » print » screen ;

@import url ( footer );

@import » print » screen ;

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

margin : 30px 10px ;

margin : 30px 10px ;

Как мы можем заметить из примера выше, произошло включение стилей из файла «example.scss» в «main.scss«. При этом включение произошло не просто в файл, а в класс sidebar, ведь мы подключили директиву @import для класса sidebar. У нас применились вложенные правила.

Итак, что стоит подключать через директиву @import? Все зависит от размера проекта. Чем больше проект, тем на большее количество блоков стоит его разбивать. Если же проект маленький (сайт-визитка, простенький блог), то не стоит особо заморачиваться по поводу разбивки на отдельные блоки, но и в этом случае стоит вынести в отдельные блоки плагины (fancyBox, colorbox, jcarousel и тд). Мы уже изучили переменные, поэтому вы вполне сможете вынести в отдельные переменные те вещи которые вы наиболее часто стилизуете в этих плагинах. К примеру в fancybox дизайнеры стилизуют: кнопку закрытия, стрелки прокрутки, подложку для фоток. Картинки этих элементов и их размеры вполне можно вынести в переменные, чтобы потом их не искать. Так вы увеличите скорость вашей работы. Для интернет-магазинов я сделал отдельные блоки для корзины, каталога. Я просто подключаю код через директиву @import, меняю переменные, и все готово, даже верстать ничего не нужно. Если вы делаете типовые вещи, а дизайнеры редко что-то новое придумывают, не поленитесь вынести их в переменные, второй раз вы их сверстаете быстрее, а скорее всего вы их и верстать не будете, просто подключите, поменяете переменные, и этого вполне хватит.

Директива @import и css-framework-и

Говоря про директиву @import не возможно не сказать о CSS-framework-ах. На SASS-е написаны следующие framework-и: zurb foundation, gumby, bourbon, и это далеко не полный список. Мало кто знает, но вы можете скачать SCSS-файлы данных framework-ов. Если не получается скачать SCSS-файлы с официальных сайтов, вы всегда сможете найти их на github-е. Эти framework-и имеют свои компоненты, mixin-ы, управляющие конструкции, файлы настроек. Используя SASS вы сможете более гибко настраивать данные framework-и. Просто подключая данные framework-и через обычный CSS, вы такой гибкости не получите.

Давайте я все объясню на конкретном примере. Предположим, вы хотите подключить к вашему проекту пагинацию, такую как на zurb foundation . Все, что вам для этого потребуется, так это скачать SASS-версию zurb foundation (ее можно скачать с официального сайта) и подключить через директиву @import файл » _pagination.scss » (в 5 zurb foundation он лежит в папке foundation/components). В самом верху файла » _pagination.scss » находится 20 переменных, меняя их вы сможете настроить пагинацию так как вам удобно.

$include-pagination-classes : $include-html-classes !default ;

$pagination-height : rem-calc(24) !default ;

$pagination-margin : rem-calc(-5) !default ;

$pagination-li-float : $default-float !default ;

$pagination-li-height : rem-calc(24) !default ;

$pagination-li-font-color : $jet !default ;

$pagination-li-font-size : rem-calc(14) !default ;

$pagination-li-margin : rem-calc(5) !default ;

$pagination-link-pad : rem-calc(1 10 1) !default ;

$pagination-link-font-color : $aluminum !default ;

$pagination-link-active-bg : scale-color($white, $lightness: -10%) !default ;

$pagination-link-unavailable-cursor : default !default ;

$pagination-link-unavailable-font-color : $aluminum !default ;

$pagination-link-unavailable-bg-active : transparent !default ;

$pagination-link-current-background : $primary-color !default ;

$pagination-link-current-font-color : $white !default ;

$pagination-link-current-font-weight : $font-weight-bold !default ;

$pagination-link-current-cursor : default !default ;

$pagination-link-current-active-bg : $primary-color !default ;

Детально описывать компоненты zurb foundation это тема не на одну статью. Могу сказать, что в zurb foundation есть компоненты для форм, кнопок, плагинов, вы можете взять только сетку если захотите. Это очень удобно. Как я выше писал, просто подключая CSS вы такой гибкости не получите, придется лезть в код и искать что заменить. В SCSS-файлах все вынесено в переменные, ничего искать не нужно.

Еще вы можете воспользоваться библиотеками миксинов, для префиксов CSS3. Я поользуюсь такими библиотеками как compas и bourbon.

Я советую вам скачать SCSS-файлы данных framework-ов и просто посмотреть их. Изучая их структуры вы многое поймете. Со временем вы будете сами писать SASS-компоненты, такие какие вам нужны. Начать стоит с плагинов которыми вы часто пользуетесь. И тут нужно сказать о подключении директивы @import. Переменные и mixin-ы должны быть объявлены раньше, чем они вызываются, иначе компилятор вызовет ошибку, если соблюдать данное правило, то со временем у вас будет свой SCSS-framework, такой какой нужен именно вам, заточенный под ваши нужды.

Мастер Йода рекомендует:  10 трендов JavaScript на 2020 год по результатам международного опроса
Добавить комментарий