Patrones de menú responsive: 10 técnicas CSS y HTML nativas
Compara diez maneras reales de resolver navegación responsive: desde checkbox hack y details hasta popover, dialog, aria-expanded y WAAPI.
No existe un único menú responsive correcto: la mejor solución depende del tipo de navegación, del soporte que necesitas y del peso de interacción que quieres asumir.
En esta lección no repetimos la teoría base de navbar; aquí comparamos patrones de implementación reales para que aprendas a elegir con criterio profesional.
El objetivo es que puedas distinguir cuándo conviene CSS puro, cuándo merece la pena una API nativa del navegador y cuándo un poco de JavaScript mejora accesibilidad y mantenimiento.
- Antes de elegir estilo, decide el mecanismo de apertura.
- Los diez snippets se agrupan en cuatro familias: CSS puro, HTML nativo con comportamiento integrado, JavaScript mínimo para estado y JavaScript avanzado para animación.
- CSS puro es ideal para menús simples y demos rápidas, pero puede quedarse corto cuando necesitas cerrar con clic externo, coordinar alturas dinámicas o sincronizar varios estados.
- Las APIs nativas como <code>details</code>, <code>dialog</code> y <code>popover</code> reducen código y resuelven parte de la accesibilidad por ti. Son una gran opción cuando el soporte del navegador encaja con tu proyecto.
- Más limpios de mantener cuando la navegación no exige lógica compleja.
Cuatro familias de solución
Antes de elegir estilo, decide el mecanismo de apertura.
Los diez snippets se agrupan en cuatro familias: CSS puro, HTML nativo con comportamiento integrado, JavaScript mínimo para estado y JavaScript avanzado para animación.
CSS puro es ideal para menús simples y demos rápidas, pero puede quedarse corto cuando necesitas cerrar con clic externo, coordinar alturas dinámicas o sincronizar varios estados.
Las APIs nativas como <code>details</code>, <code>dialog</code> y <code>popover</code> reducen código y resuelven parte de la accesibilidad por ti. Son una gran opción cuando el soporte del navegador encaja con tu proyecto.
Patrones sin JavaScript o casi sin JavaScript
Más limpios de mantener cuando la navegación no exige lógica compleja.
Aquí entran el checkbox hack, <code>:has()</code>, <code>details</code> y los menús que simplemente reordenan enlaces con Grid sin colapsar en hamburguesa.
Su ventaja principal es que el estado visual vive en HTML y CSS, así que el componente es fácil de inspeccionar, testear y portar a otros proyectos.
La contrapartida es que, en interacciones más ricas, el patrón puede volverse rígido o difícil de extender sin acabar metiendo JS igualmente.
- Checkbox hack y :has() funcionan bien cuando solo necesitas abrir y cerrar.
- details y summary son especialmente útiles para contenido desplegable simple.
- Grid sin hamburguesa tiene sentido si el menú puede recolocarse sin perder legibilidad.
Patrones con JavaScript mínimo o expresivo
Úsalos cuando la interacción aporta valor real, no por inercia.
Los snippets con <code>aria-expanded</code>, <code>classList</code> y medición de alturas enseñan un JS pequeño pero muy práctico: sincronizar atributos, animar estados y mantener accesibilidad.
WAAPI ya es otro nivel: no se limita a poner clases, sino que define keyframes desde JS para controlar entrada, salida y ritmo con más precisión.
La clave profesional es que el estado siga siendo entendible. Si el usuario y tú no podéis deducir de dónde sale la apertura del menú, el patrón no escalará bien.
Cómo elegir el patrón correcto
La decisión se toma por restricciones, no por estética.