La idea de esta serie es muy simple: ir de lo más sencillo a lo más avanzado para mostrar, con ejemplos reales, lo fácil y rápido que puede ser trabajar con Tailwind en proyectos de WordPress.

En este primer vídeo arrancamos con una configuración muy básica, a propósito: lo justo para ponernos a construir y ver resultados rápido. Más adelante iremos mostrando cómo funciona la configuración gratuita de Tailwind que tenemos en Flowtitude, para trabajar con más consistencia, productividad y escalabilidad.

En este episodio empezamos con una base clásica que vas a poder reutilizar mil veces:

• Hero a dos columnas (etiqueta + título + texto + botones + imagen)
• Responsive desde el minuto uno
• Y un extra muy útil: tipografía fluida usando Utopia, para que el diseño escale perfecto sin pelearte con breakpoints

📅 Ritmo de publicación: 3 vídeos por semana
Lunes, miércoles y viernes

Acabo de descubrir la actualización de tailwind-animations.com y me parece un candidato muy serio para nuestras animaciones: es un plugin pensado para Tailwind v4 con enfoque de “cero configuración, puro rendimiento” y una librería de animaciones lista para usar.

Lo que me llama la atención es que incluye utilidades para animar elementos según su posición en pantalla (tipo «entra en viewport») usando timelines, lo que en la práctica suele dar una sensación más suave que muchos plugins de scroll basados en JS.

⚠️ Peeeero: yo no lo voy a usar aún en proyectos propios, porque este tipo de «scroll-driven animations / view timelines» no tiene aun el soporte en Firefox por defecto. Así que por ahora: marcado y vigilado.

🔗 Link: https://tailwind-animations.com/

📖 Idea clave: cuando Firefox se ponga al día aquí, podemos tener animaciones de scroll mucho más limpias y fluidas sin depender tanto de JS.

En el post anterior ya hablamos del fondo del asunto: la IA está cambiando el flujo de consumo de documentación y eso puede golpear a proyectos que dependen de ese «escaparate».

Hoy solo quiero dejar una opinión que me pareció interesante porque cambia el enfoque: no se queda en «salseo» ni en «Tailwind ha hecho X», sino en qué significa esto para cualquiera que construya herramientas, recursos o productos alrededor del conocimiento.

Si has visto estos días el ruido alrededor de Tailwind, no va tanto de «Tailwind 4 trae X» o «han roto Y».

Va de algo más incómodo: la IA está cambiando cómo se consume la documentación… y eso está golpeando directamente el modelo de negocio de Tailwind Labs.

Antes, el flujo era bastante «clásico»:

buscas cómo hacer algo con Tailwind
aterrizas en la docs
aprendes
y de paso descubres productos/patrones/recursos premium
algunos terminan comprando (y eso financia el proyecto)

Ahora, en muchos casos, el flujo es:

«Hazme un header con Tailwind»
la IA te lo da en 10 segundos
lo ajustas un poco
y no pasas por la docs (ni ves nada alrededor)

Y claro… si tu negocio depende en parte de ese «escaparate» (docs + recursos + productos), el impacto se nota.

Lo interesante de todo esto no es Tailwind en sí, sino la pregunta que deja en el aire:

¿Cómo se sostiene el open source cuando la IA se convierte en la nueva «entrada» a todo?

Porque Tailwind no es un caso aislado: esto le puede pasar a cualquiera que venda plantillas, componentes, documentación o recursos «genéricos».

💡 Idea clave: la IA está haciendo que lo «básico» valga menos, y obliga a que el valor de pago sea algo que la IA no pueda copiar tan fácil: experiencia, sistema, integración, soporte, comunidad, actualizaciones, tooling…

Si antes usabas un complemento (Fluid for Tailwind) que te ayudaba a crear tamaños y espacios que se adaptan de forma progresiva, este proyecto viene a cubrir justo esa necesidad en Tailwind 4: puedes definir un mínimo y un máximo y el valor va creciendo suavemente según el ancho de pantalla, sin estar añadiendo variantes por cada tamaño.

Principales características

• Permite aplicar «valores fluidos» a muchas utilidades: tamaño de letra, rellenos, márgenes, separación entre elementos, anchos/altos, etc.
• Está pensado para el enfoque de Tailwind 4, donde la configuración vive en CSS.

Ejemplo de uso
La idea es indicar valor mínimo / valor máximo en una clase, por ejemplo para tamaño de letra y relleno:

