2026/05/09 20:33
ウェブのフォーク
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
文書は、Monopoly Control から Web 標準を守ることを最優先とし、極度の簡潔性と厳格な文法を重視する Rodrigo Arias Mallo による革新的な代替 Web 仕様提案を概説しています。主要な制約としては、仕様のサイズを 1.44 MiB（圧縮）の 1 枚のフロッピーディスクに収めること（現在の HTML 標準は非圧縮で 18.3 MiB）、パッチリリースでは措辞のみを変更するという不変的なセマンティックバージョニングの実施があります。この堅固な形式主義によって、バージョンの印刷物はブラウザ実装のために永久に利用可能となり、厳格な文法により準拠していないページは即時拒否されることを保証します。提案は複雑な既存機能の複製を明示的に避ける一方で、埋め込みスクリプトよりもオープンプロトコルとデバイス固有機能を推進します。さらに、形式主義の高基準は、人間向けの著者に対してより許容的な言語（例えば Markdown）や可変的な表示に合わせてテキストを改行するよう促し、機能の同一化ではなくブラウザの多様性を育むことを目的としています。究極的には、この戦略は永続的な参照仕様を確保し、収益を捕獲するために技術的障壁と複雑性を高めるようなエンティティからユーザーを守ることを目指しています。
本文
2026 年 5 月 6 日、ロドリゴ・アリアス・マロ氏によって作成された文書
はじめに
本書は、Web の多くの欠点を防ぎつつ、その優れた点も活かすよう努めた代替的な仕様の構築に関する非公式なメモをまとめたものです。本稿は仕様自体ではなく、今後改訂される可能性があります。
Web を構成する要素はいくつかあり、それぞれ見直しが必要です。当面は HTML 仕様に焦点を当て（2026 年 5 月 6 日時点での圧縮されていないサイズは 18.3 MB）、その他の検討は後回しにします。
目標
仕様を作成する前に、仕様の範囲を決める上で指針となる明確な目標リストを用意すべきです。
シンプルさ
全体として仕様は簡潔かつ短く、低コストで多様なブラウザや他のクライアントの開発が可能なように設計すべきです。長期的（数十年）にわたって単純さを維持するのは極めて困難、あるいは不可能です。一つのルールとして、仕様の長さ（バイト数）に制約を設けることを提案します。すでに Dillo プロジェクトではリリースの容量を単一の 5.25 インチフロッピーディスクに収まるよう制限しており、同様のアプローチを用いることも可能です。具体的には、圧縮した tar.gz 形式で全体仕様が 1.44 MB を超えないようにするという上限を設定し、それを守ります。
セマンティックバージョニング
現在の「Web 仕様」は週に数回変更されるページであり、仕様準拠のクライアントを実装するには常に更新が必要となります。そのため、仕様にはバージョン 1.2.3 のように極めて明確なセマンティックバージョニングを適用すべきです。そうすることで、バージョン 1.2.3 に準拠するページは、1.2.3 や 1.2.0、1.3.0 を対応しているブラウザでは正常にレンダリングされますが、1.1.0 のみまたは 2.0.0 のみのサポートしかないブラウザではレンダリングされないことを意味します。
セマンティックバージョニングを採用することで、制作者は特定のブラウザの実装状態を追うのではなく、標準そのものに集中できます。例えば、「90% のブラウザがこのバージョンをサポートしています」という事実を前提に、ターゲットとして「1.2.0」を選ぶことができます。
発行された標準版の仕様は、原則として決して、決して、決して、決して変更されません。誤字脱字などはマイナーバージョン（パッチバージョン）番号の上昇で修正し、リトロコパタブルな新機能はマイナーバージョンの上昇で導入し、互換性を損なう大規模な変更はメジャーバージョンの上昇で対応します。これは、1.2.0 の仕様の本を購入し、無人島のような環境に持ち込んで、永遠に 1.2.X ドキュメントを正しく解析できる完全に準拠するブラウザを実装することも可能であることを意味します。
厳密な文法
仕様には曖昧性のない形式的な文法を含めることで、解析が容易となるようにする必要があります。ページは仕様に対してテストされ、準拠するか不準拠かで受け入れられるか拒否されるかに判定できます。仕様に準拠しないページはレンダリングされてはならないことにします。クライアントが仕様に対応しないページを受け入れることは明確に禁止され、これにより、壊れたページを修正するために実装せざるを得なかった「悪魔的なルール」を防ぎ、仕様が後続のバージョンで自身の不備を自己修正するよう強制します。
厳密な文法を採用すると、人間は書きやすく、より許容性の高い言語（例えば Markdown）へ移行する傾向が生じる可能性がありますが、これは意図された効果です。その目的は、パーサーを単純化し、コンテンツを操作するためのツールの開発コストを低減することにあります。
特に、パッチバージョンの変更は表現のみに影響し、文法自体は不変とします。
HTML の再利用（可能な限り）
既存のソフトウェアに最小限の変更で動作するように、HTML のサブセットとして仕様が構築できれば理想的です。しかし、HTML の解析の複雑さを考慮すると、これは必ずしも実現可能ではないかもしれません。同様に、XML ドキュメントの形式的な文法を定義することも容易ではありません。したがって、HTML/XML が単純な解析に適した形式かどうかは再検討が必要です。
標準への独占防衛
Web の課題の一つは、独占的な実体が入収益を得るメカニズムを構築するやいなや、自分たちの利益のために標準を掌握・改変するインセンティブが生じる点です。Web の場合、これが原因で標準の複雑性が制御不能に膨れ上がり、新しいブラウザへの参入障壁が高まり、競争が減少しました。
この状況を回避するためのいくつかの概略的なアイデアを持っていますが、これらはゲーム理論の観点からさらに慎重に検討する必要があります。
テキストファースト
仕様の目標は、印刷された本や記事と同様、人間間で情報を伝達するために十分な詳細を含めることです。書かれたテキストを優先的に用いるべきであり、それは情報コード化において最も多様な媒体であるためです。翻訳可能で、コンピューターによる朗読が可能であり、かつ少量のストレージに格納できるという利点を備えています。
テキストは画面サイズに合わせて折り返すように設計すべきで、そうすることで同じ文書でも小さな画面でも大きな画面でも読みやすくなります。
スクリプトングなし
スクリプト機能の追加は間違いだったため、今後はそれを避けます。ただし、これはユーザーにインタラクティブなプログラムを排除することを意味しません。例えば、現在は JavaScript を用いてブラウザで場所情報表示するインタラクティブマップですが、代わりに該当地点を開くためのジオリンク（Geo link）を提供し、そのプロトコルをサポートするあらゆるクライアントから地点を表示させることができます。同様に、サーバーからのタイルを使用したい場合も、オープンな仕様が存在すれば、あらゆるクライアントから利用可能です。
ネイティブプログラムで標準化されたファイルや URL を読み込む利点は、使用されているデバイスに合わせて最適化でき、多くのインタラクティブ Web ページに見られるように「ワンサイズフィッツオール」アプローチに依存せず済む点です。
非目標
本書の目的は、Web の機能を一つずつコピーしたものを作成することではなく、仮想マシン全体を実行する必要なく、知識やメモ、その他の形態の情報を入れ替えられるよう Humans が利用できる仕様を作成することにあります。