---
title: "Errores comunes al usar Tailwind en Bricks y cómo evitarlos"
url: "https://flowtitude.com/tailwind-bricks-errores/"
type: "post"
published: "2025-08-26T08:36:34+02:00"
modified: "2026-11-02T07:50:01+01:00"
author: "Angel Julian"
---

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 `#brxe-abc123 { 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 `#brxe-abc123 { 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í va el CSS de WordPress y de plugins. Ojo: declarar la capa no lo mete dentro. Ese CSS llega sin capa, y **lo que no tiene capa gana siempre a lo que está en capas**, sea cual sea la especificidad. Para que quede por debajo de tu sistema hay que volver a cargarlo dentro de la capa (`@import url(…) layer(wordpress)`, como en el artículo sobre [@layer en WordPress](/layer-css-wordpress-tailwind/)).
- **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 —y el CSS de WordPress y plugins metido en su capa—, tu `@layer base` manda en la tipografía global sin `!important`. Si ese CSS externo se queda sin capa, ganará él.

**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`, `--text-body-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 { --text-body-sm: 15.5px; }` → `text-body-sm` (en Tailwind 4 los tamaños de letra viven en `--text-*`; con otro nombre no cambias el `text-sm` de todo el sitio).

**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 b**reakpoints**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.

---

¿Quieres ejemplos listos de `btn`, `card` y patrones `section + container`?
Únete a la **comunidad Flowtitude** y accede al curso **“Descubre Tailwind”** para empezar con una base sólida y reusable desde el día uno.

👉 **[Únete a la Comunidad Flowtitude](https://flowtitude.com/crear-cuenta/)**