# TAILWIND_CONVENTIONS

## Objetivo

Definir reglas base para construir el nuevo frontend con `TailwindCSS` sin repetir los problemas del frontend actual.

## Principio general

Tailwind debe ser el sistema principal de estilos nuevos.

Evitar:

- estilos inline nuevos,
- bloques `<style>` grandes dentro de las vistas,
- mezcla innecesaria entre Bootstrap y Tailwind en componentes nuevos,
- y clases utilitarias desordenadas sin criterio comun.

## Alcance inicial

Estas convenciones aplican primero al rediseno de `Home`.

## Regla de migracion

Mientras exista codigo legacy:

- se permite convivencia temporal con Bootstrap y CSS previo,
- pero toda seccion nueva o redisenada debe escribirse prioritariamente con Tailwind

## Convenciones de estructura

- Usar clases utilitarias legibles y agrupadas por funcion:
  - layout
  - spacing
  - size
  - typography
  - color
  - state
- Si una cadena de clases se vuelve inmanejable, considerar extraer un parcial o componente, no volver al CSS inline por reflejo

## Convenciones de layout

- Priorizar `container`, `max-w-*`, `mx-auto`, `px-*`, `py-*`, `grid`, `flex`
- Definir ritmo vertical consistente por seccion
- Evitar widths fijos innecesarios salvo que Figma lo exija claramente
- Pensar primero en responsive real, no en desktop estatico

## Convenciones tipograficas

- Centralizar familias, pesos y escalas
- No hardcodear estilos tipograficos distintos para cada bloque sin razon
- Respetar jerarquia clara:
  - heading principal
  - heading de seccion
  - body
  - caption
  - CTA

## Convenciones de color

- Los colores del nuevo sistema deben definirse una sola vez al integrar Tailwind
- No duplicar hexadecimales arbitrarios por toda la vista
- Si Figma introduce nuevos tokens, registrarlos antes de dispersarlos en markup

## Convenciones de componentes

- Extraer parcial cuando:
  - un bloque se reutiliza,
  - tiene variantes,
  - o su markup ensucia demasiado la vista principal
- Mantener en la vista principal solo la composicion de secciones

## Convenciones de estados

Todo componente interactivo debe contemplar:

- `hover`
- `focus`
- `active`
- `disabled` si aplica
- responsive

## Convenciones para contenido dinamico

- No asumir longitud fija de textos
- No depender de alturas magicas para contenido proveniente de BD
- Proteger cards, hero y CTA contra overflows o textos mas largos

## Lo que no queremos repetir del frontend actual

- CSS incrustado por componente sin estandar comun
- estilos mezclados con estructura de forma dificil de mantener
- comportamiento visual dependiente de hacks por breakpoint

## Checklist rapido antes de cerrar una seccion

- Usa Tailwind como base principal
- No depende de medidas fragiles
- Funciona en mobile y desktop
- Tolera contenido dinamico
- Mantiene consistencia con el resto del Home