Sobre fazer um fork da Web

• O objetivo da especificação alternativa não é a Web inteira, mas priorizar a especificação HTML, que em 6 de maio de 2026 tinha tamanho descompactado de 18.3MiB, preservando as vantagens da Web e evitando seus pontos negativos
• A especificação deve ser curta e simples, e deve reduzir o custo de implementação para permitir o surgimento de vários navegadores e clientes, por exemplo limitando a tar.gz compactada com a especificação completa a 1.44MiB
• Em vez de ser um documento em constante mudança como a atual Web specification, ela deve ter versionamento semântico como 1.2.3, e uma versão de padrão publicada nunca deve ser alterada
• A especificação deve incluir uma gramática formal não ambígua e fácil de analisar, e páginas fora do padrão não devem ser renderizadas, reduzindo o custo de criar parsers e ferramentas de conteúdo
• A especificação alternativa não busca replicar a Web funcionalidade por funcionalidade, mas sim a troca de informações centrada em texto escrito, preferindo abrir arquivos e URLs padronizados em programas nativos em vez de scripting, como no padrão Geo link ou no padrão de tiled web map

---

Objetivos de uma especificação alternativa para a Web

• A especificação HTML tinha tamanho descompactado de 18.3MiB em 6 de maio de 2026, e o alvo inicial de análise não é a Web inteira, mas sim a especificação HTML
• O objetivo é criar uma especificação alternativa que preserve ao máximo as vantagens da Web enquanto evita seus problemas
• Ainda não se trata de uma especificação formal, mas mais de notas informais que podem mudar com o tempo

Simplicidade e diversidade de implementações

• A especificação completa deve ser curta e simples, e deve ser possível criar vários navegadores e clientes com pouco esforço
• Como é muito difícil manter a simplicidade por décadas, uma possível abordagem é impor uma regra que limite o tamanho da especificação em bytes
• O Dillo usa o mesmo método para fazer suas releases caberem em um único disquete, e a especificação alternativa também poderia impor um limite de 1.44MiB com base no tar.gz compactado contendo toda a especificação

Versionamento semântico

• A atual Web specification é uma página que muda aproximadamente toda semana, o que obriga clientes a acompanhar mudanças contínuas para seguir a especificação
• A especificação alternativa deve ter versionamento semântico exato, como 1.2.3
• É necessário um critério de compatibilidade no qual, por exemplo, um documento 1.2.3 possa ser renderizado corretamente em navegadores que suportem 1.2.3, 1.2.0 ou 1.3.0, mas não em navegadores que suportem apenas 1.1.0 ou 2.0.0
• O alvo da escrita de documentos deve ser a versão do padrão, e não o estado de implementação por navegador; por exemplo, seria possível produzir conteúdo voltado para a versão 1.2.0 com base na premissa de que 90% dos navegadores a suportam
• Uma versão do padrão publicada nunca deve ser alterada
  • Correções de typos devem ser tratadas com aumento da versão de patch
  • Novos recursos compatíveis com versões anteriores devem ser tratados com aumento da versão minor
  • Mudanças que quebram compatibilidade exigem aumento da versão major
• Mesmo tendo apenas uma cópia impressa do padrão 1.2.0, deve ser possível criar em um ambiente isolado um navegador totalmente compatível, e esse navegador deve conseguir analisar corretamente documentos 1.2.X para sempre

Gramática estrita

• A especificação deve incluir uma gramática formal não ambígua e fácil de analisar
• As páginas devem ser testadas em relação ao padrão para determinar conformidade, e páginas que não estejam em conformidade não devem ser renderizadas
• É explicitamente proibido que clientes aceitem páginas que não sigam a especificação
• Isso elimina a necessidade de implementar regras padronizadas complexas para consertar páginas quebradas e força que erros da especificação sejam corrigidos em versões futuras
• Uma gramática estrita provavelmente levará à adoção de linguagens mais fáceis para humanos escreverem e mais tolerantes, como Markdown, e esse é um efeito intencional
• O objetivo é simplificar parsers e reduzir o custo de criação de ferramentas para manipular conteúdo
• Mudanças de versão patch alteram apenas a redação, mantendo a gramática inalterada

Possibilidade de reutilizar HTML

• Seria desejável criar um subconjunto de HTML que funcione em software existente com esforço mínimo
• No entanto, isso pode não ser possível por causa da complexidade do parsing de HTML
• Como até criar uma gramática formal para documentos XML não é algo simples, é necessário avaliar se HTML/XML são formatos adequados para parsing simples

