ハクソク

世界を動かす技術を、日本語で。

HTML仕様からXSLTの言及を削除する

279日前原文(github.com)

概要

  • XSLTサポート廃止 に関する懸念点の整理
  • 利用サイトの規模や更新頻度 の違いによる影響分析
  • <?xml-stylesheet … ?> サポート廃止の深刻な影響
  • 従来のWeb機能廃止 との比較
  • 個人的な経験 と「ロングテール」サイトへの配慮

XSLTサポート廃止に関する懸念点

  • XSLT利用ページの年齢や規模 に関する統計データの有無
    • 大規模・頻繁更新サイト中心なら、 polyfill対応 が現実的
    • 小規模・長期間未更新サイト中心なら、 恒久的なサイト破損 の可能性
  • XSLTの歴史 ：1999年からサポートされ、利用率は減少傾向
    • 影響を受けるのは主に 古い個人・大学サイト という推測
  • 機能廃止による現実的な結果
    • polyfill未対応 のまま破損するサイトの増加
  • プログレッシブエンハンスメント の重要性
    • JavaScriptやCSS機能廃止の場合、 ページの一部は利用可能
    • XSLTProcessor()の廃止なら JavaScript部分のみ破損
  • <?xml-stylesheet … ?>サポート廃止の問題点
    • 非技術ユーザーには 生XML表示＝完全に利用不可
    • 従来の廃止機能 （JavaScript/CSS/HTMLタグ）は部分的影響のみ
      • 例：<font>、align=、<xmp>などは今も動作
    • 純粋な文書用途の機能 が廃止されるのは前例なし

「ロングテール」サイトと情報保存の重要性

  • XSLTProcessor()や<?xml-stylesheet … ?>を利用する個人経験
    • polyfill追加は可能だが、 自分のサイトは更新対応可能
  • 懸念点：ロングテールの情報資産
    • 2005年以前に更新停止した 大学・個人サイト
    • Internet Archive にしか残っていない重要情報も多数
    • <?xml-stylesheet … ?>やレガシーHTML機能 利用サイトの消滅リスク
  • 文化・学術的価値の損失 への危惧

関連議論

  • Hacker Newsスレッド
    • “Should we remove XSLT from the web platform?”
    • https://news.ycombinator.com/item?id=44909599

Hackerたちの意見

以前: XSLTをウェブプラットフォームから削除すべきか？ – 4日前（89コメント）: https://news.ycombinator.com/item?id=44909599 XSLT – ウェブのためのネイティブでゼロ設定のビルドシステム – 2025年6月27日（328コメント）: https://news.ycombinator.com/item?id=44393817

└

これに関連して、今フラグが立ってる: https://news.ycombinator.com/item?id=44949857 Googleがオープンウェブを潰してる、今日のコメント127件

@whatwgがロックしたのは、議論が熱くなりすぎたからで、コラボレーターに限定された会話になった。 熱くなりすぎた？私にはかなり礼儀正しくて妥当に見えたけど。コメントする人が特定のベンダーに対してどれだけ共感しているかによって、熱さへの耐性が変わるって提案するのはおかしいかな？

└

たった3週間前に「コミュニティのフィードバックを集める」ための議論が開かれたんだ。それは熱くなったよ: https://github.com/whatwg/html/issues/11523 Googleは全てを無視して、削除を進めて、今度はこの議論も先手を打って閉じちゃった。

└

「熱すぎる」っていうのは、「反対意見に関わりたくない」っていう隠語だよね。他のフォーラムでも同じことが言える、例えばRedditとか。

└

その下に見える1つのコメントが「いいね、これに取り組んでくれてありがとう！」っていうのがちょっと違和感ある。書いたユーザーをクリックすると、GoogleでChromeに関わってる人だし…うーん、媚びすぎじゃない？

└

