Webをフォークすることについて
(dillo-browser.org)- 代替仕様の目標は、Web全体ではなく、2026年5月6日時点で展開後サイズが 18.3MiB のHTML仕様をまず対象とし、Webの長所は維持しつつ短所は避けること
- 仕様は短く単純であるべきで、仕様全体を収めた圧縮
tar.gzを 1.44MiB に制限する方式のように実装負担を下げ、多様なブラウザーやクライアントが登場できるようにするべきこと - 仕様は現在の Web specification のように変化し続ける文書ではなく、
1.2.3のような セマンティックバージョン を持つべきで、公開された標準バージョンは決して変更されてはならないこと - 仕様には簡単にパースできる 曖昧さのない形式文法 が含まれるべきであり、標準に準拠しないページはレンダリングしないようにして、パーサーやコンテンツツール作成のコストを下げるべきこと
- 代替仕様は機能ごとのWeb複製ではなく、書かれたテキスト を中心とした情報交換を目指し、スクリプティングの代わりにGeo linkやtiled web map標準のような、標準化されたファイル・URLをネイティブプログラムで開く方式を好むこと
Web代替仕様の目標
- HTML仕様は2026年5月6日時点で展開後サイズが 18.3MiB であり、まず検討対象となるのはWeb全体ではなくHTML仕様に限定される
- 目標は、Webの長所を可能な限り維持しながら短所を避ける 代替仕様 を作ること
- まだ正式な仕様ではなく、時間とともに変わりうる非公式なノートに近い
単純性と実装の多様性
- 仕様全体は短く単純であるべきで、少ない労力で多様なブラウザーやクライアントを作れるようにすべき
- 数十年にわたって単純性を維持するのは非常に難しいため、仕様の長さをバイト単位で制限するルールが一つの方法になりうる
- Dilloはリリースを単一のフロッピーディスクに収めるために同じ方式を使っており、代替仕様でも仕様全体を収めた圧縮
tar.gzを基準に 1.44MiB の制限を設けられる
セマンティックバージョニング
- 現在の Web specification はおおむね毎週変わるページであり、クライアントが仕様に従うには変更を追い続けなければならないという問題がある
- 代替仕様は
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 を提供すれば、そのプロトコルをサポートする任意のクライアントで位置を開ける
- 同様に、公開仕様があれば任意のクライアントがサーバーの地図タイルを利用でき、関連例として tiled web map標準 が挙げられている
- 標準化されたファイルやURLをネイティブプログラムで開く方式は、使っているデバイスに合わせて最適化でき、多くのインタラクティブなWebページにおける 画一的なアプローチ を避けられる
目標ではないもの
- 目標はWebを機能ごとに複製することではない
- 人間が知識、ノート、その他の情報を交換できるようにしつつ、それを読むために完全なVMを実行しなければならない要件を取り除く仕様を作ることが目標
1件のコメント
Lobste.rs の意見
つまり、また何にでもアプリが必要だということか？ スクリプト機能そのものが失敗だった、という点には同意しない
ウェブが OS の境界をまたぐ汎用プラットフォームだという点は良いと思う
Windows だけ対応して、たまに Mac が追加される程度だった時代のことだ
それに ネイティブデスクトップ開発の状況 も単純ではないので、デスクトップでウェブアプリや Electron を選ぶ人たちには十分共感できる
現代ウェブの問題は概念を延々と再発明していることで、そのかなりの部分は宣言的マークアップであるべきだ。ウェブサイトの表示経路に JavaScript が割り込む必要はないはずだ。スクリプティングは、サーバーでやっていた処理をクライアントで行う場合、たとえばサーバーが返したデータセットを加工するような特定のクライアント側プログラミングに使われるべきだ
IT 業界は、Java や Swing、Flash のようなサンドボックス型代替手段が痛いほど劣っていることが明らかになると、ウェブブラウザを事実上の仮想マシンとして押し出した感じがある。いまや単一アプリケーションである Google Chrome が、ユーザーの一般的なコンピューティングの大半における仮想マシンの役割を果たしていて、それも監視資本主義の独占企業が所有・開発している。これが本当により安全なのか、それとも実際のゼロデイが高価すぎて公表されないだけなのかは分からない
スクリプティングの追加は失敗だったと思う。少なくとも後付けの機能だったし、Dillo がハイパーテキスト文書リーダーの範囲を文書の閲覧にとどめ、そのリーダーの中で文書の作成・編集まで可能にしようとしない点には同意する
目標は、ウェブを機能ごとに複製することではなく、知識・メモ・情報を交換するためにフルサイズの仮想マシンを動かす必要なしに読める仕様を作ることだ
もっと良いサンドボックスの中で、ほとんどの「インタラクション」要求を処理する縮小版の 汎用アプリケーションを見たい。Reddit のようなソーシャルメディアのフィードでハイパーテキストをやり取りするのに、本当に完全な仮想マシンが必要なのか？ ショッピングカートや決済情報の処理にも、完全な仮想マシンが必要なのか？
ただ、「汎用」であるものは結局「アプリケーション」を飲み込んでしまい、その時点でまたウェブを再発明することになる可能性が高い。それでも Google ではない主体、C++ ではない言語が土台になるチャンスがあるなら、そのほうがましかもしれない。Dillo は C と C++ のようだから、せめてどちらか片方でも改善ということかもしれない
さらに改善するとしたら、HTTP の縮小版を使いつつクッキーはクライアントが制御するセッションクッキーだけをサポートすること、サードパーティリソースを禁止してすべてのリソースを文書と同じウェブサーバーに置くこと、ブラウザ内部の変換器で text/markdown のような形式のレンダリングを要求することだろう
今回は「食事制限を改善してクッキーを避けられるか見てみよう」という立場だ。これは文書の機械表現であり、人が読めるよう設計されているが、人が直接書くためのものではない。代わりに Markdown のようなフロントエンド言語を使い、それを移植可能で厳密な文書にコンパイルする方式がよい
example.netのクッキーはsub.example.netに送られず、sub.example.netのクッキーもexample.netに設定されるべきではないHTTP/2 と HTTP/3 はアプリケーションウェブに残し、HTTP/1 は文書ウェブに残すほうがよい。JavaScript をどう制限すれば「自分のコンテンツを見るには専用ブラウザが必要」という問題を避けられるのか分からないので、JavaScript は無いほうがよい
text/markdown のレンダリングを要求するなら、どのバージョンを指すのかも問題になる。サポートすべき方言がざっと半ダースある
厳格な文法はうまくいかないだろう。XHTML が失敗した理由もそれだし、HTML5 が一般的な「壊れ方」を処理するルールを追加したのもそのためだ
著者が望むように HTML5 をより形式的な文法で再仕様化することはできるだろうが、ページを厳格に拒否することはフォークのよい活用には見えない。もう一つの代案は、また別の gopher/gemini 代替物になることだが、熱心なファン層はあっても人気がないのには理由がある。下位互換性の力が強すぎる
厳格さはとても良いものになり得るが、機能するにはサポートが必要だ
「スクリプト機能の追加は失敗だった」という考えは、楽しさを許さない陰鬱なプログラマー気質のあいだで長らくミームだったが、想像力の欠如に近いと思う
慎重に適用された インタラクティブ・マルチメディアは、コミュニケーションや説明を大きく改善できる。たとえば Red Blob Games Hex-Grid tutorial のインタラクティブな図や、Bartosz Ciechanowski's fantastic explanation of mechanical watch movement を見ればよい。ウェブのインタラクティブなメディアのおかげで、Canon Cat のような歴史的に重要な希少コンピュータさえ、ネイティブエミュレータをコンパイルして実行する悪夢のような手順なしに、リンクをクリックして数秒で使ってみることができる。フォーム送信やイメージマップは、マルチメディアのごくかすかな影にすぎず、インタラクション対応の負担を本質的にサーバー中心で、しかも潜在的に帯域を多く使うモデルへ移している
問題はスクリプト動作そのものではなく、現在のブラウザでスクリプトが できるよう許されていることだ。HTTP と HTML をもっと小さく単純で、ユーザーの自律性を尊重するシステムに縮小できるのと同じように、ウェブ JavaScript の良い面の大半を保ちつつ、API の表面積と悪用可能性は大幅に減らせる。たとえば、ページ内に Flash のようなインタラクティブな矩形があり、そのインタラクションはユーザーがアクセス・検査できる Lua スクリプトと、Love2D のようなグラフィックス・入力機能で提供され、リモートサーバーへの通信やウェブカメラへのアクセスといったプライバシー侵害的な操作は、強力なサンドボックスとユーザーの明確な事前同意の後ろに置かれるようなウェブを想像できる
こういう形でユーザーを尊重するウェブアプリケーションは今日でも作れるが、基盤は凸凹で一貫性がなく、有用な機能の明白な欠落と、ユーザーの安全・プライバシーへの不要な脅威が至る所にある
アクセシビリティの観点からのビジョンとしては、ボタン・フィールド・チェックボックス・スライダーのような宣言的 UI 入力を厳格に扱い、静的ページのように
<iframe>内に画像とマークアップをレンダリングしつつ、リモートサーバーとの往復なしで動作する クライアント側フォームを考えられる。さまざまな計算機、ツール、インタラクティブな可視化がこのモデルに収まり、バックエンド主導モデルよりレイテンシとユーザーセキュリティが向上する「テキスト優先」なら CSS も捨てるべきだ。CSS は概してユーザーのためではなく企業のために存在する。スタイルはページではなくブラウザが制御すべきだ
ユーザーが生のページペイロードを読むと決めたなら、その大半はブラウザが「これを読め」と見せた情報と同じであるべきだ。今日、読めるコンテンツは氷山の一角にすぎない
「スクリプティングなし」については、スタイルや肥大化したページを取り除けば、表示方式に影響するスクリプティングの必要も大きく減るのではないかと推測している。表示方式に影響しないスクリプティングは、たいていユーザー利益に反して使われてきた
だが CSS と組版は複雑になりすぎ、ユーザースタイルは今や全面的な CSS リセットから始めるか、サイトごとに非常に具体的でなければならない
クライアントに JS なしで個人用ツールを作っていてこの問題にぶつかり、サーバー側に「自分のタイムゾーン設定」を持たせるか、小さな補助スクリプトを追加する必要があると気づいた
スタイルをブラウザに制御させると、「自分のページはブラウザ X と Y では読めるが Z では読めない」といった問題が今より悪化する可能性もありそうだ
著者の声を白地に黒文字へ洗い流した味気ない文書だけを見るよりはましだと思う。CSS はウェブにおける著者の表現手段であり、本当に無くしてほしくない。複雑ではあるが、そのおかげでより多くの個人が自分のウェブサイトで面白いことをできるようになるので、むしろ良い面だと思う
スタイルや肥大化したページを取り除けば、表示を変えるスクリプトの必要が減るのではないかという感覚も同じだ。単純な文法があれば、インタラクティブなネイティブプログラムの中に「文書」を埋め込めるようになり、その逆ではなくなるかもしれない
ほかの人たちが言うように Gemini は参考にするのによい例だと思う。繰り返すが Gemini はパフォーマンスアートのようでもあるが、学ぶべき点が本当に多い
Gemini であまり知られていない注目機能の一つが、購読可能なページだ。ページ内でテキストが
YYYY-MM-DDで始まるリンクが暗黙のフィードを構成する。非常に制限的で間抜けにも見えるが、Gemini の最も印象的な機能の一つだと思う。Spec here従来の HTML では、ブログを手書きすることは可能だ。退屈ではあっても十分できる。だが RSS/ATOM フィードを維持するには、ほぼ必ずフィード生成ツールが必要になる
次世代の「コンテンツ指向」HTML なら、似たような機能を入れるとよいだろう。たぶん
h-feedin microformats が正しいやり方かもしれないが、Gemini の購読可能ページが持つ単純さは本当に魅力的だ。そして至る所にあるフィードは良いものだGemini が行単位でパースしやすいのは大きな長所だが、制限が強すぎてアクセシビリティ面で悪影響があるかもしれないとも感じる。それでも Gemini 風の HTML-lite があればよさそうだ
ウェブフォークが得られる別の利点は、HTML に後付けされた部分を整理することだ。
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>はかなり煩わしい。今知っていることを踏まえて新しい版を作れば、かなり良いものになる可能性が高いほかの点については確信がやや薄い。原則としては JS なしに完全に賛成だ。ただ、ウェブの最良の用途の一つは、政府や銀行のような必須サービスへの汎用的アクセスだと思う。良い使い勝手を保ちながら本当にすべてを JS なしでできるのか、まだ完全には確信していないが、可能かもしれない
another comment の「この仕様が通常のウェブブラウザ実行を妨げるわけではなく、今のウェブが消えるわけでもない」という部分も強調したい
「コンテンツウェブブラウザ」と「アプリブラウザ」を別々に実行できるとよいと思う。多くの目的において、アプリプラットフォームとしてのウェブほど良い代替は多くなく、ウェブは大きく進化しており、開発者たちも他のものよりはるかにウェブを好んでいるように見える
こういう世界では Google Maps は自分のコンテンツウェブブラウザでは動かず、アプリブラウザで開かれるだろう。GMail をアプリブラウザで実行すると、メール内のリンクはコンテンツウェブブラウザで開かれるようになる
コンテンツウェブブラウザは理想的にはずっと実装しやすいはずで、それによって競争と革新が促進されるだろう。だがそれを実現する道筋はよく見えず、そこが残念だ。そういうコンテンツブラウザであらゆるコンテンツ探索ができれば、ずっと幸せだと思う。攻撃面がはるかに小さくなり、セキュリティ面でより安心できるからだ。だがもう誰も気にしていないように見える
だから単に ブラウザ機能として追加すればよい
Gemini に少し似ているように聞こえるが、このフォークはもう少し多くを許容しそうだ
ウェブサイトは Markdown 方言か、それに近い何かで書けるべきだと思う。生の形でも簡単に読める文書であるべきだ。Gemtext にインラインメディアのような機能を少し足した形だ
そして多少のスタイル機能も許容すべきだ。ウェブは創造性を発揮するのに素晴らしい場所だったし、今もそうだ。単純で一貫した スタイルセットを維持すれば、創造的な人たちがもっと奇抜なサイトを作れる
HTMX の基本要素も扱うとよいだろう
このアイデアは 明確な動機があれば、もっとうまく機能するだろう。「単純にしよう」では抽象的すぎる。人によって単純さの考え方が違うので、なぜウェブをより単純にすべきなのか、どんな具体的な必要を満たすのか、もっと明示的な目標が必要だ
たとえば Gemini プロジェクトは、特定の形のコミュニケーションを重視するコミュニティを作ることに焦点を当てている。そのコミュニティの目標に合っているからこそ、ウェブをそのコミュニケーション形式に制限して単純化し、画像でさえ技術的にはサポートしないものだったと記憶している
一方で Sciter や Blitz のようなツールは、他のアプリケーションにブラウザ風レンダラをより簡単に埋め込むことを目標にしている。これらは不要な特異動作を削除したり、HTML パースや JS 実行をオプションにしたりして単純化している。そうすれば実装するものも減り、ユーザーが埋め込むものも減る
どちらも単純さを目標にしているが、根本目標が大きく異なるため、結果も大きく変わる。ここでの根本目標は何なのか？