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

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

Т.е. «стиль» жестко привязывается «специальным» классом к элементу страницы?
инлайн-стили 2.0?
Ага. Это когда до дрожи в коленках хочется инлайновые стили, но кто-то не даёт.
Хорошего в этом примерно столько же, сколько в инлайновых стилях, лишенных всех их несомненных плюсов (рантайм-подстановок, например).
С другой стороны, это голый цсс, в отличии от красочных либ для css-in-js, которые тормозят, будучи переизобретением очень быстрого нативного встроенного в браузер велосипеда на JS.

Но абсолютно неясно, зачем это всё нужно. Стили компонента страницы никогда не нужно было бездумно и произвольно перекрывать. В подавляющем большинстве случаев всего-то нужно решение для единократного перекрытия (база + тема), всё. Попытки же переехать в инлайн для решения проблемы хаотичного перекрытия звучат как «Мы выстрелили себе в ногу из гранатомёта, и, скажу я вам, это больно! Поэтому далее мы попробовали выстрелить себе в ногу из пистолета, и это намного лучше! Горячо рекомендую!».

А может лучше вообще не стрелять?
А какое именно решение вы имеете в виду под «вообще не стрелять»?
Не хочется устраивать у себя хаос из перекрытий — не надо его устраивать. Вот и всё собссно. Повторы стилей устраняет любой препроцессор или просто css modules; это даже не говоря про то, что далеко не все повторы нужно устранять. Накатывание одного перекрытия для кастомизации компонентов делается через обычную специфичность селекторов, база — это 1 класс, тема — комбинация из двух (база + название темы), которая заведомо специфичнее базы и спокойно её перекрывает.

А больше ничего и не нужно.
Все равно непонятно. Чтобы не устраивать хаос и соблюдать порядок, нужна методология. Какого способа организации классов придерживаетесь вы? CSS Modules?
CSS Modules — спека, а не методология. Что автоматически делает её намного лучше (не надо стоять и следить над соблюдением).
И когда у нас не еще не было CSS Modules — нам хватало «не перекрывайте ничего и нигде вне css темы» в качестве методологии. Следить за этим было просто, хаоса — не было. Ну, вернее, в темах был заметный хаос, но css тем по определению самый короткоживущий css (нужен под конкретное оформительство конкретных компонентов конкретного продукта и релиза), и поэтому фиг бы с ним.

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

Как у вас класс с именем 'top w-30 h-100'
способствует адаптивности страницы?

Инлайновые стили кэшируются браузером вместе с html страницей.
Чем же вас не устроил bootstrap4 тогда? Скачиваете, убиваете все, кроме инструкций описания скелета и вуаля — у вас тот же подход + стандартизация.

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

Например, в какой-то момент вам нужно убрать inline-block и поставить block c padding-bottom:0.5em. Тогда у вас будет xs-block плюс xs-padding-bottom. И потом надо будет логотипу или элементу cправа дать тоже паддинг, но с .5em, чтоб они перестали слепаться и тут начинается!

Вы опять пишите классы xs-padding-right-05em… и когда все это чудо у вас написано в class="" на все брейкпоинты, то с определенного момента вы перестаете понимать, как это взаимодействует.

В итоге, количество классов просто стремится быть свойствами элемента, как в css. Конечно, мне нравится подход, при котором стили описывают скелет (колонки, блоки и их поведение при изменении ширины экрана) но как-то вот оно тоже конфликтует часто с желанием удобства.

На счёт bootstrap тяжело дать однозначный ответ. Слишком он громоздкий и неправильный с моей точки зрения. Эти бесконечные коридоры из вложенных селекторов и тд.
Я ведь борюсь за порядок и минимализм, не только для удобства, но и для увеличения скорости рендеринга страниц.
А на счёт создания кучи дополнительных классов для отступов и брейкпоинтов, я ведь написал что для этих целей просто использую классический подход написания стилей. В итоге css файлы состоят только из инструкций с числовыми значениями.
Моей главной целью было избежать повторений одинаковых инструкций, думаю я ее достиг.

Мы же говорим про 4-ую версию.Про флексы, сетку и утилиты, а там все довольно складно, вложенность технически обоснвана.

Избеганиями повторений одинаковых инструкций всегда умел заниматься CSSO https://css.github.io/csso/csso.html

*С флагом restructure

Я, честно говоря, не знаю, какие выступающие органы надо отрывать тем, кто пишет классы типа
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 ради оформления?! Это тоже ок? К сожалению, сегодня ответ да.


Рада ошибаться. С радостью посмотрю на контрпримеры.

НЛО прилетело и опубликовало эту надпись здесь
Да вот недавно пришлось использовать react-data-grid, я когда увидел, чего он там творит, мне стало не просто плохо, мне стало очень плохо. А он просто для табличек жестко использует абсолютно позиционированные дивы. Для каждой ячейки 3 дива и спан, в котором к моему удивлению лежит ещё один див. Я был в шоке от его скорости работы, её нет, 100 строк оно рендерит несколько секунд. Так что им норм, они не против делать непонятно что, лишь бы не использовать то, что приспособлено для требуемой задачи.
А он просто для табличек жестко использует абсолютно позиционированные дивы

А это для того, чтобы 100 000 строк показывать так же быстро, как и 100 (зачем их рисовать, если их все равно никто не видит)
Это ладно, но зачем 5 dom элементов для каждой ячейки?
Начните с понимания того, что множество людей не понимают: что есть классы, которые должны писаться в соответствии с принципом разделения оформления и разметки, а есть — те, что генерируются автоматически. На вторые — плевать, там может быть вообще что угодно. А что неправильно в смешении разметки и оформления, я объяснил для тех, кто понимает только на примерах, в комментарии выше: habr.com/post/432586/#comment_19476736

И, к слову, BEM был придуман именно как конвенция для случая автогенерируемых стилей, с чем этот принцип действительно прекрасно справляется. Но потом некоторые, у которых семантическая разметка в голове просто не умещается, сделали из него культ и стали по нему писать вручную. То, что нечто образует статистическую норму (то есть «дофига кто так делает») не значит, что это правильно.
Атомарный CSS полезен в небольших дозах, в виде хелперов для ситуаций-исключений.
Использовать его как основную методологию — тупиковый велосипедизм.

Поддерживаю. В нашем рабочем проекте есть вспомогательные классы типа 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% высоты экрана.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории