Interop 2024でさらに良くなるWeb

 (webkit.org)
2 ポイント 投稿者 GN⁺ 2024-02-03 | 1件のコメント | WhatsAppで共有
  • Interop 2024 は、主要なブラウザエンジンのチームが同じWeb機能をより一貫して実装できるよう足並みをそろえる共同プロジェクトであり、今年は17の重点分野と3つの調査プロジェクトで進められる
  • 相互運用性の改善は Web Platform Tests のような自動テストで測定され、WPT は180万件以上のテストを備え、主要ブラウザ全体で95%以上が合格している
  • Interop 2023 は、選定テストにおける3大ブラウザエンジン共通の合格率を48%から95%へ引き上げ、P3 color、Subgrid、Container Queries、:has()、Web Components、Media Queries 4 のサポートを大きくそろえた
  • 今年は96件の提案から16件を選び、2023年の作業の一部を引き継いで Accessibility、CSS Nesting、Custom Properties、IndexedDB、Layout、Popover、URL など17分野に注力する
  • Microsoft Edge が Interop ダッシュボードに独立した列として追加され、ブラウザごとの進捗状況をより直接的に比較できるようになった

ブラウザ相互運用性をそろえる方法

  • Web はさまざまなデバイスで動作するよう設計されており、数十億人が共同作業、学習、つながりのために利用できる
  • 開発者がすべてのブラウザとすべてのユーザーに同じ体験を提供するには、Web技術のブラウザ実装が互いに似通っている必要がある
  • 実装の一貫性は Web 標準プロセスの中で作られ、新しい Web 技術の動作は詳細な技術文書で定義される
  • ブラウザが Web 標準に従っているかは自動テストで確認する
    • Web Platform Tests には180万件を超えるテストがある
    • 主要ブラウザ全体で 95%以上 の WPT が合格している

Interop 2023 がもたらした変化

  • Interop 2023 は、2023年1月時点で選定テストの48%が3大ブラウザエンジンすべてで合格している状態から始まった
    • 基準ブラウザは、ユーザーに配布された Chrome と Firefox デスクトップ Linux、macOS Monterey 上の Safari だった
  • 1年後、合格率は 95% に上昇した
    • 基準ブラウザは、Chrome Dev、Firefox Nightly デスクトップ Linux、macOS Ventura 上の Safari Technology Preview だった
  • さまざまな Web 機能でブラウザ間のサポートが改善された
    • P3 color は、提供開始から7年後にすべてのブラウザで完全にサポートされるようになった
    • Form controls は Web の歴史上初めて縦書きモードをサポートした
    • CSS border-image は本来意図された通りに動作するようになった
    • Subgrid、Container Queries、:has()、Motion Path、CSS Math Functions、inert、@property がすべての最新ブラウザでサポートされるようになった
    • Offscreen Canvas、Modules in Web Workers、Import Maps、Import Assertions、JavaScript Modules などの Web API が改善された
    • Media Queries 4 の全仕様が、より簡単な構文とともにどこでもサポートされるようになった
    • Web Components は adoptedStyleSheets、ElementInternals、Form-Associated Custom Elements、Shadow DOM と Custom Elements の基本動作で改善された
    • :nth-child()、:nth-last-child()、:modal、:user-valid、:user-invalid のような CSS 疑似クラスで、一貫したブラウザサポートが期待できるようになった
    • Feature queries はフォント機能の検出を新たにサポートした
    • Font Palettes はカラーフォントのサポートを強化した
    • CSS Masking、HTML Forms、Pointer and Mouse Events、Scrolling、Transforms、URL、WebCodecs、Web 互換性バグのまとまりでも大きな進展があった
  • Interop 2023 の26の重点分野のうち20分野は成功として完了した
  • 2024年も Custom Properties、Pointer and Mouse Events、URL、そして Flexbox・Grid・Subgrid をまとめた Layout の作業は継続される

Interop 2024 の構成

  • 2024年には96件の重点分野提案が検討され、最終的に16件が選ばれた
  • 一部の新提案をまとめ、2023年の作業の一部を引き継ぐことで、Interop 2024 は合計 17の重点分野 を持つことになった
  • 安定版ブラウザ基準では、Interop 2024 の全体スコアは偶然にも再び48%から始まった
  • 今年から Interop dashboard に Microsoft Edge の独自列が追加された
    • 現在この列は、Windows 10 上で動作する Edge と Edge Dev を示している