なんで人はこんなジョークみたいなPRを作るんだろう？ 「お前たちの10年間のクソみたいなことは忘れてないぞ、Google。」 「熱いコメントが欲しかったのか？ちゃんと用意してやったぞ。」 「新世代の頭を壊したJavaScriptの脳虫。」 「WHATWGが仕掛けている隠れた戦争。」 「これは技術的な妨害以外の何物でもなく、恥ずべきことだ。」 「広告やLLMのゴミを提供するのに都合が悪いオープンウェブの一部をまた壊してる。」 「Google、Apple、Mozillaは、クライアントサイドのXSLTサポート削除によって影響を受けた人たちの追加ホスティングコストを支払うのか？」 「ヒント：嘘をつきたくないなら、嘘をつくな。」 「プライバシーを無効にするビジネスを築いた悪のビッグデータ企業。自由と民主主義を壊すビジネスを築いた企業。」 「プライバシーと自由の味方になるのか、それとも独裁の味方になるのか？」こんなクソみたいなことはイシュー・トラッカーにはふさわしくない。生産的な会話のために設計された場所で、みんなが子供みたいに振る舞わなければ、リポジトリのオーナーもそんなにトリガーハッピーにはならなかったかもしれない。

└

ちなみに、あのリポジトリを管理してるのはAppleの社員らしくて、その人たちがコメントをオフトピックとしてマークしてスレッドをロックしたって聞いたけど、みんなはそれをその問題を開いたGoogleの社員のせいにしてるみたい。

これについては特に意見はないけど、私の唯一のXSLTの話をシェアするね。私の最初のソフトウェアの仕事は、約500人の従業員がいる非営利団体でのソフトウェアテスト開発のインターンだった。2008年頃、19か20歳の時だったかな。ソフトウェアをテストするためのソフトウェアを書く仕事。そこでの2年間の間に、XMLテストデータフォーマットのドキュメントを書くという仕事があったんだ。テストデータはXMLドキュメントで書かれ、それをテストランナーで検証してた。なんとなくXSLTのことを知って、これが完璧な解決策だと思った。だから、XMLテストデータのためのXMLスキーマをXSDで書いたんだ。ドキュメントはスキーマの中にあって、型定義と一緒にあった。そして、XMLスキーマを受け取ってHTMLページを出力するXSLTドキュメントを書いた。これも基本的にはXMLだよね。だから、実質的にはXMLプログラムを書いていて、XMLを入力として受け取り、XMLを出力してた。全部ブラウザのドキュメントビュー時にね。実際に動いて、すごく誇りに思ったのを覚えてる。公式ブラウザ（Internet Explorer 7、もちろん）で動いたのは確かだし、好きなブラウザのFirefox（バージョン3、新しいAwesomeBarがあるよ、やばい）でも、ちょっと頑張って動かした記憶がある。あのXMLの悪夢がどうなったのか、今でも気になる。誰かが実際に使ったり、しばらくメンテナンスしてくれたのかな。多分、避けられないリライトの時に全部捨てられちゃったんだろうけど。それでも、今でもあのXSLTの「プログラム」を懐かしく思い出すよ。

└

私のXSLTの話: 2008年頃に、XSLTを使ってブラウザで見れるようにXMLで個人ウェブサイトを書いたんだ。CSS Zen Gardenにインスパイアされたのは間違いない。あの同じHTMLが違うCSSで全然違う見た目になるのが面白かったけど、CSSが難しすぎると思ったから、個人ウェブサイトのテーマごとにXSLT変換を書く方がメンテナンスしやすいと思った。あの個人ウェブページは、静的サイトジェネレーターの流行の私なりのバージョンだった。XSLTに80%の時間を使って、ウェブサイトのコンテンツには20%使った。すごくいい思い出だけど、XSLTを書くのは本当に難しかった。

└

