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

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

Звучит как работка для системы сборки
cssnano работает похожим образом, а вообще считаю, что в исходнике лучше писать понятно, нежели заниматься такой оптимизацией
Я полагаю, что посыл автора был не в том, чтобы следовать данным указаниям как четко утверждённому паттерну, а как раз в том, чтобы в целом обращать внимание на чистоту кода, он не должен быть избыточным.

Код должен быть понятным любому новому разработчику в команде. Над устранением избыточности и вообще над оптимизацией должны трудиться роботы (csso, cssnano, etc) во время сборки проекта в продакшен.
Конечно, при условии, что код не пишется, чтобы завтра про него забыть, кинув его в заказчика.

да, тоже смутило. Когда я больше верстал, то была классическая связка mini-css-extract-plugin + cssnano и ещё пара postcss плагинов, которые позволяли всё вынести в один css-бандл, объединить одинаковые правила для группы селекторов в отдельный набор, затем перечисляли уникальные для селекторов и замыкали таблицу медиазапросами. Мне кажется, что на этапе вёрстки лучше быстро сделать очевидные наборы правил, а бандлеры или таск-раннеры должны вычищать повторяющиеся объявления самостоятельно, для этого их и разрабатывали. Вроде ж даже css-in-js оптимизируется в приложениях
Маловато примеров. Хотя и так суть ясна. Автору за труды респект!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий