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

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

Комментарии игнорируются браузерами.

CSS комментарий помещается внутри элемента , начинается с /* и заканчивается с */ :

Пример

/* Это однострочный комментарий */
p color: red;
>

Вы можете добавлять комментарии в любом месте кода:

Пример

p <
color: red; /* Установить красный цвет текста */
>

Комментарии также могут занимать несколько строк:

Пример

HTML и CSS комментарии

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

В следующем примере используется комбинация комментариев HTML и CSS:

Пример

My Heading

Hello World!

Этот параграф оформлен с помощью CSS.

CSS комментарии не отображаются в выводе.

ПАЛИТРА ЦВЕТОВ

ПРИСОЕДИНЯЙТЕСЬ!

Получите ваш
Сертификат сегодня!

Связь с админом

Если вы хотите сообщить об ошибке, а также внести предложение о работе сайта, добавить объявление или рекламу на сайт, не стесняйтесь отправить админу электронное письмо на email:

Топ Учебники

Топ Справочники

Топ Примеры

Веб Сертификаты

Этот сайт оптимизирован для обучения и тестирования. Примеры могут быть упрощены для улучшения чтения и базового понимания. Учебные пособия, ссылки и примеры постоянно пересматриваются, чтобы избежать ошибок, но мы не можем гарантировать полную правильность и работоспособность всего контента. Используя этот сайт, вы соглашаетесь с тем, что прочитали и приняли условия использования, cookie и политику конфиденциальности.
Также вы можете абсолютно бесплатно скачать офлайн версию сайта W3Schools на русском архивом с GitHub и пользоваться локально на своём компьютере.
Также доступна версия сайта W3Schools на украинском языке.
Copyright 1999-2021 by Refsnes Data. All Rights Reserved.
Сайт работает на фреймворке W3.CSS.

Начинаем писать CSS

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

Препроцессоры CSS

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

Конкатенация

Наиболее ценной возможностью препроцессоров я считаю конкатенацию файлов. Уверен, вы знаете что написав @import в файле .css вы собственно говорите браузеру: «используй и этот файл, пожалуйста». И он его использует. Добавляется еще один запрос, что не очень хорошо, ведь таких файлов у вас может быть много. Большое количество запросов ухудшает производительность приложения. Если использовать препроцессоры CSS, эта проблема устраняется. Они просто объединяют все стили в один css-файл.

Расширение

Есть два основных препроцессора CSS — LESS и Sass. Они оба поддерживают расширение CSS. Да, работают они немного по-разному, но идея та же. Вы создаете базовый класс (его обычно называют «миксин») с набором свойств и затем импортируете эти свойства в другой селектор. Например:

// less .bordered(@color: #000) < border: dotted 2px @color; > .header < .bordered; > .footer < .bordered(#BADA55); > // компилируется в .header < border: dotted 2px #000000; > .footer < border: dotted 2px #bada55; > 

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

.bordered < border: dotted 2px #000; > 

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

// Sass @mixin bordered($color: #000) < border: dotted 2px $color; > .header < @include bordered; > .footer < @include bordered(#BADA55); > // компилируется в .header < border: dotted 2px black; > .footer < border: dotted 2px #bada55; > 

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

// Sass %bordered < border: dotted 2px #000; > .header < @extend %bordered; > .footer < @extend %bordered; > // компилируется в .header, .footer < border: dotted 2px #000; > 

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

Компоновка

LESS и Sass поддерживают определение переменных. Можно в любой момент обратиться к этим переменным и использовать их в качестве значений для свойств.

// Sass $brand-color: #009f0A; … h1 < color: $brand-color; > 

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

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

// Sass @mixin border($side) < border-#$side>: solid 1px #000; > .header < @include border("left"); > // компилируется в .header < border-left: solid 1px #000; > 

Аргументы против препроцессоров