約25年前に働いていた会社で、デバッグ機能付きの完全なXPathとXSLT言語を実装したことがある。楽しかったよ（XPathとXSLT 2まではね。まあ、それも楽しかったけど、言語のせいじゃなくていい同僚のおかげ）。でも、どうしてこれが流行って、Lispが流行らなかったのか、ずっと不思議に思ってた。

└

XMLの狂騒の後、どこでも技術が持ち上げられているのを見ると、XMLの時代を思い出して無視するようにしてる。

└

NFTを笑うことはできるけど、正直言って「なんとなくうまくいく/いいアイデアっぽい」技術的解決策がたくさんある。でも結局は、利害関係が絡んだカードの家みたいなもんだよ。人々がXMLについてあんな分厚い本を書くためにエネルギーを注いでるのを想像してみて。図書館の神学のセクションにファイルされるべきだね。

└

「よ、ダグ、君がXML好きだって聞いたよ…」

└

一度、私たちのシステムが生成したSOAPリクエストを変換するためにXSLTを使おうとしたことがあるんだけど、プロバイダーの実装がそれを受け入れるようにするためにね。XSDやWSDLをしっかり理解しないと、どの部分が壊れてるのかを見つけるのが難しかった。長いプロセスの末、特に問題があったエンドポイントから提供されたリファレンスリクエストXMLをハードコーディングして、いくつかの正規表現置換を使って、終わらせたよ。

これが悲しいことだと思うけど、もっと現代的なXSLTを統合する努力をしなかった方が悲しいと思う。使うのは痛かったけど、ブラウザで数回修正があれば、Reactのようなものに対抗できる存在になったと思う。XMLはIBMや他の企業が結びつけた負担のせいで不当に悪者にされてたけど、標準自体は本当に素晴らしくて強力だった。

└

同意する。XSLTが好きで、ちょっとした追加があればもっと色々できたと思う。手動で編集したシンプルなXMLデータベースをHTMLに変換するのは最高だった。特に、選択したアイテムを違う形で表示する機能が欲しかった。それがあれば、静的なドキュメントとのインタラクティビティが色々できたのに。

実はこれ、悪くないアイデアだと思う。ブラウザがXSLTみたいな特定のテンプレートエンジンを含む必要があるの？例えばJinjaでもいいじゃん。JSやWASMを使って再実装できるし。今のブラウザは重すぎて、新しいブラウザエンジンを作るのが難しい。もっとシンプルな「ミニマルブラウザ」の基準があればいいのに。例えば、基本的なHTMLタグやレイアウトルール、WASM、Javaバイトコードだけをサポートするみたいな。WebAudioやCanvasみたいなものはWASMモジュールを使って実装できるし、そのおかげでフィンガープリンティングに使われるのを防げるかも。

└

最初はクレイジーに聞こえるかもしれないけど、機能の層をいくつか重ねていくことで、ブラウザが特定の層だけを実装する選択ができるようになるんだ。最も基本的な層はHTTPとプレーンテキスト、次がHTML、その次が基本的なセレクタを持つCSS、さらにフルセレクタセットのCSS、ECMAやWASM、デバイスAPI、みたいな感じで続いていく。これによって、必要なものを削ぎ落としたり、無理やり組み込んだりせずに、異なるユースケースに応じた仕様準拠のブラウザを作れるようになるんだ。

└

なんでブラウザにXSLTみたいな特定のテンプレートエンジンが必要で、Jinjaみたいなのはダメなの？ 歴史的な理由もあるし、彼らはテンプレートエンジンをゼロにしたいみたいだね。JinjaやMustacheの一部をXSLTにトランスパイルすることはできるけど、誰もそれをやったり気にしたりしてないみたい。

└

なんでブラウザにXSLTみたいな特定のテンプレートエンジンが必要で、Jinjaみたいなのはダメなの？ JSやWASMを使って再実装することもできるよね。専用のサポートされていないメディアタイプからサポートされているメディアタイプへのWASM変換インターフェースがあったらいいと思う。新しい画像フォーマットとかにも使えるし。これをやってるJXL.jsみたいなものもあるよ。

