XSLTの死 — GoogleがXSLTサポートを終了へ

 (xslt.rip)
1 ポイント 投稿者 GN⁺ 2025-11-11 | 2件のコメント | WhatsAppで共有
  • Googleが 2027年までにXSLTサポートを完全終了する計画を正式発表
  • XSLTは XML文書を別のXML形式に変換する言語 で、複数の政府系ウェブサイトでも使用されている
  • Googleは過去に 2013年にもXSLTサポート終了を試みており、今回は2度目の試み
  • MozillaとAppleも XSLT削除への参加意向 を示しており、Googleとの 金銭的関係 にも言及
  • ウェブ標準とコンテンツのアクセシビリティに影響しうる 重要な技術的変化 と評価されている

GoogleによるXSLTサポート終了の発表

  • 2025年10月24日、GoogleはChromium開発者フォーラムに “Intent to Deprecate and Remove: Deprecate and remove XSLT” 文書を投稿
    • これにより 2027年までにXSLT機能が完全に削除される予定
  • Googleはすでに 2013年7月にもXSLT削除を試みた ことがある
    • 当時の試みは中止されたが、今回の発表で12年ぶりに再開された

Googleの技術廃止の履歴

  • これまでにGoogleは 約300件の技術を終了 したとされる
    • 代表例として Google Reader は2013年3月13日に終了が発表された
  • XSLTもまもなく 『Killed by Google』の一覧 に追加される見込み
  • 記事では「GoogleはXMLとRSSを嫌っている」という表現を用い、RSSとXSLTの関連性 を強調している

XMLおよびRSSに関する主張

  • RSSは ニュース配信に使われる技術 であり、記事ではGoogleがこれを排除することで ニュースを統制できる可能性 に言及している
  • XSLTは 複数の政府系ウェブサイトで使われている技術 で、Googleの措置が 立法関連のウェブ技術にも影響 を与えうると指摘している
  • 「GoogleがXMLとRSSを排除することでウェブに対する統制力を強める」という批判的な見方を提示

他のブラウザの立場

  • Mozilla は、XSLTの削除が「既存のウェブコンテンツを壊す可能性がある(break existing web content)」と述べた
  • Apple は、Googleの2027年のスケジュールより もっと早く参加したい(participate sooner) との立場を表明
  • 記事ではGoogleが Mozillaに年間約4億2,000万ドル、Appleに1年間で200億ドル を支払ったと引用している
    • 過去10年間で両社に合計 約2,442億ドル が支払われたという計算も示している

XSLT保全の呼びかけ

  • 筆者は「GoogleにXSLTを殺させないようにしよう」というメッセージを強調
  • 「XSLTをウェブサイトやブログに追加しよう」という行動の呼びかけも含まれる
  • 「Keep XSLT alive!」というスローガンで締めくくり、ユーザー参加と技術保全 を訴えている

関連記事

2件のコメント

 
t7vonn 2025-11-12

もう送るのはやめましょう。
 