• Препроцессор является инструментом, т.е. это еще один компонент, который вам придётся добавить в среду разработки. Вам возможно захочется сделать его встроенным в приложение. Это, само собой, предусматривает написание дополнительного кода.
• Если вы не хотите беспорядка в коде, вам вероятно понадобится средство отслеживания изменений. Еще один инструмент, который будет следить за вашими файлами и запускать компиляцию после того как в них будут внесены изменения. Если это ваш случай, вам придётся запускать этот инструмент каждый раз когда вы начинаете работать над проектом. Возможно, со временем вы найдете способ оптимизировать этот процесс, но над этим придётся поработать.
• Очень часто разработчиков заботят только файлы .less или .Sass. Однако, результат — вот, что действительно имеет значение. Ваш Sass может быть изящным и оптимизированным, однако это не гарантирует, что в результате вы получите столь же красивый CSS. Могут возникнуть довольно интересные проблемы со специфичностью. Так что скомпилированную версию нужно регулярно просматривать.

БЭМ

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

header class="site-header"> div class="logo"> div> div class="navigation"> div> header> 

Стили могут быть такими:

.site-header < … >.logo < … >.navigation 

Такой код, конечно же, будет работать, однако есть проблема: читая CSS вы не сможете понять что, например, логотип logo является частью шапки header . Еще один маленький логотип может быть использован в подвале. Следующий логичный шаг — прописать в селекторе элемент-родитель.

.site-header .logo 

Однако это не очень хорошая идея, ведь стили становятся зависимыми от иерархии конкретных тегов. Что если потребуется перенести логотип за пределы тега header ? Стиль не будет применён. Можно добавить site-header в название класса логотипа:

.site-header-logo 

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

.site-header-logo-xmas 

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

БЭМ может стать решением в таком случае. Он расшифровывается как «Блок, Элемент, Модификатор» и диктует некоторые правила, которым нужно следовать. Используя БЭМ можно превратить наш маленький пример в:

.site-header < … >/* блок */ .site-header__logo < … >/* элемент */ .site-header__logo--xmas < … >/* модификатор */ .site-header__navigation < … >/* элемент */ 

Т.е. site-header — это у нас блок. Логотип logo и навигация navigation — элементы этого блока, а версия логотипа xmas — модификатор. Возможно всё и выглядит очень просто, но такой подход даёт широкие возможности. Начав его использовать, вы убедитесь что архитектура ваших работ улучшится. Слабой стороной БЭМ является разве что синтаксис. Да, он немного безобразен, но я готов пойти на жертвы ради исправности системы.

(материалы для чтения: здесь и здесь)

OOCSS

Открыв для себя БЭМ, я научился правильно называть классы и задумался над структурой. Наверное первой мне на глаза попалась статья об Объектно-ориентированном CSS. Суть объектно-ориентированного программирования частично заключается в использовании абстракций и язык CSS их поддерживает. Не важно используете вы препроцессоры или нет, вам нужно знать об OOCSS. Я программист, поэтому эта концепция показалась мне очень похожей на то, как я программирую каждый день, например, на JavaScript. У неё есть два главных принципа:

Разделение структуры и оформления

Взгляните на следующий пример:

.header < background: #BADA55; color: #000; width: 960px; margin: 0 auto; > .footer < background: #BADA55; text-align: center; color: #000; padding-top: 20px; > 

В нём несколько стилей продублированы. Их можно выделить в отдельный класс следующим образом:

.colors-skin < background: #BADA55; color: #000; > .header < width: 960px; margin: 0 auto; > .footer < text-align: center; padding-top: 20px; > 

Теперь у нас есть объект colors-skin , которому можно найти широкое применение. Разметка может выглядеть так:

div class="header colors-skin"> … div> div class="colors-skin"> … div> div class="footer colors-skin"> … div> 

У такого изменения есть несколько плюсов:

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

Разделение контейнера и содержимого

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

.header .social-widget < width: 250px; > 

Ведь если переместить .social-widget за пределы контейнера .header , его ширина изменится. В общем, так делать не рекомендуется. Особенно для компонентов, которые встречаются по всей странице. Это принцип блочного CSS и я настоятельно рекомендую выделить немного времени на то, чтобы попробовать такой подход. Лично мне следование этому принципу помогает писать лучший CSS.

Фреймворк

