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

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

from csso.

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

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

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

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

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

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

#id1 {…}
#id2 {…}

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

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

from csso.

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

from csso.

Ага, ок.

Роман Комаров
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

from csso.

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

from csso.

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

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

.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}

from csso.

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

from csso.

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

from csso.

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

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

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

from csso.

Хороший пример, в котором много чего можно было бы лучше структурно сжать — 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}

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

from csso.