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


Почему мы вообще используем Sass?

Так было у меня лично и у команды. Я думаю, что все люди разные в этой области.

  1. хочу гнездо правила стиля, когда вы хотите стилизовать тег, не называя класс
  2. хочу гнездо правила стиля по разделам контента для повышения видимости исходного кода
  3. к отдельные файлы по назначению или содержанию для улучшения поиска
  4. определение и повторное использование цветовых шаблонов для больших проектов
  5. определять и повторно использовать значения ширины экрана для медиазапросы
  6. большие проекты хотят использовать @extend к Поделиться стили
  7. некоторые проекты используют @mixin к поделиться префиксами поставщиков (хотя в последнее время я использую автопрефиксер), определить правила стиля, делиться точками остановатак далее.


Что вас беспокоит в Сассе?


1. все функции предустановлены.

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


2. языковые реализации устарели и нуждаются в переносе.

Помимо Дарта Сасса, Sass: встроенный Sass доступен


3. Политика использования по своей сути нестабильна.

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



@import

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

Сасс: @import


4. возможные конфликты со спецификацией тела CSS.


Разделение с использованием /.

В CSS есть свойство, которое использует / как разделитель.
В этом случае Sass не может различить, является ли / является разделителем или делителем. В качестве альтернативы рекомендуем Math.div.

Sass: Breaking Change: Slash as Division


🤔 Кстати, что там с CSS?

cssdb — База данных CSS определяет этапы** стандартизации новых функций, называемых этапы.

стадияУровеньУровень зрелости
Стадия 4СтандартизированныйВысокая
Этап 3Обнял:
Этап 2допустимый:
Этап 1Экспериментальный:
Стадия 0ВдохновляющийНизкий

Кажется, что по мере продвижения Stage поддержка браузера действительно улучшается.
Также, postcss-plugins/plugin-packs/postcss-preset-env позволяет выполнить этот этап и использовать функции, которые будут стандартизированы в будущем.

Кажется, что есть довольно много функций, которые мы привыкли использовать в Sass.

СассCSSПостCSS-плагин
гнездованиеправило вложенности (этап 1)postcss-вложенность
разделение файловpostcss-импорт
повторное использование цветапользовательское свойство (этап 3)postcss-настраиваемое свойство
повторно использовать медиа-запроспользовательский медиа-запрос (этап 2)postcss-пользовательские-медиа
наследование классовпод обсуждениемpostcss-продлить
смешиваниепод обсуждением 1postcss-mixins, postcss-применить

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


Как воспроизвести Mixin для разных целей

  • Определите общие правила стиля => Не используйте один класс
  • Общий префикс поставщика => Autoprefixer
  • Общие точки останова => пользовательский медиа-запрос в CSS


Спецификации правил низкой стадии очень нестабильны

Стадия, определенная W3C, не является официальной версией выпуска, и ее использование менее стабильно.
Низкая стадия также должна быть принята во внимание, что спецификация, скорее всего, изменится или будет ОТКЛОНЕНА..
Если у вас мало знаний или опыта работы с черновиком CSS, лучше следовать стандартному (стадия 2) postcss-preset-env.

Например, правило вложенности все еще находится на этапе 1, поэтому спецификация, скорее всего, изменится. Если вы реализуете его в postcss-preset-env, вам, возможно, придется повторно реализовать только вложенную часть позже..


Возможно, еще слишком рано принимать postcss-preset-env.

Возможно, еще слишком рано принимать postcss-preset-env после всего вышеизложенного.
Впредь.

  • Мы будем использовать CanIUse и другие инструменты, чтобы увидеть, как браузеры его поддерживают..
  • Если стадия функции, которую мы хотим использовать, достигает 4 и поддержка браузера достаточна, мы примем ее..
  • Мы продолжим использовать PostCSS для подходов, отличных от самого CSS, таких как autprexier..

Думаю, это то, о чем я думал. Большое спасибо.


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