Если вы откроете репозиторий OOCSS на GitHub, то увидите фреймворк. Да, в этом фреймворке используется концепция объектно-ориентированного CSS и да, у него есть несколько крутых компонентов, готовых к использованию. С некоторого времени мне не нравятся фреймворки. Если вы на минуту задумаетесь, то увидите что слово фреймворк состоит из двух частей — «frame» и «work», что значит «каркас, рамка»1 и «изделие». И действительно, работая с фреймворком вы ограничены рамками. Вы связались с этим инструментом и вынуждены играть по его правилам. Я отдаю предпочтение микро-фреймворкам или подобным инструментам, которые дают мне лишь основу. Я ни в коем случае не пытаюсь изобрести колесо, только хочу найти баланс. Очень часто готовые к использованию решения ведут к неопрятной и слишком запутанной системе. Я бы советовал создавать такие инструменты с одной конкретной целью. Если пытаться предвидеть побольше способов применения, в результате получите… ну, вы поняли — фреймворк.

Тем не менее я настоятельно рекомендую взглянуть на фреймворк OOCSS. Возможно он подойдёт под ваши требования. Создатель репозитория — Николь Саливан (Nicole Sullivan). Она первооткрыватель OOCSS и если у вас появится немного свободного времени, советую послушать её презентации/лекции.

SMACSS

Представляю вам ещё одну популярную концепцию: SMACSS. SMACSS расшифровывается, как масштабируемая модульная архитектура CSS (Scalable and Modular Architecture for CSS). Джонатан Снук (Jonathan Snook) предложил нечто вроде гида по стилю для CSS-разработчиков. Суть в том, чтобы разделить ваше приложение на следующие категории:

• основа — базовые стили по умолчанию для простых селекторов. Например, clearfix ;
• структура — определение каркаса;
• модуль — группа элементов которые вместе формируют модуль. Например, шапка или боковая колонка;
• состояние — содержит описание различных состояний элементов. Правила при скрытии, нажатии, растяжении (и т.д.) определённого объекта;
• тема — большей мерой определение визуального представления элементов. Похожая на категорию «состояние»;

Мне пока не приходилось использовать концепцию SMACSS, но она довольно популярна и действительно продвигает хорошие идеи. Больше всего радует, что она скорее является идеей реализации, чем фреймворком. Следовательно, вы не связаны чёткими правилами, классами или компонентами.

Атомарный дизайн

Изучив OOCSS и SMACSS, я начал искать подходящее модельное представление и довольно быстро оказался на этой странице. Это презентация отличной концепции «Атомный дизайн». Её автор — Бред Фрост (Brad Frost), известный веб-разработчик, работающий преимущественно в мире отзывчивого дизайна и дизайна для мобильных устройств.

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

label>Поиск по сайту label> 

input type="text" placeholder="введите ключевое слово" /> 

Т.е. атомы содержат базовые стили элементов DOM. Например, цветовую палитру, размеры шрифтов или переходы. Затем эти частички можно объединить в молекулы. Например:

form> label>Поиск по сайту label> input type="text" placeholder="введите ключевое слово" /> input type="submit" value="Поиск" /> form> 

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

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

header> div class="logo"> nav> ul> li>a href="#">Домашняя страница a> li> li>a href="#">Общие сведения a> li> li>a href="#">Контакты a> li> ul> nav> form> label>Поиск по сайту label> input type="text" placeholder="введите ключевое слово" /> input type="submit" value="поиск" /> form> header> 

Еще одна особенность концепции — заготовки. Они не имеют ничего общего с химией, однако вписываются в веб-контекст. Сочетая разные организмы, мы создаём заготовку. Затем из этих заготовок формируется конечная страница.

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

Органический CSS

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

Когда я натолкнулся на статью Бреда Фроста, мне уже была знакома похожая концепция, реализованная в Organic. Работа Бреда просто великолепна, однако я решил пойти дальше и написать собственный микро-фреймворк на основе концепции атомного дизайна. Я использовал Sass в качестве препроцессора и создал репозиторий на Github — https://github.com/krasimir/organic-css.

Атомы

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

margin-top: 24px; 

Добавление атомов посредством прописания стилей прямо в классах не соответствует моим намерениям. Потому что если я напишу что-то вроде этого:

