Разрушительны ли CSS, которые объединяют элементы разрушительными?

StackOverflow https://stackoverflow.com/questions/7811395

  •  26-10-2019
  •  | 
  •  

Вопрос

Я нашел этот минивер CSS (http://www.lotterypost.com/css-compress.aspx) В нижней части этой страницы есть раздел с надписью: «Что компрессор CSS нарочно не делает?» Есть четыре вещи, две из которых я не мог понять, почему они могут быть разрушительными:

Объединение индивидуальной маржи, прокладки или границ в одну собственность.

  margin-top: 10px; 
  margin-right: 0; 
  margin-bottom: 8px;
  margin-left: 30px;

Становится 

  margin: 10px 0 8px 30px;

И объединение стилей для того же элемента, которые указаны в разных блоках стиля.

#element {
   margin: 0;
}

#element {
   color: #000000;
}

Становится

#element {
   margin: 0;
   color: #000000;
}

Я думаю, что Csstidy делает оба этих. Веб -страница выше правильной? Существуют ли ситуации, когда эти типы минификации могут быть проблемой?

Это было полезно?

Решение

Я разработчик компрессора CSS, который является предметом этого вопроса (http://www.lotterypost.com/css-compress.aspx), поэтому я уточлюсь с примером того, как компрессор может сломать каскад CSS, если инструмент агрессивно переписывает его.

В листе стиля есть много способов нацеливания на элементы, и поскольку компрессор CSS не обладает интимным знанием структуры DOM, классов, идентификаторов и т. Д. Определения сломаются или нет.

Например, простая структура HTML:

<div class="normal centered">
    <p>Hello world.</p>
</div>

И некоторые CSS:

div.normal p {
    margin: 10px 0 10px 0;
}

div.centered p {
    margin: 10px auto;
}

div.normal p {
    margin-bottom: 5px;
}

А несомненно Код будет создавать центрированный абзац с верхним краем 10PX и нижним краем 5PX.

Если вы запустите стили CSS через компрессор CSS, вы получите следующий код, который поддерживает заказ и каскад оригинальных несжатых стилей.

div.normal p{margin:10px 0}div.centered p{margin:10px auto}div.normal p{margin-bottom:5px}

Допустим, вы хотите агрессивно сжать стили дальше, объединив поля двух Div.normal p определения У них обоих есть один и тот же селектор, и они, кажется, избыточно стиляют нижний край.

Будет два способа объединить поля: вы можете либо объединить два определения маржи в первом (вверху) Div.normal p стиль или объедините их в последний (нижний) один. Давайте попробуем в обоих направлениях.

Если вы объедините маржу в первую (вверху) Div.normal p стиль, вы получаете это:

div.normal p{margin:10px 0 5px}div.centered p{margin:10px auto}

Результат объединения поля таким образом приведет к тому, что нижний край будет неправильно установить на 10px, потому что класс «центрированного» переопределяет нижний край (потому что определение «центрированного» стиля теперь появляется позже в каскаде).

Если вы объедините маржу в последнее (внизу) Div.normal p стиль, вы получаете это:

div.centered p{margin:10px auto}div.normal p{margin:10px 0 5px}

Результат объединения поля таким образом приведет к тому, что абзац больше не появляется как центрированное, потому что нижнее определение «P» будет отменять левую и правую краю «Авто», которые определены в «центрированном» классе.

Таким образом, мы видим, что, объединяя определения стиля, которые даже имеют точно такой же селектор, может вызвать довольно плохие проблемы.

Вы бы лично писали код, как это? Может быть, а может и нет. Из -за различных правил «веса» каскада можно попасть в этот тип ловушки кода, не осознавая этого.

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

На самом деле, я написал компрессор CSS для этого самого сценария на моем веб -сайте, Лотерейный пост. Анкет Каждая веб -страница имеет много листов в стиле, поддерживающих различные JQUERY и другие компоненты, а компрессор CSS используется для автоматического сжатия всех этих листов в стиле в одну загрузку. Все страницы на сайте имеют как минимум 10 различных листов в стиле, объединенных, и большинство страниц имеют больше, чем это.

Например, если вы посмотрите на код, стоящую за самой страницей компрессора CSS, вы найдете основной лист стиля в голове, который выглядит так:

<link rel="stylesheet" href="http://lp.vg/css/d11019.0/j2HKnp0oKDOVoos8SA3Bpy3UHd7cAuftiXRBTKCt95r9plCnvTtBMU2BY2PoOQDEUlKCgDn83h16Tv4jbcCeZ(gupKbOQ9ko(TcspLAluwgBqrAjEhOyXvkhqHA(h5WFDypZDK2TIr(xEXVZtX7UANdFp6n1xfnxqIMR8awqGE)vrwUgY2hrCGNNTt1xV7R1LtCSfF46qdH1YQr2iA38r1SQjAgHze(9" />

Gobbledeegook в URL -адресе на самом деле представляет собой зашифрованную строку, содержащую все листы стилей для объединения на сервере. Сервер сжимает их и кэширует результат.

Методы экономения пространства и экономения времени на этом листе одного стиля включают в себя:

  • Объединение многих листов в стиле в один файл/скачать, просто добавив их все вместе
  • Сжатие листа комбинированного стиля с помощью компрессора CSS (не испортив каскад!)
  • Использование другого доменного имени (LP.VG) для загрузки листа стиля, которая улучшает способность браузера загружать параллельно
  • Использование очень короткого доменного имени (LP.VG)
  • Сжатие GZIP применяется к листу стиля на веб -сервере
  • Номер версии листа стиля включен в URL (".../d11019.0/..."), так что, если какой -либо стиль изменяется в любом из нескольких листов стилей, я могу изменить номер версии и Браузер никогда не будет использовать версию, которую он кэшировал. (Обратите внимание, что номер версии должен быть частью пути URL, а не в строке запроса, потому что некоторые прокси -серверы не рассматривают строку запроса, чтобы определить, следует ли извлечь страницу из кэша.)

Я надеюсь, что это лучше объяснит и помогает тем, кто хочет улучшить производительность страницы!

-Todd

БОЛЬШЕ ИНФОРМАЦИИ:

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

Вот несколько несжатых стилей:

div.normal p {
    margin: 10px 0 10px 0;
}

div.centered p {
    margin: 10px auto;
    color: blue;
}

div.normal p {
    color: black;
}

Компрессор CSS создает следующий выход:

div.normal p{margin:10px 0}div.centered p{margin:10px auto;color:blue}div.normal p{color:#000}

Если бы мы применили агрессивное сочетание определений стилей, которые имеют одинаковый селектор, мы получим следующий код.

Метод 1, объединяя оба в первое определение, неправильно сделает текст цвета синим:

div.normal p{margin:10px 0;color:#000}div.centered p{margin:10px auto;color:blue}

Метод 2, объединяя оба во второе определение, неправильно сделает текст влево выровненным:

div.centered p{margin:10px auto;color:blue}div.normal p{margin:10px 0;color:#000}

Единственное время объединения определений стилей с одним и тем же селектором, на 100% без ошибок,-это когда определения появляются непосредственно один за другим, но в любом другом случае этот метод рискует развращать каскад стилей.

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

Честно говоря, я был бы очень обеспокоен компрессором CSS, который объединил стили из разных блоков определения, потому что каскад - очень хрупкая вещь, и крайне легко сломать каскад.

Другие советы

На странице есть Раздел о «разуме, не используемом», который описывает, почему он не делает эти две вещи.

И вдобавок ко всему, я бы предположил, что это не пытается делать эти вещи, потому что это не полный анализатор/интерпретатор CSS, и начнет бурку, как условные блоки CSS.

Под «разрушительным» я предполагаю, что вы имеете в виду «CSS не работает так, как ожидалось».

Объединение правил длинных рук, таких как ваш первый пример, может быть сделано без каких-либо вредных последствий.

В простой старой таблице стилей без медиа -блоков или других причудливых вещей, второй пример также не вызовет никаких проблем.

Причина № 2 рискованна, заключается в том, что изменение порядка правил или правила складывания вместе без учета каскада может привести к поломкам.

Некоторые компрессоры CSS могут переупорядочить правила алфавитно или типа селектора. Они очень рискованны, потому что движущиеся правила вокруг могут нарушить каскадное поведение, созданное автором.

Минификаторы, такие как компрессор Yui, не делают ни одного из них, выбирая более безопасные стратегии, такие как удаление пробелов, избыточные полуколоны и нули, а также тому подобное.

С большим количеством CSS, содержащих носители, и другой код CSS3, вероятно, что многие из текущих компрессоров CSS вообще не будут работать правильно. Большинство не имеют надлежащего лексера для анализа кода-они используют контекст, знаясь по байто-байтовому (аккуратному) или режимам (большую часть остальных) для обработки кода.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top