Estándares CSS de WordPress: lo que cambia con Stylelint

En pocas palabras: El 7 de octubre de 2026 se propuso actualizar los estándares CSS de WordPress Core para integrar Stylelint: se exige una sola línea en blanco entre secciones y bloques, y se evita la propiedad order y los valores *-reverse por accesibilidad.

Una propuesta publicada el 7 de octubre de 2026 en Make WordPress Core plantea actualizar los estándares CSS de WordPress para poder integrar Stylelint en Core. Los dos cambios relevantes: una sola línea en blanco entre secciones y bloques, y evitar la propiedad order y los valores *-reverse.

Los estándares CSS de WordPress (CSS Coding Standards) son las reglas de escritura de hojas de estilo que sigue el código de WordPress Core: formato, valores, propiedades y organización. Forman parte del Coding Standards Handbook, que también cubre PHP, JavaScript, HTML y accesibilidad. Al 7 de octubre de 2026, ninguna herramienta las hace cumplir en Core. Stylelint sería el linter que lo haga, y por eso primero hay que ajustar el texto.

¿Qué son los estándares de codificación CSS de WordPress y por qué entra Stylelint?

Stylelint es un linter de CSS que Core quiere sumar para que los estándares se cumplan solos y no por la buena voluntad de cada contribuidor. Según el ticket #29792 de Trac, la idea es chequear errores de sintaxis y hacer cumplir las reglas de estilo.

Los errores de sintaxis ya los atrapa postcss. Lo que falta es la parte de los estándares.

Stylelint se usa desde hace varios años en el repositorio de Gutenberg y, según la propuesta, está muy extendido en la industria. El objetivo declarado es que no entren errores nuevos contra el estándar y que el código sea más fácil de mantener. También apunta al pipeline de integración continua de WordPress, o sea que el chequeo correría en cada contribución. Antes de eso, la propuesta pide una actualización menor del texto, y ya hay un pull request listo en el repositorio relacionado. Te puede servir nuestra cobertura de la comunidad de contribuyentes de WordPress Core.

Mi lectura: tiene sentido ordenar la norma antes de prender el linter. Si el linter dice una cosa y el handbook otra, el contribuidor termina peleándose con las dos (y no es lo que querés en una herramienta que se supone que ayuda).

¿Qué cambia en los estándares CSS de WordPress?

Cambian dos reglas. La primera baja las líneas en blanco a una sola entre secciones y entre bloques. La segunda agrega dos viñetas nuevas, en las secciones de propiedades y valores, que piden evitar order y los valores *-reverse. El resto de la configuración de Stylelint coincide con los estándares actuales, según la propuesta oficial.

Tema	Estándar actual	Propuesta	Motivo según la fuente
Líneas en blanco	Dos entre secciones, una entre bloques de una sección	Una entre secciones y entre bloques	Stylelint no distingue entre las líneas que van antes de una sección y las de un bloque
Propiedad order	Sin regla específica	Evitarla	Puede dañar la accesibilidad; ya rige en Gutenberg
Valores *-reverse	Sin regla específica	Evitarlos	Mismo motivo: el orden visual, de lectura y del DOM deben coincidir

Un ejemplo ilustrativo (armado por mí, no sale de la fuente) de cómo quedaría el espaciado:

/* Header */

.site-header {
	display: flex;
}

.site-header a {
	color: currentColor;
}

/* Footer */

.site-footer {
	padding: 1rem;
}

Una sola línea entre todo. Se pierde un poco la pista visual de «acá empieza otra sección», y ahí la decisión es pragmática: una regla que el linter pueda verificar vale más que una convención que nadie controla. En mantener WordPress actualizado paso a paso profundizamos sobre esto.

¿Por qué se desaconseja usar la propiedad order y los valores reverse en CSS?

Se desaconsejan porque pueden separar lo que ves en pantalla de lo que recorrés con el teclado o lo que leen los lectores de pantalla. La propuesta exige que el orden visual, el de lectura y el del DOM coincidan. Solo permite order y *-reverse cuando no afectan el orden de lectura, el significado ni la interacción.

La fuente cita dos especificaciones del W3C. El CSS Display Module Level 3 dice (cita literal): «Authors must use order only for spatial, not logical, reordering of content. Style sheets that use order to perform logical reordering are non-conforming.» El CSS Flexible Box Layout Module Level 1 agrega: «Authors must not use order or the *-reverse values of flex-flow/flex-direction as a substitute for correct source ordering, as that can ruin the accessibility of the document.»

Ponele un caso hipotético: una tarjeta de producto donde el HTML pone primero el título y después el botón «Comprar», y un flex-direction: column-reverse muestra el botón arriba. Con el mouse nadie nota nada, pero quien navega con Tab llega al botón en un orden que no coincide con lo que ve. Ese es el tipo de desajuste que la regla quiere cortar.

Ojo: no es una prohibición absoluta. Un reordenamiento puramente espacial, que no cambia el sentido de lo que se lee, sigue siendo legítimo. Más contexto en probar cambios de CSS en un staging.

Criterio práctico para revisar tus hojas de estilo

Lo que sigue es una propuesta editorial mía, no está en la fuente:

• Buscá los casos. Rastreá order: y -reverse en tus hojas de estilo.
• Probá con el teclado. En cada coincidencia, recorré la página con Tab y fijate si el foco salta de forma incoherente con lo que ves.
• Probá sin CSS. Desactivá los estilos y leé el HTML en su orden natural: si pierde sentido, el reordenamiento era lógico y no espacial.