body < margin-top: 24px; > header < margin-top: 24px; > 

препроцессор оставит эту запись как есть. А мне нужен вот такой результат:

body, header < margin-top: 24px; > 

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

%margin-top-24 < margin-top: 24px; > body < @extend %margin-top-24; > header < @extend %margin-top-24; > 

Итак, мне пришлось использовать плейсхолдеры. Это также значит что мне потребовалось создать большое количество плейсхолдеров, которые можно было бы использовать впоследствии. Я решил, что фреймворк будет состоять только из атомов. И может быть нескольких молекул с функциями широкого применения вроде всем известного reset.css , определения сетки и т.п. Я хотел написать нечто, что могло бы служить основой для разработки CSS. Возможно в дальнейшем процессе работы над проектами я найду и какие-то заготовки, которые также можно будет предложить в качестве основы, но для начала я хотел сохранить репозиторий чистым и простым.

Для большей последовательности работы я создал миксин для определения атома. Итак, вот пример:

@include define-atom("block") < display: block; > @include define-atom("font-family") < font-family: Georgia; > 

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

@mixin header < // @include atoms(( block, clearfix, font-family )); > 

Молекулы

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

@mixin login-box < @include atoms(( block, font-size-20, margin-top-23, bold )); > 

Ко мне пришла одна интересная мысль. Рассмотрим тег body . Что это? Молекула или что-то другое? Он, без сомнения, нуждается в стилизации посредством атомов, но в общем содержит другие молекулы. Значит он должно быть не молекула, а что-то другое. Я пришёл к заключению, что CSS должен быть на первом месте. Т.е. если для стилизации body нужны несколько атомов, значит он является молекулой, что значит что теоретически я не должен присоединять к нему никаких других молекул. Это может показаться непрактичным, но в большинстве случаев поможет вам воздержаться от использования дочерних селекторов, что хорошо.

Органеллы

Как только вы разберётесь с тем какие элементы DOM являются молекулами, вы поймёте что такое органеллы. Например, обычный элемент form служит прекрасным примером органеллы. Он содержит молекулы label , input и textarea .

.login-form < @include label; @include input; @include textarea; > 

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

Больше абстракций

Очень часто у вас может вознкать желание объединить органеллы ещё во что-то. В таком случае добавим ещё абстракций.

Атом → Молекула → Органелла → Клетка → Ткань → Орган → Система → Организм 

Только от вас зависит, как вы построите свой CSS. Пока я использовал OrganicCSS только в одном проекте, но могу сказать что он помогает внести в проект ясность. Я рассортировал разные элементы по разделам и дал классам такие названия чтобы с лёгкостью ориентироваться с чем я имею дело. Например, если у меня есть органелла с названием header , я просто изменю её название на o-header . Просматривая HTML-разметку спустя некоторое время, я сразу вижу что CSS-стили для этого элемента находятся в разделе «органеллы».

Заключение

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

Примечания

1 В английском языке слово «frame» имеет большое количество значений. Одно из них — «рамка» (напр. для картины или зеркала), его обыгрывает автор статьи в своём рассуждении о работе с фреймворком.

Методики и инструменты для разработки стилей веб-страниц

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

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

Проблемы CSS

В самом начале нового проекта стили обычно выглядят просто и понятно. Скажем, имеется совсем мало CSS-селекторов, вроде .title , input , #app , работа с которыми никому не покажется трудной.

Но, по мере роста приложения, стили превращаются в кошмар. Разработчик начинает путаться в CSS-селекторах. Он обнаруживает, что пишет нечто вроде div#app .list li.item a . Однако работу останавливать нельзя, поэтому программист продолжает использовать подобные конструкции, CSS-код запихивают куда-нибудь в конец файла. И правда — кого интересуют стили? Да и сам по себе CSS — это такая ерунда… В результате получается 500 строк совершенно неподдерживаемого, ужасного CSS.

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

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

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

SCSS

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

▍Переменные

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

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

// Объявление переменной $primary-color: #0099ff; // Использование переменной h1

▍Вложенные конструкции

SCSS поддерживает вложенные конструкции. Вот обычный CSS:

h1 < font-size: 5rem; color: blue; >h1 span

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

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

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

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

Файлы, содержащие фрагменты описаний стилей, можно создавать, добавляя в начале их имён знак подчёркивания: _animations.scss , _base.scss , _variables.scss , и так далее.

Для импорта этих файлов используется директива @import . Вот как пользоваться этим механизмом:

// файл _animations.scss @keyframes appear < 0% < opacity: 0; >100% < opacity: 1; >> // файл header.scss @import "animations"; h1

Возможно, вам покажется, что в этом коде имеется ошибка. Действительно, ведь файл, который мы хотим импортировать, называется _animations.scss , а мы, в файле header.scss , используем команду @import «animations» . Однако ошибки здесь нет. SCSS — система достаточно интеллектуальная для того, чтобы понять, что в подобной ситуации разработчик имеет в виду соответствующий файл.

Это — всё, что нам надо знать о переменных, о вложенных конструкциях, о фрагментировании стилей, и об импорте. В SCSS есть и другие возможности, вроде миксинов, наследования, и других директив (среди них — @for , @if и ещё некоторые), но мы тут о них говорить не будем.

Если вы хотите познакомиться с SCSS поближе — взгляните на соответствующую документацию.

Организация CSS-кода: методология БЭМ

Я уже и не помню, сколько раз я использовал универсальные термины для именования CSS-классов. В результате у меня получались такие имена, думаю, знакомые всем: .button , .page-1 , .page-2 , .custom-input .

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

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

▍Блоки

Блоки можно рассматривать как компоненты. Наверняка, вы играли в детстве в Lego. Поэтому включим машину времени.

Как вы строили, скажем, обычный домик? Тут понадобится окно, крыша, дверь, стены, и, в общем-то, этого достаточно. Всё это — наши блоки. Они значимы сами по себе.

Именование: имя блока — .block

Примеры: .card , .form , .post , .user-navigation

▍Элементы

Как сделать из Lego окно? Вероятно, некоторые кубики выглядят как рамки, поэтому, если соединить четыре таких кубика, получится красивое окно. Это — элементы. Они являются частями блоков, они нам нужны для того, чтобы создавать блоки. Однако, элементы, вне блоков, бесполезны.

Именование: имя блока + __ + имя элемента — .block__element

Примеры: .post__author , .post__date , .post__text

▍Модификаторы

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

Именование: имя блока ИЛИ имя элемента + — + имя модификатора — .block__element—modifier , .block—modifier
Примеры: .post—important , .post__btn—disabled

▍Примечания

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

▍Упражнение

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

Например, вот что у меня получилось в результате анализа Google Store.

Анализ сайта

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

▍Примеры

Вот пример, подготовленный средствами Codepen, демонстрирующий возможности БЭМ. Тут мы по-разному оформляем нечто вроде публикаций в некоем блоге. Вот HTML-код этого примера.

 
Thomas 3 minutes ago 
Lorem ipsum dolor sit amet, consectetur adipisicing elit. Laboriosam sit voluptatem aut quis quisquam veniam delectus sequi maxime ullam, inventore blanditiis quia commodi maiores fuga, facere quaerat doloremque in. Nisi!
 
 
Thomas 2 hours ago 
Voluptatem incidunt autem consequatur neque vitae aliquam, adipisci voluptatum. Ipsum excepturi dolores exercitationem rem ab similique consequatur nesciunt, tempora aut vel unde.
 

.post < display: inline-block; padding: 1rem; background-color: #ccc; border: 1px solid #222; border-radius: 5px; &--important < background-color: yellow; >&__author < font-size: 1.2rem; font-weight: bold; color: blue; >&__date < float: right; >&__text < line-height: 2rem; font-size: 1.3rem; >> .mt-large

А вот то, что в итоге получилось.

Оформление «публикаций» с использованием БЭМ

Рассмотрим ещё один пример. Тут, пользуясь БЭМ, мы оформляем кнопки. Вот HTML-код этого примера.

 
 Click me Danger Success Small Big Border 