2024年の重点領域

  • Accessibility

    • Interop 2023のAccessibility調査プロジェクトで、AppleのアクセシビリティチームがWPT向けのアクセシビリティテスト基盤を構築し、1,300件を超えるアクセシビリティテストを作成した
    • これらのテストがInterop 2024の重点領域に含まれ、ブラウザのアクセシビリティ対応改善を促している
    • 新しいアクセシビリティテストの大半はWAI-ARIAを扱う
    • 特にRoles ModelとAccessible Name and Description Computationが中心だ
    • これらは、支援技術の利用者が要素の目的やできることを理解できるよう、一貫したメカニズムを提供する
    • HTML Accessibility API Mappings specification関連のテストも含まれる
    • HTML要素の基本的なアクセシビリティ上の意味や、<label>、画像のaltテキストのような機能に関するブラウザの動作規則を定義する
    • display: contentsのアクセシビリティテストも新たに含まれる
    • このCSS表示モードは、FlexboxやGridのために親・子・孫の関係を調整する際、コンテンツの周囲のボックスを取り除くのに役立つ
    • 初期実装では、ボックスを取り除くとアクセシビリティツリーからもコンテンツが完全に消えてしまい、支援技術の利用者に問題を引き起こしていた
    • ブラウザでは大半の問題が修正されたが、すべての状況で完全に解決されたわけではない

  • CSS Nesting

    • CSS Nestingは、実装差を減らし、開発者が信頼して使えるようにするためInterop 2024に含まれた
    • CSSのネスト機能は2023年に主要4ブラウザすべてで提供された
    • Chrome、Edge、Safariは4月と5月に先行して提供した
    • Firefoxは8月に提供した
    • Web標準は5月から8月の間にわずかに変更され、すべてのネストされたセレクタが記号で始まらなければならないという当初の要件が緩和された
    • 開発者は& articleの代わりにarticleを使える
    • 実装はすべて更新されたが、Nestingの複雑な細部の動作がCSS Working Groupで整理されている間は、相互運用性を改善する余地が残っている
    • Safariのテスト失敗の大半は、ネストされたCSSがShadow DOMや:hostを通じて相互作用する方式に関連している

  • Custom Properties

    • @property at-ruleはここ数年でブラウザへの搭載が始まった
    • Interop 2023のCustom Properties領域では、すべての安定版ブラウザに共通するテストの通過率が4%から7.6%に上がり、プレビューブラウザ全体では90.7%が通過した
    • Firefoxが最後に対応を追加するブラウザで、現在Firefox Nightlyで作業中だ
    • 作業が完了していないため、2024年も重点領域として継続される
    • @propertyを使うと、CSSカスタムプロパティの構文、継承動作、初期値を、ブラウザエンジンがCSSプロパティを定義するのに近い形で宣言できる
    • これにより、グラデーションやtransformの特定部分のように、従来はCSSでは不可能だったアニメーションが可能になる

  • Declarative Shadow DOM

    • Declarative Shadow DOMは、JavaScriptなしでHTMLだけを使って再利用可能なウィジェットやコンポーネントを作れる宣言的APIだ
    • Safari 16.4は2023年3月から、Chrome 90は2021年4月から対応している
    • FirefoxはFirefox Nightlyで実装を備えている
    • State of HTML 2023の調査で頻繁に要望された機能の一つであり、すべてのブラウザで相互運用性を確保するためInterop 2024に含まれた

  • Font size adjust

    • font-size-adjustは、古い技術に注力することの有用性を示す例だ
    • Firefoxは2008年に最初に実装したが、Webデザイナーや開発者の間でほとんど使われたり議論されたりしてこなかった
    • 初期仕様は時を経て、2値構文によってより多くの言語をサポートし、from-font値によって使い勝手も改善された
    • WebKitチームはSafari 16.4で基本バージョンを実装し、Safari 17.0で更新を追加した
    • MozillaはFirefox 118で実装を更新しており、SafariとFirefoxは現在すべてのテストを100%通過している
    • Chromeは2015年に実験的実装を開始したが、まだ提供していない
    • Font size adjustは、テキスト文字列内の複数のフォントが同じ視覚的サイズに見えるよう揃える方法を提供する
    • たとえば1.4remのテキストで、x-height、cap height、ch width、ic width、ic heightを揃えられる
    • コードと通常のテキストを混在させたり、複数の言語を一つの文に混在させたりするときに有用だ

  • HTTPS URLs for WebSocket

    • WebSocket APIには、ws:とwss:という非HTTP(S)スキームを使わなければならないという特性がある
    • URLの動作はHTTP(S) URLとほぼ同じため、APIの利用が煩雑になることがある
    • WebKitチームはWeb開発者のフィードバックを基に、APIがHTTP(S) URLもサポートするようにし、Safari 17.0で提供した
    • 従来はlocation.protocolに応じてwss:またはws:に書き換えるコードが必要だったが、これでnew WebSocket(path)のように使える
    • Interop 2024に含め、他のブラウザにもこれを採用させることが目標だ

  • IndexedDB

    • IndexedDBは、オブジェクト指向データベースの形でクライアント側にデータを保存するAPIだ
    • 2011年からブラウザへの搭載が始まり、Web標準は進化を続けてきた
    • version 2とversion 3はすべての主要ブラウザが対応している
    • version 2は完全に相互運用可能だが、version 3は実装品質を揃えるための追加作業が必要だ

  • Layout

    • CSSのGridとFlexboxは、2021年の当初のInteropプロジェクトに含まれていた
    • SubgridはInterop 2023に追加された
    • 3つのレイアウト方式はいずれも良好な状態だが、まだ完璧ではない
    • 2024年には、3領域のテストがLayoutという1つの重点領域に統合される
    • 複雑な境界ケースの相互運用性を高める作業が続けられている
    • 開発者はFlexbox、Grid、Subgridのいずれも信頼して使うことができ、すべてのブラウザが堅牢にサポートしている

  • Pointer and Mouse Events

    • Pointer eventsは、マウス、ペン・スタイラス、1本以上の指によるタッチなどのポインティング入力デバイスを1つのDOMイベントモデルで扱う
    • このAPIは2012年からブラウザへの搭載が始まり、2019年までにすべてのブラウザに導入されたが、相互運用性は不安定だった

  • Interop チームは2022年に Pointer and Mouse Events の調査プロジェクトを開始し、合意事項を明確化して、それを反映するテストを作成した

    • Interop 2023 ではこのテストが重点領域に入り、通過率は34%から**81%**へ上昇した
    • まだやるべきことが残っているため、2024年も引き続き重点領域となる

  • Popover

    • HTML の popover 属性は、ページの最上位レイヤーに要素を表示するためのブラウザー内蔵の方法を提供する
    • ページ全体を覆うオーバーレイを作る場合は、dialog 要素が最適である
    • 他の要素をポップアップメッセージ、ユーザーインターフェース、表示と非表示を切り替えるコンテンツにしたい場合、popover がフレームワークを提供する
    • popover のサポートは2023年に Chrome 114 と Safari 17.0 で提供開始された
    • Firefox は Firefox Nightly でサポート作業を進めている

  • Relative Color Syntax

    • Relative Color Syntax は、別の色を参照して CSS の色を定義する新しい方法である
    • 既存の色を一定量だけ明るくまたは暗くしたり、色変数の彩度を調整して2つ目の変数に割り当てたりできる
    • デザインシステムを作る際に特に強力になり得る
    • Safari 16.4 が2023年3月に最初のサポートを提供開始した
    • Chrome 119 と Edge 119 は2023年10月と11月にサポートを提供開始した
    • 現在のところ、currentcolor を Relative Color Syntax と一緒に使う機能をサポートする実装はない
    • Interop 2024 の Relative Color Syntax 領域は、全面的なサポート可否ではなく、currentcolor サポートと色域外動作のテストに絞って重点的に扱う
    • P3 color をサポートしないディスプレイで何が起こるかを確認する

  • requestVideoFrameCallback

    • <video> 要素は、Web 上で動画を扱うための強力な機能を提供する
    • HTMLVideoElement は、JavaScript で動画オブジェクトを操作するためのプロパティとメソッドを提供する
    • requestVideoFrameCallback() により、動画フレームごとの処理を効率的に実行できる
      • 動画処理や分析
      • canvas への描画
      • 音声ソースとの同期
    • Chrome 83 と Safari 15.4 以降でサポートされている
    • Interop 2024 への追加は、ブラウザー実装の完成度向上と改善に役立つ

  • Scrollbar Styling

    • Scrollbar Styling 領域には、スクロールバーのスタイリングに使える2つの CSS プロパティが含まれる
    • scrollbar-width は、auto、thin、none の3つの値を提供する
      • auto はデフォルトの幅である
      • thin はより細いスクロールバーを提供する
      • none はコンテンツのスクロールを維持したままスクロールバーを隠す
    • Firefox 64 は2018年12月にサポートを実装し、Chrome 121 と Edge 121 にも提供されたばかりである
    • scrollbar-gutter は、スクロールバー用の領域を予約し、スクロールバーの有無にかかわらず同じレイアウトを維持できるようにする
    • scrollbar-gutter: stable は、スクロールバーがなくても領域を予約するようブラウザーに指示する
    • スクロールバーが必要かどうかの状態が変わる際のレイアウトシフトを防げる
    • 2021〜2022年に Chrome 94、Edge 94、Firefox 97 で提供開始された
    • Safari はこの重点領域を完了するために最も多くの作業を必要としている
    • Chrome と Firefox はすでにテストを100%通過している
    • Safari は2009年に ::-webkit-scrollbar-* という9つの疑似要素でスクロールバーのスタイリング機能を先行提供したが、この方式は正式な CSS Web 標準にはならなかった
    • CSS Working Group は、はるかに単純なアプローチを選択した

  • @starting-style and transition-behavior

    • この領域は、アニメーション制御のための2つの新機能に焦点を当てている
    • どちらの機能も2023年9月に Chrome 117 と Edge 177 で提供開始された
    • @starting-style は、特定要素の開始値を定義できるようにする
    • 要素が transition を経る場合に必要となる
    • display:none に入る、またはそこから出る遷移方法も提供する
    • transition-behavior は、以前はアニメーションでしかできなかった離散的アニメーション可能プロパティの処理を CSS transition に拡張する
    • 要素を表示または非表示にする際に display プロパティを遷移させる道を開く

  • Text Directionality

    • テキストの流れる方向は、Web 組版における重要な要素である
    • 言語によって左から右へ流れるものもあれば、右から左へ流れるものもある
    • dir attribute は、HTML 要素に方向を left、right、auto で指定できるようにする
    • auto は、最初の文字を見てブラウザーが方向を推定するよう求める
    • 方向性と shadow tree の相互作用は、最近まで十分に定義されていなかった
    • この問題は標準レベルで扱われ、Interop 2024 への追加によって実装の整合性が確認される

  • text-wrap: balance

    • Web デザイナーは、極端に短い行や1語だけの行を防ぐ方法を長く求めてきた
    • レスポンシブ Web デザインと列幅の制御不足により、この問題はさらに難しくなっている
    • text-wrap は、特定のユースケースに合わせて改行計算の方法をブラウザーに伝える複数のオプションを提供する
    • text-wrap: balance は見出しに適した解決策である
    • 数行のテキストをバランスよく配置し、各行がほぼ同じ量のテキストを持つようにする
    • Chrome 114 と Firefox 121 で提供され、Safari Technology Preview に実装されている
    • Interop 2024 には、text-wrap-mode、text-wrap-style、white-space-collapse の動作テストも含まれる
    • CSS Working Group が最近これらの longhand 同士の相互作用の仕組みを変更したため、ブラウザー間のサポートは現状では均一ではない

  • URL

    • URL は Web の最も根本的な要素の1つであり、URL なしでは Web は存在しない
    • Web の初期の歴史の中で発明された多くのものと同様に、URL サポートもまだ完全には相互運用可能ではない
    • WHATWG は、URL が正確にどのように動作すべきかを詳細に記した URL Living Standard を策定した
    • この標準をサポートするテストは Interop 2023 の重点領域であり、通過率は77%から85%に向上した
    • 2024年も相互運用性の確保に向けた作業が続けられる
    • Safari はテストの**99.7%**を通過している

