HTML Puede Hacer Eso

Capacidades y límites de los widgets nativos de HTML

• Muchos se impresionan por cuánta interactividad ya es posible con “solo HTML” más CSS (diálogos, popovers, details, transiciones de vista).
• Otros subrayan que algunas funciones aún están “casi ahí”: por ejemplo, datalist carece de fuertes restricciones de valor, búsqueda difusa y tiene un soporte irregular entre navegadores.
• Los selectores de fecha nativos son ampliamente criticados por ser defectuosos, inconsistentes entre navegadores/SO y por romperse con facilidad por gestores de contraseñas.

Contenido oculto, <details> y capacidad de búsqueda

• hidden="until-found" y <details> reciben elogios por permitir que CTRL+F revele contenido plegado (FAQs, organigramas, contenido con pestañas).
• Los casos de uso incluyen paneles de “ver términos/exclusiones”, árboles plegables y patrones de “saltar al contenido” (aunque eso se resuelve mejor con estilo de foco).
• Hay debate sobre el comportamiento agrupado/de acordeón: algunos quieren que solo un <details> esté abierto; otros (citando investigación de UX) encuentran frustrante el cierre automático.

SPAs, JavaScript y enfoques “HTML-first”

• Varios usuarios usan NoScript y juzgan los sitios por cuánto JS de terceros requieren; aprecian los sitios que funcionan mayoritariamente sin JS.
• A muchos no les gustan las SPAs por romper las URLs, el botón de atrás y los marcadores; otros señalan que esto puede resolverse con enrutado adecuado y actualizaciones de URL.
• Hay entusiasmo por patrones de “renderizado en servidor con chispas” (HTMX, JS mínimo, View Transition API) y experimentos con UIs completamente sin JS.

Diálogos, popovers y acciones declarativas

• Los nuevos atributos de popover/diálogo/comando reciben elogios por foco consistente, apilamiento, accesibilidad y menús/tooltip/confirmaciones sin JS.
• Los críticos ven la API de acciones declarativas (popovertarget, ...action) como una complicación excesiva de HTML frente a simples manejadores de eventos en JS.
• Los defensores argumentan que permite un tiempo hasta interactivo más rápido, mejor SSR e interactividad sin scripts; los atributos de script pueden deshabilitarse, haciendo útiles los enlaces declarativos.

Tablas, ordenación y diseño frente a semántica

• Algunos quieren tablas ordenables nativas e incluso virtualización integrada; otros insisten en que “para eso está JS” y temen el hinchamiento del navegador.
• Se defiende la ordenación del lado del servidor mediante enlaces en los encabezados por ser simple y seguir siendo eficiente; otros quieren ordenación multicolumna sin recarga.
• Un debate lateral: HTML como estructura/semántica frente a diseño. Algunos sostienen que las etiquetas describen implícitamente el diseño; otros citan especificaciones que dicen que el diseño pertenece a CSS.

Fechas, formularios y localización

• Se piden formatos de fecha ISO forzados o alineados con lang de la página; los formatos nativos del SO confunden a usuarios y flujos de trabajo administrativos.
• Sugerencias: hacer que <time> realmente localice la visualización, o siempre enviar ISO mientras se muestran formatos localizados de forma consistente.

Compatibilidad del navegador, adopción y herramientas

• Preocupa que el creciente alcance de los estándares haga difícil construir nuevos motores; algunos dudan en adoptar nuevas funciones incluso cuando están soportadas.
• Se dice que los LLM y generadores de código van por detrás en nuevas APIs de HTML/CSS, reforzando patrones antiguos muy basados en JS, aunque “skills” y guías podrían mitigar esto.

Notas misceláneas

• Se discuten las imágenes responsivas (srcset, <picture>); <picture> se ve como más flexible que srcset por sí solo.
• Controles nativos como <select> y los selectores de color están infrautilizados en parte porque es difícil darles estilo uniforme entre plataformas.