¿Qué otros ajustes menores incluye la propuesta?

Incluye tres retoques de contenido y un cambio de forma, todos detallados en el post original:

• Excepciones a los valores en minúscula. Se agregan explícitamente currentColor y optimizeLegibility.
• Animaciones CSS3. Se quita «such as CSS3 animations» de la frase sobre cosas que Core todavía no usa, porque Core ya las usa.
• Excepción de wp-admin.css. Se elimina la viñeta que ubicaba las media queries al final de cada sección, porque wp-admin.css ya no está dividido en secciones.
• Cambios cosméticos. Por ejemplo, oraciones largas partidas en viñetas para leerse mejor.

¿Los cambios en los estándares CSS de WordPress ya están aprobados?

No. Es una propuesta que quien la publicó dejaría abierta a comentarios durante una semana. Si no aparecen objeciones significativas, sugiere avanzar con la actualización. Contando desde el 7 de octubre, eso lleva más o menos a mediados de mes (cuenta mía, la fuente no fija una fecha de cierre).

Qué está confirmado

• La publicación del 7 de octubre de 2026 y el pull request ya preparado.
• La revisión de @joedolson, mencionado en los agradecimientos del post.
• El pedido de limitar el feedback al alcance de estos cambios menores.
• La intención de que, con Stylelint activo, cambios mayores se discutan con datos reales en una propuesta posterior.

Qué falta o no se sabe

• La aprobación final y la fecha de aplicación de los cambios.
• Cuándo se integra Stylelint a Core y al pipeline de integración continua.
• Cómo se van a tratar los incumplimientos (la fuente no lo detalla).
• Si afecta a temas y plugins de terceros: la propuesta habla de Core y no dice nada de ellos.

Si mantenés un tema o un plugin, la jugada sensata es mirar tus hojas de estilo contra las reglas nuevas, sin asumir que ya se aplican a tu código ni que hay que reformatear todo hoy. Y lo que dice la propuesta sobre el futuro vale por lo que es: con Stylelint corriendo, el equipo tendría datos concretos para discutir reglas más grandes, algo que hoy no existe porque nadie mide el cumplimiento.

Errores comunes al leer esta propuesta

• Creer que order quedó prohibida. La regla pide evitarla y deja usarla cuando no afecta lectura, significado ni interacción.
• Dar por hecho que Stylelint ya corre en Core. Al 7 de octubre de 2026, los estándares no se hacen cumplir con ninguna herramienta; la propuesta es el paso previo.
• Reformatear tus archivos antes de tiempo. Pasar todo a una línea en blanco hoy es trabajo que puede cambiar si la propuesta se modifica durante la semana de comentarios.
• Usar row-reverse como atajo en lugar de reordenar el HTML. Es justo el uso que el W3C desaconseja.
• Mandar feedback fuera de alcance. El post pide comentarios sobre estos cambios menores; las discusiones grandes quedan para una propuesta posterior.

Preguntas Frecuentes

¿Qué cambios se proponen en los estándares CSS de WordPress Core?

Hay dos cambios relevantes: una sola línea en blanco entre secciones y bloques, y evitar la propiedad order y los valores *-reverse. El resto son ajustes menores, como excepciones de minúsculas para currentColor y optimizeLegibility, y cambios cosméticos. Cubrimos ese tema en detalle en armar una landing page en WordPress.

¿Por qué WordPress quiere usar Stylelint en Core?

Quiere hacer cumplir los estándares CSS, que al 7 de octubre de 2026 no se verifican con ninguna herramienta, y evitar nuevos errores de estándares. Según la propuesta, mejora la compatibilidad con las reglas y el mantenimiento futuro. Stylelint ya se usa desde hace varios años en el repositorio de Gutenberg.

¿Por qué no se recomienda usar la propiedad order en CSS?

Porque puede dañar la accesibilidad cuando el orden visual no coincide con el orden del DOM y de lectura. Las especificaciones del W3C piden usarla solo para reordenamientos espaciales, no lógicos.

¿Cuántas líneas en blanco hay que dejar entre bloques según los estándares CSS de WordPress?

Una. El estándar actual pide dos entre secciones y una entre bloques; la propuesta unifica todo en una línea en blanco, porque Stylelint no distingue entre ambos casos. Mientras no se apruebe, sigue vigente la regla actual.

¿Los cambios en los estándares CSS de WordPress ya están aprobados?

No, son una propuesta publicada el 7 de octubre de 2026 con una semana de comentarios. Si no hay objeciones significativas, se avanzaría con la actualización. La fuente no confirma una fecha de aplicación.

Conclusión

La propuesta es chica en texto y grande en consecuencias: prepara el terreno para que Stylelint haga cumplir los estándares CSS de WordPress en Core y en su integración continua. De los dos cambios relevantes, el de las líneas en blanco es una concesión práctica a la herramienta, y el de order y *-reverse es el que merece tu atención porque toca accesibilidad.

Qué hacer: revisá tus CSS buscando order y -reverse con el criterio de Tab y sin estilos, seguí el post oficial por si cambia algo en la semana de comentarios y no reformatees nada hasta que haya decisión final. Si querés opinar, mantené el feedback dentro del alcance que pide el post.

Fuentes

• Make WordPress Core – Proposal: Minor updates to the WordPress Core CSS Coding Standards (7 de octubre de 2026)
• WordPress Trac – Ticket #29792, propuesta de linter de CSS para Core
• W3C – CSS Display Module Level 3
• W3C – CSS Flexible Box Layout Module Level 1