Как стать автором
Обновить

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

.title input #app

У меня знакомство с CSS только базовое, но разве многократное использование идентификаторов это хорошо, там где встречаются слова «лучше» и «красивее»?
".title input #app" вместо "#app" предполагает наличие или нескольких блоков #app или его сильно различное поведение в зависимости от родителя (и тогда вроде все ок, но все равно какое-то ощущение неправильности).
Но это все равно какая-то страшная конструкция — элемент с идентификатором в элементе input.
Ан, нет, оказывается по ссылке m.habr.com/company/ruvds/blog/418825 всё имеет другой смысл и там перечисление: .title, input, #app

Ещё существует мнение, что благодаря прорывам в 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.

Чушь это все. Недавно слезли со stylus в пользую postcss с исключительно поддержкой стандарта будущего. Ничто не пострадало, мир не упал и поддерживаемость кода такая же. Если у вас при обычном css страдает поддержка, то вам стоит задуматься о методологии/архитектуре.

Про CSS Modules упомянуть бы, очень облегчают жизнь. В том же Vue нечто похожее вообще из коробки идет.

НЛО прилетело и опубликовало эту надпись здесь

Для того чтобы сборщик собрал всё необходимое — как раз и нужны импорты, он же по ним строит дерево зависимостей. Иначе как он узнает порядок включения файлов (который имеет значение)?

У вас всё равно будет где-то зашита эта информация о списке файлов и о порядке их включения. Так зачем же её вытаскивать в сборщик, если можно оставить в стилях?
Если человек не может писать нормальный код на CSS (например, с использованием БЭМ), то на SCSS с его богатыми возможностями он наворотит еще более запутанный код. Ему нужен не препроцессор, а курс изучения CSS.

Например, возможность вкладывать стили приводит к тому, что люди в 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 файл.
Претензия: у вас нельзя искать классы по имени.
Ответ: вам это и не нужно, ведь с нашей системой…

Я наверно, все же лучше знаю, что мне нужно.
В статье автор рядом расположил scss и postcss (autoprefixer). Но если есть postcss, то зачем ещё один инструмент для сборки стилей (node-sass)? Если очень хочется использовать этот DSL, например в силу привычки, то есть postcss-scss (он не компилирует, он лишь парсит, открывая возможность для остальных postcss-плагинов обрабатывать scss исходники).

Но ИМХО для сохранения sass/scss-синтаксиса нет особого смысла в новом проекте, плагины postcss покрывают большую часть функционала SASS и добавляют кучу дополнительных возможностей.

Пробовал так делать, использовал precss. К сожалению, встретилось слишком много досадных багов (раз, два, плюс вопрос про стабильность проекта).


Откатились обратно на SASS, с ним работает намного надежнее.

я недавно пытался свой цсс в ангулар приложении привести к бэму и у меня возник вопрос.
в какой-то из статей я встречал совет, что в имени класса не должно быть больше одного элемента (бЭм), но класс хедера я назвал — header, класс контейнера логотипа — header__logo, а самой картинки — header__logo__image.
стили у меня прописаны для всех 3 уровней вложенности. как правильно называть эти классы в моем случае?
Одна и та же ошибка у всех. По БЭМ нельзя в элемент вкладывать другой элемент. Т.е. Должен быть класс header__logo и header__logo-image (header__image). Или если необходимо — для логотипа делать отдельный блок logo с структурой .header>.header__logo.logo>.logo__image
Вот и я удивился такому наименованию: user-nav__links / user-nav__links__link

Даже пример на сайте БЭМ есть
<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, .header__logo, .header__logo-image. На практике часто приходится использовать двусложные названия, так что я не вижу ничего страшного в "...logo-image". Можно выделить отдельный блок .logo, и тогда получилось бы: .header, .logo, .logo__image. Но это рационально, только если .logo будет использоваться где-то ещё, помимо .header.
И писать «header__logo__image» точно не стоит :) Это читается так: блок, элемент, элемент (!).
А вот мне наоборот нравится писать CSS, и с опытом все красивее и удобнее получается, и вложенности и классы и тд. А вот с SCSS не сложилось, несколько раз пробовал начинать, но явных преимуществ не видел
Последнее читается лучше, правда?

Как по мне так же, как если бы h1 span сделать с отступом

Зарегистрируйтесь на Хабре, чтобы оставить комментарий