Tailwind CSS CDN: prueba una interfaz y compila su CSS
Crea una muestra en el navegador, acuerda qué demuestra y traslada la interfaz aceptada a una hoja de estilos compilada.
Utiliza el script de Play CDN de v4 en un documento HTML independiente para una prueba de desarrollo. Revisa contenido, teclado y anchuras relevantes. Traslada el HTML y las decisiones del tema a un flujo de compilación compatible antes de la entrega en producción.
Tailwind CSS CDN permite probar utilidades en un archivo HTML sin preparar una compilación. Añade el script de Play CDN, construye una muestra pequeña y revisa su contenido en el navegador. Para entregar la web, traslada el resultado a CSS compilado: la documentación oficial reserva Play CDN para desarrollo. Esta guía propone una tarjeta de curso y un proceso de revisión que puedes repetir.
Decide qué debe demostrar la prueba en navegador
Empieza con una pregunta que el prototipo pueda resolver. En este ejercicio, el catálogo ficticio de cursos Fieldnote necesita una tarjeta legible con título, resumen y enlace a los detalles. La revisión debe averiguar si esas piezas siguen entendiéndose cuando el título crece. Es una propuesta editorial: no se trata de una plantilla de EmviUI ni de un resultado de usabilidad medido.

Antes de abrir el editor, escribe una nota de aceptación: el título se puede leer, la descripción admite más contenido y el enlace a los detalles resulta fácil de encontrar. Así, el equipo dispone de algo más concreto que «¿parece terminado?». Deja fuera el acceso a cuentas, la inscripción y el pago. Representarlos sugeriría un nivel de implementación que este documento no proporciona.
Prepara dos registros contrastados: un curso introductorio con nombre corto y un taller de accesibilidad con nombre largo. Conserva el mismo orden de información. Pide a otra persona que encuentre el taller y explique qué espera al seguir el enlace. Anota sus palabras. Esa observación aporta más que añadir un carrusel antes de acordar para qué sirve la tarjeta.
Define también cuándo terminar. Una vez aceptados la jerarquía del contenido y el nombre del destino, guarda la muestra y continúa en el flujo de la aplicación. Extender la prueba a todas las funciones del catálogo dificulta comunicar sus límites.
Usa una tarjeta de EmviUI como referencia visual
Utiliza una muestra real de diseño para hablar de jerarquía antes de trasladarla a HTML. El ejemplo local de EmviUI sitúa una imagen junto al título, el texto de apoyo y una acción. Las tarjetas horizontales repetidas permiten comparar cómo compite el contenido con la imagen cuando aumenta su longitud. La captura sirve como referencia visual, no como prueba de comportamiento en el navegador.

EmviUI ofrece un kit de interfaz y sistema de diseño editable en Figma, con recursos orientados a Tailwind. En este ejercicio ayuda a elegir una composición y comentar el espaciado con quien desarrolla. No sustituye la implementación HTML ni demuestra que una captura incluya enlaces funcionales, código adaptable o soporte de teclado. El código de esta guía es un ejemplo propio y deliberadamente pequeño.
Para Fieldnote, traslada la jerarquía en lugar de copiar los textos del catálogo de muestra. Sustituye el lenguaje de compra por información del curso, elimina controles que la tarea no necesita y conserva un destino claro para los detalles. No arrastres un icono de favoritos sin definir su acción. Cada control adicional exige revisar otro comportamiento.
Mantén el frame elegido junto a la muestra del navegador durante la conversación. Señala cambios intencionados, como permitir que el resumen ocupe más líneas en vez de truncarlo. Si necesitas evaluar recursos con más amplitud, consulta la guía para elegir un kit Tailwind gratuito. Aquí se entrega una traducción visual que se pueda inspeccionar, no una clasificación de kits.
Crea un archivo HTML con Play CDN
Crea index.html y utiliza el script actual de las instrucciones oficiales de Play CDN. El ejemplo mínimo carga el paquete de navegador de v4 e incluye viewport, un encabezado semántico y un destino local real. Guarda también course.html con un título para que el enlace a los detalles tenga una página que abrir durante la revisión.

Abre index.html en un navegador compatible con conexión de red. Si no aparecen los estilos, comprueba primero si se ha cargado el script externo. Esta prueba depende de esa petición. Compartir un archivo HTML sencillo no elimina las dependencias situadas fuera de la carpeta que entregas.
Usa la muestra como punto de partida. La descripción del curso permanece como texto normal y el enlace abre otro documento; no inscribe a nadie. La versión española del código declara su idioma y traduce el contenido visible. Prepara también el destino en español: revisar solamente la tarjeta deja sin comprobar una parte de la tarea que realiza la persona.
Mantén el ejemplo separado de una web existente. Añadir un script experimental a una aplicación establecida complica saber de dónde viene cada estilo. Una carpeta independiente aclara además la posterior revisión de la migración: el equipo puede identificar exactamente qué documento y qué decisiones se aceptaron.
<!doctype html>
<html lang="es">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Fieldnote — Cursos</title>
<script src="https://cdn.jsdelivr.net/npm/@tailwindcss/browser@4"></script>
</head>
<body class="bg-slate-50 p-6 text-slate-900">
<main class="mx-auto max-w-xl">
<h1 class="mb-6 text-3xl font-bold">Cursos</h1>
<article class="rounded-xl border border-slate-200 bg-white p-6">
<h2 class="text-xl font-semibold">Práctica de accesibilidad</h2>
<p class="mt-3 leading-7">Aprende a revisar una interfaz con teclado.</p>
<a href="./course.html"
class="mt-6 inline-block rounded-lg bg-blue-700 px-4 py-2 text-white focus-visible:outline-2 focus-visible:outline-offset-4 focus-visible:outline-blue-700">
Ver detalles del curso
</a>
</article>
</main>
</body>
</html>Mantén las decisiones del tema junto a la muestra
Añade un bloque de tema pequeño cuando la prueba necesite una decisión compartida concreta. Por ejemplo, el enlace del curso puede utilizar un color de acento con nombre. Las variables de tema de Tailwind conectan determinados nombres con utilidades; --color-course permite utilizar bg-course. Documenta para qué existe ese nombre, sin convertir el experimento en una arquitectura completa de tokens.

