Как разбить css на файлы
Обновлено: 06.07.2024
Каждый раз, когда приходится создавать какой-то элемент, возникает небольшая проблема с придумыванием имени класса элемента, потому что мы хотим назвать его понятным именем, отражающим смысл и назначение этого элемента. Также, должны учесть то, что имя css-селектора не должно пересекаться с другими стилями.
Для того чтобы победить эту проблему, были разработаны разные методологии организации кода в css, но не все фронтендеры пользуются этими методологиям, и не все они идеальны.
Когда у нас в макете много разных по оформлению блоков, которые несут в себе один смысл, использовать понятное имя становится сложно. Чтобы добиться нужного результата приходится добавлять к имени еще что-то. Это все может сделать код трудным для восприятия (как длиннющие названия классов в беме).
Если вам посчастливилось присоединится к разработке какого-то проекта, то, возможно вы сталкивались с такой ситуацией когда стили написанные вами, пересекаются с теми, которые уже есть и используются в проекте. Самое неприятное, что это может всплыть не сразу, а когда всплывает, не всегда понятно откуда ноги растут.
Важную роль во всем этом играет еще то, как организована структура проекта. Чаще всего можно встретить свалку файлов в каталоге css(и не только там), тому кто пришел в проект бывает совсем не очевидно, в каком файле лежит нужный стиль и как стили одного файла влияют на стили другого файла. Хотелось бы верить, что когда все браузеры научатся понимать стандарты web components, проектов с помойной структурой станет меньше, и эти проблемы исчезнут.
Не смотря на то, что пока браузеры не всё умеют, много чего уже реализовано в компонентом стиле с помощью разных библиотек и полифилов, и это отлично работает, причем давно! Но бывают задачи, в которых использование мощных фреймворков и библиотек просто не нужно. К таким задачам можно отнести создание шаблонов под всякие вордпрессы, опенкарты, битриксы и прочие движки.
Как делают другие?
Чтобы решить проблему изоляции стилей, нам необходимо посмотреть, каким образом достигают этого современные фреймворки и библиотеки.
Для популярнейшей библиотеки от синей социальной сети, разрабатываются различные решения, которые последнее время, одно ужаснее другого (возможно я ошибаюсь и не до конца понимаю мощь этих решений).
Докатились до того, что, в js запихнули не только html, но стали писать еще и css, ломая устоявшиеся стереотипы, что так делать плохо. И тут можно сказать, что мы возвращаемся к тому с чего начали, свалка из структуры проекта перекочевала в код компонента.
Пару слов про новый велик
Для того чтобы такой подход можно было использовать в своих проектах, я решил написать плагин для gulp, который делает, примерно тоже самое, что Angular со стилями и html разметкой. Таким образом мы сможем реализовать инкапсуляцию стилей внутри компонента, при этом, нам ничего не помешает использовать глобальные стили, так как атрибут будет присвоен, только тем стилям и тегам, которые относятся к компоненту.
Структура проекта
Каждый компонент должен находится в своем каталоге. Имя каталога является именем компонента и используется в качестве префикса генерируемого атрибута. Все компоненты, должны лежать в каталоге components.
В каждом компоненте должен лежать файл html и css, если есть какая-то логика, то, там же следует разместить js файл.
Каждый компонент должен иметь свой тег. Желательно, чтобы в теге был дефис, например:
<my-component></my-component>
Такие правила заложены в стандарте custom elements, который пока мало где работает, но это не беда, рано или поздно заработает везде.
Свой тег компонента поможет лучше понимать что происходит в коде. Для демонстрации работы плагина и самого подхода, я подготовил крохотный пример.
В качестве примера я сделал два компонента карточек, карточка состоит из картинки и текста. Каждый компонент имеет одинаковые имена классов, но разные правила стилей, соответственно выглядеть все это должно по разному, то-есть вот так:
Вот такая получилась структура проекта:
После отработки всех gulp тасков, можно будет увидеть во что превратился код.
Код примера
Плагин
В статье, посвященной внешним таблицам стилей, говорилось о возможности подключать несколько различных CSS-файлов к одной HTML-странице, если использовать группу тегов link. Например, так:
Такой подход, когда таблицы стилей разделены на несколько файлов, иногда удобен. Он позволяет, как бы собирать общий CSS из отдельных блоков-файлов, используя только те из них, которые нужны непосредственно на данной странице.
Но злоупотреблять такой блочной структурой все же не стоит. Помни, что лишний файл — это лишнее обращение к серверу, а, значит, дополнительное время и трафик.
Впрочем, если ты все-таки решил использовать такую блочную структуру CSS, то, кроме тегов link, у тебя есть еще один вариант — директива @import.
Соединяем несколько CSS
Как ты, наверное, помнишь, в CSS-файле не может быть никакой HTML-разметки. То есть теги link, конечно, записываются непосредственно в файле HTML (в секции head).
В отличие, от link, директива @import позволяет соединять таблицы стилей внутри CSS. Указанные в директиве CSS-файлы загружаются и присоединяются к тому CSS в котором встретилась @import.
Синтаксис
- путь к CSS-файлу — абсолютный или относительный адрес файла;
- тип устройства — необязательный параметр, эквивалентный атрибуту media тега link. Позволяет импортировать таблицу только для определенных устройств отображения. Подробнее смотри в CSS справочнике.
Примечания:
Если в CSS есть директива @import, то она должна находиться в самом начале таблицы (перед всеми правилами). В противном случае браузер может ее проигнорировать.
Так, как @import — это CSS-конструкция, то содержатся она должна либо в CSS-файле, либо внутри тега style (использовать @import во встроенных стилях нельзя!).
Резюме
Для создания блочной структуры CSS можно использовать два варианта.
- подключать нужные файлы таблиц в HTML с помощью тегов link;
- импортировать все таблицы в одну, с помощью директивы @import.
Блочная структура удобна, например, в больших проектах, которые делает множество людей. Но помни, что для повышения быстродействия, как правило, таблицы наоборот, соединяют в один файл.
Поэтому использовать @import без реальной необходимости не стоит, т.к. страдает скорость загрузки.
Посоветуйте, как лучше всего разбивать стили на файлы, чтобы не получалась огромная колбаса из стилей? Какие есть варианты, технологии? Какие у них плюсы/минусы?
Лучше всего по области использования. То есть стремиться к тому, чтобы к странице подключалось только то, что необходимо. Это недостижимый результат на больших проектах.
reset.css - файл обнуления. Подключается везде.
basic.css - файл общих для всех страниц стилей.
catalog.css - каталог
modal.css - модальные окна
acp.css - админпанель
по технологиям: firebug или аналоги. просто смотрите что где используется, записываете. Можно попытаться автоматизировать. Некоторые IDEшки сами умеют определять неиспользуемые стили.
Я работаю над адаптивным веб-дизайном для доставки контента для всех размеров экрана. У меня есть медиа-запросы для 5 разных «шагов», а файл CSS - около 30 КБ.
Было бы лучше разбить это на отдельные файлы и сделать их похожими на это:
, или я должен хранить их в одном файле CSS?
Обновление: я просто хотел добавить, что моя главная проблема заключалась в том, что скорость открытия /рендеринга браузера /устройства была не просто, а простота разработки.
Я думаю, что это действительно зависит от того, что вы считаете самым легким для разработки, и что помогает вам поддерживать аккуратную таблицу стилей.
Единственный реальный недостаток, который я могу придумать в расщеплении, заключается в том, что если атрибут элемента появится во всех ваших таблицах стилей, вам нужно будет обновить 5 отдельных файлов, чтобы изменить его (вместо того, чтобы появляться бок о бок в одном месте ).
Это немного зависит от того, чего вы хотите достичь: пытаетесь ли вы быстрее загружать свою страницу или пытаетесь сделать процесс разработки более легким?
Если вы нацелитесь на последнее, вы можете использовать несколько листов, но это все зависит от предпочтений. Я считаю, что проще всего использовать один большой файл, так как это дает вам обзор всех стилей, которые вы объявили.
Далее я попытался бы оптимизировать сам css. Вы можете попытаться объединить классы, которые очень похожи, например:
Может быть преобразован в:
Единственное, что вам нужно немного изменить html: <span > foo bar </span> в класс <span >foo bar</span>
Надеюсь, это поможет.
Вероятно, лучше всего иметь только один файл CSS, но для его минимизации и gzip. Предполагая, что ваш 30KB до этого, вы, вероятно, получите размер файла примерно до 5 КБ с мини-настройкой (удаление пробела) и gzipping.
Разделение, вероятно, приведет к еще большему ускорению, но только при некоторых условиях.
Кроме того: не следует оптимизировать преждевременно. Только делайте это, если у вас проблемы с производительностью.
Я был бы склонен сказать это.
Для производства всегда держите их в одном файле; причина в том, что он более эффективен для браузера, и это должно быть вашим основным интересом (IMO) при переходе от разработки к производству.
Развитие - это отличный чайник. Я стараюсь разбить медиа-запросы так, чтобы они были с помощью любого элемента, например:
Как правило, если я меняю элемент, я не хочу, чтобы он везде искал CSS (хотя вы можете использовать что-то вроде grep . ).
Но , я бы сказал, что стоит рассмотреть сам сайт, процесс разработки и так далее. Если вы искренне думаете, что стоит отделить их в файлах на основе размера экрана, дайте им уйти. Сделайте копию сайта (если возможно), попробуйте сыграть с копией - если это упростит, используйте это. Вам не нужно следовать парадигме единого размера, как разработать веб-сайт.
Вы должны разделить файлы CSS на основе медиа-запросов, потому что файлы CSS блокируются рендерингом.
Когда браузер создает вашу DOM, он должен сначала подождать и загрузить все ваши файлы CSS. Вы уменьшите время загрузки страницы, если некоторые из ваших файлов CSS загружаются только на основе определенных медиа-запросов.
Это также относится к добавлению async в тег скрипта JavaScript; например: <script src='myfile.js' async></script> .
DOM не должен ждать загрузки вашего JS-файла. Добавляйте async только в том случае, если для построения DOM не нужен какой-либо из этих JavaScript при загрузке.
Простой: используйте 1 таблицу стилей и просто добавьте к ним комментарии, чтобы упростить поиск и изменение стилей CSS, например.
Если вы хотите, вы можете использовать несколько таблиц стилей и называть их для каждого конкретного размера.
Я бы предпочел посмотреть Bootstrap . Это 1 файл CSS, содержащий все CSS. Он работает почти на 99% браузеров и очень отзывчив.
Нажмите живую демонстрацию увеличения ( Ctrl + = увеличить, Ctrl - = уменьшить масштаб, Ctrl 0 = normal) или откройте его на своем мобильном устройстве, чтобы посмотреть, как он выглядит.
Читайте также: