HTML仕様からXSLTへの言及削除を提案
(github.com/whatwg)- HTML標準文書から XSLT関連の言及を削除 しようとする Pull Request が提案されている状況
- 提案者は、Chrome、Firefox、Safari など主要ブラウザーで関連する 実装バグが報告 されており、テストおよび文書化の課題も進行中だと説明
- 反対意見では、既存ウェブサイトとの互換性問題 と
<?xml-stylesheet?>を削除した場合に XML 文書が壊れる 可読性の問題 が指摘されている - 一部の開発者は、XSLT が依然として 政府文書、RSS、組み込み環境 などで使われていると強調
- 大手ブラウザーベンダー中心の決定が、ウェブの開放性と歴史的多様性の縮小 につながりかねないという懸念も出ている
Pull Request 概要
- PR タイトル: Remove mentions of XSLT from the html spec
- 提案者: mfreed7
- 対象: whatwg/html:main
- 関連イシュー: #11523
- Chromium、Gecko、WebKit のすべてに関連する 実装バグレポートが存在
- MDN 文書 や HTML AAM など関連資料の更新も予定
主な反対意見
gucci-on-fleek (2025-08-15)
- 利用統計とウェブサイト規模 を考慮すべきだとの主張
- 大規模サイトは更新できても、小規模サイトや個人サイト は何十年も保守されておらず、恒久的な 互換性破壊 が懸念される
XSLTProcessor()の削除は JS 機能を制限するだけだが、<?xml-stylesheet?>を削除すると XML 文書がまったく表示されなくなる問題 が発生- これまでの古い HTML 機能（
<font>、<align>、<xmp>）は今でも動作する一方、今回は文書自体を壊す 前例のない変更 だと指摘 - 古いアーカイブや大学サイト など重要な資料へのアクセスが遮断される危険性を強調
nomis (2025-08-18)
- XSLT の 具体的な利用例 を提示
- 個人的な利用例
- 複雑な XML データを HTML テーブルに変換
- メモリ制約のあるマイクロコントローラー で動的 XML を静的 XSLT に変換
- libxml2 を丸ごと含む JS polyfill は非現実的 であり、ブラウザーサポートの削除は事実上の再実装強制だと批判
jonsterling (2025-08-18)
- ブラウザーベンダーがウェブプラットフォームを独占的に定義している現実を批判
- XSLT は今なお 多様で創造的なウェブ活用 に貢献しており、削除は Open Web の弱体化 につながるとの懸念
- 「ウェブは私たちみんなのもの」という原則を強調し、歴史と多様性を尊重する必要があると主張
賛成意見と後続対応
- domenic (2025-08-19): 前向きな反応を示しつつ、DOM 仕様における XSLT への言及も更新が必要だと指摘
- mfreed7 (2025-08-19): DOM 仕様についても別途 PR を提出すると回答
まとめ
- XSLT の削除は、ブラウザーの簡素化とモダン化の取り組み の一環として提案された変更
- しかし反対側は、既存文書との互換性、政府・学術データへのアクセス性、オープンウェブの多様性 が損なわれることを懸念
- 今回の議論は単なる技術的選択を超え、ウェブ標準の決定権が誰にあるのか という哲学的論争にまで発展している
1件のコメント
Hacker Newsの意見
いくつか注目すべき点がある
今回の決定はChrome単独の行動ではなく、イシュートラッキングや関連する標準会議の記録を見ると、主要ブラウザすべての代表者が支持の意思を示していることが確認できる
最近の議題もMozillaのエンジニアが提案したもの
PRが提出されたからといってすぐにマージされるという意味ではなく、未確認の課題もかなり残っている
ただし複数のブラウザベンダーが同意している状況なので、マージされる可能性は高い
XSLTをWebプラットフォームから削除するか検討するイシューは、コミュニティの意見収集のためではなく、HTML仕様メンテナー向けの議論用イシューである
このイシューはChromeのエンジニアが立てたが、Mozillaのエンジニアたちが何度もこの話題を会議で提起しており、すでにベンダー間の合意があった点が大きい
深刻なセキュリティ脆弱性が発見されたことがある
libxsltのメンテナーも自ら辞任している
タイトルからChromeという単語は外した
元の投稿タイトルは "Chrome intends to remove XSLT from the HTML spec" だった
Chromeのテレメトリデータによれば、実際にXSLTを使っているWebサイトはほとんどない
提案によってWeb全体に大きな影響が出るわけではないことは、少なくともデータで確認できる
以前MozillaとGoogle（Chromeチーム）で働いていた開発者である
Chrome/Blink、Safari/WebKit、Firefox/GeckoのすべてがXSLT削除を支持しているのはわかるが、2つのプロジェクトはリソース不足で、1つは新機能を無理に押し込む傾向が強い
SafariとFirefoxの開発者にとっては、この変化を歓迎する理由もある
重要なのは「権威ある人たちが良い考えだと思っているか」ではなく、「このアイデアがWebプラットフォームと数十億の利用者に悪影響を与えるかどうか」である
数十億人のうち0.1%しか依存していなくても、相当な規模になる
誰も使っていないならpolyfillが存在する理由もない
新機能を追加するなら必ず既存機能を消さなければならないというゼロサムゲームに持ち込むのは望ましくない
Googleは十分な資本と人員があるにもかかわらず、XSLTサポートを意図的にしない選択をしている
複数ベンダーが同意したからといって即座に推進された例はしばしばあった
confirm/prompt削除もそうだったが、結局は無期限保留になった
Googleには公式の機能削除プロセス文書がある
Google feature removal doc
「ベンダー単独支持」は実際の利用状況を十分に検討していなかった
私が読んだ2つのスレッドでは、Googleがフィードバックを求めたものの、フィードバックのほとんどは「やめてくれ」だった
それでもGoogleは「意見ありがとう、でもやるよ」という反応を見せた
もしこのイシューがセキュリティのためなら、オープンソースへの支援や、より安全なライブラリへの置き換え、JSサンドボックス内での維持など、さまざまな代替案があったが、ほとんど無視された
XSLT 3.0のような新しいバージョンへの対応要望も継続的にあったが、反映されなかった
XSLTはオープンWebを支える技術であるにもかかわらず、Googleは10年前からサポートを縮小して放置し、シェア低下を理由に削除を試み続けてきた
最近XSLTが再び人気を得つつある時期に、オープンな競合が現れる前に潰そうとしている意図を感じる
関連イシュー
フィードバックの多くが「やめろ」だったという主張については、そのスレッドは悪意あるコメントや誹謗中傷などで早々にロックされた
「これは良いアイデアだ」という意見は普段あまり書き込まれないので、反対意見ばかり多いように見えることはある
みなが過激な言動をした結果として議論が整理されたのであり、自業自得でもある
もし「やめてください」という意見の人たちが実利用者でもなく、必要な理由も説明できないなら、開発チームが無視するのは合理的である
フィードバック要請は単純な賛否投票ではない
XSLT 3.0をJS/wasmサンドボックスに移してサポートできるなら良いと思う
多少の性能低下はあるだろうが、両方の利点を取れる
XMLはバージョン管理スキーマや名前空間などの特性上、統合が比較的容易である
Angularのようなjsフレームワークと違って、信頼性の高いデータ契約が可能だ
XMLファミリーの成熟度のおかげで専門ツールも多く、実際にはXML/XSDをテキストとして直接扱わなくてもよい
Googleは「質問形式」でWebに何が起きるかを事前に知らせるやり方をしている
以前の関連スレッド紹介
XSLT削除トピックのスレッド
XSLT - Webのためのネイティブ・ゼロ設定ビルドシステム
関連イシューとしてフラグ処理された別スレッドもある
Google is killing the open web, today
ブラウザが特定のテンプレートエンジン（XSLT）を組み込みでサポートする必要があるのか疑問である
Jinjaのようなテキストエンジンではないが、JS/wasmで再実装することも可能だ
今のブラウザは重すぎ、新しいエンジンの開発も難しい
「ミニマルブラウザ」のための、もっと単純な標準（基本タグ、レイアウトなど）だけがあればよいと思う
WebAudioやCanvasなどもwasmモジュールとして実装可能である（そしてそうすればフィンガープリンティングも防げる）
XSLTは（特定のエンジンではなく）テンプレートエンジンの「仕様」であり、さまざまな実装が存在する
Mozillaはlibxsltの代わりにtransformiixを使用している
Jinjaは単純なテキスト処理だが、XSLTはノードレベルで動作するため、はるかに優れている
JS変換はXSLTネイティブ変換よりずっと遅く、結果のキャッシュも難しい
XSLTを古臭いものと見る感覚は理解できるが、過去20年間、性能面での秘密兵器としてうまく使ってきた
Googleは結局AMPのような代替で問題を覆い隠そうとする可能性が高い
ブラウザが重いのはGoogleのせいだ
XSLTは言語（spec）であってエンジンではない
JS/wasmへの実装変更は内部実装の問題であり、言語そのものをWebプラットフォームからなくすときに起きる話ではない
AudioやCanvasはブラウザの根本的なI/O機能であり、wasmに移すと性能と互換性に深刻な問題が生じる
Audioの一部はwasm blobに移せるかもしれないが、全体を移すのは難しい
CanvasコンテキストやWebGLなどはGPUとの直接統合が核心なので、wasmでは実現できない
結局こうした機能は事実上すでに基本的なプリミティブAPIであり、譲れない領域である
古いXSLTコードをwasmにパッケージして、旧来サイトを壊さず互換性を保つアイデアも議論された
実際に内部でも検討されたが、やらないと決めた
ごく少数しか使わない、Webとかけ離れた機能は削除対象になり得ると思う
ただしセキュリティ脆弱性を名目にすることには賛成しない
メモリセーフなパッケージの有無すら確認していない状態では説得力に欠ける
実利用率は0.001%レベルだという主張もある
HTML仕様の基本的な約束を破ることは非常に重大な問題である
議論がこの点を深く扱っていないことのほうがむしろ驚きだ
HTMLは「これはHTMLだ。信頼してよい」という約束だったが、今や「今はHTMLだが、将来もそうだという保証はない」になってしまう
XSLT削除の論理なら、他の古い技術も今後切り捨てられ続ける可能性がある
結局これはWebの「ロングテール」を切り落とそうという提案だ
今後追加されたさまざまなWeb技術もまたロングテールとなり、さらに多くの削除対象が生まれる点も考える必要がある
古いメディアやソフトウェアのサポートについては、いつかは移植・エミュレーション・アーカイブなどで解決する時期が来ると思う
変化に備えるための十分な時間とツール提供、そして複雑性の漸進的蓄積を避けることのバランスが必要だ
実際のPRで削除された部分を見ると、HTMLにXSLTサポートを要求する明示的な規定はないように見える
単にブラウザ対応の問題に対する反応が大きいという程度である
PR自体は意外と短い
WHATWGがHTMLを「Living Standard」（生きた標準）と定義して以来、実質的にはもはや実装標準ではなく、ブラウザベンダーが現在進めている状態を共有する役割になっている
そのためHTML5のようなバージョン表記もやめて、ただ「HTML」とだけ呼ぶようになった
Living Standard FAQ
HTML standard FAQ
皮肉なことに、HTML/CSS/ブラウザ仕様に膨大な機能を押し込んできた代表格もまさにGoogleである
もしGoogleが「ブラウザは軽量であるべきで、奇妙なものはJSライブラリに任せるべきだ」と一貫して主張してきたなら今回の措置も理解できたかもしれないが、まったくそうではない
FTPサポート削除の時点で、XSLの運命はすでに予見できた
ブラウザは攻撃面の縮小を最優先にする傾向がある
次の削除候補はSVGのSMILアニメーション属性やMathMLなど、XML関連機能になるのではないかと思う
関連スレッド
SMILは特定のアニメーション開始・終了タイミングに基づいて逐次的なアニメーション制御ができるが、CSSアニメーションはまだこの点が弱い
CSSでは計算を使ったタイミング指定以外に方法がない
ChromiumもかつてSMIL削除の意思を示したことがあるが、CSSが十分ではなかったため時期尚早だった
その余波でSMIL関連の各種案内文などが更新されないまま放置されている
攻撃面を減らすことが本当に良いことなのか悪いことなのか、問い直したい
技術者と一般利用者では優先順位が違うこともある
FTP機能の削除がいつ行われたのか気になる
まだアドレスバーでftp://に接続できると認識している
BlinkとWebKitのXSLT実装は非常に非効率である
今回の決定は残念だが、よりモダンなXSLT統合に努力が注がれなかったことのほうがさらに惜しい
使い勝手は良くなかったが、ブラウザ内であと少し進化していれば、Reactのようなフレームワークに匹敵する競争相手になれたかもしれない
XMLは大企業的な複雑ささえなければ、標準そのものは非常に強力で、魅力的な技術だった
XSLTを使って小さくシンプルなxml/データをhtmlへ直接変換するのは本当に良かった
選択項目だけを違って表示する小さな機能だけでも追加されていれば、静的文書まで含めてさまざまな活用が可能だったのではないかと惜しまれる
@whatwgが、議論が「過熱した」としてこのイシューを協力者限定にロックしたという
見たところかなり合理的で落ち着いていたが、特定ベンダーに好意的かどうかで「過熱」の基準が変わるのではないかと思ってしまう
「過熱した」という表現は、しばしば反対意見を扱いたくないという意味に解釈される
Redditなど他のコミュニティでも同様だ
実際にその下に残っている1件のコメントは、Google Chrome所属の開発者が「良い仕事をした」と書いたものだ
少し見ていて気まずい感じがする
イシュートラッカーに、問題提起というより罵倒や陰謀論、政治的メッセージなどが殺到した事例に言及している
こうなると生産的な議論そのものが不可能になり、リポジトリ管理者が迅速に議論を止めざるを得なくなる
そのリポジトリの議論ロック措置は、実はApple社員が行ったものだと聞いた
だが人々は、このイシューを立てたGoogle社員の責任にしているらしい
Googleは最近、コミュニティの意見収集を掲げてオープンな議論を行ったが、その後はすべての意見を無視して押し通そうとしている
関連イシュー
古いWeb要素に関する全般的な考察が必要だ
私の場合、昔のWebページも今なお正しく動くことで得られる価値が大きい
HTML/JSが互換性を守ってきたおかげで、何十年も前のページですらTLS証明書さえ付ければ今でも正常に動く
しかし、あらゆるレガシー技術を永遠にサポートし続けることはできない
Flashも結局はエミュレータ（Ruffle）を通じて、懐かしいゲームやサイトを体験する形へと移った
長期的には、古いレンダリングに特化した専用ブラウザやエミュレータを使うことも代案になり得る
すでにそのためのXSLT polyfill拡張が登場している
Chromeはこれを公式に配布したり保守したりしたいとは思っていない
Ruffleと非常によく似た状況である