• Tamaño de letra que va de 2XL a 5XL de forma progresiva.
• Relleno que va de 4 a 8 de forma progresiva.

Más información 👉 https://fluid-tailwindcss.vercel.app/

Hace un tiempo compartí por aquí Code2Bricks, la app web que convierte HTML + CSS + JS en estructura de Bricks. Fue muy bien recibida… y lo mejor es que ahora el creador está trabajando en una versión nativa como plugin, que vive directamente dentro del constructor.

📌 ¿Qué aporta esta versión plugin?

Lo potente no es solo «importar», sino el flujo de trabajo:

• Edición bidireccional en tiempo real: editas el HTML y el canvas se actualiza al instante. Y si cambias cosas en Bricks (elementos, texto, clases), el panel se sincroniza también.
• 3 editores en un panel: HTML / CSS / JS juntos, integrados en el builder.
• Workflow «cero fricción»: por defecto es instantáneo; si quieres, puedes activar sincronización manual o atajos.

No es un importador, es un puente vivo entre código y builder.

🧠 Lo más importante: usa el almacenamiento nativo de Bricks

Esto me parece lo diferencial:

• No crea un sistema paralelo.
• Guarda todo donde Bricks lo guarda (CSS root, clases globales, CSS por elemento, JS en elementos de código…).
• Si desactivas/eliminás el plugin, tu trabajo se queda intacto porque sigue siendo «Bricks estándar».

Puedes probarlo sin miedo: no te «secuestra» el proyecto.

✨ Extras que suenan MUY útiles

• Selección inteligente de CSS (Root / Global Classes / Element Classes) con chips, renombrado, copiar, borrar, etc.
• Modo «pin» para editar un elemento sin perder el foco al navegar por la estructura.
• Generador de clases BEM: te propone estructura de nombres, puedes editarla y aplicarla de golpe (globales o por elemento).

Acelera muchísimo cuando quieres ordenar un diseño rápido y dejarlo bien estructurado.

💰 Modelo y próximos pasos

• La app web seguirá siendo gratis.
• El plugin será de pago.
• Está en fase de pruebas y el autor promete vídeos completos + anunciar precio y fecha pronto.

Pinta a herramienta «pro» para quien mezcla Bricks + código de verdad.

🎆 Notición para empezar 2026: si esto cumple lo que promete, puede convertirse en un imprescindible para quienes trabajamos con Bricks y queremos velocidad sin perder control.

Si alguna vez has montado un acordeón con JS «porque toca»… prueba esto: HTML nativo con <details> y <summary>.

✅ Accesible por defecto
✅ Soporta teclado (tab/enter)
✅ Cero dependencias
✅ Y con Tailwind se ve pro en 2 minutos

1) El acordeón mínimo (y ya funciona)

<details class="rounded-xl border p-4">
  <summary class="cursor-pointer font-medium">
    ¿Qué incluye Flowtitude?
  </summary>

  <div class="mt-3 text-sm opacity-80">
    Componentes, utilidades, patrones y una base sólida para construir rápido.
  </div>
</details>

2) Con icono animado usando open: (Tailwind)

open: te deja aplicar estilos cuando el acordeón está abierto.

<details class="rounded-xl border p-4 open:border-zinc-900/20">
  <summary class="flex cursor-pointer list-none items-center justify-between font-medium">
    ¿Necesito JS?
    <span class="transition-transform open:rotate-180">⌄</span>
  </summary>

  <div class="mt-3 text-sm opacity-80">
    Nope. Esto ya abre/cierra con HTML nativo 🙂
  </div>
</details>

3) Versión “pro” con group-open: (control total del interior)

Si quieres que otros elementos dentro reaccionen al estado abierto, usa group + group-open:.

<details class="group rounded-xl border p-4">
  <summary class="flex cursor-pointer list-none items-center justify-between font-medium">
    ¿Puedo estilizar todo al abrir?
    <span class="transition-transform group-open:rotate-180">⌄</span>
  </summary>

  <div class="mt-3 text-sm opacity-80 group-open:opacity-100">
    Sí: iconos, separadores, colores, sombras… lo que quieras.
  </div>
</details>

📌 Idea clave: si el acordeón no necesita lógica compleja, details/summary + open: / group-open: es de esas «victorias rápidas» que encajan perfecto con el enfoque Flowtitude: menos fricción, más avance.

Ya está disponible WindPress 3.3.73, con una actualización muy importante y un par de mejoras que se notan especialmente en proyectos grandes.

✅ Novedad principal

