Acerca de hacer un fork de la Web

 (dillo-browser.org)
1 puntos por GN⁺ 1 시간 전 | 1 comentarios | Compartir por WhatsApp
  • El objetivo de la especificación alternativa no es abarcar toda la Web, sino tomar primero como objetivo la especificación HTML, cuyo tamaño descomprimido era de 18.3MiB al 6 de mayo de 2026, manteniendo las ventajas de la Web y evitando sus desventajas
  • La especificación debe ser corta y simple, y debe reducir la carga de implementación —por ejemplo, limitando a 1.44MiB el tar.gz comprimido que contiene la especificación completa— para permitir la aparición de diversos navegadores y clientes
  • En lugar de ser un documento que cambia constantemente como la actual Web specification, debe tener una versión semántica como 1.2.3, y una versión del estándar publicada nunca debe modificarse
  • La especificación debe incluir una gramática formal no ambigua que sea fácil de analizar, y las páginas que no cumplan el estándar no deben renderizarse, para reducir el costo de crear parsers y herramientas de contenido
  • La especificación alternativa no busca replicar la Web función por función, sino el intercambio de información centrado en texto escrito, y prefiere abrir archivos y URL estandarizados en programas nativos, como con Geo link o el estándar de tiled web map, en lugar de usar scripting

Objetivos de una especificación alternativa para la Web

  • La especificación HTML tiene un tamaño descomprimido de 18.3MiB al 6 de mayo de 2026, y el alcance inicial de revisión se limita a la especificación HTML, no a toda la Web
  • El objetivo es crear una especificación alternativa que conserve en lo posible las ventajas de la Web mientras evita sus desventajas
  • Aún no es una especificación formal, sino más bien una nota informal que puede cambiar con el tiempo

Simplicidad y diversidad de implementaciones

  • La especificación completa debe ser corta y simple, y debe ser posible crear diversos navegadores y clientes con poco esfuerzo
  • Como es muy difícil mantener la simplicidad durante décadas, una posible forma es imponer una regla que limite la longitud de la especificación por cantidad de bytes
  • Dillo usa el mismo enfoque para que sus lanzamientos quepan en un solo disquete, y la especificación alternativa también podría imponer un límite de 1.44MiB sobre el tar.gz comprimido que contiene la especificación completa

Versionado semántico

  • La actual Web specification es una página que cambia aproximadamente cada semana, por lo que los clientes deben seguir esos cambios constantemente para ajustarse a la especificación
  • La especificación alternativa debe tener una versión semántica precisa, como 1.2.3
  • Se necesita un criterio de compatibilidad del tipo: un documento 1.2.3 puede renderizarse correctamente en navegadores que soportan 1.2.3, 1.2.0 y 1.3.0, pero no necesariamente en navegadores que solo soportan 1.1.0 o 2.0.0
  • El objetivo al escribir documentos no debe ser el estado de implementación de cada navegador, sino una versión del estándar; por ejemplo, se podría escribir para la versión 1.2.0 bajo el supuesto de que el 90% de los navegadores la soportan
  • Una versión del estándar, una vez publicada, nunca debe modificarse
    • Las correcciones de erratas se manejan aumentando la versión de parche
    • Las funciones nuevas compatibles hacia atrás se manejan aumentando la versión menor
    • Los cambios que rompen compatibilidad requieren aumentar la versión mayor
  • Incluso con solo una copia impresa del estándar 1.2.0, debería ser posible crear en un entorno aislado un navegador totalmente conforme, y ese navegador debería poder analizar correctamente para siempre los documentos 1.2.X

Gramática estricta

  • La especificación debe incluir una gramática formal no ambigua que sea fácil de analizar
  • Las páginas deben probarse contra el estándar para determinar si lo cumplen, y las que no lo cumplan no deben renderizarse
  • Debe prohibirse explícitamente que los clientes acepten páginas que no sigan la especificación
  • Así no haría falta implementar reglas estandarizadas complejas para arreglar páginas rotas, y además se fuerza a que los errores de la especificación se corrijan en versiones posteriores
  • Una gramática estricta probablemente empujaría a usar lenguajes más fáciles de escribir para humanos y más permisivos, por ejemplo Markdown, y ese es un efecto intencional
  • El objetivo es simplificar los parsers y reducir el costo de crear herramientas que manipulen contenido
  • Los cambios de versión de parche solo modifican la redacción; la gramática permanece igual

