Formateador de CSS

Para qué sirve

El CSS que sale de un compilador, de una herramienta de diseño o del inspector del navegador viene sin saltos de línea. Leerlo así es imposible y compararlo con otra versión, todavía peor: un cambio de una propiedad aparece como una línea entera distinta. Repartirlo en declaraciones es lo primero que hay que hacer para poder trabajar con él.

Al revés también hace falta. Un fragmento en una sola línea entra en un atributo, en un correo o en un campo de configuración donde los saltos molestan, y ocupa menos.

Lo que parece un problema trivial tiene tres trampas, y las tres consisten en tomar por sintaxis algo que es contenido: un «url()» sin comillas puede llevar dentro puntos y coma, una cadena puede llevar una llave de cierre, y los operadores de «calc» necesitan espacios que no se pueden quitar.

Cómo se calcula

Primero se trocea el texto reconociendo las piezas que hay que copiar enteras: comentarios, cadenas y llamadas a «url()». Solo después se buscan las llaves, los puntos y coma y los dos puntos que dan estructura. En ese orden, un «url(data:image/svg+xml;base64,…)» pasa entero y su punto y coma no corta ninguna declaración.

El reparto es mecánico. Cada llave de apertura sube un nivel de sangría y cada cierre lo baja. Todo lo que hay antes de una llave son selectores, y si llevan comas se escribe cada uno en su línea. Todo lo que termina en punto y coma es una declaración, que se parte por los primeros dos puntos en propiedad y valor.

Los dos puntos solo separan cuando están en una declaración. En un selector forman parte del nombre —«a:hover», «li::marker»— y ahí no se toca nada, que es la razón de mirar primero si lo que viene después es una llave.

Dentro del valor el espacio se colapsa pero no se elimina. Un «calc(100% - 2rem)» sin los espacios alrededor del signo menos deja de ser válido según la especificación, y es el fallo más repetido de los minificadores escritos con expresiones regulares.

url(data:image/svg+xml;base64,PHN2Zz4=)

Un punto y coma que no termina nada. Partir por él trocea la imagen.

content: "; }"

Una llave de cierre que no cierra ningún bloque.

calc(100% - 2rem)  ≠  calc(100%-2rem)

El segundo no es CSS válido: en las expresiones matemáticas los operadores llevan espacio a los dos lados.

Ejemplo resuelto

Una hoja compilada

Entrada: .a,.b{display:grid;padding:calc(var(--g) * 2 - 4px)}

Los dos selectores van separados por una coma en el nivel exterior, así que cada uno baja a su línea y la llave se pega al último.
Cada declaración termina en punto y coma y se escribe en un renglón, sangrada un nivel.
La declaración se parte por los primeros dos puntos: «padding» a la izquierda, el resto a la derecha.
Dentro del «calc» los espacios alrededor del asterisco y del signo menos se conservan tal cual.
A la última declaración se le añade el punto y coma que le faltaba.

Seis líneas, con los dos selectores y las dos propiedades a la vista.

Lo que se respeta sin preguntar

Hay partes del CSS donde el contenido manda sobre la forma. En todas ellas el texto se copia carácter a carácter, aunque contenga signos que en cualquier otro sitio significarían algo.

Caso	Qué pasa	Por qué
url() sin comillas	se copia entera	puede llevar «;» y «:»
cadenas	intactas	una «}» dentro no cierra nada
comentarios	en su línea	titulan las secciones
calc, clamp, min…	espacios intactos	sin ellos no son válidos
variables --x	sin tocar	su valor admite casi cualquier cosa
@media, @supports	abren bloque	se sangra lo de dentro

Ordenar no es optimizar

Esto reparte líneas. No agrupa selectores repetidos, no elimina la propiedad que otra posterior pisa, no reordena para aprovechar la cascada y no añade prefijos de navegador. Todo eso lo hace un optimizador de verdad, dentro del proceso de compilación, con conocimiento del proyecto entero.

El minificado tampoco pretende competir con esas herramientas: quita comentarios y espacio sobrante, y ahí se detiene. Prefiere conservar un espacio de más alrededor de un combinador «>» antes que arriesgarse a romper una expresión matemática que use el mismo signo.

Preguntas frecuentes

¿Por qué no quita los espacios de un calc al minificar?

Porque el estándar los exige. En una expresión matemática los operadores tienen que llevar espacio a ambos lados, y sin él la declaración entera se descarta. Es el fallo clásico de minificar con buscar y reemplazar, y produce estilos que desaparecen sin dar ningún error.

¿Qué pasa con las imágenes incrustadas en base64?

Pasan enteras. Una «url()» sin comillas se reconoce como una sola pieza y se copia tal cual, con sus dos puntos y su punto y coma dentro. Es justo el caso donde un formateador ingenuo trocea la imagen y deja la hoja rota.

¿Comprueba si el CSS es válido?

No. Una propiedad que no existe o un valor imposible se reparten en líneas igual que los correctos. Para saber si el navegador acepta algo, lo fiable es el inspector: tacha las declaraciones que descarta.

¿Entiende Sass, Less o el anidamiento nativo?

El anidamiento con llaves se sangra bien, venga de donde venga, porque solo se mira la estructura. Lo que no se interpreta son las construcciones propias de un preprocesador: mixins, funciones y variables con dólar se conservan pero se tratan como texto corriente.

¿Por qué separa cada selector en una línea?

Porque así un control de versiones marca solo el selector que has añadido en lugar de la línea entera. Con listas de cinco o seis selectores la diferencia entre revisar un cambio y no poder revisarlo es exactamente esa.

¿Se aplican a esta página los estilos que pego?

Nunca. El texto no se inserta en el documento ni se registra como hoja de estilos: se analiza como una cadena y se muestra dentro de un bloque de código. Puedes pegar la hoja entera de un proyecto sin que cambie nada de lo que ves aquí.