└

あまり使われていない、ウェブらしくない機能を削除するのは妥当だと思います。ただ、セキュリティの脆弱性を理由に隠れるのはやめてほしいですね。それが本当の理由じゃないのは明らかですし。著者はメモリセーフなパッケージが存在するかどうかも調べようとしませんでした。「あなたのためにこれを削除します」というのは最悪のやり方ですが、スレッドの後半でもその考えを貫いています。[0] ある投稿によると、使用率は約0.001%だそうです。

└

なぜブラウザにJavaScriptのような特定のスクリプト言語が含まれ、ActiveScriptのようなものは含まれないべきなのでしょうか？

└

ウェブキットをUDK（ゲーム開発用のアンリアル開発キット）と比較して、なぜブラウザにこんなに膨大なものがあるのか考えてみてください。人々はますます高度なものをレンダリングしたいと思っていて、ウェブキットエンジンはできる限りそれに応えようとしています。良くも悪くも、httpはもはや単なるテキスト文書を提供するためのものではありません。

└

これは実際、悪くないアイデアだね。なんでブラウザが特定のテンプレートエンジン、例えばXSLTを含む必要があるの？XSLTは「テンプレートエンジン」の仕様であって、特定のエンジンじゃないんだ。XSLTの実装はたくさんあるし、Mozillaはlibxsltじゃなくてtransformiixを使ってるよ。 > それに、例えばJinjaじゃなくて？Jinjaはテキストを扱うから、基本的にはdocument.write()みたいなもんだ。XSLTはノード自体で動くから、そっちの方がいいよ。 > それに、JSやWASMを使って再実装することもできる。まあ、そうだけど。JSはネイティブのXSLT変換よりもずっと遅いし、XSLTの結果はキャッシュできるから、それは大きいよ。もしXSLTを誰も使わない古い技術だと思ってるなら、これが大丈夫だと思うのもわかるけど、私はそれを秘密兵器として見てるんだ。20年間使ってきたけど、他のどれよりも速いからね。Googleは自分たちが作ってる問題を解決するために、またAMPを押し出してくると思うよ。 > 今のブラウザは重すぎるよ。いや、Googleのブラウザが重すぎるんだ。それはGoogleのせいだよ。 > 新しいブラウザエンジンを作るのは難しいって言ってるけど、何かをやらない理由を探してるなら、難しいを作るのと売るのを混同しない方がいいよ：解決策の間にはほとんど重複がないからね。

└

古いバグだらけのネイティブXSLTコードも、非推奨にするんじゃなくて、ブラウザと一緒にWASMとして配布できるはずだよ。サンドボックスが脆弱性を無効にして、古いサイトを壊さずに済むからね。実際にそれを考えたけど、やらないことに決めたみたいだね :-/

└

なぜブラウザに特定のテンプレートエンジン、例えばXSLTが必要なの？XSLTはテンプレート言語（HTMLがコンテンツ言語であるのと同じ）で、ブラウザエンジンのBlinkやWebKitとは違うテンプレートエンジンじゃないし。 > それに、JSやWASMを使って再実装できるし、実装を変えることはウェブプラットフォームからその言語を取り除くことにはならないよ。どのブラウザで使う実装を変えるかについて、標準化の話をする必要もないしね。

└

WebAudioやCanvasのような多くのものは、WASMモジュールを使って実装できるけど、その副作用としてフィンガープリンティングに使われるのを防ぐことができる。オーディオやキャンバスは基本的なI/Oのものだから、WASMに移行することはできないよ。理論的には、オーディオのかなりの部分をWASMのブロブに移行できるかもしれないけど、MozillaのオリジナルのAudio Data APIのようなものを公開して、Web Audio APIが何らかの理由でそれを打ち負かしたものを実装することになる。2DキャンバスコンテキストにはDOMレンダリングと一致させる必要があるレンダリングの要素が含まれてるから、ピクセルデータを公開して、その上に2Dコンテキストの残りをWASMのブロブで実装することもできない。できるだけ多くの2DコンテキストをWASMに移行すると、パフォーマンスが壊滅的になるよ。WebGLやWebGPUコンテキストについては、GPU統合が全てだから、それをWASMでやることはできない。だから、君が言ってるWASMでできることはプリミティブなものだから、絶対にできないよ。

いくつか注意すべき点があるよ： - これはChromeが一方的にやってるわけじゃない。https://github.com/whatwg/html/issues/11523 には、すべてのブラウザの代表者が支持していることが示されていて、スタンダード会議でもこの件について話し合われてるよ： https://github.com/whatwg/html/issues/11146#issuecomment-275... - WHATNOTの会議の議題からも、最後に提案したのはMozillaのエンジニアだってわかる。 - PRを開くことが必ずしもマージされることを意味するわけじゃない。チェックが入ってないタスクもあるし、まだやることがたくさんある。この件については、クロスベンダーのサポートがあるから、いつか進む可能性が高いと思う。

└

それと、https://github.com/whatwg/html/issues/11523（XSLTをウェブプラットフォームから削除すべきか？）はコミュニティフィードバックのリクエストじゃないよ。HTML仕様のメンテナが検討するためのイシューが開かれているだけ。これは、Mozillaのエンジニアがこの話題を持ち出した少なくとも二回の会議の後にChromeのエンジニアによって開かれたもので、どうやらベンダーの支持もあったみたい。これは、いくつかの深刻な脆弱性が見つかった後に起こっている。libxsltのメンテナが辞任したのも影響してるみたいだ。

└

元MozillaとGoogle（特にChromeチーム）の開発者です。あなたが言っていることを私なりに解釈すると、Chrome/Blink、Safari/Webkit、Firefox/Geckoの代表者たちは、XSLTをウェブプラットフォームから削除することに賛成しているようです。たとえそれがまだ使われているかどうかに関わらず。Mozillaの誰かがそれを持ち出したから、問題ないってことですね。この3つのプロジェクトのうち、2つはリソースが不足していて、1つは他の2つが追いつけないペースで新機能をどんどん押し進めていることで有名です。リソースが不足しているSafariやFirefoxの人たちが、仕事を減らす口実を求めない理由は何でしょうか？この権威への訴えは私には通用しません。重要な質問は「特定の優先事項を持つ人たちがこれを良いアイデアだと思っているか」ではなく、「このアイデアがウェブプラットフォームやその数十億のユーザーに悪影響を与えるかどうか」です。その数十億のユーザーの中には、XSLTに依存している人がかなりいる可能性がありますが、この問題について調べた限り、XSLTを使っていないという具体的なデータは見当たりませんでした。もし誰も使っていないなら、そのポリフィルが必要になることはないでしょう。根本的に問うべきことは、毎日数十億人がウェブを使っているということです。つまり、彼らはHTML、CSS、XML、XSLTなどの技術に依存しています。ユーザーの0.1%が依存しているものを壊してもいいのでしょうか？もしそれが許されるなら、でもその10万人に「君たちは重要じゃない」と誰が言うのでしょうか？私が見た主張は、GoogleはXSLTのサポートを維持するリソースがないというものでした。あるグーグラーは、新しいウェブAPIがより人気があり、リソースを割く価値があると主張しました。つまり、プラットフォームに新機能を追加するたびに既存の機能を削除しなければならないゼロサムゲームが生まれてしまったわけです。そのゲームはどこで終わるのでしょうか？最終的には、十分な人に使われていないからといってARIAやスクリーンリーダーのサポートを削除することになるのでしょうか？私は、3つのブラウザベンダーすべてがユーザーをできる限りサポートする義務があると思います。そして、GoogleはXSLTのユーザーをサポートするための財政的および人的リソースを持っているのに、それを選ばないのです。