Posibilidad de reutilizar HTML

  • Sería deseable poder crear un subconjunto de HTML que funcione en software existente con un esfuerzo mínimo
  • Sin embargo, puede que no sea posible debido a la complejidad del parsing de HTML
  • Como tampoco es simple crear una gramática formal para documentos XML, hace falta evaluar si HTML/XML son formatos adecuados para un parsing sencillo

Resistencia a la captura del estándar

  • Uno de los problemas de la Web es que, cuando actores monopolísticos pueden crear mecanismos de extracción de rentas, surge el incentivo de capturar el estándar y modificarlo a su favor
  • En la Web, se considera que eso llevó a que la complejidad del estándar creciera sin control, aumentara la barrera de entrada para nuevos navegadores y disminuyera la competencia
  • Hay algunas ideas iniciales para evitar esta situación, pero se necesita una revisión más cuidadosa desde la teoría de juegos

Principio de texto primero

  • El propósito de la especificación es cubrir los detalles suficientes para transmitir información entre personas, como en un libro o un escrito impreso
  • El texto escrito debe priorizarse como el medio más versátil para codificar información
  • El texto puede traducirse, la computadora puede leerlo en voz alta y puede almacenarse usando poco espacio
  • Los documentos deben ajustar los saltos de línea al tamaño de la pantalla, de modo que el mismo documento pueda leerse tanto en pantallas pequeñas como grandes

Exclusión del scripting

  • Agregar capacidades de scripting fue un error, por lo que puede evitarse en la especificación alternativa
  • Eso no significa limitar el uso de programas interactivos por parte del usuario
  • Por ejemplo, hoy se carga con JavaScript un mapa interactivo dentro del navegador para mostrar la ubicación de un punto de interés, pero en su lugar se podría proporcionar un Geo link para abrir esa ubicación en cualquier cliente que soporte ese protocolo
  • Del mismo modo, si existe una especificación pública, cualquier cliente podría usar los mosaicos de mapa del servidor; como ejemplo relacionado se menciona el estándar de tiled web map
  • Abrir archivos o URL estandarizados en programas nativos puede optimizarse según el dispositivo en uso y evitar el enfoque uniforme de muchas páginas web interactivas

Lo que no es el objetivo

  • El objetivo no es replicar la Web función por función
  • El objetivo es crear una especificación que permita a las personas intercambiar conocimiento, notas y otra información, pero eliminando la necesidad de ejecutar una VM completa para poder leerla

Lecturas relacionadas

