Учёт встречаемости свойств при определении нужно ли склеивать

[kizu]

Для многих новых свойств (т.е. редко используемых) может быть ситуация, что оно (свойство), встретится в таблице стилей только в двух-трёх местах, но при этом значение будет везде одинаковым. Сейчас если между двумя селекторами будет третий, то эти свойства не склеются, тогда как вынести это свойство из них в отдельный блок будет безопасным т.к. мы точно знаем, что нигде нет блоков, в которых это свойство могло бы быть переопределено.

Например, сейчас у

.block1 {
    text-shadow: 1px 0 2px red;
    }
.block2 {
    text-shadow: 1px 0 2px red;
    }
.block3 {
    color: red;
    }
.block4 {
    text-shadow: 1px 0 2px red;
    }

будут оптимизированы только первые два блока, тогда как если это и есть вся таблица стилей, то безопасно склеивать блоки с одинаковыми значениями. А вот если бы появился какой-то селектор .block4 {text-shadow: 0 -1px 1px green;} (причём только где-то между этими свойствами т.к. если он будет в конце или начале, то вес селектора не позволит потом им что-то переопределить), то всё, мы только тогда начинаем бояться и всё делаем как и сейчас.

Тот же text-shadow часто может использоваться только для одного и того же эффекта вдавленного текста с одним и тем же значением, и из-за его природы вынести его в отдельный блок будет выгоднее и безопасно. Для всяких бордер-радиусов, бокс-шедоу и т.д. тоже вполне может возникнуть такая же ситуация.

[art-shen]

Жаль нет голосования за Issues. В общем я всеми руками и ногами за эту фичу! )

[kizu]

Ещё подумалось: можно при анализе «есть ли что-то, что мешает склеивать селекторы» учитывать могут ли фактически пересечься селекторы.

Например, если в селекторах есть разные имена тегов для конечного элемента, то они точно друг друга не перекроют и их порядок не важен:

a.class {…}
b.class2 {…}

То же и с nth-childами: два подобных селектора никогда не будут применяться к одному элементу, следовательно, они не будут и конфликтовать:

.class:nth-child(1) {…}
.class2:nth-child(2) {…}

Ну и, кажется, селекторы с айдишниками не могут конфликтовать т.к. для одного элемента в html не может быть два айди:

#id1 {…}
#id2 {…}

Вообще, подозреваю, подобных случаев может быть довольно много (селекторы атрибутов, :not() и т.д.), правда, и учитывать всё это дело, должно быть, сложно. Но какой-то профит от этого можно будет в конце концов получить.

Хотя, это можно и отдельным issue вынести, наверное )

[afelix]

Ты пока всё сюда складывай, я потом всё унесу в CSS stat, когда всерьёз за него возьмусь.

[kizu]

Ага, ок.

Роман Комаров http://kizu.ru/

09.09.2011, 15:10, "Sergey Kryzhanovsky" [email protected]:

Ты пока всё сюда складывай, я потом всё унесу в CSS stat, когда всерьёз за него возьмусь.

Reply to this email directly or view it on GitHub: https://github.com/afelix/csso/issues/20#issuecomment-2050191

[afelix]

Ёлки, я не в тот issue ответил. Т.ч. не "ок". :) Всё пока на своих местах.

[kizu]

+ сюда же — можно смотреть на вес селекторов.

Можно безопасно сжать

.a{width:10px}
.b .c{width:20px}
.d{width:10px;}

до

.b .c{width:20px}.a,.d{width:10px}

т.к. .b .c будет всегда выше по специфичности, чем .a, ну и аналогично с

.a{width:10px}
.b .c{width:20px}
.a{height:10px}

можно сжать до

.b .c{width:20px}.a{width:10px;height:10px}

[kizu]

В итоге, кажется, что, если всё это учитывать (наличие перекрывающих свойств, невозможность пересечения селекторов, важность специфичности), то структурная минификация может стать заметно круче.

[css]

М... Первые CSSO умели сжимать так, как в последнем примере. Оказалось, что в ряде случаев это опасная фишка, дающая разный рендер "до" и "после". Одна из причин, почему тотальная лихая реструктуризация закончилась тем, что сейчас. Было год назад, детали не вспомню.

[kizu]

Дада, но в этом таске я как раз описываю примеры когда не будет разницы в «до» и «после» — т.е. когда есть .a{…} .b{…} .a{…} в общем случае оба .a не получится склеить, но:

1. Если нет пересечений по свойствам между первым .a и .b, то их порядок не важен.
2. Если вместо .b будет любой селектор с заведомо большей специфичностью, чем у первого .a, то их порядок не важен.
3. Если специфичность одинаковая, но селекторы гарантированно не пересекаются (span.a{…} div.b{…} span.a{…}), то порядок не важен.

и т.д. — т.е. всё-таки есть случаи когда можно структурно минифицировать.

[kizu]

Хороший пример, в котором много чего можно было бы лучше структурно сжать — http://csswizardry.com/inuitcss/inuit.min.css

У меня пока не получилось нормально выделить кейс оттуда, но если посмотреть на несколько первых селекторов, то там (с учётом последующих) в результате получаем такой сжатый CSS:

body{margin:0}body,h1,h2,h3,h4,h5,h6,p,blockquote,pre,dl,dd,ol,ul{padding:0}form,legend{margin:0;padding:0}table{padding:0}th,td,caption{margin:0}caption,figure,hr{padding:0}

Т.к. селекторы по элементам никогда не пересекаются (т.е. порядок не важен), тут можно сгруппировать паджины и паддинги.