Cuando trabajamos con estilos de CSS para crear un diseño o modificar uno existente, tenemos que ser conscientes de dos temas muy importantes que nos van a condicionar: las prioridades y la especificidad de los estilos.
En este artículo vamos a ver estos dos conceptos en general y que ocurre en el caso de trabajar con WordPress, que además debemos tener en cuenta si son estilos del theme, child theme, un plugin o custom CSS.
¿Qué es la prioridad de estilos CSS?
En cualquier proyecto web en HTML, existen distintas formas de añadir estilos de CSS:
- Enlazando archivos css externos:
<link rel=»stylesheet» type=»text/css» href=»mystyle.css»> - Añadiendo estilos en la cabecera de la página:
<head>
<style> h1 { color: orange; } </style>
</head> - Utilizando estilos inline (*), es decir, insertados en el mismo elemento que estamos modificando:
<h1 style=»color: green;»>Título de la página</h1>
Por norma general, la prioridad de estos estilos, en caso de estar modificando el mismo elemento sería:
1º el estilo inline, que prevalece siempre.
2º el estilo de página, siempre y cuando esté después que la llamada al CSS externo (que es lo habitual):
<head>
<link rel=»stylesheet» type=»text/css» href=»mystyle.css»>
<style> h1 { color: orange; }</style>
</head>
3º Y por último el archivo externo, a menos como decía antes, que la llamada a ese archivo esté después de las líneas de estilo de la cabecera.
En el caso de cargar varias hojas de estilo externas, la última sobre-escribe las anteriores, por lo que en caso de tener diferentes estilos para el mismo elemento, haría caso a la última que encuentre.
(*) Los estilos inline, aunque son los que tienen máxima prioridad y sobreescriben a cualquier otra indicación, no se recomiendan utilizar por temas de optimización y limpieza de código.
Aún así, se utilizan en algunos casos cuando trabajamos con estilos dinámicos que modificamos «al vuelo» mediante Javascript o jQuery: mostrar u ocultar elementos, cambiar la visualización, etc…
En ese caso no hay problema si son cosas puntuales, pero si han de ser muchos los cambios también existe la opción de cargar hojas de estilo dinámicamente en lugar de añadir o quitar estilos inline.
Especificidad del CSS
Una vez vista de forma resumida el tema de las prioridades, la cosa se complica un poco si tenemos en cuenta la especificidad de los estilos que agregamos.
¿A qué nos referimos con especificidad?
Cuando añadimos estilos con CSS podemos hacerlo refiriéndonos a un elemento genérico, por ejemplo h1, a una clase o atributo concreto de ese elemento (h1.destacado) o a un ID concreto (h1#dest)
Por ejemplo, para la etiqueta en HTML: <h1 ID=»dest» class=»destacado»>Título de la página</h1>, podemos darle estilo de 3 formas:
h1 { color: black; }
h1.destacado { color: grey; }
h1#dest { color: red; }
En general y sin entrar en detalles de selectores, pseudo-selectores, etc… cuanto más específico sea, más predominará la instrucción, es decir, en el caso anterior, el estilo aplicado a un ID, prevalecerá sobre el de la clase y sobre el genérico.
El problema o complicación viene cuando combinamos ambos conceptos, y tenemos por ejemplo, un estilo dado a un ID concreto en una hoja externa mientras que en otra hoja con más prioridad tenemos un estilo para la clase del mismo elemento.
En ese caso, la especificidad «gana» a la prioridad, siempre y cuando no sea en un estilo inline, que siempre prevalece ante todo lo demás.
Es decir, si tenemos en una hoja
h1#dest { color: red; }
Y después:
h1.destacado { color: grey; }
Por prioridad, se aplicaría siempre el último que se encuentra, que sería h1.destacado, pero como el anterior es mucho más específico porque aplica a un ID, en este caso el titular aparecería de color rojo, excepto que en el html tuvieramos indicado otro color mediante ‘style=»» ‘, que prevalecería ante los anteriores.
La etiqueta !important
Seguramente habrás visto (y utilizado, que lo hemos hecho todos…), la etiqueta !important añadida a un estilo CSS:
h1.destacado { color: grey !important; }
Básicamente lo que hace esta etiqueta es cargarse toda la jerarquía de prioridades y especificidades para obligar a que el navegador utilice ese estilo, esté donde esté y utilice el selector que utilice.
En general no se recomienda utilizarlo ya que rompe la lógica de las hojas CSS, cuyo nombre indica precisamente eso: Cascading Style Sheets (Hojas de estilo en cascada), aún así, hay que reconocer que en algunos casos nos puede sacar de algún apuro cuando la arquitectura de hojas de estilo de una web es realmente compleja y no conseguimos llegar a modificar un elemento en concreto de la forma que debería ser la correcta.
Ese puede ser el caso de lo que queríamos llegar hoy, y es el tema de los CSS en WordPress y que voy a intentar explicar a continuación.
CSS en WordPress: themes, child themes y plugins
Todo lo comentado hasta ahora es relativamente fácil de controlar cuando estamos trabajando en un proyecto a medida, en el que tanto el html como los estilos los añadimos nosotros y podemos controlar el orden y a qué aplican.
El problema viene cuando trabajamos en WordPress, y es que en ese caso nos vamos a encontrar que tenemos estilos que vienen de:
- El mismo WordPress
- El theme o plantilla padre
- El child theme o tema hijo
- Los plugins instalados
- Maquetadores visuales que añaden estilos propios o inline
Sólo tienes que abrir la web e ir a ver el código de cualquier página para ver en la cabecera la cantidad de archivos y código CSS que se está cargando cada vez:
Si además sumamos el hecho de que cada plugin tiene su desarrollador y que es diferente del creador del theme y que no todos siguen las mismas normas o recomendaciones a la hora de añadir estilos a la web… nos encontramos que no en pocas ocasiones intentamos modificar un estilo de la forma que teóricamente es la correcta y no funciona.
Y es que aunque la forma óptima en general recomendada para añadir estilos a WordPress es mediante un child theme, si lo que estamos intentando es modificar el aspecto de algún componente de un plugin y sus estilos no están cargando después del child theme, o el theme usa un personalizador para modificar estilos y los añade directamente en la cabecera de la página… pues eso, que nuestros estilos en el child theme no van a funcionar.
Un caso típico es con WooCommerce o con plugins de formularios como Contact Form 7 o Ninja Forms… muchas plantillas de WordPress incluyen estilos específicos para estos elementos como valor añadido de sus temas.
Si esta todo correcto, esos estilos podremos modificarlos en nuestro child theme (ojo, siempre y cuando estemos usando la misma o mayor especificidad que el theme padre), pero si, por ejemplo, el theme tiene un personalizador donde el usuario puede cambiar alguna prioridad, ésta tendrá prevalencia sobre la hoja de estilos del child theme.
¿Cómo lo solucionamos entonces?
Sí has llegado hasta aquí a pesar de que el apartado anterior pueda parecer un poco complejo (y un poco travalenguas…), tengo una buena noticia, a pesar de todo hay forma de sobreescribir esos estilos que no te funcionan.
La forma drástica y poco recomendada es mediante la etiqueta !important que comentábamos antes… funciona, pero si puedes evítalo a menos que no lo consigas de otra forma.
Otra alternativa, que tampoco es que sea ideal, pero mejor que la anterior, es utilizar un plugin de CSS personalizado (como Simple CSS ) para añadir estilos desde el escritorio de WordPress o incluso el editor de CSS que incluye WordPress en el personalizador.
Ambas opciones seguramente te solucionarán el problema porque añaden el CSS en la cabecera de la página, pero por eso mismo tampoco se recomienda demasiado si se puede evitar, aunque si es para algo puntual te puede servir.
Por último, la opción que yo intento implementar siempre es encontrar la especificidad que consigue que mis estilos prevalezcan sobre los del plugin o theme que quiero sobreescribir.
No siempre es fácil porque algunos estilos son muy específicos, pero si por ejemplo tenemos este estilo:
.woocommerce form.cart button.single_add_to_cart_button { color: green; }
y no sabemos cómo especificarlo más, podemos hacer referencia a la clase de las página que pueden ser comunes en donde aparece ese botón:
.product-template-default.woocommerce form.cart button.single_add_to_cart_button { color: black; }
En el caso de los formularios de contacto que también comentábamos, una opción es usar el ID que se asigna automáticamente a cada uno, aunque en ese caso deberemos tener en cuenta de que sólo se aplicará a ese formulario en concreto y si tenemos varios tendremos que añadir los otros ID afectados.
Cierto que hay otra opción, la que objetivamente sería la ideal, pero para la que necesitas conocimientos más avanzados y más tiempo disponible, y sería revisar la carga de las hojas de estilos del tema y plugin afectados y ver si podemos alterarla para que cargue en el orden correcto, pero como digo, eso ya sería un tema a tratar en otro artículo más complejo, y según el problema a corregir puede que no valga la pena.
¿Eres implementador o desarrollador WordPress?
En la Zona DPW encontrarás más recursos, tutoriales, plantillas, y una biblioteca de snippets para poder utilizar en tu día a día y ganar tiempo en tu trabajo:
ACCEDER AHORA