La web solo mejora con Interop 2024

Artículo original ↗ Discusión en Hacker News ↗

La iniciativa Interop 2024 de los proveedores de navegadores busca reforzar la consistencia entre navegadores, con un fuerte énfasis en funciones CSS como anidado, barras de desplazamiento, tipografía y el comportamiento de popover, que muchos ven como mejoras prácticas para el diseño y maquetación web cotidianos. Los comentaristas están divididos sobre las prioridades: algunos celebran estas mejoras de calidad de vida, mientras que otros argumentan que se están descuidando capacidades más transformadoras para las Progressive Web Apps, como el acceso fiable a archivos locales, la persistencia del almacenamiento y un soporte más amplio para la instalación de PWA, culpando a menudo a las objeciones de seguridad y privacidad de Apple y Mozilla frente a propuestas impulsadas por Google. El intercambio pone de relieve tensiones más profundas sobre la complejidad de la web, la política de la estandarización y hasta qué punto la web debería evolucionar hacia capacidades similares a las de las aplicaciones nativas frente a la preservación de la privacidad del usuario y el control de la plataforma.

Enfoque y selección de Interop 2024

  • Se considera que Interop es una coordinación útil, pero algunos sienten que muchos de los elementos elegidos (CSS, popover, correcciones de QoL) son cosas que los navegadores ya estaban implementando de todos modos, no las brechas de interoperabilidad más difíciles.
  • Otros responden que estas áreas (anidado de CSS, scroll snap, popover, IndexedDB, accesibilidad, workers) tienen un impacto amplio en el desarrollo diario y son exactamente lo que muchos desarrolladores quieren.
  • En cuanto al proceso, se describe como un pequeño grupo entre navegadores que se alinea sobre lo que pueden trabajar de manera realista junto con sus hojas de ruta normales, más orientado a armonizar el comportamiento que a forzar nuevas funciones.

PWAs, capacidades y política de navegadores

  • Varios comentaristas preguntan por qué no hay un área de enfoque dedicada a PWA; las respuestas dicen que las piezas relevantes para PWA (IndexedDB, service workers, móvil, módulos) ya están incluidas.
  • Debate sobre APIs faltantes o implementadas de forma desigual: OPFS, acceso al sistema de archivos, Trusted Types, URLPattern, módulos JSON, atributos de importación.
  • Fuerte desacuerdo sobre las motivaciones de Apple: algunos la acusan de proteger el App Store frenando las capacidades de PWA; otros dicen que Apple y Firefox están bloqueando propuestas inseguras y no estándar de Chrome (WebUSB/WebHID/WebSerial, algunas “capacidades” de PWA) por motivos de privacidad y seguridad.
  • Confusión y desacuerdo sobre qué significa “eliminar el soporte para PWA” en Firefox (APIs vs PWAs de escritorio instalables).

Almacenamiento, sistema de archivos y persistencia

  • OPFS y las APIs más amplias de acceso al sistema de archivos se consideran por algunos cruciales para que las PWA sean auténticos competidores nativos (edición local de archivos, sin almacenamiento en backend).
  • Contraargumento: las APIs de almacenamiento potentes son posibles vectores de rastreo a largo plazo; el comportamiento del almacenamiento debe alinearse con las políticas anti-rastreo.
  • La eliminación de datos en Safari tras 14 días para sitios poco visitados y la expulsión del almacenamiento no persistente frustran a los autores de aplicaciones offline-first. El almacenamiento “persistente” mediante navigator.storage.persist() se critica por ser opaco y poco fiable en la práctica.
  • Algunos sostienen que Apple y Mozilla rechazaron correctamente la especificación de acceso al sistema de archivos de Chrome por ser insegura; otros les reprochan no haber propuesto alternativas aceptables.

CSS, UI y barras de desplazamiento

  • El anidado de CSS, popover, scroll snap, subgrid, funciones de color, filtros, etc. son ampliamente aplaudidos por reducir la repetición de JavaScript y hacer que la web se sienta más “nativa”.
  • La inclusión del estilizado de barras de desplazamiento divide opiniones: algunos lo ven vital para interfaces complejas y como un compromiso para evitar barras de desplazamiento hechas en JS; otros lo ven como una personalización innecesaria impulsada por diseñadores que perjudica la usabilidad y la accesibilidad.
  • Tensión más amplia entre la consistencia de la plataforma nativa y el diseño web multiplataforma “igual en todas partes”; se citan el coste y el abandono de las toolkits nativas como impulsores del paso hacia interfaces web.

Imágenes, color, tipografía e iconos

  • La ausencia de JPEG XL decepciona a quienes lo consideran un formato de imagen técnicamente superior; sus defensores dicen que AVIF ya tiene más adopción y es “suficientemente bueno”.
  • Se señala que el soporte de color de amplia gama/P3 es desigual (Firefox limita a sRGB). Debate sobre cuán importantes son hoy realmente las pantallas de amplia gama.
  • Algunos quieren que se prioricen más funciones de tipografía CSS (por ejemplo, leading/text-box-trim, margin-trim) de forma cruzada entre navegadores.
  • Se piden favicons SVG y un manejo simplificado de iconos; las soluciones parciales de Safari y los requisitos de iconos específicos de Apple se ven como fricción para desarrolladores ocasionales.

Modelos de navegador, pruebas y áreas faltantes

  • Se critica que Safari vincule las actualizaciones del motor a las versiones del sistema operativo (especialmente en iOS), dejando hardware antiguo atrapado con funciones y errores desactualizados; sus defensores argumentan que las tasas de actualización en iOS son altas y que los parches de seguridad se retroportan.
  • Algunos critican las métricas de Interop/WPT por incluir APIs no estándar de Chrome y hacer que Safari/Firefox parezcan peores.
  • Preocupaciones sobre áreas faltantes o poco enfatizadas: WebGPU, WebAssembly GC/múltiples memorias, WebXR, controles de formulario, calidad de la separación por sílabas, Cookie Store API.
  • Discusión meta: algunos lamentan la complejidad de la web y el dominio de unos pocos motores; otros sostienen que las capacidades ricas de aplicaciones y la entrega rentable de software son ahora el papel de facto de la web. Se mencionan protocolos alternativos simples (Gemini, Spartan, Scorpion) como experimentos fuera de la web dominante.