Errores comunes al usar Tailwind en Bricks y cómo evitarlos

Si trabajas con Bricks Builder + Tailwind v4, el mayor riesgo no es “no saber clases”, sino mezclar capas y especificidades, romper la coherencia del sistema y duplicar trabajo con estilos aislados.
En este artículo te muestro los fallos más habituales, cómo detectarlos y cómo corregirlos con una metodología clara, ejemplos prácticos y checklists accionables.

Contexto: por qué aparecen estos errores

Cuando combinas un constructor visual con un framework utility-first, tienes dos formas de dar estilo conviviendo:

1. El panel visual de Bricks (que puede generar CSS con alta especificidad, IDs o clases autogeneradas).
2. Las clases utilitarias de Tailwind (baja especificidad, predecibles, componibles).

Si no defines reglas del juego desde el principio, tu CSS acabará siendo una colcha de retales: media web con utilidades, media web con estilos de ID, overrides por todas partes y decisiones inconsistentes de tipografías, espaciado y colores.

Claves:

• Decide cómo y dónde estilizas antes de empezar (panel vs clases).
• Mantén baja especificidad y un sistema de capas estable.
• Evita añadir “parches” si el problema es estructural.

1. Estilizar con el panel de Bricks en lugar de usar clases

El error: aplicar color, tipografía, margen, etc. desde el panel de estilo de Bricks porque está a mano. Bricks genera CSS ligado al ID o a una clase autogenerada, lo que eleva la especificidad y te obliga a pelearte con !important o duplicar reglas.

Cómo evitarlo:

• En Bricks, usa siempre el campo CSS Classes para añadir utilidades Tailwind.
• Reserva el panel visual solo para casos excepcionales.
• Si necesitas un estilo repetible, crea una clase utilitaria propia en @layer utilities y aplícala como clase.

Ejemplo:
❌ Panel → Margin-top: 24px
✅ Clases → mt-6 en el campo CSS Classes

2. No tener un sistema de capas CSS (layering)

El error: dejar que todo conviva en una sola capa, sin orden. Resultado: choques entre CSS de WordPress/Bricks, componentes propios y utilidades.

Solución: define una jerarquía de capas clara. En Flowtitude se recomienda:

• wordpress: resets y compatibilidades mínimas con Gutenberg.
• bricks: ajustes que neutralizan estilos internos del builder.
• base: tipografía, tamaños, colores globales.
• layouts: uso interno en Flowtitude para patrones globales como .section o .container.
• components: botones, cards, headers, navbars.
• utilities: helpers reutilizables (.stack, .bleed).
• custom: solo para excepciones puntuales.

3. No usar componentes globales de Bricks para elementos repetidos

El error: repetir las mismas 8–10 clases Tailwind cada vez que construyes un botón, card o bloque de sección.

Por qué es un problema:

• Si cambias un detalle (ej. padding de botones), tendrás que modificarlo en decenas de páginas.
• Aumenta el riesgo de inconsistencias visuales.

La solución:

• Usa componentes globales de Bricks. Son plantillas que se actualizan en todo el sitio desde un único lugar.
• Aplica una sola vez las clases Tailwind al componente (btn btn-primary, card, etc.).
• Cuando necesites un cambio global, lo modificas en el componente y se refleja en todas las instancias.

Ejemplo:

• Crea un componente “Botón” en Bricks → CSS Classes: btn btn-primary.
• En tu CSS defines .btn y sus variantes (.btn-primary, .btn-light, etc.).
• Usa ese componente en cualquier página. Si cambias .btn, se actualiza en todo el sitio automáticamente.

4. Abusar de valores arbitrarios y romper la coherencia del sistema

El error: mt-[27px], text-[15.5px], shadow-[...] por todas partes. Útil en prototipado, letal a medio plazo.

La solución: define tus escalas en @theme y evita inventar valores “a capricho”. Si un tamaño se repite, conviértelo en token.

5. Ignorar el patrón section + container + bloques

El error: páginas con divs y márgenes manuales, que terminan en desalineaciones y falta de ritmo visual.

La solución:

• Usa siempre <section class="section"> para delimitar áreas.
• Dentro, un <div class="container"> para centrar contenido y limitar ancho.
• Organiza bloques con utilidades gap-* en lugar de márgenes sueltos.

6. Tipografía, colores y responsive sin sistema

Errores comunes: no definir roles tipográficos, inventar hexadecimales distintos para el mismo color o aplicar breakpoints sin criterio.

Buenas prácticas:

• Define roles tipográficos (h1, h2, .lead, .eyebrow) en @layer base.
• Crea tu paleta de colores en tokens (--color-primary-600, --color-neutral-700).
• Documenta tus breakpoints y usa container queries cuando el layout dependa del ancho del bloque.

Checklist de auditoría rápida

• ¿Usas el panel de Bricks o las clases Tailwind? → Prioriza clases.
• ¿Tus secciones siguen el patrón section + container?
• ¿Tienes componentes repetidos? → Convierte en componente global de Bricks.
• ¿Hay valores arbitrarios? → Migra a tokens.
• ¿Tus botones y cards se actualizan desde un solo lugar?

Conclusión

Bricks y Tailwind se complementan de maravilla, pero solo si gobiernas la especificidad, mantienes una jerarquía de capas clara y aprovechas los componentes globales de Bricks para no repetir trabajo.

El objetivo no es saber más clases, sino tomar menos decisiones porque tu sistema ya las tomó por ti.

Beneficios al aplicar estas prácticas:

• Reducirás overrides y CSS difícil de mantener.
• Acelerarás el trabajo con mayor coherencia visual.
• Podrás cambiar decenas de páginas con un solo ajuste.