GN⁺ 2025-11-11
Hacker Newsのコメント

  • サイトが本当にXMLドキュメントになっていてほしいと思ったら、幸い本当にXMLドキュメントだった。
    curl https://xslt.rip/ コマンドで確認すると、<html> タグの中に “If you're reading this, XSLT was killed by Google.” という文が入っている。

    • これはブラウザがXSLTをサポートしているかを見分ける巧妙な方法だ。
      実際のコンテンツは index.xsl にあり、作者はフロントエンドデザイナーで、dbushell.com という素敵な個人サイトも運営している。
      どちらのサイトにも個人的な感性が生きている。
    • 私にとってXSLTは、Webの複雑さを爆発的に増やし、結果的に2つのブラウザしか残らない状況を作った技術のように感じる。
      サイトのデザインが90年代のWebを思い出させて、妙に笑える。
    • テキストブラウザ（Lynxなど）でアクセスするとその文だけが見えるが、<noscript> で「このサイトはJavaScriptが必要です」と出るのに近い感じだ。
      いまやGoogle以外のブラウザでXSLTを実装しているところが残っているのか気になる。

  • 私はブラウザでのXSLTサポート廃止に強く反対する。
    個人サイトでJavaScriptの XSLTProcessor と <?xml-stylesheet …?> の両方を使っており、関連する GitHubスレッド にも意見を書いた。
    ただ、このサイトはやや大げさな表現を使っているように思う。Googleのセキュリティ・保守上の理由は本気だと思うが、方向性は間違っていると見る。
    こういうページは意思決定者を説得するより、むしろ苛立たせる危険がある。

    • そんな機能を使う人は本当にごく少数のエリートチームだろう。
    • XSLT変換をサーバー側でやれば最新のツールを使えるし、すべてのブラウザで動く。
    • サイトの大げささは意図されたユーモアに見える。
    • Webページ1枚で意思決定者を説得することはできない。このページの目的は単に問題意識を高めることだ。
    • libxslt はほとんど保守されておらず、セキュリティ脆弱性も多いので、削除は妥当だと思う。
      もしXSLTを生かしたいなら、Rustで新しい実装を作るのが最善だったはずだ。

  • 少数意見かもしれないが、XSLTが止まってしまった現実は残念だ。
    25年前、XML+XPath+XSLTのエコシステムを置き換えようとして無数の不完全なライブラリを作ったのは人材の無駄遣いだった。
    SOAPやXML Schemaのやりすぎは認めるが、JSON初期の eval() ベース方式も良いエンジニアリングではなかった。
    結局、より良いXMLシステムを作ることもできたのに、新しさに酔って既存の利点を捨ててしまったのが惜しい。

    • 良いXMLパーサーは今でもほとんどないが、JSONパーサーはたくさんある。
      Ruby、Python、JavaなどでXMLパースは常に苦痛で、JSONはずっと単純で安定していた。
    • JSONの仕様は 2ページ で終わるが、XMLの仕様は 本1冊分 ある。この違いだけでも重みが違う。
    • 昔XSLTを使ったことがあるが、本当にひどく嫌いだった。
      専任の専門家が必要になるほど複雑で、それ自体が無駄に感じられた。
    • それでもRSSファイルをブラウザで直接レンダリングできるなど、気の利いた使い道はあった。
      2010年代のセマンティックWebのアイデアが消えていくのは惜しい。

  • 私はXSLTをほとんど使わないが、Googleがまるで「Webそのもの」であるかのように振る舞うのが腹立たしい。
    uBlock Originを排除しようとする動きもそうだし、AIブラウザが現実を歪んだ形で見せるのも嫌だ。
    政府や企業が仲介者として情報を統制する世界は望まない。
    Google検索の品質も、もう5年前から意図的に悪化させられていると思う。

    • 私も同感だ。XSLTには関心がないが、GoogleがHTMLを廃止すると言い出したら誰が止められるのかという疲労感がある。
    • いまブラウザエンジンが事実上3つしかないのは心配だ。
    • GoogleはSearch、Android、Chrome、AdSenseを分離すべきだ。
      広告独占、adblock排除、アプリインストール制限などでWebエコシステムを掌握している。
      それでもこのサイトのデザインは本当に美しく、レトロな味わいが生きている。
    • では代替モデルは何なのだろうか。
      Google内部でも「これは自分たちで担いたくないが、他に誰ができるのか」という形の決定が多かった。
      OpenGLがコンソーシアム型モデルで失敗しDirectXに押された例のように、標準の開放性だけでは市場を守れないという教訓がある。
      ブラウザ標準にも似た危うさがある。結局は誰が声を上げられるかが重要だ。

  • ブラウザがあまりに複雑なので、XSLT削除の判断には部分的に同意する。
    個人的にXSLTを使ったこともなく、RSSとの関連もそれほど大きいとは感じない。

    • ただ、気づかないうちにすでにXSLTを使っているかもしれない。たとえば 欧州議会サイト のような例がある。
    • 昔はRSSフィードを開くとブラウザが自動でスタイルを適用していたが、いまはただのXMLが表示される。
      例 / 過去のスタイリング説明 / 手動でスタイル適用した例
    • RSSフィードにXSLTを適用すれば、ブラウザ上で人間が読みやすい形にできる。
      lepture.comの例 のように、RSSリーダーを知らないユーザーにも役立つ。

  • もしGoogleが明日がんを治療しても、誰かは「Googleががんを殺した」と言うだろう。
    小規模ブラウザ企業が古いXSLTコードを保守したがるはずもないし、新しいブラウザが追加される予定もないだろう。
    よく整理された判断だと思う。

    • ただ、小さなブラウザはもともと必要な機能だけを選んで実装する。
      だとすれば、この決定に賛成している企業が具体的にどこなのか気になる。
    • 「小さなブラウザ」とは、具体的にどのあたりを指しているのか聞いてみたい。

  • このサイトは一種のロールシャッハ・テストのようだ。
    「GoogleがXSLTを殺した」という批判と、「2025年にXSLTを推しているのは滑稽だ」という風刺の両方を含んでいる。
    「友人や家族にXSLTを伝えよう！ 手遅れになる前にWebサイトへ追加しよう！」という文句がそれをよく表している。

    • 明らかに誇張を風刺する意図だ。
    • ただ、私は実際にAtomフィードのためにXSLTを使っている。
      静的サイトでRSSを見栄えよくレンダリングするにはXSLTが唯一の方法だ。
      こうした変化は個人Webの自律性をさらに奪い、大規模Webアプリ中心へと押し流す流れだ。

  • ひとつの時代の終わりのように感じる。
    昔XSLTチュートリアルを学びながら、XML文書を「生きて動く」ものにする感覚が新鮮だった。
    今でも 自分のRSSフィード にスタイルを当てるのに使っている。
    関連告知へのリンクは Chromiumフォーラム投稿 と Chrome開発者ドキュメント だ。
    保守負担が大きいのは理解するが、Webの小さな楽しみがまたひとつ消える感じがする。

  • Googleはすでにほぼあらゆる領域を独占している。
    Androidの事例（関連リンク）のように、いまや何が許され何が禁じられるかまでGoogleが決めている。
    だから keepandroidopen.org のように、keepXSLTAlive.tld のようなキャンペーンサイトを作るとよいかもしれない。
    あるいは xslt.rip のUIを少し整えて、抵抗の空気を出すのも悪くなさそうだ。

    • ただ、Google批判が正しいとしても、それがXSLTを維持し続ける理由にはならない。
      技術はそれ自体の価値で評価されるべきだ。

  • このWebページ、本当にすごくいい。
    突然 <iframe>、<blink>、<marquee>、<table> タグで90年代風のHTMLページを作りたくなる。

    • 冗談だけど、blinkとmarqueeはいまやCanvasでレンダリングしないといけない。
      いや、Canvasも古いからWebGPUでやるべきか。
    • 「工事中」バナーは絶対に必要だ。
    • 最近、テーブルだけで構成されたページからデータを抽出しなければならなかったが、ネストしたテーブル地獄だった。