.colors < font-size: 1.5rem; font-family: sans-serif; >.btn < background-color: #FF6B93; color: #fff; text-transform: uppercase; padding: 1.5rem 2.5rem; border-radius: 4px; transition: all .2s; font-size: 1.3rem; border: none; letter-spacing: 2px; cursor: pointer; &:hover < background-color: #D15879; >&:focus < outline: none; >&--danger < background-color: #FF3B1A; &:hover < background-color: #D43116; >> &--success < background-color: #00D123; &:hover < background-color: #00AB1D; >> &--small < padding: 1rem 2rem; font-size: 1rem; >&--big < padding: 1.8rem 4.5rem; font-size: 1.7rem; >&--border < background-color: #fff; color: #FF6B93; border: 1px solid #FF6B93; &:hover < background-color: #FF6B93; color: #fff; >> >

А вот — результат.

Оформление кнопок с использованием методологии БЭМ

Организация CSS-файлов: шаблон «7-1»

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

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

1. Все файлы с SCSS-фрагментами надо разместить в 7 разных папках.
2. Все эти файлы нужно импортировать в один файл, main.scss , расположенный в корневой директории, в которой лежат все эти папки.

▍7 папок

Вот папки, о которых идёт речь:

1. base : в этой папке надо разместить весь, так сказать, «шаблонный» код. Под «шаблонным» кодом здесь понимается весь тот CSS-код, который приходится писать при создании нового проекта. Например: типографские правила, анимации, утилиты (то есть — классы вроде margin-right-large , text-center ), и так далее.
2. components : название этой папки явно указывает на то, что в ней будет храниться. Речь идёт о стилях компонентов, используемых для сборки страниц. Это — кнопки, формы, всяческие слайдеры, всплывающие окна, и так далее.
3. layout : эта папка применяется для хранения стилей элементов макетов страниц. Это — шапка и подвал страницы, навигационная область, различные разделы страницы, сетка, и так далее.
4. pages : иногда в проекте нужны страницы, обладающие собственным специфическим стилем, который отличается от стиля остальных страниц. Описания стилей для таких вот особенных страниц и попадают в эту папку.
5. themes : если веб-проект предусматривает использование различных тем оформления (скажем, нечто вроде «dark mode», или «admin»), стили для них надо положить сюда.
6. abstracts : в эту папку попадают всяческие вспомогательные вещи — функции, переменные, миксины.
7. vendors : редкий сайт обходится без внешних зависимостей. В этой папке хранятся стили, которые созданы не тем, кто разрабатывает конкретный сайт. Сюда, например, можно сохранить файлы проекта Font Awesome, стили Bootstrap и прочее подобное.

▍Файл main.scss

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

@import abstracts/variables; @import abstracts/functions; @import base/reset; @import base/typography; @import base/utilities; @import components/button; @import components/form; @import components/user-navigation; @import layout/header; @import layout/footer;

Не могу не согласиться с тем, что выглядит вся эта конструкция из семи папок довольно масштабной. Однако тут надо отметить, что эта архитектура рассчитана на большие проекты. Для маленьких проектов можно использовать адаптированную версию шаблона «7-1». Особенности этой версии заключаются в том, что в ней можно обойтись без некоторых папок. Так, тут можно отказаться от папки vendors , поместив ссылки на внешние по отношению к проекту файлы стилей в тег link . Далее, можно обойтись без папки themes , так как, вероятно, в небольшом веб-приложении темы оформления использоваться не будут. И, наконец, можно избавиться от папки pages , так как в этом проекте, скорее всего, не будет страниц, стиль которых сильно отличается от общего стиля. В результате из семи папок остаётся всего четыре.

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

• Если вы предпочитаете воспользоваться тем, что осталось от шаблона «7-1», то у вас сохраняются папки abstracts , components , layout и base .
• Если вы решаете обойтись одной большой папкой, то все файлы с фрагментами стилей, вместе с файлом main.scss , попадают в эту папку. Выглядеть это может примерно так:

sass/ _animations.scss _base.scss _buttons.scss _header.scss . _variables.scss main.scss

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

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

Компиляция SCSS в CSS

Для того чтобы преобразовать SCSS-код в CSS, вам понадобится платформа Node.js и менеджер пакетов NPM (или Yarn).

Мы будем использовать пакет node-sass , который позволяет компилировать .scss -файлы в .css -файлы. Это — инструмент командной строки, пользоваться им несложно. А именно вызов node-sass выглядит так:

node-sass  [options]

Здесь доступно множество опций. Мы остановимся на двух:

• Опция -w позволяет организовать наблюдение за папкой или файлом. То есть, node-sass будет следить за изменениями в коде, и, когда они происходят, автоматически компилировать файлы в CSS. Эта возможность весьма полезна в процессе разработки.
• Опция —output-style определяет стиль выходного CSS-файла. Тут доступно несколько вариантов: nested , expanded , compact , compressed . Эту опцию мы будем использовать для сборки готового CSS-файла.

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

Создайте папку проекта и перейдите в неё:

mkdir my-app && cd my-app

npm init

Добавьте в проект пакет node-sass :

npm install node-sass --save-dev

Создайте файл index.html , папки со стилями, файл main.scss :

touch index.html mkdir -p sass/ css cd sass && touch main.scss

Добавьте в файл package.json следующее:

Добавьте ссылку, ведущую к скомпилированному CSS-файлу, в тег head файла index.html :

         
My app
  

Вот и всё. Теперь, когда вы занимаетесь работой над проектом, выполните команду npm run watch и откройте в браузере файл index.html . Для того, чтобы минифицировать CSS, выполните команду npm run build .

Дополнительные полезности

▍Интерактивная перезагрузка страницы

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

Установите пакет live-server (обратите внимание на то, что его устанавливают глобально):

npm install -g live-server

Добавьте в зависимости проекта пакет npm-run-all , который позволит одновременно запускать несколько скриптов:

npm install npm-run-all --save-dev

Добавьте следующее в package.json :

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

▍Пакет autoprefixer

На данном этапе у вас имеется настроенная среда разработки, что очень хорошо. Теперь поговорим об инструментах для сборки проекта, и, в частности, о пакете autoprefixer. Это — инструмент (речь идёт о postcss-плагине), который парсит CSS-код и добавляет префиксы производителей браузеров к CSS-правилам, используя данные с Can I Use.

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

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

-webkit-animation-name: myAnimation; -moz-animation-name: myAnimation; -ms-animation-name: myAnimation;

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

• Скомпилируем все SCSS-файлы в один основной CSS-файл.
• Добавим в этот файл префиксы браузеров с помощью autoprefixer .
• Сожмём этот CSS-файл.

Добавьте в проект две зависимости — postcss-cli и autoprefixer :

npm install autoprefixer postcss-cli --save-dev

Добавьте в package.json следующий код и модифицируйте скрипт build :

Теперь осталось лишь выполнить команду npm run build , и вы получите сжатый CSS-файл, в который будут добавлены префиксы браузеров. Вот репозиторий, в котором вы найдёте шаблонный проект, построенный с использованием рассмотренных здесь технологий. А вот — ещё один репозиторий с моими учебными проектами, при разработке которых я пользовался описанными здесь приёмами, и страница с рабочими примерами.

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

Итоги

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

Уважаемые читатели! Как вы создаёте стили для ваших веб-проектов?

CSS GuideLines, часть 1. Синтаксис и форматирование

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

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

Важность руководства по оформлению кода

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

• Установление стандарта качества кода для всех исходников;
• Обеспечение согласованности между исходниками;
• Следование стандартам всеми разработчиками;
• Увеличение продуктивности.

Дисклеймер

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

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

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

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

• 4 пробела для отступов. Именно пробелы, а не таб;
• Строки не длиннее 80 символов;
• Мультистрочный CSS;
• Эффективное использование пустого пространства.

Разбиение на несколько файлов

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

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

Таблица содержимого

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

Например, самый простой вариант оглавления — добавить название раздела и его описание:

/** * CONTENTS * * SETTINGS * Global. Globally-available variables and config. * * TOOLS * Mixins. Useful mixins. * * GENERIC * Normalize.css. A level playing field. * Box-sizing. Better default `box-sizing`. * * BASE * Headings. H1–H6 styles. * * OBJECTS * Wrappers. Wrapping and constraining elements. * * COMPONENTS * Page-head. The main page header. * Page-foot. The main page footer. * Buttons. Button elements. * * TRUMPS * Text. Text helpers. */ 

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

