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 errores 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 trabajas con Bricks Builder + Tailwind, en realidad conviven dos formas de dar estilo al mismo proyecto. Y ahí está la raíz del problema:

1. El panel visual de Bricks → muy tentador porque está a un clic. Permite cambiar colores, tipografía, márgenes… pero lo hace generando CSS ligado al ID del elemento o a una clase autogenerada. Resultado: reglas con alta especificidad que luego son difíciles de sobrescribir.
   • Ejemplo: cambias el margin-top desde el panel y Bricks genera #brx-123 { margin-top: 24px; }. Cuando quieras usar mt-6 en Tailwind, no tendrá efecto porque el ID manda.
2. Clases globales en Bricks → puedes crearlas desde el panel y reutilizarlas, pero si no las organizas en un sistema claro, acabarás con un cajón desastre de clases sin coherencia.
3. CSS personalizado en elementos individuales → cómodo para una urgencia, pero es como pegar un post-it en medio del proyecto. A la larga se acumulan «parches» que nadie recuerda y que pueden romper otros estilos.
4. Clases utilitarias de Tailwind → la opción más ligera y predecible, con baja especificidad y escalas consistentes. El problema es que si no defines reglas de uso, acaban mezclándose con los tres puntos anteriores.

👉 El resultado típico:

• Una sección hecha con utilidades Tailwind (mt-6, text-lg).
• Otra sección con estilos aplicados desde el panel de Bricks.
• Un bloque con CSS personalizado porque «no funcionaba».
• Y al final, una web que parece cosida a trozos: tipografías inconsistentes, márgenes que no encajan y overrides con !important para salir del paso.

Claves para no caer en este caos:

• Decide desde el inicio dónde estilizas (panel vs clases) y cúmplelo.
• Mantén baja especificidad para que tu CSS sea flexible.
• Trabaja con un sistema de capas estable que ponga orden.
• Evita añadir “parches”: si algo falla, revisa la estructura antes de añadir CSS suelto.

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

El error:
Aplicar color, tipografía, márgenes o cualquier estilo desde el panel visual de Bricks porque está «a mano». El resultado: Bricks genera CSS ligado al ID o a una clase autogenerada, lo que dispara la especificidad y te obliga a luchar con !important, reglas duplicadas y un CSS más difícil de mantener.

La solución correcta:

• No uses el panel visual como método principal.
• Añade siempre utilidades de Tailwind desde la caja de clases planas de WindPress, que aplica las clases directamente sin generar estilos globales vacíos o innecesarios.
• Reserva el panel solo para casos excepcionales (ej. compatibilidad puntual).
• Cuando necesites un estilo repetible o semántico (ej. un botón, una card, un navbar), créalo en la capa components, no en utilities.
  • En components defines .btn, .card, .badge con sus utilidades internas de Tailwind.
  • Así, al usar btn btn-primary, aplicas un bloque de estilos consistente y fácil de actualizar en todo el sitio.

Ejemplo práctico:

• ❌ Panel Bricks → Margin-top: 24px → genera #brx-123 { margin-top: 24px; }.
• ❌ Capa utilities → .btn { … } → rompe la lógica: no es un helper, es un componente.
• ✅ Caja de clases planas WindPress → mt-6 → aplicación directa de utilidades.
• ✅ Capa components → .btn { @apply px-4 py-2 font-semibold rounded-lg; } → definiciones globales para patrones repetidos.

Beneficio: Ganas en coherencia y escalabilidad:

• Y evitas contaminar la capa utilities con lo que en realidad debería ser un componente global.
• Las utilidades (mt-6, flex, text-lg) se usan de forma directa y puntual.
• Los componentes (btn, card, navbar) encapsulan patrones repetidos.

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

El error:
Dejar que todo conviva en una sola capa, sin ningún orden. Eso provoca choques entre el CSS de WordPress y plugins, los estilos internos de Bricks y tus propias utilidades Tailwind. Resultado: reglas que se pisan unas a otras y un código impredecible.

La realidad:
Cuando usas WordPress con Bricks + Tailwind, no todo tu CSS está bajo tu control directo.

• WordPress y los plugins cargan sus propias hojas de estilo.
• Bricks genera sus reglas internas para el editor y para algunos elementos.
• Tú añades tu sistema de diseño con Tailwind.

Si no defines un orden de capas, se genera una «tormenta» de estilos donde nunca sabes qué regla manda.

La solución:
Establecer una jerarquía clara de capas desde el inicio. En Flowtitude usamos esta estructura:

• wordpress → aquí se coloca el CSS de WordPress y de plugins. No lo escribes tú, pero al definir esta capa te aseguras de que todo lo heredado cargue primero y no interfiera después con tu sistema.
• bricks → Bricks ya maneja su propia capa. Lo que haces es simplemente darle su lugar en el orden de carga. En general, Bricks no suele dar problemas graves; donde más fricciones aparecen es en Gutenberg y en ciertos plugins que inyectan estilos con alta especificidad.
• base → aquí defines tipografía global, escalas de tamaños, colores, espaciado, etc.
• layouts → patrones estructurales como .section, .container, .grid-page.
• components → elementos repetidos: botones, cards, headers, navbars.
• utilities → helpers genéricos como .stack, .bleed, .flow.
• custom → excepciones puntuales. Cuanto menos uses esta capa, mejor.

