Как разбить css на файлы

Разбиение стилей с помощью sass

Иногда при верстке бывает необходимо разбить файлы стилей на несколько по какому-нибудь принципу. В этой статье мы разобьем стили на основной файл и файл для IE9.

Структура папок (отображены только те, которые необходимы для данной статьи):

└──assets └── sass/ └── helpers/ _mixins.scss _reset.scss _fonts.scss _header.scss _main.scss _includes.scss main_global.scss ie_9.scss └──dist └──styles main_global.css ie_9.css

Т.к. sass не компилирует файлы начинающиеся на символ “_” , в итоговом css оказываются только основные файлы. Сейчас это работает по следующей схеме:

main_global.scss — стили всего проекта без IE9
ie_9.scss — стили всего проекта + IE9

Рассмотрим как это работает.

В файле _mixins.scss объявляем миксин для разделения стилей IE9:

@mixin ie_9_check  @if $ie9 == true  @content; > >

Все отдельные стили включаем в один файл :

@import "includes/_mixins"; @import "reset"; @import "fonts"; @import "header"; @import "main";

Основной файл стилей выглядит так:

$prefix-for-webkit: true !default; $prefix-for-mozilla: false !default; $prefix-for-microsoft: true !default; $prefix-for-opera: false !default; $prefix-for-spec: true !default; // required for keyframe mixin $develop:true; $production:false; $all:true; $ie9:false; $ie8:false; $ie7:false; $doc:false; $local_var:global; $holydat_var:none; @import "includes";

Весь файл нам в данный момент не интересен, обратите внимание на два ключевых момента:

$ie9:false; @import "includes";

В наш файл войдут все стили, кроме IE9. Файл для IE9 будет отличаться только переменной $ie9.

$prefix-for-webkit: true !default; $prefix-for-mozilla: false !default; $prefix-for-microsoft: true !default; $prefix-for-opera: false !default; $prefix-for-spec: true !default; // required for keyframe mixin $develop:true; $production:false; $all:true; $ie9:true; $ie8:false; $ie7:false; $doc:false; $local_var:global; $holydat_var:none; @import "includes";

Теперь в _main.scss запишем стили и посмотрим итог:

.container  display: flex; @include ie_9_check()  display:block; > > @include ie_9_check()  .parent  display: block; > .child  float:left; width: 33%; > >

.container  display: flex; >

.container  display: flex; display: block; > .parent  display: block; > .child  float: left; width: 33%; >

Как разбить css на файлы

на старте разработки css правила быстрее и проще писать в одном файле.

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

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

какрас сегодня думал почему никто не делает даклад о проблеммах БЕМ-а. разбивка компанента на множество мелких файлов одна из ярких странностей БЕМ-а

имхо если для компонента требуется более 1-го css файла то стоит подумать о том чтоб разбить этот компонент на более мелкие.

В официальном наборе такого инструмента нет.

Сделать его не должно быть сложно. Для парсинга css можно использовать gonzales.

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

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

а есть какой-то неофициальный набор (мм.. неужели Яндекс опенсорсит лишь необходимый, но не достаточный стек технологий)?

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

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

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

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

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

для составных css селекторов «.a .b < .. >» придумалося следующий принцип: помещать код в файл для максимально конкретной сущности. который представляется думя правилами. 1. селектор читается справа-налево. 2. элемент конкретнее блока, а модификатор конкретнее всех.

например, результат разложения селетора

.b-form-input__popup .b-form-input__popup-items <>

разложится в файл b-form-input/__popup-items/b-form-input__popup-items.css т.к селектор элемента popup-items стоит правее, а значит он конкретнее.

Как разбить таблицу стилей на части?

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

Отслеживать
32k 19 19 золотых знаков 79 79 серебряных знаков 105 105 бронзовых знаков
задан 16 апр 2013 в 8:59
408 8 8 серебряных знаков 21 21 бронзовый знак
Чтобы не получалась огромная колбаса из стилей, нужно не создавать эту колбасу 🙂
16 апр 2013 в 9:10

Их с самого начала разбивают на определенные разделы: один для каркаса например, другой для слайдера, третий для новостей. А уже перед релизом файлы стилей объединяют в один.