Resistência à captura do padrão

• Um dos problemas da Web é que, quando entidades monopolistas podem criar mecanismos de extração de renda, surge um incentivo para capturar o padrão e alterá-lo em benefício próprio
• Na Web, isso teria levado a uma complexidade do padrão fora de controle, aumentado a barreira de entrada para novos navegadores e reduzido a concorrência
• Existem algumas ideias iniciais para evitar esse cenário, mas elas exigem uma análise mais cuidadosa do ponto de vista da teoria dos jogos

Princípio do texto em primeiro lugar

• O objetivo da especificação é tratar dos detalhes suficientes para transmitir informações entre humanos, como um livro ou texto impresso
• Texto escrito deve ter prioridade por ser o meio mais versátil de codificar informação
• O texto pode ser traduzido, pode ser lido em voz alta por computadores e pode ser armazenado usando pouco espaço
• Os documentos devem quebrar linha de acordo com o tamanho da tela, para que o mesmo documento possa ser lido tanto em telas pequenas quanto grandes

Exclusão de scripting

• Adicionar capacidades de scripting foi um erro, então isso pode ser evitado na especificação alternativa
• Isso não significa limitar o uso, pelo usuário, de programas interativos
• Por exemplo, hoje um mapa interativo que mostra a localização de um ponto de interesse é carregado no navegador com JavaScript, mas em vez disso seria possível fornecer um Geo link para abrir a localização em qualquer cliente que suporte esse protocolo
• Da mesma forma, se houver uma especificação pública, qualquer cliente poderá usar os tiles de mapa de um servidor; um exemplo relacionado é o padrão de tiled web map
• Abrir arquivos ou URLs padronizados em programas nativos pode ser otimizado para o dispositivo em uso e evitar a abordagem uniforme de muitas páginas web interativas

O que não é objetivo

• O objetivo não é replicar a Web funcionalidade por funcionalidade
• O objetivo é criar uma especificação que permita a humanos trocar conhecimento, notas e outras informações, eliminando a exigência de executar uma VM completa apenas para ler esse conteúdo

[GN⁺]

Opiniões no Lobste.rs

• Então isso significa que vamos precisar de aplicativos para tudo de novo? Não concordo que a capacidade de scripting em si tenha sido um erro
  Acho bom que a web seja uma plataforma de uso geral que atravessa as fronteiras dos sistemas operacionais

  • Penso a mesma coisa. Dizem que a vantagem de abrir arquivos padronizados ou URLs em programas nativos é a otimização para cada dispositivo e evitar a abordagem de página web “única para todo mundo”, mas não quero voltar à época em que usuários de Linux eram cidadãos de segunda classe
    Aquela época em que só havia suporte para Windows e, às vezes, adicionavam Mac
  • Dá para reclamar bastante dos web apps, mas eles também são quase a única forma de evitar o imposto da Apple e o futuro imposto do Google ao distribuir apps em plataformas móveis
    E a situação do desenvolvimento desktop nativo também não é simples, então entendo perfeitamente quem escolhe web apps ou Electron no desktop
  • Por que tudo precisaria de aplicativo? Essa especificação não impede a execução em navegadores web comuns, nem significa que a web atual vá desaparecer
  • Acho que o ponto realmente apropriado é descobrir até onde dá para ir só com marcação padronizada
    O problema da web moderna é reinventar conceitos sem parar, e boa parte disso deveria ser marcação declarativa. Não deveria ser necessário ter JavaScript no caminho de renderização de um site. Scripting deveria ser usado para programação específica no cliente, em casos em que algo antes feito no servidor passa a ser feito no cliente, por exemplo processar um conjunto de dados retornado pelo servidor
  • Na verdade, já existem apps para tudo. Só que, em vez de app, chamamos isso de URL ou nome de domínio
    Parece que a indústria de TI empurrou o navegador web como máquina virtual de fato depois que ficou claro que alternativas sandboxed como Java com Swing e Flash eram dolorosamente inferiores. Agora um único aplicativo, o Google Chrome, virou a máquina virtual da maior parte da computação cotidiana dos usuários, e ainda por cima pertence e é desenvolvido por um monopólio de capitalismo de vigilância. Não sei se isso é realmente mais seguro, ou se os zero-days reais só ficaram caros demais para serem divulgados
    Acho que adicionar scripting foi um erro. Pelo menos era algo acrescentado depois, e concordo com o Dillo em manter o escopo de um leitor de documentos de hipertexto na leitura de documentos, sem tentar tornar possível também criar e editar documentos dentro do leitor
    O objetivo não é replicar a web por funcionalidade, mas criar uma especificação legível sem exigir rodar uma máquina virtual completa para trocar conhecimento, notas e informações
    Gostaria de ver um aplicativo de uso geral reduzido, dentro de um sandbox melhor, capaz de lidar com a maioria das demandas de “interatividade”. Será que realmente precisamos de uma máquina virtual completa para trocar hipertexto num feed de rede social como o Reddit? E para lidar com carrinho de compras e informações de pagamento?
    Ainda assim, há uma grande chance de que o “uso geral” acabe engolindo o “aplicativo”, e aí estaremos reinventando a web. Mesmo assim, se houver uma chance de isso ser baseado em algo que não seja o Google e em uma linguagem que não seja C++, talvez já seja melhor. Pelo visto o Dillo usa C e C++, então talvez ao menos uma dessas duas partes já seja um avanço

• Outra melhoria desejável seria usar uma versão reduzida de HTTP, mas suportando só cookies de sessão controlados pelo cliente, proibir recursos de terceiros e manter todos os recursos no mesmo servidor web do documento, além de exigir renderização de formatos como text/markdown por um conversor interno do navegador

  • Só proibir recursos de terceiros já evitaria vários problemas graves
  • Idealmente, eu gostaria de tornar isso independente do meio de transporte. Provavelmente começaria pelo local, para que funcione em qualquer ponto de montagem de sistema de arquivos remoto
    A ideia desta vez é melhorar a dieta e ver se dá para evitar cookies. Isso é uma representação mecânica do documento; foi projetada para ser legível por humanos, mas não para ser escrita diretamente por humanos. Em vez disso, seria melhor usar uma linguagem frontend como Markdown e compilá-la para um documento portátil e rígido
  • Minha sugestão é que, se cookies forem realmente necessários, eles se apliquem apenas ao domínio exato do site. Cookies de example.net não deveriam ser enviados para sub.example.net, e sub.example.net também não deveria poder definir cookies para example.net
    HTTP/2 e HTTP/3 deveriam ficar na web de aplicações, e o HTTP/1 na web de documentos. Não sei como limitar JavaScript para evitar o problema de “você precisa de um navegador específico para ver meu conteúdo”, então JavaScript não deveria existir
    Se você exigir renderização de text/markdown, também surge a questão de qual versão está falando. Há mais ou menos meia dúzia de variantes que precisariam ser suportadas

• Sintaxe rígida provavelmente não vai funcionar. Foi por isso que XHTML fracassou, e por isso o HTML5 adicionou regras para lidar com “quebras” comuns
  Dá para reespecificar o HTML5 em uma gramática mais formal, como o autor quer, mas rejeitar páginas rigidamente não parece um bom uso de um fork. A outra alternativa é virar mais um substituto de gopher/gemini, e existe um motivo para eles continuarem impopulares apesar de terem um público entusiasta. A força da compatibilidade retroativa é muito grande

  • Não concordo que o XHTML tenha fracassado por ser rígido. O IE não suportou XHTML até 2011, o que foi tarde demais, e por isso as pessoas não usaram XHTML de verdade nem obtiveram seus benefícios
    Rigidez pode ser muito boa, mas só funciona se houver suporte