└

それに、Chromeのテレメトリによると、実際に使っているウェブサイトは非常に少ないです。提案がウェブのかなりの部分をアクセス不可能にする脅威になっているわけではありません。少なくとも、ここで提案の裏にあるデータは確認できます。

└

実装は実装者が所有しています。実際の標準は、実装者が所有しているのか、それともユーザーが所有しているのか？

└

このスレッドの一部の人の反応を見て、これを思い出したよ： https://xkcd.com/1172/

└

ありがとう、上のタイトルを「デクローム」したよ。（提出されたタイトルは「ChromeはHTML仕様からXSLTを削除するつもり」だった。）

ああ、やっぱりそのことが起こったね。XSLの運命は、ブラウザがFTPサポートを外した時点で見えてた。攻撃面を最小限に抑えたいっていう欲求が、現状維持を好む傾向を上回るんだろうな。次に削除されるあまり人気のない機能は何になるんだろう。SVGアニメーションのためにCSSに移行するSMIL属性とか、ずっと文句言われてるし。もしかしたら、結局ネイティブのMathMLサポートが嫌われることになるかも。要するに、「CSS属性」や「JSメソッド」に収まらない機能はリスクがある。XML関連のほとんどのものがそうだね。

└

彼らの攻撃面を最小限に抑えたいという欲求が、現状維持を好む傾向を上回っている。 それっていいことなのか悪いことなのか？ 技術者の私たちには欲求があるけど、ブラウザで銀行取引をしている何十億人の人たちは多分違う優先順位を持ってるよね。

└

ブラウザがFTPサポートを削除した時点で、XSLの運命は決まっていた。 それっていつの話？まだftp://example.comをURLバーに入力できるんじゃないの？

└

CSSアニメーションは、他のアニメーションの始まりや終わりに基づいてアニメーションをシーケンスするためのセマンティックな方法がまだないんだよね。SMILが提供してるやつ。SMILを使えば、「このアニメーションIDが始まったり終わったりしたときにだけ、この別のアニメーションをトリガーする」って言えるし、その時点からの時間オフセットも含められる。これって、CSSアニメーションのタイミングを計算するためにCSS変数とかを使って、いつ始まるか終わるかを追跡する必要があるのとは比べ物にならないくらい良いよ。数年前、Firefoxも確か時間ベースの計算をサポートしてなかったし。Chromiumが10年前にSMILを非推奨にする意向を発表したとき（その後撤回したけど）、その時のCSSはSMILが許可していた多くの機能が欠けていたから、早すぎたと思う（パスに沿った動きやSVG属性値のアニメーションも含めて、CSSのサポートは後からだったし）。それに、SMILについての警告記事が連鎖的に出てきて、更新もされなかったから、混乱を招いたよね。LLMですら、SMILがChromiumでまだ非推奨だと思ってたのを覚えてる。

だから、二つのスレッドを正しく読んだら、要するにGoogleはフィードバックを求めて、ほとんどのフィードバックが「いや、やめてくれ」って言ってたってこと？ それに対して「フィードバックありがとう、でもやるから！」って返したの？ 他の無視された提案は「これがセキュリティに関することなら、OSSプロジェクトに資金を提供するか、新しい安全なライブラリに切り替えるか、JSサンドボックスに取り込んでサポートを維持するべきだ」って感じだったけど、ほとんど無視されてた。あと「採用に関することなら、何年も前から出ていて、JSONの扱いを含む多くのQoL改善がある新しいXSLT 3.0の更新をコミュニティが常に求めているのを聞くべきだ」っていうのもあった。提示された主張は、XSLTがオープンウェブをサポートしているってこと。Googleは10年前にそれを潰そうとしたけど、コミュニティが反発して止めた。だからGoogleの計画は、サポートするために何もしない、コミュニティの簡単な改善要求を無視する、徐々に衰退させてそれを後で潰す理由にするってことだった。ほとんどのフィードバックが反対している中でこれを強行するのは、そのことを支持しているように思える。特にXSLTが最近急に人気を集めているのに、オープンな競争相手が出てくる前に潰そうとしているみたいだし。

