Как я структурирую CSS

Автор оригинала: Matthias Ott
  • Перевод

Приветствую. Представляю вашему вниманию перевод статьи «How I Structure My CSS (for Now)», опубликованной 11 августа 2020 года автором Matthias Ott

Когда вопрос касается структурирования CSS, нет недостатка различных соглашений об именовании, методологий и архитектур. Будь то BEM, OOCSS, SMACSS, ITCSS или CUBE CSS - за последние годы появилось много разных подходов к управлению модульным CSS. Одни предлагают стратегии разделения CSS на небольшие, лучше поддающиеся управлению фрагменты, другие больше сосредотачиваются на соглашениях об именовании классов. Порой сложно понять, в чём отличия или преимущества определённых методик, но у всех них, в конце концов, одна цель – обеспечить единую структуру и принципы при работе в команде с другими людьми или с самим собой в будущем.

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

В этой статье я поделюсь своим текущим принципом структурирования CSS. В нём я не придерживаюсь какой-либо определённой методологии, хотя те, кто знаком с ITCSS Гарри Робертса, определённо увидят сходства. Если вы ещё не знакомились с ITCSS, настоятельно рекомендую это сделать. Больше всего в этой методологии мне нравится прагматичный, полностью прикладной подход и принцип структурирования, делающий CSS всё более конкретным и явным по мере продвижения вниз по структуре. Это облегчает работу с каскадом и наследованием селектора, оставляя количество классов их специфичность на низком уровне. Существует, однако, и несколько отличий, и это именно то, что я предлагаю любому, кто создаёт свою собственную структуру: берите любую методологию и свободно адаптируйте её к своим потребностям и способу работы.

Структура основной папки

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

/scss/
├── 1-settings
├── 2-design-tokens
├── 3-tools
├── 4-generic
├── 5-elements
├── 6-skeleton
├── 7-components
├── 8-utilities
├── _shame.scss
└── main.scss

Настройки

Первая папка 1-settings предназначена для общих настроек проекта, самой базовой конфигурации. Это может быть набор глобальных переменных: Sass-переменных или CSS-переменных

├── 1-settings
│   └── _global.scss

Дизайн-токены

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

├── 2-design-tokens
│   ├── _colors.scss
│   ├── _fonts.scss
│   ├── _media-queries.scss
│   ├── _spacing.scss
│   └── _typography.scss

Инструменты

Папка "Tools" предназначена для ваших глобальных Sass-миксинов и функций. Возможно, вы захотите управлять цветами с помощью режимов смешивания (blend-mode) или установить соотношение сторон для элемента, содержащего видео? Или применить "clear" для каких-то float-элементов. Сам я не особо использую миксины, но знаю много людей, которые их любят.

├── 3-tools
│   ├── _aspect-ratio.scss
│   ├── _blend-modes.scss
│   ├── _center.scss
│   ├── _clearfix.scss
│   └── _gradients.scss

Общие стили

Как и в методологии ITCSS, "generic" - первая папка, в которую помещаются стили для оформления разметки. Она содержит глобальные правила "box-sizing", сброс CSS или стили для печати - всё, что должно быть задано в самом начале CSS, но еще не зависит от конкретного проекта.

├── 4-generic
│   ├── _box-sizing.scss
│   ├── _font-face.scss
│   ├── _normalize.scss
│   └── _print.scss

Элементы

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

├── 5-elements
│   ├── _forms.scss
│   ├── _headings.scss
│   ├── _images.scss
│   ├── _links.scss
│   └── _lists.scss
│   ├── ...

Скелет

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

├── 6-skeleton
│   ├── _grid.scss
│   ├── _layouts.scss
│   └── _objects.scss

Компоненты

Сердце проекта. Здесь мы разрабатываем компоненты интерфейса. В нескольких последних проектах я даже отделял большие модули и маленькие компоненты, но вместо этого можно просто вкладывать компоненты друг в друга. Если нравится, можете использовать префиксы и соглашение об именовании, такое как BEM. Недавно я остановился на BEM-подобном, но более упрощённом соглашении об именовании. Суть в том, чтобы использовать как можно более простые, но информативные имена классов и разделять элементы и их содержимое чертой. Например, .card и .card-content. Иногда, когда я работаю с Fractal, CSS для отдельных компонентов может также находиться в другой папке вместе с HTML и JavaScript-кодом. В этом случае папка с компонентами может быть пустой или содержать @import@.

