¿Son los minificadores CSS que combinan elementos destructivos?

Question

Encontré este minificador CSS (http://www.lotterypost.com/css-compress.aspx). Hay una sección en la parte inferior de esa página etiquetada "¿Qué no hace el compresor CSS a propósito?" Hay cuatro cosas, dos de las cuales no podía entender por qué podrían ser destructivas:

Combinando el margen individual, el acolchado o los estilos fronterizos en una sola propiedad.

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

Convertirse en

  margin: 10px 0 8px 30px;

Y combinando estilos para el mismo elemento que se especifican en diferentes bloques de estilo.

#element {
   margin: 0;
}

#element {
   color: #000000;
}

Convertirse en

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

Creo que Csstidy hace ambos. ¿Es correcto la página web anterior? ¿Hay situaciones en las que estos tipos de minificación puedan ser un problema?

Answer 1

Soy el desarrollador del compresor CSS que es el tema de esta pregunta (http://www.lotterypost.com/css-compress.aspx), así que explicaré un ejemplo de cómo un compresor puede romper la cascada CSS si una herramienta lo reescribe agresivamente.

Hay muchas formas de dirigir elementos en una hoja de estilo, y debido a que un compresor CSS no tiene un conocimiento íntimo de la estructura DOM, las clases, las identificaciones, etc., etc. Las definiciones se romperán o no.

Por ejemplo, una estructura HTML simple:

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

Y algunos CSS:

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

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

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

los sin comprimir El código produciría un párrafo centrado con un margen superior de 10 px y un margen inferior de 5px.

Si ejecuta los estilos CSS a través del compresor CSS, obtendrá el siguiente código, que mantiene el orden y la cascada de los estilos originales sin comprimir.

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

Digamos que desea comprimir agresivamente los estilos aún más, combinando los márgenes de los dos Div. Normal P Definiciones. Ambos tienen exactamente el mismo selector, y parecen diseñar redundantemente el margen inferior.

Habría dos formas de combinar los márgenes: puede combinar las dos definiciones de margen en la primera (arriba) Div. Normal P estilo o combínelos en el último (inferior). Intentemos en ambos sentidos.

Si combinas los márgenes en el primero (arriba) Div. Normal P estilo, obtienes esto:

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

El resultado de combinar los márgenes de esa manera resultaría en que el margen inferior se establezca incorrectamente en 10px, porque la clase "centrada" anularía el margen inferior (porque la definición de estilo "centrada" ahora aparece más tarde en la cascada).

Si combina los márgenes en el último (abajo) Div. Normal P estilo, obtienes esto:

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

El resultado de combinar los márgenes de esa manera resultaría en que el párrafo ya no aparezca como centrado, porque la definición de "P" inferior anularía los márgenes izquierdo y derecho de "Auto" que se definen en la clase "centrada".

Por lo tanto, podemos ver que combinando definiciones de estilo que incluso tienen exactamente el mismo selector puede causar algunos problemas bastante malos.

¿Alguna vez escribirías un código como este? Tal vez o tal vez no. Debido a las diversas reglas de "peso" de la cascada, es posible caer en este tipo de trampa de código sin darse cuenta nunca.

Además, dado el hecho de que en las páginas web de hoy, múltiples archivos CSS a menudo se combinan en un archivo para presionar el servidor con menos descargas, es fácil imaginar que el compresor CSS arruine la cascada al reescribir múltiples láminas de estilo (posiblemente Escrito por diferentes personas) que se adjuntan juntos en un archivo.

De hecho, escribí el compresor CSS para este mismo escenario en mi sitio web, Publicación de lotería. Cada página web tiene muchas hojas de estilo que admiten varios jQuery y otros componentes, y el compresor CSS se utiliza para comprimir automáticamente todas esas hojas de estilo en una sola descarga. Todas las páginas del sitio tienen al menos 10 hojas de estilo diferentes combinadas, y la mayoría de las páginas tienen más que eso.

Por ejemplo, si mira el código detrás de la página del compresor CSS en sí, encontrará la hoja de estilo principal en la cabeza que se ve así:

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

El GobBleegook en la URL es en realidad una cadena cifrada que contiene todas las hojas de estilo para combinar en el servidor. El servidor los comprime y almacena el resultado.

Las técnicas de ahorro de espacio y tiempo en esa llamada de hoja de estilo incluyen:

• Combinando muchas hojas de estilo en un archivo/descargar simplemente agregándolas todas juntas
• Comprimiendo la hoja de estilo combinada usando el compresor CSS (¡sin estropear la cascada!)
• Uso de un nombre de dominio diferente (LP.VG) para la descarga de la hoja de estilo, que mejora la capacidad del navegador para descargar en paralelo
• Usando un nombre de dominio muy corto (LP.VG)
• La compresión de GZIP se aplica a la hoja de estilo en el servidor web
• El número de versión de la hoja de estilo está incrustado en la URL (".../D11019.0/...") para que si se cambia algún estilo en cualquiera de las hojas de estilo múltiple, puedo cambiar el número de versión y el número de versión y el número de versión El navegador nunca usará la versión que ha almacenado en caché. (Tenga en cuenta que el número de versión debe ser parte de la ruta de URL, no en la cadena de consulta, porque algunos servidores proxy no miran la cadena de consulta para determinar si una página debe recuperarse de la caché).

¡Espero que esto explique mejor las cosas y sea útil para aquellos que buscan mejorar el rendimiento de la página!

-Todd

MÁS INFORMACIÓN:

Para agregar a lo anterior, imagine si tomamos su ejemplo de color y combinamos definiciones de estilo con los mismos selectores.

Aquí hay algunos estilos sin comprimir:

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

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

div.normal p {
    color: black;
}

El compresor CSS produce la siguiente salida:

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

Si aplicamos una combinación agresiva de definiciones de estilo que tengan el mismo selector, obtendremos el siguiente código.

Método 1, combinando ambos en la primera definición, haría que el color del texto sea azul:

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

Método 2, combinando ambos en la segunda definición, haría incorrectamente el texto a la izquierda:

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

El único tiempo que combina definiciones de estilo con el mismo selector es 100% libre de errores es cuando las definiciones aparecen directamente una tras otra, pero en cualquier otro caso, esta técnica corre el riesgo de corromper la cascada de los estilos.

No podía imaginar un caso en el que cualquier desarrollador escribiría código de esta manera (dos definiciones de estilo con exactamente el mismo selector, uno inmediatamente después del otro), por lo que concluí que la cantidad de esfuerzo requerida para codificarlo y la posibilidad de la posibilidad de Un punto adicional de falla en el compresor no valió la pena por un disparo largo.

Francamente, estaría muy preocupado por un compresor CSS que combinó estilos de diferentes bloques de definición, porque la cascada es algo muy frágil, y es extremadamente fácil romper la cascada.

Answer 2

La página tiene un sección sobre 'razón no utilizada' que describe por qué no hace estas dos cosas.

Y además de eso, supongo que no está tratando de hacer estas cosas porque no es un analizador/intérprete CSS completo, y comenzaría a Bork como Bork como Bloques condicionales de CSS.

Answer 3

Por 'destructivo' supongo que te refieres a 'el CSS no funciona como se esperaba'.

La combinación de reglas de mano larga, como su primer ejemplo, se puede hacer sin ningún efecto negativo.

En una hojas de estilo antiguas y simples sin bloques de medios u otras cosas elegantes, el segundo ejemplo tampoco causará ningún problema.

La razón por la que n. ° 2 es arriesgado es porque cambiar el orden de las reglas o el plegado de las reglas juntas sin tener en cuenta la cascada puede dar lugar a roturas.

Algunos compresores CSS pueden reordenar las reglas alfabéticamente, o por tipo selector. Estos son muy arriesgados porque las reglas de mudanza pueden romper el comportamiento en cascada que creó el autor.

Los minificadores como el compresor YUI no hacen ninguno de estos, optando por estrategias más seguras como eliminar espacios en blanco, semicolones y ceros redundantes, y similares.

Con más CSS que contienen bloques de medios y otro código CSS3, es probable que muchos de los compresores CSS actuales no funcionen correctamente. La mayoría no tiene un lexer adecuado para analizar el código: utilizan el contexto consciente de byte por byte (ordenado) o regexs (la mayoría del resto) para procesar el código.

Al seleccionar un compresor, sugeriría encontrar algo que lo haga localmente y está respaldado con una buena suite de prueba para que pueda ver qué caso (y no) se manejan correctamente.