Coloca el bloque en el head después del script. Para este ejemplo, utiliza un elemento style con type="text/tailwindcss" que contenga @theme { --color-course: #1d4ed8; }. Después, sustituye bg-blue-700 por bg-course en el enlace. El valor es una propuesta para el ejercicio, no una recomendación universal de accesibilidad. Revisa la combinación real con su texto y su indicador de foco.
Evita cambiar a la vez el acento y el espaciado durante una revisión. Guarda una versión, compara el cambio y anota qué mejora o empeora. Si hay desacuerdo, pregunta qué tarea debe favorecer el tratamiento: localizar los detalles, leer el resumen o reconocer la categoría del curso. Así, la conversación visual sigue vinculada a la muestra.
Recuerda que Preflight modifica estilos base, incluidos márgenes predeterminados y presentación de encabezados. Define la jerarquía de forma deliberada. Un título sigue necesitando el nivel HTML adecuado aunque las utilidades determinen su apariencia. El tamaño de letra, por sí solo, no permite deducir la estructura del documento.
Revisa contenido, anchuras y foco de teclado
Revisa el mismo HTML con los dos registros antes de añadir componentes. En una anchura estrecha, lee el título completo y llega al enlace con el teclado. En una anchura amplia, comprueba si la columna de texto sigue siendo cómoda en vez de ocupar todo el espacio disponible. El ancho máximo elegido es una propuesta que debe inspeccionarse, no una medida óptima garantizada.
Las variantes adaptables de Tailwind aplican estilos en puntos de ruptura configurados. Parte de las clases sin prefijo y añade un cambio solamente cuando un problema concreto de contenido lo justifique. Revisa justo antes y después de ese cambio, y recorre también las anchuras intermedias. Dos capturas de los extremos no muestran todos los saltos de línea incómodos.
Pulsa Tab para llegar al enlace y comprueba que su posición sea evidente. Las variantes de estado permiten describir el foco; W3C explica por qué debe ser visible con teclado. Una utilidad de foco es una decisión de implementación, no una auditoría de accesibilidad. Inspecciona el resultado dibujado y la interacción efectiva.
Prepara un registro con contenido, viewport, acción y observación. Para problemas específicos de tipografía, continúa con la guía de texto Tailwind, zoom y adaptación. Conserva las incidencias junto a la muestra para que la implementación posterior no herede una suposición pendiente sin que nadie lo advierta.
Distingue la prueba en ejecución del archivo CSS
Una prueba en navegador y una hoja de estilos compilada son entregables distintos. En la primera, el paquete de navegador procesa el experimento durante la ejecución. En la segunda, el proyecto genera un archivo CSS antes de que las personas carguen la página. Trata la migración como un paso explícito de aceptación, aunque las dos pantallas parezcan iguales al principio.

Proponemos esta regla de equipo: aprobar el prototipo acepta la jerarquía y el comportamiento del contenido observado; aprobar la implementación acepta el resultado compilado en su entorno previsto. Guarda ambas decisiones por separado. Un diseñador puede aceptar los saltos de línea del título sin aprobar las dependencias de una publicación ni el enrutamiento de la aplicación.
No utilices el experimento para afirmar que la aplicación funcionará sin conexión, cumplirá un objetivo de rendimiento o satisfará una política de seguridad. Esas conclusiones necesitan comprobaciones del entorno real de entrega. Elegir un flujo u otro no implica ningún resultado de benchmark. Si la demostración exige acceso fiable sin red, define ese requisito antes de escoger su formato.
Contrasta la documentación vigente de compatibilidad de Tailwind con los navegadores reales de la audiencia. Cambiar el mecanismo de entrega no hace que una función CSS incompatible pase a ser compatible. Si importa un navegador antiguo, registra esa restricción y prueba una solución adecuada. Una demostración correcta en el navegador de quien desarrolla no debe convertirse en toda la evidencia de compatibilidad del equipo.
Traslada la muestra aceptada a una compilación
Traslada el HTML aceptado al proyecto que lo mantendrá. Para este ejercicio sencillo, el flujo oficial de Tailwind CLI ofrece una ruta directa: instala el framework y la CLI, importa Tailwind en la hoja de entrada y genera la hoja de salida. Sustituye el script del navegador por un enlace a ese archivo y mueve la definición pequeña del tema a la entrada.
Ejecuta los comandos desde la raíz del ejercicio. Sitúa index.html y course.html en src y escribe @import "tailwindcss"; al principio de src/input.css. Añade debajo el bloque del tema del curso. Genera src/output.css y apunta ambos documentos a ./output.css. Cambiar solamente la referencia de uno dejaría la otra ruta fuera de la comprobación de migración.
Después del traslado, utiliza los mismos cursos y anchuras de revisión. Compara saltos de línea, acento, foco y destino. La detección de clases de Tailwind necesita nombres que pueda encontrar en los archivos fuente; conserva cadenas de clase completas al convertir la muestra en componentes. Comprueba la equivalencia antes de ampliar el trabajo a una refactorización general.
Si la implementación final pertenece a React y Vite, sigue el flujo de instalación y comprobación CSS en React/Vite en vez de añadir otro sistema de compilación. El ejemplo aporta contenido aceptado y un caso de revisión; la aplicación elige su integración compatible.
npm install tailwindcss @tailwindcss/cli
npx @tailwindcss/cli -i ./src/input.css -o ./src/output.css --watchEntrega las evidencias con el prototipo
Entrega el prototipo con una ficha breve de evidencias. Incluye el documento fuente, la referencia visual elegida, los registros de cursos y el navegador utilizado. Añade lo observado en cada anchura. Una captura ilustra una decisión, pero el código editable y una acción reproducible permiten inspeccionarla con más facilidad cuando otra persona retoma el trabajo.

Redacta las cuestiones pendientes con un responsable. Por ejemplo: «Contenido debe aprobar el nombre largo del taller» o «Desarrollo debe comprobar el foco al moverlo a la ruta de la aplicación». Evita una etiqueta global de «responsive terminado» que oculte lo comprobado. Si un comportamiento solo aparece representado por un estado estático, indícalo junto a ese estado.
En la entrega propuesta para Fieldnote, aceptar significa que los títulos se leen, el enlace abre el documento previsto y la muestra compilada reproduce la presentación acordada. Inscripción, autenticación y datos reales son tareas futuras. Esos límites describen con precisión el ejercicio; no son carencias que haya que disimular mediante pantallas de relleno convincentes.
Mantén identificables la última prueba en navegador y el resultado compilado revisado. Nombra los archivos aceptados, añade la fecha y explica las diferencias intencionadas. El resultado útil es una decisión pequeña de interfaz que otra persona pueda reproducir e implementar. Con esas evidencias disponibles, el experimento CDN ya ha cumplido su cometido y el equipo puede continuar en el entorno de entrega.
| Entrega | Evidencia prevista | Responsable |
|---|---|---|
| Muestra HTML | Dos títulos y destino comprobado | Diseño |
| CSS compilado | Mismas acciones tras el traslado | Desarrollo |
| Pendientes | Pregunta concreta y siguiente paso | Equipo |
Pablo Mayoral
Diseñador UX/UI y Web con más de 10 años de experiencia. Creador de EmviUI (sistema de diseño en Figma con más de 10k componentes), UImand y Vitamin Bootstrap. Diseñando actualmente productos digitales en CQMRewards.