├── 7-components
│   ├── _accordion.scss
│   ├── _card.scss
│   ├── _hero.scss
│   ├── _pan-galactic-gargle-blaster.scss
│   └── ...

Утилиты

Ещё одна папка? Да, но эта - последняя. Папка "utilities" содержит служебные и другие полезные классы и, самое главное, состояния и модификаторы, такие как .is-active или .visually-hidden. Эти стили переопределяют стили предыдущих слоёв и часто устанавливаются через JavaScript. Мне очень нравится предложение Andy Bell в его методологии CUBE CSS использовать data-атрибуты для изменения состояния компонентов, что также полезно с точки зрения большей специфичности.

├── 8-utilities
│   ├── _modifiers.scss
│   └── _states.scss

_shame.css

Этот файл является ещё одной идеей Harry Roberts и предназначен для всех постыдных CSS-решений, таких как быстрые фиксы и хаки, которые могут выступить временным решением, но позже должны быть реализованы как полагается. Обязательно документируйте все эти временные меры с помощью комментариев. Почему вы реализовали это именно так? Есть ли у вас идея, как сделать лучше? Что для этого нужно? И так далее.

Собираем всё вместе

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

@charset "UTF-8";

// 1. Settings
@import 
	"1-settings/global";
  
// 2. Design Tokens
@import
  "2-design-tokens/colors",
  "2-design-tokens/fonts",
  "2-design-tokens/media-queries",
  "2-design-tokens/spacing",
  "2-design-tokens/typography";
...

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

На днях я делал опрос в Твиттер о предпочитаемой CSS-методологии:

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

Итоговая структура папок:

/scss/
├── 1-settings
│   └── _global.scss
├── 2-design-tokens
│   ├── _colors.scss
│   ├── _fonts.scss
│   ├── _media-queries.scss
│   ├── _spacing.scss
│   └── _typography.scss
├── 3-tools
│   ├── _aspect-ratio.scss
│   ├── _blend-modes.scss
│   ├── _center.scss
│   ├── _clearfix.scss
│   └── _gradients.scss
├── 4-generic
│   ├── _box-sizing.scss
│   ├── _font-face.scss
│   ├── _normalize.scss
│   └── _print.scss
├── 5-elements
│   ├── _forms.scss
│   ├── _headings.scss
│   ├── _images.scss
│   ├── _links.scss
│   ├── _lists.scss
│   └── ...
├── 6-skeleton
│   ├── _grid.scss
│   ├── _layouts.scss
│   └── _objects.scss
├── 7-components
│   ├── _accordion.scss
│   ├── _card.scss
│   ├── _hero.scss
│   ├── _pan-galactic-gargle-blaster.scss
│   └── ...
├── 8-utilities
│   ├── _modifiers.scss
│   └── _states.scss
├── _shame.scss
└── main.scss

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

    +5
    Как же я люблю смотреть на людей, которые все усложняют на серьезных щщах и выдают это за откровение.
      0
      А как в данном случае использовать кастомные файлы стилей сторонних наборов компонентов (PrimeNG, Ant Design, Telerik, DevExpress и тд)?
        +1

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

          +1

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


          Это если нет каких то механизмов изоляции стилей, как в angular например

            0
            Микроскопом по гвоздям, когда проблема в самом интрументе, пытаться решить ее поиском способа именования, чтобы он не «сдувался»
              0

              Расскажите как правильно делать

                +1
                — отдельный файл с css переменными
                — дефолтные стили элементов (table, card итд), причем сделаны они должны быть так чтобы дочерние элементы не требовали позиционирования в родительском через margin.
                — стили компонентов должны лежать прямо в каталоге компонента и по возможности вносить минимальные изменения для обеспечения своих функций. При правильной организации они нужны редко.
                — все css правила сортированы по алфавиту

                Легко, просто, не жрем себе мозг.
                  0
                  вы не ответили на вопрос. (upd: оказывается я и не вам его задавал :D)
                  как вы стили компонентов инкапсулируете?

                  При правильной организации они нужны редко

                  В идеальном мире, где нет никакой кастомизации компонентов

                  Начиналось с «Ребят, это ж всего лишь текстовик со стилями, вы чего носитесь с ним?»

                  Тут уж «Вот у меня есть несколько правил» никак не соответствует вышесказанному

                  Мой изначальный посыл был, что это не просто «текстовик со стилями» если нет никакой инкапсуляции то рано или поздно начнутся проблемы
                    0
                    как вы стили компонентов инкапсулируете?

                    Вообще у vue.js Был какой то механизм, но я лично — никак. Я стараюсь делать стили такими, чтобы у компонентов общего назначения не было необходимости в стилях. А компоненты применяемые один раз (например компонент конкретной страницы) — через Id.

                    рано или поздно начнутся проблемы

                    В современном вебе проблемы начинаются очень быстро и связаны они с тем что люди думать перестали. Ну простой пример
                    .mds_precious_card
                    .mds_precious_card > *
                    .mds_precious_card > h2

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

                    Конечно, пример утрированный, но я это вижу постоянно.

                    Итого у нас остаются строго функциональные стили которые являются уделом создателей компонентов. Именуем их по имени компонента и радуемся жизни.
                      0

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

                        +1
                        ой камон, какая производитильность на дата атрибутах? Думать надо как меньше кода писать, хотя бы jquery до 3 версии обновить)), вот это значимо.
                        0

                        А потом h2 заменили на h3 и стили слетели
                        А если отступ нужен для одного элемента другой — уже нужен класс. Для последнего сделали через :last-child, а потом добавился ещё один блок и нужно переделывать

                          0

                          Так может тогда суть беды в архитектуре, а не в именовании классов?

                            0
                            А потом h2 заменили на h3 и стили слетели

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

                            а потом добавился ещё один блок и нужно переделывать

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

                            А если отступ нужен для одного элемента другой — уже нужен класс.

                            Нет не нужен.
                            У вас есть карточка, нет разницы что вы в нее воткнете, ничего не должно особо меняться. Если элемент несет какую либо семантику, как например type=«submit», section, итд итп их тоже можно проработать для компонента и прописать стили в родительском компоненте.

                            Если вам нужны стили строго по месту то либо через #id родительского компонента либо по id дочернего. Какое тут место классу тоже не понимаю.

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

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

                                у вас нет дизайнера

                                Даже не знаю что этим хотелось сказать…

                                не все живут в идеальном мире

                                но некоторые могут его создавать
                                  0
                                  и вы для этого используете описанный подход?
                                  Это довольно забавно, если учесть, что в vue, как и у многих других фреймворках, есть возможность использовать css modules, которые инкапсулируют стили в рамках компонента.
                                  «Хитрый стиль для заголовка» это вообще как?
                                  Не проще ли всем назначать классы и стилизовать от них, а не от родителя?
                                  То, что вы пишите, очень смахивает на ретроградный подход к верстке, но вы пишите на vue и не используете базовых возможностей?
                                  А тилизовать от id, это попахивает извращением.
                                    0
                                    Попробуйте нахреначить стилей прямо по компонентам а потом поддерживать две темы. В остальном мне в принципе все равно как вы делаете, убеждать мне лениво.
                                      0
                                      не нужно убеждать. Нужно попробовать найти механизм, который удобно позволяет поддерживать темы, при использовании css модулей. У меня с этим нет проблем, и вам рекомендую обратить внимание на эту кроличью нору.
                                        0
                                        Меня все устраивает.
                                          0
                                          что ж, после такого безапелляционного ответа, действительно нет смысла что-то обсуждать. Надеюсь, что не только вам такой подход удобен.
                              –1
                              Это кто это такой модный будет менять уровни заголовков?) Это очень серьезная модификация, чтобы ее случайно сделать.
                              Если можно обойтись без стилей, лучше без них. Например, меню
                              nav ul li a span

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

                                0
                                Дополню предыдущего оратора: этот подход вам позволит сменить или написать новую тему легко и просто.

                                Если у вас в проекте есть кастомные компоненты, то они должны содержать только тот css который их делает таковыми.

                                Например мы очень хотим табличку со стики хедером:
                                .mds_datagrid thead > tr > th {position:sticky; top:0;}
                                и все, остальные стили наследуем с table
                  0

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


                  … потом вываливают CSS на 4мб, в котором намешаны фреймворки, лайфхаки, нейроинтерфейсы и малиновое варенье.

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

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

                    Но когда проект разрастается и вместо страницы с десятком секций мы имеем сотни, то все становится сильно сложнее. Без внятной структуры такую систему в принципе невозможно поддерживать.

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

                    С этой проблемой сталкиваются все верстальщики, но, к сожалению, не все умеют ее красиво решить.
                    0
                    Насмотрелся я на эти структуры в темах вордпресса. Думал, вертел и не понял прикола.

                    Я не верю, что автор способен придерживаться этой структуры без ущерба. Любая структура это рамки. Я порой, чтобы не думать, куда пхать индивидульные стили, кладу их в main.scss, inner, contacts проще искать. Если ты описываешь уникальные сущности, привязанные скорее к урлам, их проще потом искать и отрефакторить если вдруг изменение будет в html.
                      0
                      Проблемы начнутся, когда по мере роста проекта в условном main.scss количество кода перевалит за десяток тысяч строк. Вот тогда и начинают посещать мысли о структуре и определенных рамках.
                        0
                        Если речь идет десятках тысяч, это либо легаси, либо бойлерплейт индусский. Там уже структура историческая, осмыслять поздно)
                          0
                          По мере роста проекта количество кода неизбежно растет. Чем лучше он структурирован — тем дешевле его поддерживать и вносить изменения.

                          Собственно, по этой причине одним верстальщикам платят 5$ в час, а другим 50$.
                            –2
                            css не код. Его особо структурировать не надо. От переструктуризации начинаются грязные хаки. Но границу эту я не смогу назвать. А платят так, как себя продашь.
                              0
                              Вот из таких убеждений и рождается то что вы называете индусским бойлерплейтом.

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

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

                              В итоге рано или поздно клиент уйдет к другим разработчикам, которым придется это все счастье разбивать на более мелкие компоненты и рефакторить. Вот так и получаются ставки и 50$, и 100$ в час.
                                0
                                Мы все равно говорим без предмета критики. Я критикую подход из статьи. Он переструктурирован. Крупный магазин просто обслуживается не одним человеком, поэтому договоренности тут не потому что не дадут переписать, а потому что решение должно быть удобным не для одного.
                                Яж не говорю все лепить в 1 файл. Я видел темы вордпресса которые так структурированы и кроме самодурства ничего в голову не пришло. С ними работать нифига не проще, особенно бесят папки, поиск по которым достает.

                                Топик какой-то скучный. Раньше минусили, спорили. Сейчас всем все равно.
                          0
                          Он у вас что 5 лет растет? Через два года уже все переписывать и менять надо, а большинство проектов — это просто странички.
                            0

                            'Через два года уже все переписывать и менять надо'


                            Зачем?

                              +1

                              Потому-то пишут в одном файле и невозможно поддерживать)

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

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

                        Это хорошо работает на маленьких проектах. Там вообще любой подход будет работать: описание всех стилей в одном файле, всякие Tailwind и прочие Atomic CSS, можно даже Bootstrap прикрутить.

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

                        Самый оптимальный способ ее решить — это система именования в комбинации с использованием каскада. Проблему конфликта имён можно решить с помощью суффиксов для классов компонент. Проблему с переиспользуемыми элементами — с помощью оператора @extend.
                          0
                          Только не с помощью оператора extend, а с помощью миксинов, которые просто дублируют код. Кроме того, миксины проще изменять и дополнять, прокидывая аргументы.
                          Использование экстенд достаточно давно считается антипаттерном (есть исключения, конечно, но в целом это антипаттерн), потому что экстенды плохо работают с вложенными селекторами, media query и ухудшают читаемость кода (если экстенд используется не 2-3 раза, а 50-100).
                          Extends or Mixins?
                          Extends and mixins are both ways of encapsulating and re-using styles in Sass, which naturally raises the question of when to use which one. Mixins are obviously necessary when you need to configure the styles using arguments, but what if they’re just a chunk of styles?

                          As a rule of thumb, extends are the best option when you’re expressing a relationship between semantic classes (or other semantic selectors). Because an element with class .error--serious is an error, it makes sense for it to extend .error. But for non-semantic collections of styles, writing a mixin can avoid cascade headaches and make it easier to configure down the line.

                          В той же документации sass на странице про экстенды выделено 3 блока с важными уточнениями и отдельная секция по limitations
                            0
                            Как я уже говорил выше, @extend позволяет избежать ненужного дублирования кода.

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

                            Собственно, в приведенной вами цитате как раз и описан неплохой пример. Если .error заменить на плейсхолдер %error, то получится вообще классно. У нас не будет глобального класса .error и связанных с этим эффектов.
                          0
                          Я себе написал авто оптимизатор-сборщик. Изменил CSS или JS — система сразу проверила MD5 и заменила собранные сжатые файлы шаблона и ресурсов JS\CSS. Оригиналы лежат отдельно, а сборщик кладет и подключает их из директории public cache. CSS и скрипты при этом оптимизируются и сжимаются автоматически c добавлением integrity. Для Kernel на PHP подобный сборщик у меня занял 3 часа работы двумя регулярками.

                          Бандлеры, сборщики и транспайлеры для CSS становятся не нужны с появлением CSS 4 variables.

                          И первым по списку должен идти reset(посмотрите Boiler Plate — там не плохой сброс реализован).

                          Попутный вопрос: @_import() ваш SASS заменяет на что-то(они оптимизируются в один source)? Это же плохая рекомендация по версиям того же Google Page Insights или GT Metrix.
                            0

                            Вы написали свой webpack, а зачем? Мне правда интересно

                              0
                              Нет. Вы так рассуждаете, что кроме JavaScript больше ни чего не осталось. У меня, например, PHP на backend. А вы со своей Node.js даже инсталляторы делать не научились до сих пор 98% разработчиков.

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

                                Я со своей Node.js не научился писать инсталляторы? Да, так и есть, но я в общем-то и не собирался, не пытался и не планирую. Также JS не считаю своим дефолтным языком программирования.

                                  0
                                  Я вас и не осуждаю. Но мне надо как и моим клиентам и прочим потребителям чтобы оно устанавливалось. Они берут у меня продукт на котором работают, а не пачку деплоев для которых еще надо разрабов купить целый отдел. Если вы работаете над одним проектом — это понятно. А если их 50?
                                    0
                                    какой-то непонятный кейс. Почему они должны устанавливать это у себя через самописный установщик? Какая у них инфраструктура и на чем запускается? Почему бы не настроить CI/CD с использованием Docker'а?
                                      0
                                      Человек строит гипотезу о квалификации оппонента ничего не зная о ней, продолжает ее развивать исходя из своего личного взгляда на решение тех или иных задач, опуская при этом вопрос качества и имеющихся альтернатив. Я согласен с вашим взгядом, но боюсь здравого обсуждения у вас не получится. Изобретать велосипеды полезно, для своего опыта в качестве хобби, но практики ставшие общими придумали не идиоты. Если знания о сборщиках, и упомянутом webpack ограничиваются этим:
                                      Есть конфиг файл описывающий какие скрипты и файлы подключаются.
                                      Продолжать беседу довольно сложно и бессмысленно.
                                        0

                                        Тогда чем ваше велосипедирование от иного отличается?

                                          0
                                          Мое? Я о своем не рассказывал, но раз вы затронули эту тему — мое осталось моим личным, мои цели не приследовали стать всеобщей практикой, достоянием общественности. Это изначально были велосипеды ради велосипедов и моих персональных экспериментов.
                                            0

                                            За сим всё ясно.

                            0
                            Рекомендую почитать CSS Utility Classes and «Separation of Concerns».

                            Исходя из статьи я перешел на Utitity Classes плюс для очень специфичных задач дополнительные css. За основу взял TailwindCSS, только он уж очень большой, обычно всего этого не нужно. И конечно удобно использовать SCSS и переменные CSS.

                            Упрощенно это выглядит так:
                            <div class="ma1">
                                <div class="pb1">
                                   Текст сообщения
                                </div>
                                <div class="flex pa1">
                                    <button>Cancel</button>
                                    <button>OK</button>
                                </div>
                            </div>
                            

                            ma1 — margin all 1em, pb1 — padding bottom 1em, pa1 — padding all 1em, flex — flex, row, space-between, center.
                            90 процентов верстки закрываются utility классами. Их создаю по потребностям. Поэтому их намного меньше, чем в TailwindCSS. Верстку делать очень легко с таким подходом.
                            А для тем и реактивностей — создал отдельные классы и переменные.

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

                            Примерное дерево:
                            sass/ui
                            -_button.scss
                            -_checkbox-and-radio.scss
                            -_file.scss
                            -_input.scss
                            -_texarea.scss
                            sass/utility
                            -_border.scss
                            -_flex.scss
                            -_spacing.scss
                            -_text.scss
                            -_width-height.scss
                            sass/
                            -_minireset.scss
                            -_properties.scss
                            -_themes.scss
                            -_typography.scss
                            -_var.scss
                            

                              0
                              Был такой подход. Он не очень, потому-что мало отличается от прописывания инлайн стилями, просто короче.
                              Этот подход размывает сущность между шаблоном и css. Например, вам нужно после 800px уменьшить margin-top на половину. Эта сущность описана в двух файлах: шаблоне и css.
                              Либо вы будете городить новый стиль less-800px-ml-half либо перекрывать его в css. В любом случае это вызывает путаницу, когда понадобится что-то изменять адаптивно. Это допустимо, если вы не будете выходить за рамки выбранного css фреймворка. Это известно по бутсрап войне. Сначала натягивают бутстрап, а потом с ним воюют отдельным файлом !important.

                              Поэтому снижение когнитивной нагрузки — это следствие всего лишь договоренности, что мы не делаем сложный адаптив. А нюансов там куча, например, убирать полностью padding у сетки при ширине менее 420px, чтобы в телефоне в два ряда шли товары, и задать max-height какой нибудь.
                                0
                                Он не очень, потому-что мало отличается от прописывания инлайн стилями, просто короче.

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

                                Например, вам нужно после 800px уменьшить margin-top на половину.

                                убирать полностью padding у сетки при ширине менее 420px


                                Есть те паддинги и марджины которые всегда одинаковые. А есть те которые адаптивные. Ничего не мешает вам сделать адаптивный класс, и использовать его вместо mt1 или pa1.

                                А можно сделать адаптивный utility класс:
                                pt1-adaptive: {
                                  padding-top: var(--size1-adaptive)
                                }
                                ....
                                :root {
                                  --size1-adaptive: 1em;
                                }
                                @media screen and (min-width: 800px) {
                                  :root {
                                    --size1-adaptive: 0.5em;
                                  }
                                }
                                


                                Вариантов много. Поэтому я написал, что есть набор utility классов- закрывающих 90 процентов задач, а есть набор спец классов. Но их будет гораздо меньше, чем БЭМ и т.д.
                              0
                              выше
                                0
                                Если отталкиваться от компонентной архитектуры, то зачем вообще нужны эти пляски с каскадами?
                                Селекторы придумай, за их специфичностью проследи, статический анализ достигается только подключением 100500 плагинов на все случаи жизни, базирующиеся на данных из JS стили создаются через красивые хитрые решения

                                Конечно, все еще зависит от инструментов. Конечно, без них никуда.
                                Допустим, возьмем React.js. Тогда смело можно использовать какой-то CSS-in-JS, например styled components, и по возможности вообще избегать вложенных селекторов и декларации className где-либо, что сразу избавляет от пропасти в статическом анализе и каких либо мега инструментов для удаления мертвого CSS, и многое другое реализуется средствами JS, что избавляет нас от каких-либо препроцессоров, которые пытаются повторить то же самое, что уже умеет JS, и то на момент сборки.

                                Конечно, можно аргументировать около олдскульные подходы и трюки в CSS тем, что они менее требовательны к ресурсам, но давайте еще помнить о вреде низкоуровневых оптимизаций, так как в <ваш процент>% случаев они не играют никакой роли. Как минимум, lazy loading и разбитие бандла на части даст больше профита, чем попытки сжать итоговый CSS

                                И в конце концов, CSS создавали не люди, которые прилетели из будущего и уже знают, какое недостатки будет иметь в будущем такая реализация
                                  0
                                  styled components — это конечно здорово. Во Vue есть тоже возможность писать стили в компонентах, но только это не оптимально получается. CSS раздувается очень сильно.
                                    0
                                    можно использовать какой-то CSS-in-JS, например styled components, <...>, что сразу избавляет от пропасти в статическом анализе и каких либо мега инструментов для удаления мертвого CSS
                                    Можно поподробнее?
                                    Почему переход от Тьюринг-неполного CSS к Тьюринг-полному JS избавляет от пропасти в статическом анализе?
                                      0
                                      в чистом JS можно добиться относительно бедного статического анализа через тот же ESLint. Если пойти дальше, можем использовать TS. С ним тоже будет некоторая пропасть, но это хотя бы решает такую дилемму как:
                                      1. установить 100500 модулей для проверки CSS и 100500 модулей для проверки JS/TS
                                      или
                                      2. установить 100500 модулей для проверки JS/TS
                                        0
                                        Уточните, какие задачи по Вашему мнению должен решать статический анализ?
                                        Кроме синтаксического анализа, проверки типов и проверки ограничений, вроде того, что импортируемые модули существуют, а переменные в окружении определены.
                                    0
                                    Чем tools отличается от utilites?
                                      0
                                      наверное, тулы скачиваешь, а утилы выдумываешь сам.
                                      0

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

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

                                      Самое читаемое