Ширина строки в 80 символов

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

/** * Я — очень длинный комментарий. Я детально описываю CSS-код подо мной. Я * настолько длинный комментарий, что я превышаю лимит в 80 символов, * поэтому я разбит на несколько строк. */ 

Следует отметить, что есть и исключения для этого правила — например, строки с длинными URL-адресами.

Именование секций кода

Каждый крупная секция CSS-кода должна начинаться так:

/*------------------------------------*\ #SECTION-TITLE \*------------------------------------*/ .selector <> 

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

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

/*------------------------------------*\ #A-SECTION \*------------------------------------*/ .selector <> /*------------------------------------*\ #ANOTHER-SECTION \*------------------------------------*/ /** * Comment */ .another-selector <> 

Анатомия CSS-правил

Прежде чем поговорить о том, как разработчикам следует писать CSS-правила, давайте уточним используемую терминологию:

[селектор] < [свойство]: [значение]; [] > 

.foo, .foo--bar, .baz

• Связанные селекторы на одной строке, несвязанные селекторы на разных строках;
• Пробел перед открывающей скобкой ( <);
• Свойства и их значения на одной строке;
• Пробел после двоеточия, относящегося к свойству;
• Каждое объявление свойства и его значения на новой строке;
• Открывающая скобка находится на той же строке, что и последний селектор;
• Первое объявление свойства находится на новой строке после открывающей скобки;
• Закрывающая скобка находится на отдельной строке:
• Каждое объявление имеет отступ в 4 пробела;
• Точка с запятой находится сразу после значения свойства, без пробела.

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

.foo, .foo--bar, .baz

• Табы вместо пробелов;
• Несвязанные селекторы на одной строке;
• Открывающая скобка на отдельной строке;
• Закрывающая скобка на той же строке, что и последнее объявление;
• Точка с запятой (кстати говоря, необязательная именно в последнем объявлении) в конце последнего объявления не стоит;
• Нет пробелов после двоеточий.

Мультистрочный CSS

• Снижение риска появления конфликтов при слиянии объявлений за счет того, что каждое объявление находится на отдельной строке;
• Более надежные и читаемые diff’ы, потому что одна строка несет только одно изменение.

.icon < display: inline-block; width: 16px; height: 16px; background-image: url(/img/sprite.svg); >.icon--home < background-position: 0 0 ; >.icon--person < background-position: -16px 0 ; >.icon--files < background-position: 0 -16px; >.icon--settings

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

Отступы

Так же, как вы делаете отступы для объявлений, делайте и отступы у связанных наборов правил:

.foo <> .foo__bar <> .foo__baz <> 

Благодаря этому разработчик сразу увидит, что .foo__baz располагается внутри .foo__bar, который, в свою очередь, находится внутри .foo. Такой способ имитации DOM многое рассказывает разработчикам о том, где класс располагается, благодаря чему не приходится каждый раз открывать разметку и искать нужный кусок кода.

Отступы в Sass

Sass предоставляет возможность вкладывать правила друг в друга. Это означает, что написав такой scss-код:

… мы получим следующий скомпилированный CSS:

.foo < color: red; >.foo .bar

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

Выравнивание

По возможности, выравнивайте схожие строки со свойствами:

.foo < -webkit-border-radius: 3px; -moz-border-radius: 3px; border-radius: 3px; >.bar

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

Разумное использование пустого пространства

• Одну пустую строку между связанными наборами правил;
• Две пустые строки между несвязанными наборами правил;
• Пять пустых строк между секциями.

/*------------------------------------*\ #FOO \*------------------------------------*/ .foo <> .foo__bar <> .foo--baz <> /*------------------------------------*\ #BAR \*------------------------------------*/ .bar <> .bar__baz <> .bar__foo <> 

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

.foo <> .foo__bar <> .foo--baz <> 

HTML

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

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

Этот код будет работать:

 Но предпочтительно использовать такой код:

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

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

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

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

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

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

Материалы для дополнительного изучения