• A ideia de que “adicionar scripting foi um erro” é um meme antigo entre aquele tipo deprimente de programador que não permite diversão, mas acho que isso é mais falta de imaginação
  Multimídia interativa aplicada com cuidado pode melhorar muito a comunicação e a explicação. Basta ver os diagramas interativos do tutorial de grade hexagonal do Red Blob Games ou a explicação fantástica do funcionamento de um relógio mecânico, de Bartosz Ciechanowski. Graças à mídia interativa da web, dá até para experimentar em poucos segundos, só clicando num link, computadores raros e historicamente importantes como o Canon Cat, sem passar pelo processo infernal de compilar e executar um emulador nativo. Envio de formulários e mapas de imagem são só uma sombra muito pálida da multimídia, e transferem o peso do suporte à interação para um modelo intrinsecamente centrado no servidor e potencialmente intensivo em largura de banda
  O problema não é o comportamento de scripting em si, e sim o que os navegadores atuais permitem que scripts façam. Assim como HTTP e HTML podem ser reduzidos a um sistema menor, mais simples e mais respeitoso da autonomia do usuário, também seria possível manter a maior parte do lado positivo do JavaScript da web e ao mesmo tempo reduzir muito a superfície de API e o potencial de abuso. Por exemplo, dá para imaginar uma web em que haja um retângulo interativo estilo Flash dentro da página, e essa interação seja fornecida por scripts Lua acessíveis e inspecionáveis pelo usuário, com recursos gráficos e de entrada como os do Love2D, enquanto ações invasivas à privacidade, como contatar servidores remotos ou acessar a webcam, fiquem atrás de um sandbox forte e do consentimento prévio explícito do usuário
  Ainda hoje dá para construir aplicações web respeitosas desse jeito, mas a base é irregular, inconsistente e cheia de ausências óbvias de funcionalidades úteis, além de ameaças desnecessárias à segurança e à privacidade do usuário por toda parte
  Como visão do ponto de vista de acessibilidade, dá para imaginar formulários no lado do cliente que tratem estritamente entradas declarativas de UI como botões, campos, caixas de seleção e sliders, e renderizem imagens e marcação dentro de um <iframe> como se fossem páginas estáticas, mas funcionando sem ida e volta a um servidor remoto. Vários tipos de calculadoras, ferramentas e visualizações interativas caberiam nesse modelo, com latência menor e mais segurança para o usuário do que no modelo orientado por backend

• Se a ideia é “texto em primeiro lugar”, então CSS também teria que sair. CSS existe em grande parte para as empresas, não para os usuários. O estilo deveria ser controlado pelo navegador, não pela página
  Se o usuário decidiu ler a carga útil bruta da página, então a maior parte dela deveria ser a mesma informação que o navegador mostrou para leitura. Hoje, o conteúdo legível é só a ponta do iceberg
  Sobre “sem scripting”, suponho que, se você remover estilos e páginas pesadas, a necessidade de scripting que afeta a forma de exibição também diminuirá bastante. Scripting que não afeta a exibição em geral tem sido usado contra o interesse do usuário

  • Esse era justamente o ponto central da cascata do CSS. Existia um subconjunto razoável de CSS que podia ser usado para formatação de livros e artigos, e ele foi concebido para ser combinado com estilos do usuário
    Mas CSS e formatação ficaram complexos demais, e os estilos do usuário agora precisam começar com um reset completo de CSS ou ser extremamente específicos para cada site
  • Se você quiser exibir timestamps no fuso horário do leitor, hoje não há como fazer isso sem scripting no lado do cliente
    Eu esbarrei nisso ao criar uma ferramenta pessoal sem JS no cliente, e percebi que teria de manter uma configuração de “meu fuso horário” no servidor ou adicionar um pequeno script auxiliar
    Se o navegador passar a controlar o estilo, parece que problemas como “minha página é legível nos navegadores X e Y, mas não no Z” podem ficar ainda piores do que hoje
  • Vou continuar vivendo feliz num mundo cheio de CSS, com cores, fundos chamativos, boas fontes, layouts com flexbox e grid
    Acho isso melhor do que ver apenas documentos sem graça em que a voz do autor é lavada e reduzida a texto preto sobre fundo branco. CSS é a forma de expressão do autor na web, e eu realmente não gostaria de perdê-lo. É complexo, mas vejo isso mais como algo positivo, porque permite que mais pessoas façam coisas interessantes em seus próprios sites
  • Concordo. Estilos opcionais do autor merecem mais investigação antes de serem proibidos
    Também compartilho a impressão de que remover estilos e páginas pesadas reduziria a necessidade de scripts que alteram a exibição. Com uma sintaxe simples, talvez fosse possível embutir “documentos” dentro de programas nativos interativos, e não o contrário