1 comentarios

 
GN⁺ 1 시간 전
Opiniones en Lobste.rs

  • ¿Entonces de nuevo necesitamos apps para todo? No estoy de acuerdo con que la funcionalidad de scripts en sí haya sido un error.
    Me parece bien que la web sea una plataforma de propósito general que cruza los límites del sistema operativo.

    • Pienso igual. Se dice que la ventaja de abrir archivos o URL estandarizados con programas nativos es que se optimizan para cada dispositivo y evitan el enfoque de páginas web de “una sola talla para todos”, pero no quisiera volver a la época en que los usuarios de Linux eran ciudadanos de segunda.
      Hablo de cuando solo se soportaba Windows y a veces se agregaba Mac.
    • Se puede criticar mucho a las web apps, pero también son casi la única forma de evitar el impuesto de Apple y el futuro impuesto de Google al distribuir apps en plataformas móviles.
      Y como la situación del desarrollo nativo de escritorio tampoco es sencilla, entiendo perfectamente a quienes eligen web apps o Electron en escritorio.
    • ¿Por qué tendría que haber una app para todo? Esta especificación no impide ejecutar navegadores web normales ni significa que la web actual vaya a desaparecer.
    • Creo que el punto realmente adecuado es encontrar hasta dónde se puede llegar solo con markup estandarizado.
      El problema de la web moderna es que reinventa conceptos sin parar, y buena parte de eso debería ser markup declarativo. No debería hacer falta que JavaScript se meta en la ruta de renderizado de un sitio web. El scripting debería usarse para programación específica del lado del cliente cuando se hace en el cliente algo que antes se hacía en el servidor, por ejemplo procesar un conjunto de datos devuelto por el servidor.
    • En realidad ya hay apps para todo. Solo que en vez de apps las llamamos URL o nombres de dominio.
      Da la impresión de que la industria IT empujó al navegador web como máquina virtual de facto cuando quedó claro que alternativas sandbox como Java con Swing o Flash eran dolorosamente inferiores. Ahora una sola aplicación, Google Chrome, hace de máquina virtual para la mayor parte de la computación general del usuario, y además pertenece y es desarrollada por una empresa monopolística de capitalismo de vigilancia. No sé si eso de verdad es más seguro, o si simplemente los zero-day reales son demasiado caros como para hacerse públicos.
      Sí creo que agregar scripting fue un error. Al menos fue una función añadida después, y coincido con Dillo en mantener el alcance de un lector de documentos de hipertexto en leer documentos, sin intentar que dentro del lector también se puedan escribir y editar documentos.
      La meta no es duplicar la web por funcionalidad, sino crear una especificación que pueda leerse para intercambiar conocimiento, notas e información sin exigir ejecutar una máquina virtual de tamaño completo.
      Me gustaría ver una aplicación de propósito general reducida que maneje la mayoría de las necesidades de “interacción” dentro de un sandbox mejor. ¿De verdad hace falta una máquina virtual completa para intercambiar hipertexto en un feed de redes sociales como Reddit? ¿Y también para manejar un carrito de compras y datos de pago?
      Claro, es muy probable que “de propósito general” termine devorando a la “aplicación”, y en ese punto se vuelva a inventar la web. Aun así, si hubiera la posibilidad de que se base en algo que no sea Google y en un lenguaje que no sea C++, quizá sería mejor. Dillo parece ser C y C++, así que supongo que ya mejoró al menos una de las dos cosas.

  • Otra mejora posible sería usar una versión reducida de HTTP, pero con soporte solo para cookies de sesión controladas por el cliente, prohibiendo recursos de terceros y poniendo todos los recursos en el mismo servidor web que el documento, además de exigir renderizado de formatos como text/markdown mediante un convertidor interno del navegador.

    • Prohibir recursos de terceros por sí solo ya evitaría varios problemas graves.
    • Idealmente me gustaría que fuera independiente del medio de transporte. Probablemente intentaría primero con archivos locales para que funcione desde cualquier punto de montaje de un sistema de archivos remoto.
      Esta vez la idea sería mejorar la dieta para ver si podemos evitar las cookies. Esto es una representación mecánica del documento; está diseñada para que un humano la lea, pero no para que la escriba directamente. En vez de eso, sería mejor usar un lenguaje frontend como Markdown y compilarlo a un documento estricto y portable.
    • Mi propuesta sería que, si las cookies son realmente necesarias, se apliquen solo al dominio exacto del sitio. Una cookie de example.net no debería enviarse a sub.example.net, y una cookie de sub.example.net tampoco debería poder configurarse en example.net.
      HTTP/2 y HTTP/3 deberían quedarse en la web de aplicaciones, y HTTP/1 en la web de documentos. No sé cómo habría que restringir JavaScript para evitar el problema de “necesitas un navegador especial para ver mi contenido”, así que no debería haber JavaScript.
      Si se exige renderizado de text/markdown, también surge el problema de qué versión se quiere decir. Hay como media docena de variantes que habría que soportar.

  • Una gramática estricta probablemente no funcione. Esa es también la razón por la que XHTML fracasó, y por la que HTML5 agregó reglas para manejar las “roturas” comunes.
    Se podría volver a especificar HTML5 con una gramática más formal, como quiere el autor, pero rechazar páginas de forma estricta no parece un buen uso de un fork. La otra alternativa sería convertirse en otro reemplazo tipo gopher/gemini, y si bien tienen una base de fans entusiasta, hay razones por las que no son populares. La fuerza de la compatibilidad hacia atrás es demasiado grande.

    • No estoy de acuerdo con que XHTML fracasara por ser estricto. El hecho de que IE no soportara XHTML hasta 2011 fue demasiado tarde, y por eso la gente no usó XHTML real ni obtuvo sus ventajas.
      La estrictez puede ser muy buena, pero necesita soporte para funcionar.

  • La idea de que “agregar scripting fue un error” ha sido un meme viejo entre cierto tipo de programadores deprimentes que no permiten la diversión, pero me parece más bien falta de imaginación.
    La multimedia interactiva aplicada con cuidado puede mejorar muchísimo la comunicación y la explicación. Basta ver, por ejemplo, los diagramas interactivos del tutorial de cuadrículas hexagonales de Red Blob Games o la fantástica explicación del movimiento de un reloj mecánico de Bartosz Ciechanowski. Gracias a los medios interactivos de la web, incluso una computadora rara e históricamente importante como Canon Cat se puede probar en segundos con un clic, sin el procedimiento de pesadilla de compilar y ejecutar un emulador nativo. Los envíos de formularios y los mapas de imagen son apenas una sombra muy tenue de la multimedia, y trasladan la carga del soporte interactivo a un modelo intrínsecamente centrado en el servidor y potencialmente intensivo en ancho de banda.
    El problema no es el scripting en sí, sino las cosas que hoy se permite hacer al scripting en los navegadores. Así como HTTP y HTML podrían reducirse a un sistema más pequeño, simple y respetuoso de la autonomía del usuario, también podría mantenerse la mayor parte de lo positivo del JavaScript web reduciendo mucho la superficie de APIs y el potencial de abuso. Por ejemplo, se podría imaginar una web donde haya dentro de una página un rectángulo interactivo tipo Flash, cuya interacción esté dada por scripts Lua accesibles e inspeccionables por el usuario y capacidades gráficas y de entrada como Love2D, mientras que acciones invasivas para la privacidad como contactar servidores remotos o acceder a la webcam queden detrás de un sandbox fuerte y del consentimiento explícito previo del usuario.
    Aun hoy se pueden crear aplicaciones web respetuosas de esa manera, pero la base es irregular e inconsistente, y por todas partes hay omisiones evidentes de funciones útiles y amenazas innecesarias para la seguridad y privacidad del usuario.
    Desde una visión de accesibilidad, podría imaginarse un formulario del lado del cliente que trate de forma estricta entradas declarativas de UI como botones, campos, casillas y sliders, y que renderice imágenes y markup dentro de un <iframe> como si fuera una página estática, pero funcionando sin ida y vuelta a un servidor remoto. Muchos tipos de calculadoras, herramientas y visualizaciones interactivas cabrían en ese modelo, con mejor latencia y mejor seguridad para el usuario que en un modelo guiado por backend.

  • Si la idea es “texto primero”, entonces también habría que soltar CSS. CSS existe en gran medida para las empresas, no para los usuarios. El estilo debería controlarlo el navegador, no la página.
    Si el usuario decide leer la carga útil cruda de la página, la mayor parte de ella debería coincidir con la información que el navegador le mostró para leer. Hoy el contenido legible es apenas la punta del iceberg.
    En cuanto a “sin scripting”, sospecho que si se quitan los estilos y las páginas pesadas, también se podría reducir mucho la necesidad de scripting que afecta la forma en que se muestra algo. El scripting que no afecta la visualización, por lo general, se ha usado en contra del interés del usuario.

    • Ese era justamente el núcleo original de la cascada de CSS. Había un subconjunto razonable de CSS utilizable para el formato de libros y papers, y estaba pensado para fusionarse con estilos del usuario.
      Pero CSS y el formato se volvieron demasiado complejos, y ahora los estilos del usuario tienen que empezar con un reset completo de CSS o ser muy específicos para cada sitio.
    • Si quieres mostrar una marca de tiempo según la zona horaria del lector, hoy no hay forma de hacerlo sin scripting del lado del cliente.
      Me topé con esto al hacer una herramienta personal para el cliente sin JS, y me di cuenta de que tenía que guardar “mi configuración de zona horaria” en el servidor o agregar un pequeño script auxiliar.
      Si dejas que el navegador controle el estilo, parece que podrían empeorar más que ahora problemas como “mi página se puede leer en los navegadores X y Y, pero no en Z”.
    • Yo viviría feliz en un mundo lleno de CSS, colores y fondos vistosos, buenas tipografías, layouts con flexbox y grid.
      Me parece mejor eso que ver solo documentos sosos donde la voz del autor queda lavada en texto negro sobre fondo blanco. CSS es la forma de expresión del autor en la web, y de verdad no quisiera que desapareciera. Sí, es complejo, pero justamente eso también me parece bueno, porque permite que más personas hagan cosas interesantes en sus propios sitios web.
    • De acuerdo. Habría que investigar más antes de prohibir los estilos opcionales del autor.
      También comparto la sensación de que, si se quitan el estilo y las páginas pesadas, disminuiría la necesidad de scripts para cambiar la visualización. Si hubiera una gramática simple, podría pasar que se incrusten “documentos” dentro de programas nativos interactivos, en vez de al revés.

  • Como dicen otros, Gemini me parece un buen ejemplo de referencia. Otra vez, Gemini se siente como performance art, pero realmente tiene mucho de lo que se puede aprender.
    Una función notable de Gemini que no es lo bastante conocida son las páginas suscribibles. Dentro de una página, los enlaces cuyo texto empieza con YYYY-MM-DD forman un feed implícito. Es muy limitado y hasta parece tonto, pero me parece una de las funciones más impresionantes de Gemini. Spec here
    En el HTML tradicional, escribir un blog a mano es posible. Es tedioso, pero totalmente viable. Pero para mantener un feed RSS/ATOM casi siempre necesitas alguna herramienta que lo genere.
    Si hubiera un HTML de próxima generación “orientado a contenido”, estaría bien incluir algo parecido. Quizá h-feed en microformats sea la manera correcta, pero me encanta la simplicidad que da el modelo de páginas suscribibles de Gemini. Y los feeds por todos lados son algo bueno.
    El hecho de que Gemini sea orientado a líneas y fácil de parsear es una gran ventaja, aunque siento que es demasiado limitado y podría tener efectos negativos en accesibilidad. Aun así, un HTML-lite que se pareciera a Gemini podría estar bien.
    Otro beneficio que podría traer un fork de la web es ordenar todas las cosas que se le fueron añadiendo a HTML. <meta name="viewport" content="width=device-width, initial-scale=1.0"/> es bastante molesto. Si se hiciera una nueva versión con lo que sabemos hoy, hay una buena posibilidad de que quedara bastante bien.
    Sobre otras partes tengo menos certeza. En principio estoy totalmente a favor de no tener JS. Solo que uno de los mejores usos de la web es el acceso universal a servicios esenciales como gobierno y banca. Aún no estoy completamente convencido de que realmente se pueda hacer todo eso sin JS y mantener buena usabilidad, aunque quizá sí sea posible.
    También quiero subrayar otro comentario que dice: “esta especificación no impide ejecutar navegadores web normales, ni significa que la web actual vaya a desaparecer”.
    Estaría bien poder ejecutar por separado un “navegador web de contenido” y un “navegador de apps”. Para muchos propósitos no hay muchas alternativas tan buenas como la web como plataforma de apps, la web ha avanzado muchísimo y parece que los desarrolladores la prefieren bastante sobre otras opciones.
    En un mundo así, Google Maps no funcionaría en mi navegador web de contenido y se abriría en el navegador de apps. Si ejecuto GMail en el navegador de apps, los enlaces dentro del correo se abrirían en el navegador web de contenido.
    Idealmente, un navegador web de contenido debería ser mucho más fácil de implementar, y eso fomentaría la competencia y la innovación. Pero da pena que no se vea una ruta clara para lograrlo. Sería mucho más feliz si pudiera explorar todo el contenido con un navegador así. La superficie de ataque sería muchísimo menor, así que me sentiría más tranquilo en términos de seguridad. Pero parece que ya a nadie le importa.

    • Casi todos los casos legítimos de uso de JS en páginas web existen porque al navegador le faltan funciones importantes. Llevamos décadas aprendiendo eso, y gracias al scripting el navegador no ha tenido que agregarlas.
      Así que simplemente hay que agregarlas como funciones del navegador.

  • Suena un poco parecido a Gemini, pero este fork probablemente permitiría un poco más.
    Creo que los sitios web podrían escribirse en alguna variante de Markdown o algo similar. Deberían ser documentos fáciles de leer incluso en su forma cruda. Algo así como Gemtext con unas cuantas funciones extra, como medios embebidos en línea.
    Y también debería permitirse un poco de estilo. La web fue y sigue siendo un gran lugar para la creatividad. Si se mantiene un conjunto de estilos simple y consistente, la gente creativa podrá hacer sitios aún más ingeniosos.

  • También estaría bien abordar los elementos básicos de HTMX.

    • Personalmente preferiría que solo se incorporaran primitivas tipo Triptych. Ofrecen lo suficiente para construir del lado del servidor sin volver excesivamente complejo al cliente.

  • Creo que esta idea funcionaría mejor si tuviera una motivación clara. “Hagámoslo simple” es demasiado abstracto. Como cada quien entiende algo distinto por simplicidad, hace falta una meta más explícita sobre por qué la web debería ser más simple y qué necesidad concreta estaría cubriendo.
    Por ejemplo, el proyecto Gemini se enfoca en crear una comunidad que valora una forma específica de comunicación. Como su objetivo va por ahí, simplificó la web restringiéndola a ese formato de comunicación, y si mal no recuerdo ni siquiera soporta imágenes técnicamente.
    En cambio, herramientas como Sciter o Blitz buscan facilitar la integración de un renderizador tipo navegador dentro de otras aplicaciones. Simplifican eliminando comportamientos extraños innecesarios o haciendo opcional el parseo de HTML y la ejecución de JS. Así hay menos que implementar y menos que incrustar para quien las usa.
    Ambas apuntan a la simplicidad, pero como sus objetivos fundamentales son muy distintos, el resultado también cambia mucho. ¿Cuál es aquí el objetivo fundamental?