Комментарии 29
инлайн-стили 2.0?
Хорошего в этом примерно столько же, сколько в инлайновых стилях, лишенных всех их несомненных плюсов (рантайм-подстановок, например).
С другой стороны, это голый цсс, в отличии от красочных либ для css-in-js, которые тормозят, будучи переизобретением очень быстрого нативного встроенного в браузер велосипеда на JS.
Но абсолютно неясно, зачем это всё нужно. Стили компонента страницы никогда не нужно было бездумно и произвольно перекрывать. В подавляющем большинстве случаев всего-то нужно решение для единократного перекрытия (база + тема), всё. Попытки же переехать в инлайн для решения проблемы хаотичного перекрытия звучат как «Мы выстрелили себе в ногу из гранатомёта, и, скажу я вам, это больно! Поэтому далее мы попробовали выстрелить себе в ногу из пистолета, и это намного лучше! Горячо рекомендую!».
А может лучше вообще не стрелять?
А больше ничего и не нужно.
И когда у нас не еще не было CSS Modules — нам хватало «не перекрывайте ничего и нигде вне css темы» в качестве методологии. Следить за этим было просто, хаоса — не было. Ну, вернее, в темах был заметный хаос, но css тем по определению самый короткоживущий css (нужен под конкретное оформительство конкретных компонентов конкретного продукта и релиза), и поэтому фиг бы с ним.
Не совсем, инлайновые стили не кешируются браузером, что естественно сказывается на скорости загрузки страниц сайта.
Так же инлайновыми стилями тяжело контролировать адаптивность страницы.
Минус такого подхода для меня вылился в работе с отзывчивостью. Вам придется увеличивать количество классов для разных брейкпоинтов рано или поздно.
Например, в какой-то момент вам нужно убрать inline-block и поставить block c padding-bottom:0.5em. Тогда у вас будет xs-block плюс xs-padding-bottom. И потом надо будет логотипу или элементу cправа дать тоже паддинг, но с .5em, чтоб они перестали слепаться и тут начинается!
Вы опять пишите классы xs-padding-right-05em… и когда все это чудо у вас написано в class="" на все брейкпоинты, то с определенного момента вы перестаете понимать, как это взаимодействует.
В итоге, количество классов просто стремится быть свойствами элемента, как в css. Конечно, мне нравится подход, при котором стили описывают скелет (колонки, блоки и их поведение при изменении ширины экрана) но как-то вот оно тоже конфликтует часто с желанием удобства.
На счёт bootstrap тяжело дать однозначный ответ. Слишком он громоздкий и неправильный с моей точки зрения. Эти бесконечные коридоры из вложенных селекторов и тд.
Я ведь борюсь за порядок и минимализм, не только для удобства, но и для увеличения скорости рендеринга страниц.
А на счёт создания кучи дополнительных классов для отступов и брейкпоинтов, я ведь написал что для этих целей просто использую классический подход написания стилей. В итоге css файлы состоят только из инструкций с числовыми значениями.
Моей главной целью было избежать повторений одинаковых инструкций, думаю я ее достиг.
Избеганиями повторений одинаковых инструкций всегда умел заниматься CSSO https://css.github.io/csso/csso.html
sidebar fixed left top w-30 h-100 main-fill
Потому что это костыль, который противоречит самой идее CSS — отделению разметки от оформления. Это даже еще хуже чем inline style, потому что
style="width:30px; height:100px"
не может значить ничего другого. А вот идиотская ситуация, когда у вас .h-100 {height:100px}
завтра превращается в .h-100 {height:200px}
— более чем возможна.Погодите вырывать мои органы, описанная ситуация возможна только в теории. На практике нет нужды переписывать значения атомарных классов, можно их можно удалить и заменить новыми.
Это не противоречит сути css, ведь мы продолжаем держать таблицы стилей отдельно от разметки, оставляя возможность применения одних и тех же классов к разным элементам и страницам.
Это не тоже самое что инлайновыми стили, так как инлайновые стили нельзя переиспользавать и они не кешируются вашим браузером.
.h-100
несут на практике всегда одну и ту же функцию — назначение определенного свойства оформления. От того, что вы его переименуете, он не потеряет свою функцию и не перестанет быть использован там, где разработчику была о нужно height:100
. Такое вполне допустимо в стилях, который генерирует движок или фреймворк дополнительно к семантической разметке, например — при назначении темы. Но совершенно недопустимо по своей функции в том, что пишется руками.1. Вы создаете класс, который назначает ширину 100 пикселей.
2. Называете его w-100.
3. Назначаете его множеству элементов.
4. Переименовываете в abcde в CSS и в HTML.
Но от того, что он теперь называется abcde, ничего принципиально не меняется в том, как он используется. То есть вы как-бы реализовали переменную, и даже назвали ее так, чтобы название не отражало значение (что вообще ад). Вы можете менять значение этой переменной, редактируя только CSS, но не можете, редактируя только стили, сделать один блок, который был 100, например, 150, а другой оставить 100. Так что делать так можно, только если вы точно уверены, что это всё никогда не будет действительно переделываться.
Вот скажите мне друзья. Где нынче тот принцип разделения содержания и оформления? Открой любой современный сайт, там 20 этажные обёртки дивами. И все это нормальным считают, всё по bem-у сделано. А JS ради оформления?! Это тоже ок? К сожалению, сегодня ответ да.
Рада ошибаться. С радостью посмотрю на контрпримеры.
И, к слову, BEM был придуман именно как конвенция для случая автогенерируемых стилей, с чем этот принцип действительно прекрасно справляется. Но потом некоторые, у которых семантическая разметка в голове просто не умещается, сделали из него культ и стали по нему писать вручную. То, что нечто образует статистическую норму (то есть «дофига кто так делает») не значит, что это правильно.
Использовать его как основную методологию — тупиковый велосипедизм.
Поддерживаю. В нашем рабочем проекте есть вспомогательные классы типа util-padding-xl
, util-padding-s
или util-text-secondary
для отступов, цветов и т.д.
В то же время UI компоненты имеют нормальные классы c недо-бэм именамиcomponent-name-element-name
. В результате получается аккуратный читаемый html.
<aside class=”sidebar fixed left top w-30 h-100 main-fill”></aside>
С одного взгляда достаточно что бы понять что это боковая колонка, с фиксированным позиционированием, с левой стороны экрана, занимающая 30% его ширины и 100% высоты, залитая главным цветом.
А как поступать в ситуациях, когда этот элемент на больших экранах должен вести себя так, как описано выше, а на малых — быть прижатым к низу, занимать 100% ширины и 30% высоты экрана.
Атомарный CSS — порядок и чистота