Ejemplo:
Imagina que Gutenberg mete su CSS para títulos, Bricks añade otro para tipografías y tú defines un h2 en Tailwind.

• Si no hay orden, a veces se aplicará el estilo de Gutenberg, otras el de Bricks, y en otros casos tu regla.
• Con las capas bien organizadas, tu @layer base siempre manda en la tipografía global, y no tienes que usar !important para imponerlo.

Beneficio: tu CSS es predecible y jerárquico. Sabes en qué capa revisar cuando algo falla y evitas guerras de especificidad.

3. No usar componentes globales de Bricks para elementos repetidos

El error:
Aplicar las mismas 8–10 clases Tailwind una y otra vez cada vez que creas un botón, una card o una sección. Puede parecer ágil, pero en cuanto un proyecto crece se convierte en un caos difícil de mantener.

Por qué es un problema:

• Si decides cambiar el estilo de los botones, tienes que hacerlo manualmente en decenas de lugares.
• Aparecen inconsistencias visuales: un botón con rounded-md, otro con rounded-lg, o paddings distintos sin querer.
• Repites trabajo innecesario y rompes la coherencia de diseño.

La solución principal: Usar componentes globales de Bricks.

• Son bloques instanciables: los insertas en cualquier página y, si modificas el original, los cambios se aplican automáticamente en todas sus instancias.
• Aplicas una sola vez las utilidades de Tailwind en la caja de clases planas de WindPress (btn btn-primary, card, etc.).
• Mantienes consistencia y ahorras tiempo en cada proyecto.

Ejemplo:

• Creas un componente global “Botón primario” en Bricks.
• Le añades las clases btn btn-primary en la caja de WindPress.
• En tu CSS (@layer components) defines:

@layer components {
  .btn {
    @apply inline-flex items-center px-4 py-2 font-semibold rounded-lg transition;
  }
  .btn-primary {
    @apply bg-primary-600 text-white hover:bg-primary-700;
  }
}

Cuando lo uses en cualquier página, siempre tendrá la misma base. Si un día decides que los botones deben ser más grandes o con otro color, cambias la definición de .btn o .btn-primary y se actualizan en todo el sitio.

¿Y si no puedes usar un componente global de Bricks?
A veces no es posible (por limitaciones del proyecto, porque el elemento no admite componentes globales o porque buscas algo más ligero).
En esos casos, la alternativa complementaria es crear una clase en la capa components para encapsular ese conjunto de utilidades y reutilizarlo sin necesidad de repetir cadenas largas.

👉 Así, card o btn pueden estar definidos en tu CSS y aplicarse en cualquier elemento directamente desde la caja de clases planas.

Beneficio:

• Con componentes globales de Bricks → gestionas bloques enteros de forma centralizada.
• Con clases en la capa components → reutilizas patrones de utilidades cuando no puedes instanciar un componente.
• Ambas estrategias son compatibles y juntas refuerzan la coherencia visual del proyecto.

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

El error:
Cuando empiezas a trabajar con Tailwind, es tentador tirar de valores arbitrarios para ajustar algo «al milímetro»:

• mt-[27px] porque el diseño se veía raro con mt-6.
• text-[15.5px] porque querías una tipografía un poco más pequeña.
• shadow-[3px_4px_8px_rgba(0,0,0,0.2)] porque ninguna sombra de la escala te convencía.

Esto puede servir durante un prototipo rápido, pero a medio plazo es una bomba de relojería:

• Tu proyecto acumula decenas de valores únicos imposibles de mantener.
• Se rompe la coherencia: cada página parece tener «su propia escala».
• Ajustar algo global (ej. tipografía base) deja de ser efectivo porque tienes valores hardcodeados que no responden al sistema.

La solución: Construir sobre escalas predefinidas y tokens, no sobre ocurrencias puntuales.

• Define tus tamaños, espacios y colores en @theme.
• Si un valor se repite más de una vez, conviértelo en un token (ej. spacing-7, font-size-sm).
• Reserva los valores arbitrarios solo para casos muy específicos que no encajen en ningún token.

Ejemplo práctico:

• ❌ mt-[27px] en tres secciones diferentes.
• ✅ Definir en @theme:

@theme {
  --spacing-7: 27px;
}

Y luego usar mt-7.

Lo mismo con la tipografía:

• ❌ text-[15.5px] en un párrafo.
• ✅ @theme { --font-size-sm: 15.5px; } → text-sm.

Beneficio:

• Mantienes un lenguaje visual común en todo el proyecto.
• Puedes cambiar un valor en el tema y actualizarlo en todo el sitio.
• Tu CSS es más limpio, más predecible y más fácil de compartir con un equipo.