16 апр 2013 в 9:11

Какие технологии? Какие плюсы/минусы? Открыл css в блокноте, вырезал кусок, вставил в новый файл! Лень открывать в блокноте — напиши простенький парсер, который будет разбивать один css-файл на несколько так, чтобы не разрывать на части определение одного правила.

16 апр 2013 в 9:19

я не знаю даже с чего начать, думал, не придется писать очевидные вещи, но скептицизм очень свойственен программистам, да и айтишникам вообще. >> взять да разбить взял, да разбил. получилось пятнадцать @import. я так понимаю, это 15 ненужных запросов к серверу? то же самое, если встраивать с помощью link. >> Чтобы не получалась огромная колбаса из стилей, нужно не создавать эту колбасу 🙂 в натуре! как же я сразу не догадался просто не писать ничего в css файле! ой. а что это сайт у меня черно-белый стал?

16 апр 2013 в 9:25

Чтобы сами собирались в один — это запросто. Просто при сохранении дебужной версии из редактора герится релизный CSS. Правил при этом можно насоздавать сколько угодно, хоть на каждую страницу. Ну или ещё как-то, вариантов подобной автоматизации навалом, как хочешь так и делай. Про «не создавать колбасу» что удивило? К CSS нужно относиться как к любому другому коду. Чтобы и через полгода ты мог ткнуться в любое место и сказать зачем оно. В иной css посмотришь: каждая пыркалка со своим id тащит полстраницы свойств, а что это — непонятно. А сократить можно было бы раз в 5 (см. первую «C»).

Стоит ли разделять CSS и JS на более мелкие

При изучении основ сайтостроения, учат все стили и js-код выносить в отдельные файлы. И, как правило, всё кучей пишется в один большой файл.

В bitrix, как, наверное, и в любой другой CMS, у каждого модуля есть свои собственные js и css файлы. Тут это всё крайне логично, особенно, в случае с подключаемыми модулями. Это скорее следствие реализуемого в той или иной степени иерархического MVC, то есть независимости друг от друга различных частей приложения.

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

Возникает два вопроса: “как?” и “зачем?”. Давайте по порядку.

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

Я навскидку предлагаю два способа подключения “своих” файлов к скрипту.

Создавать файлы с одинаковыми названиям в папках со скриптами.

Мы создаем в папке с вызываемым скриптом файлы style.css и script.js. При подключении стилей и javascript’ов в head, проверяем в папке с текущем вызываемым скриптом наличие этих самых файлов и если они там есть, то подключаем их.

Создаем в папке, где у нас лежат css и js скрипты файлы с названием папки в которой лежит исполняемый в данный момент скрипт.

Так например, если мы сейчас находимся в clickon/catalog/, то при подключении стилей и js, мы проверяем наличие файлов /css/catalog.css и /js/catalog.js, и если они там присутствуют, то подключаем.

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

Возможно, для маленького сайта это и бессмысленно.

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

Например, есть магазин с интересной версткой каталога с css на 1000+ строк и js на 200+ строк.

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

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

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

Получается своего рода инкапсуляция css и js файлов.

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

Поделиться:

Зачем и как правильно оформлять страницы сайта?

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

vitaliy

Как сэкономить на контекстной рекламе или не Директом единым.

vitaliy

Таргетинг по тематическим площадкам в РСЯ

vitaliy

Зачем платить за рекламу в социальных сетях

vitaliy

Какие сайты должны использовать сертификаты безопасности?

adsvet

Что продается в социальных сетях

vitaliy

Контекстная реклама или SMM, что выбрать?

vitaliy

Каким должен быть сайт медицинского учреждения?

vitaliy

Палех. Жар-птица для оптимизатора

vitaliy

Участие в семинаре «Как создать успешную рекламную компанию в Google AdWords»

vitaliy

Google Tag Manager все скрипты в одном контейнере…

vitaliy

UTM метки в SMM или как считать лиды из социальных сетей

vitaliy

Черная и белая стороны продвижения в Instagram

vitaliy

Новый пиксель ВКонтакте — новые возможности по сбору баз ретаргетинга с сайтов

vitaliy