調査プロジェクトと進捗追跡

  • Interop 2024には3つの調査領域も含まれる
    • Accessibility Testing
    • Mobile Testing
    • WebAssembly Testing
  • 調査領域は、Interopチームがより多くのテストを作成し、実行可能にするための取り組みである
  • Mobile Testing調査プロジェクトは、モバイルOS上でブラウザーをテストできるように、WPTに必要なインフラを完成させることを目標としている
    • 将来的にはInteropプロジェクトのダッシュボードにモバイルスコアが含まれる可能性もある
  • 3つの調査のうち2つは昨年から続くプロジェクトだが、2024年はいずれも完了率0%の状態から始まる
  • 参加チームは今年の新たな目標を定め、ダッシュボードはその目標に対する進捗状況を表示する
  • Interop 2024の進捗状況はInterop 2024 dashboardで確認できる
  • 相互運用性はWebの成功を支える根本的な柱の1つであり、Interop 2022と2023の取り組みを土台として、2024年も協業が続く

関連記事

1件のコメント

 
GN⁺ 2024-02-03
Hacker News の意見

  • ここには確かに素晴らしい変化があり、サポートが改善されるのは歓迎すべきこと
    たとえば CSS ネストは、SASS や LESS が有用だった核心的な理由の一つなので、大きな変化だ。変数のようなプリプロセッサ機能というより、CSS のコア機能として入るほうが本来は自然だった
    カスタムプロパティで何ができるかも常に興味深いし、Shadow DOM とカスタム要素の次の段階として見栄えがよい。popover も意外に良く、JavaScript なしでポップアップモーダルのようなものを作れるようになった点は非常に有用だ。カスタムモーダル、ドロップダウンメニュー、ハンバーガーボタンなどに時間を浪費することを減らしてくれるはず
    ただ、こうしたプロジェクトでは フォームにももっと気を配ってほしい。HTML 5 時代のさまざまなフィールドがブラウザごとにあまりにも違い、表示のために独自の擬似クラスによるスタイリングに頼っており、全体としてカスタマイズが難しいという現状は、ほぼ何でもできるプラットフォームとしては驚くほど古びて見える

    • UI デザイナーが自由に動けるなら、以前は好んでいたとしても、こうした新しい標準の モーダル・メニュー・ボタンを望まないことが多い
      この変化は役に立つだろうが、UI では一貫性が誰もが目指すべき機能ではなく、弱点のように扱われているように見える
    • CSS ネストは、CSS プリプロセッサを使う最後の理由だ
      Safari 17.2+ がもっと広く普及すれば、そのまま素の CSS を使える
      それ以外では @media クエリ用の変数も理由ではあるが、これはそれほど一般的な必要性ではない

  • 結局 JPEG XL は入らなかったようだ。非常に久しぶりに全体として明確な改善をもたらした最初の画像形式だと考えると、かなり理解しがたい
    Interop が、Google が事実上採用を妨げている状況を止めてくれることを期待していたが、広く使われている古い形式の中途半端な代替物が積み重なる間、さらに待つ必要がありそうだ

    • この点は自分も残念だ
      Google が JPEG XL の何を不満に思っているのか分からない

  • 「すべてのブラウザが P3 色を完全にサポートするようになった」というのは、実際とは少し違う
    Firefox は今でも、色をデバイスに送る前にすべて sRGB にクランプしている。https://bugzilla.mozilla.org/show_bug.cgi?id=1626624#c16

  • Web の仕事はごくたまにする程度なので自分は主な対象ではないが、WebKit で最も目立つ欠けている機能は SVG ファビコンのサポート不足だ
    本当に理解しがたく、サイズの違う Apple 専用アイコンをすべて用意するのは、自分のような軽めの Web 開発者にはかなり面倒だ

    • 今は以前とは違うので、喜べるはずだ。現在は Apple 専用アイコンが一つあればよい [1]:
      [1]: https://evilmartians.com/chronicles/how-to-favicon-in-2021-s...
    • 少し関連する話だが、Chrome は ico ファビコンがあると SVG ファビコンを使わない。(https://bugs.chromium.org/p/chromium/issues/detail?id=145085...) なので PNG ファビコンと SVG ファビコンを一緒に配布している
    • 参考までに、Safari はこの形式の 単色 SVG ファビコンをサポートしている
      Vite のようなものを使えば、単一の元画像からファビコンとホーム画面アイコンの生成をすべて自動化することもできる
    • SVG は望むようにはスケールしない。たとえば 256px の正方形画像をベクターで作ったとしても、ベクター変換だけで 24px で見栄えよくすることはできない
    • その通りだ。こうしたアイコンをすべて生成しなければならない必要はないはずだ
      それに、リストもスタイリングできるとよい。たとえば要素に旗のようなものを付けるといった形で
      CSS ページ遷移や スクロール駆動アニメーションにも言及がないが、これらも定型的な JavaScript を減らせる

  • 思ったよりこの記事を読んでずっとワクワクした
    参加コンソーシアムに、なぜ PWA 重点領域がないのか気になる

    • 歴史的に Interop は CSS により焦点を当ててきたが、だんだん変わってきている
      それでも多くのテスト領域にワーカーのテストが含まれていて、PWA の状況も良くなるようになっている。2023年には Modules セクション全体があり、PWA/ワーカー特化の機能を多くテストしていた。OffscreenCanvas やモバイルテストのように、テスト・調査対象の API のかなり多くも、複数の PWA アプリケーションと大きく関係している
      今年は昨年と同様、CSS 中心性が最も低い Interop だと思う。私が見る限り、PWA が主に依存する IndexedDB、WebSocket、重要なアクセシビリティ改善のセクションがある。調査領域の3つである WebAssembly、アクセシビリティ、モバイルテストもすべて PWA と関係が深い
      具体的にどの API にもっと注力してほしいのか気になる
    • 記憶では、コンソーシアムはおおよそ12人ほどで、この人たちはブラウザ企業でも働いている
      目標は集まって、現在のロードマップと作業量を考慮し、1年間一緒に取り組んだり改善したりできる機能を見つけること。Interop は、本業の主要機能開発の合間に処理できる小さな追加チケットのようなものだと考えればよい
      これまでの焦点は、ブラウザがコンテンツをレンダリングする方法の非常に低レベルな詳細に当てられていた。JavaScript API はおおむね標準化され、「上流」で統合されているため、改善余地が最も大きい領域がここなのだ
      すべてのエンジンで新機能を同時に実装しようという流れが出てくる前に、ブラウザ間の隙間を埋める作業が今後もより多く行われると思う
      ただし Apple がついにモバイル Safari に Web Push を追加したことで、PWA 機能の恩恵を受ける Web アプリの大半が必要とする部分にはかなり近づいている。まだブラウザ共通で存在しない機能のうち、どれを使いたいのか気になる
    • PWA 重点領域に何が含まれると考えているのか気になる
      別の場所で https://web.dev/learn/pwa/capabilities と https://whatpwacando.today をリンクしたが、その機能のかなり多くは本質的に PWA 機能とは言いにくいと思う。本当に多くの機能が PWA の外でも広く使われているので、それらを「PWA」という括りに入れる意味は薄くなる。Web 開発者にとっては「ストレージ」や「メディア」のような括りのほうが意味を持つ可能性が高い
      PWA の基本的な定義を見ると、主に manifest と service worker、そしてそれらを Web プラットフォームと組み合わせて使うことに関するものだ
      manifest は自動テストが難しい。内容がブラウザ UI の異なる部分に表示されるが、UI は概して Web 標準では明記されていない。ベンダーが独自の UI 判断を行う自由を望んでいるためだ。そのため含めるのが難しく、相互運用性の問題がどれほどあるのかも不明確だ
      service worker は提案される可能性はある。ここ数年は提案されていないが、こちらも最近は相互運用性の問題がそれほど多かったとは見ていない
    • PWA は アプリストアモデルを迂回する。ブラウザから直接アプリをインストールできる
      だから、この問題を引き延ばして PWA 体験を意図的に魅力の低いものにすることが彼らの利益になる
      Firefox が PWA サポートを外した理由はよく分からないが、おそらく保守コストのためかもしれない
    • 「コンテンツ表示」というはるかに広い用途に比べれば、PWA はニッチなユースケースだからだ

  • フォント
    CSS タイポグラフィにもっと力を入れてほしい
    特に leading-trim と margin-trim が必要だ
    https://medium.com/microsoft-design/leading-trim-the-future-...
    https://developer.mozilla.org/en-US/docs/Web/CSS/margin-trim

  • 最大の成果は、Safari のアップデートが OS アップデートに縛られなくなることだ

    • macOS では可能だ
      ただし iOS ではできない
      そして iOS アップデートは3〜4か月ごとに新しく出るので、実際には iOS では問題にならない

  • これが WebKit が WebAssembly 機能に追いつき始める兆しなのか気になる
    現在 Chrome や Firefox と比べてかなり遅れていて、multiple memories や garbage collection のような大きく重要な機能がない

    • どちらもまだ Wasm 仕様には含まれておらず、標準化中だ
      Google は「構え！撃て！狙え！もう一度撃て！」に近く、完成していない仕様の実装をより簡単に出す傾向があり、Apple は「構え！狙え！狙え！撃て！」に近いため、一般にそうしたことを嫌がる。Firefox については何とも言いにくい

  • まだ Cookie Store API が正式に実装されていないなんて信じられない
    2024年にもなって、名前でクッキーを1つ取得するために巨大で汚い文字列をパースしなければならないなんてあり得るのか

    • HTML 5 の localStorage ができたからではないだろうか

  • WebSocket プロトコルの件はよく理解できない
    アップグレード後の接続はもはや http(s) プロトコルではないのだから、ここで http や https の使用を許すのは誤解を招かないだろうか？ 三項演算子を使ったり、現在のページから変換した値と異なる値を持ったりすることがそんなにひどいのか？ ブラウザの正規化作業をするのは歓迎だが、この項目は変更する価値があるとしても、優先順位はかなり低そうに見える