└

ウェブは実質的にChromeOSのためのものだけど、そうするとAppleが協力しないと文句を言う人たちがいますね。

└

基本的に、全てのフィードバックは「いや、お願いだからやめて」って言ってたよね。そして「フィードバックありがとう、でもやるから！」って言ったの？これはフィードバックが「やめて」って言ってるのに、実際に使ってる人や必要性を説明できる人が言ってないなら、全く合理的な行動だと思う。これはフィードバックを求めてるのであって、ただのアンケートじゃないんだ。

└

JSやWASMのサンドボックスにXSLT 3.0サポートを引き込むことができたら、すごいことになるね。パフォーマンスの影響はあるけど、両方の良いとこ取りだよ。

└

Googleは、ウェブに何をするつもりかを疑問符をつけて教えてくるよ。

└

XMLの領域には、バージョン管理されたスキーマや名前空間があって、XSLTでプログラムできるのがついてくるんだ。これによって、一般的に統合は公的で信頼できる契約のおかげで簡単になる。普通のAngularプロジェクトとは違ってね。ミニファイドされたTypeScriptの上に構築するのはかなり無理があるし、JSONと統合するのはスキーマなしで信頼性の低いデータ転送プロトコルを持つことになるから、バリデーションは粗い試行錯誤のプロセスになるんだ。生のXMLやその関連物にはエレガンスはないけど、このファミリーの成熟度のおかげで、非常に成熟したツールもあるから、実際にはXMLやXSDをテキストとして見る必要はないんだ。選んだプログラミング言語にアンマーシャルして、他のデータ構造を見るように扱えるんだ（もちろん、適切なものを選べばだけど）。

HTML仕様の基本的な約束を破るのは大きな問題だよね。その議論はそれに触れてないのが驚きだ。これが仕様を担当してる人たちのように見えるから。約束は「これがHTMLだ。信じていいよ。」なのに、今は「これが今のHTMLだ。でも、これがそのままでいるとは限らないよ。」って感じになっちゃう。やるべきじゃないとは言わないけど、大きな問題だよ。XSLTを長尾技術だからって理由で取り除こうとしてるんだ。他の長尾ウェブ技術にも同じことが言えるよね。だから、彼らが本当に提案してるのは、ウェブの長尾を切り捨てることなんだ。（ちょっと言っておきたいのは、長尾ウェブ技術のリストは時間とともに増え続けるだろうってこと。約20年前にウェブ技術が追加されたペースに比例して増えると予想できる。つまり、長尾ウェブ技術の爆発がすぐに来るかもしれない。今ウェブを運営してる人たちが、私たちが望むようにウェブの長尾を大切にしているかどうか、慎重に考える必要があるかもしれないね。）

ちなみに、BlinkやWebKitのXSLT実装は非常に非効率的なんだ。例えば、ドキュメント全体を文字列に変換して、それをlibxsltと互換性のある形式に解析してから、再びノード構造に戻すための文字列を生成するって感じ。ユーザースペースライブラリも同じくらい効果的かもしれないと思ってる。例：https://source.chromium.org/chromium/chromium/src/+/main:thi... https://source.chromium.org/chromium/chromium/src/+/main:thi... https://github.com/WebKit/WebKit/blob/65b2fb1c3c4d0e85ca3902... Mozillaは少なくとも社内実装を持ってるみたいだね：https://github.com/mozilla-firefox/firefox/tree/5f99d536df02... 互換性の問題の答えはMathMLアプローチかもしれない。外部のベンダーがすべてのブラウザに実装を提供する必要があるだろうね。おそらく、ポートしやすい非常に非効率的なルートを取ることになるだろうけど。