Piensa en un proyecto donde cada desarrollador ajusta márgenes y tamaños «a ojo». El resultado es una web que nunca parece terminada: botones que no alinean, bloques que se sienten desordenados, tipografías que no guardan ritmo.
Cuando trabajas con tokens y escalas, el sistema decide por ti y todos los elementos encajan como piezas de un puzzle.

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

El error:
Construir páginas con div sueltos y márgenes manuales:

• Un bloque con mt-12, otro con mb-10, ajustes a ojo según la pantalla…
• El resultado: desalineaciones, falta de ritmo y un diseño que parece hecho a parches.

La solución (con Flowtitude):
Adoptar siempre el patrón section + container + bloques como base:

1. <section> → delimita áreas semánticas (hero, beneficios, testimonios, CTA). No necesita clase extra: la semántica es suficiente.
2. <div> → div descendiente directo que centra el contenido y limita el ancho.
3. Bloques internos con gap-* semánticos → organiza los elementos usando utilidades como gap-columns-lg o gap-block-md en lugar de márgenes sueltos.

Ejemplo práctico:

<section>
  <div class="grid gap-columns-lg">
      <h2 class="text-3xl font-bold">Nuestros servicios</h2>
      <p class="text-lg text-neutral-600">
        Diseñamos webs escalables y optimizadas con Bricks + Tailwind.
      </p>
  </div>
</section>

• ❌ Márgenes manuales (mt-8, mb-10) que cambian según el bloque.
• ✅ gap-columns-lg, un valor semántico consistente que aplica el espaciado según el sistema.

Beneficio:

• Layouts coherentes en todas las páginas.
• Espaciados predecibles y mantenibles (no hay que inventar valores cada vez).
• Código más limpio y semántico, fiel al sistema de diseño.

Una web hecha con márgenes manuales se desordena en cuanto crece: cada bloque tiene su propio «criterio visual». Cuando usas el patrón section + container + gap semántico, todos los bloques se alinean como parte de un mismo lenguaje visual.

6. Tipografía, colores y responsive sin sistema

El error:
Los proyectos que no siguen un sistema visual caen en tres trampas recurrentes:

• Tipografía → títulos con tamaños distintos en cada página, párrafos sin jerarquía y estilos improvisados (text-xl aquí, text-base allá).
• Colores → cada diseñador o maquetador mete un hex distinto «que se parece al azul corporativo», y terminas con cinco variantes del mismo color.
• Responsive → se aplican breakpoints “a ojo” (sm:, lg:) sin relación con el diseño real, o se meten márgenes manuales para arreglar layouts en móvil.

El resultado es un sitio que transmite desorden, inconsistencia y falta de profesionalidad.

La solución (con Flowtitude): trabajar con un sistema ya definido.

Tipografía con roles predefinidos

En Flowtitude, los roles tipográficos se resuelven desde la capa @layer base con un componente tipográfico semántico. Esto permite separar etiqueta HTML de jerarquía visual, y garantiza consistencia en todo el proyecto:

• display → títulos destacados, jerarquía visual más alta (independiente de la etiqueta).
• heading → títulos principales (h1, h2, h3) con jerarquía clara.
• subheading → subtítulos o headings secundarios.
• text-large → párrafos destacados, en lugar de .lead.
• badge → equivalente al antiguo .eyebrow, usado como subtítulo pequeño o marca visual encima de un heading.
• text-medium → texto base o estándar, en lugar de .body.

👉 Esto elimina el riesgo de improvisar tamaños: usas el rol semántico correcto y todo encaja automáticamente, sin inventar clases nuevas en cada página.

Colores normalizados en tokens

Flowtitude define la paleta de colores en tokens dentro de @theme, con nombres claros y consistentes:

• --color-primary-600, --color-primary-700--color-neutral-700, --color-neutral-900

👉 No hay que inventar hexadecimales. Cuando aplicas bg-primary-600 o text-neutral-700, sabes que es parte de la paleta oficial y será el mismo en toda la web.

Responsive con breakpoints documentados + container queries

Flowtitude documenta los breakpoints y sus usos, de modo que no se aplican «porque sí», sino como parte de una escala coherente.
Además, se promueve el uso de container queries, lo que permite que los layouts respondan al ancho del bloque, no de la pantalla completa.

👉 Así evitas duplicar márgenes o meter parches: el sistema ya define cuándo y cómo deben adaptarse los componentes.

Beneficio de aplicar Flowtitude:

• No necesitas inventar reglas de tipografía, colores o responsive.
• Las decisiones ya están tomadas en el sistema: solo usas los roles, tokens y breakpoints definidos.
• Los errores más comunes (hex aleatorios, tamaños improvisados, breakpoints sin criterio) se eliminan casi por completo.

En un proyecto sin sistema, cada desarrollador aporta su “criterio visual” y la web acaba pareciendo un collage. Con Flowtitude, en cambio, todo fluye: los roles tipográficos marcan jerarquía, los tokens de color aseguran consistencia y los breakpoints documentados garantizan un responsive sólido.

👉 La coherencia no depende de la disciplina de cada persona, sino de aplicar el sistema.

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.