• Actualizado a Tailwind CSS v4 (v4.1.18, la última disponible)

🛠️ Correcciones destacadas

• Scanner mejorado para sitios “grandes”:
  Ahora soporta correctamente el sistema por lotes (batch) para manejar datasets grandes, y aplica la mejora a integraciones con:
  Elementor, Bricks, Oxygen, OxygenClassic, Breakdance, Builderius, Timber y Blockstudio.
• Mejora interna de caché:
  Corrección en la detección de strings JSON dentro del método fetch_contents, para asignar correctamente el tipo de contenido.

Si estás trabajando con proyectos con mucho contenido (o con muchas plantillas), esta versión debedarte un escaneo más estable y fiable.

Hoy comparto un snippet interesante: «Posts relacionados por taxonomía» en Bricks, usando el Query Editor (PHP).

✅ ¿Qué hace?
Cuando estás en un single (post o CPT), el snippet lee la taxonomía del contenido actual (la que tú elijas) y monta un listado de contenidos relacionados que comparten esos mismos términos.

🎯 Lo bueno:

• No depende de plugins extra
• Funciona tanto para blog como para CPTs
• Puedes elegir si excluye el post actual (modo «auto» incluido)
• Y si algo no cuadra, incluye un modo debug visible (sin FTP) para detectar taxonomías mal puestas o términos vacíos

💡 Detalle importante:
El 90% de los fallos viene de lo mismo: usar el «nombre» de la taxonomía en vez del slug real. El debug lo deja clarísimo.

He leído tu artículo y, con respeto, creo que el planteamiento queda bastante condicionado por el marco: en la práctica no es «Tailwind vs BEM», sino Tailwind vs (BEM/ACSS + Etch). Cuando comparas un framework con un entorno que neutraliza varias ventajas típicas del otro (cambio de contexto, aislamiento, automatismos), la conclusión sale casi decidida desde el inicio. Puede ser válida dentro de tu stack, pero cuesta aceptarla como tesis general.

Sobre los tokens: son muy valiosos cuando codifican decisiones del sistema (coherencia, escalas compartidas, tematización, mantenimiento global). Pero si se convierten en regla universal para valores puntuales, añaden indirección sin aportar valor real. No es anti-tokens; es «tokens cuando aportan sistema».

También me chirría cómo se arma el argumento con ciertas herramientas. En algunos textos parece que los paneles son «malos» por defecto o síntoma de un flujo inferior, pero en la práctica con Bricks + Tailwind se puede trabajar casi sin paneles si el flujo está bien planteado. Y cuando el panel encaja con ACSS o con tu forma de trabajar, entonces pasa a ser «fantástico». Los paneles no son buenos o malos: son una herramienta, y el juicio debería depender del objetivo y los trade-offs, no de la bandera del stack.

Algo similar con la IA: se critica como si degradara el trabajo, pero luego aparece en ejemplos para generar o apoyar componentes concretos. No pasa nada por usarla; el problema es el mensaje implícito de «esto es malo… salvo cuando lo uso yo». Ese doble rasero debilita el debate.

Y ya que quiero responderte con claridad, también sobre tu comentario de Bricks 2.2 (lo de «secuestra», «roba», «cinta adhesiva»…): sinceramente, ese framing me parece más retórico que técnico. En software las ideas convergen, se inspiran, se adaptan y se mejoran. Si vamos a usar “copiar ideas” como descalificador, entonces también habría que reconocer que un editor HTML+CSS+JS integrado no nació en Etch: ya existía en entornos como LiveCanvas. Lo relevante no es quién lo hizo primero, sino qué tan bien se integra, qué problemas resuelve y con qué costes.

Y te lo digo con un ejemplo para que se entienda el punto: si mañana sacaras tu propio CMS, sospecho que de repente WordPress pasaría a ser «malo malísimo» por todo lo que no hace como tu CMS, resaltando sus límites como si fueran defectos imperdonables. Pero la realidad es que nada es blanco o negro: cada herramienta tiene compromisos, cada equipo tiene un contexto, y cada uno tiene sus preferencias y metodología.

Por eso, más allá de gustos técnicos, lo único que pediría es respeto: se puede defender un enfoque sin convertir la crítica a los demás en un argumento de venta, ni presentar al resto como si estuvieran equivocados o atrasados por elegir otra vía. Un ecosistema sano mejora cuando discutimos trade-offs de forma honesta, no cuando reducimos el debate a «lo mío es lo correcto».

Un saludo.