• Como outras pessoas disseram, Gemini parece um bom exemplo de referência. De novo: Gemini parece performance artística, mas realmente há muito o que aprender com ele
  Um recurso notável do Gemini que não recebe atenção suficiente são as páginas assináveis. Dentro da página, links cujo texto começa com YYYY-MM-DD formam um feed implícito. É extremamente limitado e parece meio burro, mas acho que é um dos recursos mais impressionantes do Gemini. Spec here
  No HTML tradicional, é possível escrever um blog manualmente. É tedioso, mas totalmente viável. Já para manter feeds RSS/ATOM, quase inevitavelmente você precisa de uma ferramenta para gerar o feed
  Se fosse um HTML de próxima geração “orientado a conteúdo”, seria bom incorporar algo parecido. Talvez h-feed em microformats seja a forma certa, mas gosto muito da simplicidade proporcionada pelas páginas assináveis do Gemini. E feeds em todo lugar são uma coisa boa
  O fato de o Gemini ser baseado em linhas e fácil de parsear é uma grande vantagem, mas também parece limitado demais e pode ter implicações ruins para acessibilidade. Ainda assim, um HTML-lite parecido com Gemini talvez funcionasse bem
  Outra vantagem que um fork da web poderia trazer seria limpar os acréscimos que foram sendo empilhados sobre o HTML. <meta name="viewport" content="width=device-width, initial-scale=1.0"/> é bem irritante. Se uma nova versão fosse criada com base no que sabemos hoje, há boa chance de ficar muito boa
  Tenho menos certeza sobre outras partes. Em princípio, sou totalmente a favor de não ter JS. Só que também vejo um dos melhores usos da web como o acesso universal a serviços essenciais, como governo e bancos. Ainda não estou completamente convencido de que dê para fazer realmente tudo isso sem JS mantendo boa usabilidade, mas talvez seja possível
  Também quero destacar a parte de outro comentário que diz “essa especificação não impede a execução em navegadores web comuns, e a web atual não vai desaparecer”
  Seria ótimo poder rodar separadamente um “navegador web de conteúdo” e um “navegador de apps”. Para muitos objetivos, não há tantas alternativas tão boas quanto a web como plataforma de apps, e a web evoluiu muito; os desenvolvedores também parecem preferi-la muito mais do que as outras opções
  Nesse mundo, o Google Maps não funcionaria no meu navegador web de conteúdo, e seria aberto no navegador de apps. Se eu executar o GMail no navegador de apps, os links dentro dos emails seriam abertos no navegador web de conteúdo
  O navegador web de conteúdo idealmente deveria ser muito mais fácil de implementar, o que estimularia competição e inovação. Mas é frustrante não ver um caminho claro para tornar isso realidade. Acho que eu seria muito mais feliz se pudesse fazer toda a exploração de conteúdo em um navegador assim. A superfície de ataque pareceria muito menor, então eu me sentiria mais tranquilo em termos de segurança. Mas parece que ninguém mais se importa com isso agora

  • Quase todos os casos legítimos de uso de JS em páginas web existem porque faltam recursos importantes no navegador. Aprendemos isso ao longo de décadas, e graças a scripts os navegadores não precisaram de fato adicionar essas capacidades
    Então basta adicioná-las como recursos do navegador

• Isso soa um pouco parecido com Gemini, mas esse fork parece permitir um pouco mais
  Acho que os sites poderiam ser escritos em alguma variante de Markdown ou algo semelhante. Deveriam ser documentos fáceis de ler até em sua forma bruta. Algo como Gemtext, mas com um pouco mais de recursos, como mídia inline
  E também deveria haver um pouco de estilo. A web sempre foi, e ainda é, um ótimo lugar para exercer criatividade. Mantendo um conjunto de estilos simples e consistente, pessoas criativas poderiam fazer sites ainda mais inventivos

• Seria bom se isso também cobrisse os elementos básicos do HTMX

  • Pessoalmente, eu gostaria que só as capacidades primitivas do Triptych fossem incorporadas. Isso oferece o suficiente para construir coisas no lado do servidor sem tornar o cliente excessivamente complexo

• Essa ideia funcionaria melhor com uma motivação clara. “Vamos simplificar” é abstrato demais. Como cada pessoa entende simplicidade de um jeito, é preciso um objetivo mais explícito sobre por que a web deveria ser mais simples e que necessidade concreta isso atenderia
  Por exemplo, o projeto Gemini se concentra em construir uma comunidade que valoriza uma forma específica de comunicação. Como isso combina com os objetivos dessa comunidade, a web foi simplificada ao ser limitada a esse formato de comunicação, e pelo que me lembro nem imagens são tecnicamente suportadas
  Já ferramentas como Sciter e Blitz têm como objetivo facilitar a incorporação de um renderizador parecido com navegador em outras aplicações. Elas simplificam removendo comportamentos estranhos desnecessários ou tornando o parsing de HTML e a execução de JS opcionais. Isso reduz tanto o que precisa ser implementado quanto o que o usuário precisa embutir
  Ambos têm a simplicidade como meta, mas, como seus objetivos fundamentais são muito diferentes, os resultados também acabam sendo muito diferentes. Qual é o objetivo fundamental aqui?