Комментарии 30
Вас лучше статью скрыть в черновики или вовсе удалит, так как данный материал уже имеется тут
.title input #app
У меня знакомство с CSS только базовое, но разве многократное использование идентификаторов это хорошо, там где встречаются слова «лучше» и «красивее»?
".title input #app" вместо "#app" предполагает наличие или нескольких блоков #app или его сильно различное поведение в зависимости от родителя (и тогда вроде все ок, но все равно какое-то ощущение неправильности).
Но это все равно какая-то страшная конструкция — элемент с идентификатором в элементе input.
Ещё существует мнение, что благодаря прорывам в CSS за последние 4-5 лет, SCSS уже не нужен. В частности, например, переменные уже есть в CSS и поддерживаются всеми браузерами.
SCSS — это далеко не только CSS переменные. Вложенные селекторы, типизированные данные, mixins, placeholders и т.п. — всего этого нет и не будет в CSS, просто потому что там всему этому не место. Конечно есть и альтернативы более близкие к CSS, тот же PostCSS, но во многом SCSS — незаменимый инструмент в написании большого количества поддерживаемого CSS кода
Я не занимаюсь фронтендом, но так как часто приходится смотреть или делать мелкие правки, пытаюсь быть в курсе происходящего.
К сожалению, выводы к которым я пришел: большинство даже во фронтенде не знаю возможностей даже голого CSS, не говоря уже о SCSS. Например, те же mixin'ы в коде, не являющемся частью какого-нибудь фреймворка, я почти не встречал. Более того, масса верстальщиков, дизайнеров и т.д. до сих пор вкрячивает свойства с префиксами типа -moz, -webkit вручную в SCSS даже там, где все браузеры включая IE поддерживают свойства без префиксов уже несколько лет.
Может быть, это локальный феномен, беда маленьких компаний, и мне так не везет, конечно.
Более того, масса верстальщиков, дизайнеров и т.д. до сих пор вкрячивает свойства с префиксами типа -moz, -webkit вручную в SCSS даже там, где все браузеры включая IE поддерживают свойства без префиксов уже несколько лет.
Может быть это станет для вас открытием, но не все люди используют браузеры последних версий. И IE6-то до сих пор не умер вот чтоб прям совсем полностью, несмотря на активное удавливание его самим Microsoft.
Не открытие, я даже работал в проектах, где было важно поддерживать совместимость со старыми браузерами.
Но я говорю о тех проектах, где пользователь с IE6 в принципе не может встретиться. Просто пишут на автомате, и самое главное без использования средств SCSS для автоматического раскрытия таких пропертей.
Даже более того, приходится следить и бить по рукам, когда пишут константы в SCSS (например, цвета) без использования переменных.
Но я понимаю, что это в первую очередь вопрос грамотности разработчиков, не каждая компания может позволить себе нанять лучших из лучших.
Просто очень часто сталкиваюсь с ужасным кодом CSS, и когда его запихивают в SCSS не становится лучше.
Просто очень часто сталкиваюсь с ужасным кодом CSS, и когда его запихивают в SCSS не становится лучше.
А это потому, что CSS в своей основе настолько печален, что никакой препроцессор поверх этого — ситуацию не улучшает сам по себе.
CSS не «бьет по рукам», и не имеет возможности этого делать, да и вообще обладает запредельно скудными возможностями структурирования, так, что даже очень простые вещи поверх, типа тех же CSS Modules, уже воспринимаются как прорыв. От добавления в это всё новых фич ничего принципиально не меняется — фичи можно использовать во благо, а можно и нет.
Тут спасает только написание внутренних дев-доков относительно правил и нормативов пользования фичами препроцессора, и потом код-ревью для проверки соответствия. Тогда еще можно как-то немного прибираться.
В защиту CSS всё-таки стоит сказать что во многом то, как он сделан, определяется тем как он используется. Я имею в виду то что сама суть CSS — это описание правил стилизации элементов документа браузерами. Причём не просто стилизации, а realtime стилизации (уверен что вы понимаете разницу). Требование очень высокой производительности (а, я думаю, никто не против того что высокая производительность здесь необходима) подразумевает введение различного рода ограничений которые вне контекста кажутся странными и глупыми.
К примеру, думаю, многие в курсе что в CSS селекторах нет т.н. back references т.е. нельзя сделать селектор вида "элемент перед которым стоит другой элемент". Попытка ввести такой селектор была в CSS Selectors Level 4, но в итоге от неё отказались несмотря на то что фича явно полезная. Причина — это замедлит работу CSS движка т.к. сейчас CSS всегда идёт по DOM дереву слева направо, введение потенциальной необходимости идти и в другом направлении усложнит и замедлит код.
Ещё один пример с которым сам столкнулся недавно: у весьма интересного нового свойства position: sticky нет возможности с помощью CSS узнать в каком же состоянии находится элемент (т.е. нет какого-нибудь псевдо-класса типа :stuck хотя он явно напрашивается). Вот здесь можно почитать обсуждение W3C CSS WG по данному вопросу, рекомендую ознакомиться, очень интересно, особенно этот и этот комментарии.
Требование очень высокой производительности
… ушло в прошлое уже давненько, на самом деле. В нынешнее время, в эпоху фреймворков и прочего JS в гигантских объемах, выполняющего в миллионы (и хорошо если только в миллионы) больше операций, чем это реально нужно — говорить о «необходимости высочайшей производительности ЦСС» лицемерно.
Попытка ввести такой селектор была в CSS Selectors Level 4, но в итоге от неё отказались несмотря на то что фича явно полезная.
Ага, вот только отказались от неё не из-за производительности, а потому, что все сказали «ребята, мы уже миллионы лет делаем однократный проход по DOM, а вы тут нам щас предлагаете ради одного селектора многопроходность лепить?».
И я больше чем уверен, что через некоторое время таки прогнутся и сделают.
ЗЫ: И весь этот разговор опять же не имеет никакого отношения к отсутствию структурирования. Вот уж структурирование в ЦСС можно было преспокойно запиливать, никакие соображения производительности тут помешать не могут.
Вот доклад с конференции этого года про статус и планы на container queries:
https://www.youtube.com/watch?v=0wA4CMo9_EU
Если коротко, то добавлять многопроходность в CSS никто не будет, слишком много всего придется переписать, зато появится новое DOM-API, ResizeObserver, в котором можно размеро-зависимые стили оформить через Javascript.
Про CSS Modules упомянуть бы, очень облегчают жизнь. В том же Vue нечто похожее вообще из коробки идет.
Для того чтобы сборщик собрал всё необходимое — как раз и нужны импорты, он же по ним строит дерево зависимостей. Иначе как он узнает порядок включения файлов (который имеет значение)?
Например, возможность вкладывать стили приводит к тому, что люди в SCSS копируют структуру HTML, создавая по 5-6 (!) уровней вложенности и пишут бредовые конструкции вроде
.header {
div {
span {
a {
span {
Я знаю, многие подумают «ну бред, как такое можно писать». А я это видел своими глазами.
Или пишут вложенные блоки длиной в несколько экранов, так, что не понять, где ты находишься.
Или разрывают названия классов:
.header {
&_logo {
Так, что в итоге их нельзя искать поиском. Вдумайтесь! Вы не сможете узнать, где какой класс используется.
Миксины дают возможность конфликта CSS правил (когда миксин определяет одно правило и оно мешает заданному явно правилу).
Так как это не упомянуто в статье, а содержатся лишь похвалы, то я подозреваю, что ее писал неопытный человек, который нашел в интернете описание фич SCSS и «нареврайтил» из них хвалебную статью.
Имена файлов, начинающиеся с подчеркивания, имхо, выглядят отвратительно. _как _это _предложение.
Идея имопртировать все в один файл нездоровая и приводит к тяжеленным CSS файлам как на гитхабе, где используется лишь 5-10% правил. Да, в гитхабе крутые разработчики, но в плане навыков использования CSS они не сильно отличаются от фрилансера Васи.
Из плюсов — удобно для адаптивной верстки писать media правила внутри блока.
Потому SCSS хорошо подходит для одноразовых задач — когда вам надо сверстать что-то, отдать и дальше это уже не ваши проблемы. В такой ситуации возможности SCSS позволяют его писать быстрее, чем CSS. Но поддерживать и развивать такой код, особенно если его пишут разработчики без строгих гайдов и умения думать о других, будет тяжело.
Ну и отдельно доставляет необходимость использовать ноду. Она тормозная, может только запускаться несколько секунд, а в режиме watch с большим количеством каталогов любит есть CPU как легкая инди-игра.
Еще раз напомню, тот, кто не видит недостатков SCSS, просто или не имеет достаточного опыта или зрения.
Ну и отдельно доставляет необходимость использовать ноду.Ужас-ужас. Как же у вас npm работает? На Воле Божьей? Аль по щучьему велению?
Или разрывают названия классов:
.header {
&_logo {
Так, что в итоге их нельзя искать поиском. Вдумайтесь!
Если мы придерживаемся той же методологии именования БЭМ, то нам не нужно искать класс .header_logo! Нам достаточно найти класс-имя блока, и в нем мы увидим всё остальное. Вдумайтесь! =)
Имена файлов, начинающиеся с подчеркивания, имхо, выглядят отвратительно. _как _это _предложение.
нижнее подчёркивание не просто так… оно указывает «sass-компилятору» игнорировать этот файл и не создавать из него лишний .css файл.
Ответ: вам это и не нужно, ведь с нашей системой…
Я наверно, все же лучше знаю, что мне нужно.
Но ИМХО для сохранения sass/scss-синтаксиса нет особого смысла в новом проекте, плагины postcss покрывают большую часть функционала SASS и добавляют кучу дополнительных возможностей.
Пробовал так делать, использовал precss. К сожалению, встретилось слишком много досадных багов (раз, два, плюс вопрос про стабильность проекта).
Откатились обратно на SASS, с ним работает намного надежнее.
в какой-то из статей я встречал совет, что в имени класса не должно быть больше одного элемента (бЭм), но класс хедера я назвал — header, класс контейнера логотипа — header__logo, а самой картинки — header__logo__image.
стили у меня прописаны для всех 3 уровней вложенности. как правильно называть эти классы в моем случае?
Даже пример на сайте БЭМ есть
<header class="header">
<img class="logo">
<form class="search-form">
<input class="input">
<button class="button"></button>
</form>
<ul class="lang-switcher">
<li class="lang-switcher__item">
<a class="lang-switcher__link" href="url">en</a>
</li>
<li class="lang-switcher__item">
<a class="lang-switcher__link" href="url">ru</a>
</li>
</ul>
</header>
А само дерево такое
header
logo
search-form
input
button
lang-switcher
lang-switcher__item
lang-switcher__link
lang-switcher__item
lang-switcher__link
И писать «header__logo__image» точно не стоит :) Это читается так: блок, элемент, элемент (!).
Последнее читается лучше, правда?
Как по мне так же, как если бы h1 span сделать с отступом
Пишем CSS лучше и красивее