Почему seo-продвижение сайтов это не только ссылки?

Старые продукты. Польза или вред?

Версия для слабовидящих — нюансы разработки

Почему мы используем Parser в большинстве своих проектов?

vitaliy

Что показывает статистика Яндекс Wordstat

Что лучше адаптивная вёрстка или мобильная версия

Новый алгоритм «Владивосток» — ранжирование сайтов в мобильном поиске Яндекса

vitaliy

Поздравление клиентов с новым 2016 годом

vitaliy

Адская капча

Что нужно дизайнеру для работы в web-студии?

ClickON на семинарах Google AdWords и Google Analytics в Волгограде

vitaliy

Интересные страницы ошибок 404

Творческий клиент — инфаркт дизайнера

Никто не знает что такое “тех.поддержка сайтов”

Евгения Медникова

Что такое продвижение с социальных сетях (SMM) и что оно даст вашему бизнесу?

vitaliy

Как организовать рассылку со своего сайта и не попасть в спам-лист

SEO 2.0

Евгения Медникова

Яндекс отжигает 🙂

Вот нехорошо, но не удержался

А вот просто про время. 🙂

Человечные опыты над Blender (часть II)

Как должна называться правильная веб-студия, или «фух, отлегло» 🙂

Никто его не любит, не любит, не любит.

Это очень смешно и это реально одновременно.

Продвижение сайтов в Волгограде — держи карман крепче

07 апреля 2016 16:18:12

read

На dev версии должно быть разделение файлов для удобной разработки. На production всё должно объединяться в один файл css и один js. Всё должно минифицироваться. Плюсы: малое кол-во запросов на сервер для получения статики; более быстрая загрузка страницы для клиента; то, что файл получится большой, не совсем беда — он закэшируется на клиенте; более быстрая загрузка страницы положительно сказывается в СЕО.

07 апреля 2016 16:33:30

ShaGGy

Именно. Подцепляем один раз, объединяем и кэшируем. Это и имелось в виду.

Создание и продвижение сайтов для бизнеса только кликни мы откликнемся

Создание и продвижение сайтов.
© 2004-2023, +7-8442-60-20-77, +7(495)740-35-85,
8-800-77-55-123 бесплатно по России

адреса, контактыМосква, м. Павелецкая, ул. Дербеневская, дом 11

адреса, контактыВолгоград, ул. Ковровская, дом 24, 4 этаж, офис 317

Вся информация, размещённая на сайте не является публичной офертой, кроме тех случаев в которых явно указано на оферту

Будущему клиенту
О нас в других форматах: ВКонтактеRSS

В порядке и на условиях, определённых Федеральным законом от 27 июля 2006 года № 152-ФЗ «О персональных данных». Согласие на обработку следующих моих персональных данных: фамилии, имени, отчества, года, месяцы, даты и места рождения, пола, гражданства, места жительства, в том числе сведения о регистрации по месту жительства, месту пребывания, места работы, социального положения (статуса), реквизитов документа, удостоверяющего личность. Обработка моих персональных данных Оператором осуществляется исключительно в целях защиты моих прав на регистрацию доменного имени, услуги по созданию и продвижению сайтов, услуги по размещению рекламных компаний в интернет и обеспечения соблюдения законов и иных нормативных правовых актов, связанных с предоставлением этих услуг. Я предоставляю Оператору право осуществлять следующие действия с моими персональными данными: сбор, систематизация, накопление, хранение, уточнение (обновление, изменение), использование, обезличивание, блокирование, уничтожение персональных данных, передача персональных данных между: — Оператором ООО «КликОН», в котором мне будут осуществляться вышеперечисленные услуги ; — Оператором АНО «Региональный Сетевой Информационный Центр», осуществляющим непосредственную регистрацию доменных имён ; Мне гарантируется конфиденциальность моих персональных при обработке их и хранении не дольше срока, предусмотренного нормативными актами. Настоящие согласие данное мной и действует бессрочно. Я оставляю за собой право отозвать своё согласие посредством составления соответствующего письменного документа, который может быть направлен мной в адрес Оператора по почте заказным письмом с уведомлением о вручении либо вручен лично под расписку уполномоченному представителю Оператора.