2 ポイント 投稿者 GN⁺ 2024-02-03 | 1件のコメント | WhatsAppで共有
  • CanIUse.comはWeb技術の互換性を追跡するサイトだが、基本要素であるhtmlのサポート率が**97.34%**と表示されており、数値の解釈に疑問が生じる
  • このサポート率はCanIUse.comが利用しているMDN互換性データと関係しており、html要素ページの一部の下位項目が影響していると見られる
  • 問題の項目は任意のmanifest属性とsecure context requiredで、どちらも標準化されていない、または廃止された項目である
  • 未サポート・サポート可否不明のブラウザと古いブラウザの扱いが混在することで、htmlのような基本要素でも直感と異なるサポート率が表示される
  • “% of all tracked”基準ではsupport unknownを加えて**99.98%**と見ることができ、丸め誤差の可能性は高まるが、CanIUse.comの数値はより注意して読む必要がある

htmlのサポート率97.34%が生んだ疑問

  • CanIUse.comはWeb技術のブラウザ採用率と機能互換性を追跡し、機能が実際にどれだけ使えるかを数値で示す
  • html要素のサポート率は**97.34%**と表示される
    • これはaudio要素より低い数値である
    • ap要素も同じ**97.34%**のサポート率として表示される
  • かなり以前から使われてきたWebの基本要素が100%ではないため、単純な互換性の数値以上の確認が必要になる

MDN互換性表に見える下位項目

  • CanIUse.comの多くのデータはMDNから取得されていると見られる
  • MDNのhtml要素ページにはブラウザ互換性セクションがある
  • この表で赤いXが多い項目は2つある
  • ほぼすべてのブラウザがこの2項目をサポートしていないのは事実だが、それだけでhtml要素全体のサポート率が**97.34%**まで下がる理由が明確になるわけではない

古いブラウザと丸め誤差の可能性

  • 一部のブラウザはSupport Unknownと表示され、これらのブラウザの現在の使用量合計は**1.27%**である
  • Android Browser 2.1–4.3はhtml要素をサポートしていないと表示されるが、使用量シェアは**0%**である
    • これらの古いブラウザが実際にhtml要素をサポートしていなかったという表示は疑わしい
    • 丸め誤差が1.27%を2.66%まで膨らませ得るのかも不明である
  • CanIUse.com右上で「usage」の横の基準を「% of all tracked」に変え、「support unknown」ブラウザの数値を足すと**99.98%**になる
    • この基準では、丸め誤差によって現在の数値が出ている可能性をより容易に確認できる
    • ただし、htmlのような基本要素における古いブラウザの扱い方は依然として混乱を招く
  • CanIUse.comは今でも有用なリソースだが、表示されるサポート率は文脈と計算基準をあわせて確認する必要がある

1件のコメント

 
GN⁺ 2024-02-03
Hacker News のコメント
  • CanIUse には Global の割合のすぐ上に「% of all」オプションがある。機能ページの歯車を開くと、利用率の計算方法がもう少し詳しく出ている デフォルトは、caniuse が追跡していないブラウザの利用をすべて非対応とみなす All Users で、All tracked users に変えると追跡対象ブラウザだけを計算して 98.71% になる チャートで対応状況が Unknown のブラウザの合計は 1.27% だが、98.71% に 1.27% を足すと 99.97999… なので、丸めの影響がありそうだ 本当の問題は、それらのブラウザが Unknown と表示されている点で、実際には `` 要素をサポートしていると見てよさそうだ

    • 私たちの API SaaS のリクエストログに出てくる、「特に何なのか識別できない」User-Agent 文字列を見ると、1.27% の「ブラウザ」のかなりの部分は、自分の専門領域を外れて偶然やって来た各種の特殊目的スクレイパーである可能性が高そうだ なので、必ずしも `` をパースできるとは限らない。JSON スクレイパーかもしれない
    • wget はよく使われているが、これを含めるなら話は別だ。src/html-url.c を確認したところ、実際には `` をまったくサポートしておらず、不明なタグとして扱っている
  • MDN は以前 Mozilla Developer Network の略だったのに、今では単に MDN なのだという点が気になって調べてみたが、私も正式名称は見つけられなかった

    • その変更は 2017 年ごろに行われた。Mozilla Developer Network という名前はやや曖昧で、アンケートやユーザーインタビューでも混乱があった Web 開発者たちは Mozilla 開発者専用の資料だと思っていたが、初期には実際にそういう性格が強かったので、完全に間違いでもなかった しばらくの間、MDN には Web プラットフォームの文書以外にも Mozilla 関連の文書が多くあったが、2017 年には Web プラットフォーム文書が MDN トラフィックの 95% を占めるようになり、Mozilla 開発者向け資料であることはもはや主なアイデンティティではなくなっていた そのため、焦点の変化が分かるように名前を MDN Web Docs に変えたのだ
    • この変更は 2017 年 8 月 15 日ごろに起きた。ブランディングは変わったのにページ内容はまだ変わっていない瞬間を偶然見たので覚えている そのとき投稿したバグレポートがここにある: https://bugzilla.mozilla.org/show_bug.cgi?id=1390381
    • こういうものを anachronym と呼ぶのが好きだ。時代錯誤的な略語のように感じるからだ。厳密に言えば、これは頭字語というよりイニシャリズムだが、関連する記事も書いた https://simpsonian.ca/blog/anachronyms/
    • サイドページやサンプルコードにいくつか残ってはいるが、見つけたのはこの程度だ “will soon be a proud part of the Mozilla Developer Network (MDN)” — https://developer.mozilla.org/en-US/blog/mdn-observatory/ “Their brilliant but offbeat idea grew into today's Mozilla Developer Network” — https://developer.mozilla.org/en-US/docs/MDN/At_ten const heading = Mozilla Developer Network;https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes...
    • 数年前、Microsoft のドキュメントが Mozilla のドキュメントを指すようになった記憶がある。Edge のリブランディングの一部だったのかもしれない その合意の過程で MDN に改名したのだとしたら、「これは M(ozilla)DN なのか、M(icrosoft)DN なのか?」という混乱を避けようとしたのかもしれないが、確かなことは分からない
  • 興味深いことに、 要素もまったく同じ 97.34% の対応率を示すと聞いた この 2 つの要素も `` 要素と同じく、MDN 由来のデータを使っている: https://caniuse.com/mdn-html_elements_a および https://caniuse.com/mdn-html_elements_p この内容を記事に反映して更新した

  • CanIUse で別機能として html-manifest を分けてもよさそうだ そして、MDN が本当に素晴らしい資料であることも改めて言っておきたい

  • 最初の Web ページは html 要素を使っていない http://info.cern.ch/hypertext/WWW/TheProject.html

  • これは最小の妥当な HTML と関係があるのか? そこには HTML タグがない

    • あまり関係はなさそうだ。`` もほぼ同じ割合になっている: https://caniuse.com/mdn-html_elements_title むしろ、利用率は分かっているが対応状況を検証できていないブラウザをどう計算するかの問題に近そうだ ついでに言うと、その HTML は実際には妥当ではなく空のタイトルとして扱われるが、空のタイトルは妥当ではない。. のように変えればエラーなしで通るはずだ
    • それでもそこには タグがあるのでは? 単に明示されていないだけで推論される。どのブラウザで開いても、そのページには タグが入る
    • メールの Subject ヘッダーのように、タイトルを別の方法で渡せるプロトコルの中では は任意だ そのため、最短の妥当な HTML は単に 1 つだけであり、ただし特定の文脈でのみ妥当だ
  • 「サイトのデータの多くは MDN 由来だ」という言い方は少し曖昧だ CanIUse に接続されている機能対応マトリクスは、MDN の browser-compat-data リポジトリから来ている。HTML 要素の元データはここにある: https://github.com/mdn/browser-compat-data/blob/main/html/el... ただし、ここには CanIUse が対応率の算定に引用しているテストや利用率情報はなく、どのブラウザバージョンがどの機能を含めたかだけがある CanIUse も自分のリポジトリを指していて、そこには多くのデータがある: https://github.com/fyrd/caniuse しかし、特定要素の数値がどこから来ているのかを簡単に見つけられる入口は見つけられなかった。そこのデータも主に機能単位に見える より正確な質問は、CanIUse が HTML 要素テストと利用率の数値をどこから取得しているのかであり、それが核心的な問題のように見える

  • `` 要素の対応率は、他のどの要素よりも少なくとも低いか同じであるべきではないのか?

    • いいえ。要素が「HTML 全体」を意味するわけではなく、単に**文書のルート要素**を表すもう 1 つの要素にすぎない 他の人が書いていたように、エラーのない妥当な HTML 文書を作るときに実際に必須なわけでもなく、そのとき必要なのは と妥当な本文程度だ 例えるなら、エッセイのタイトルにある “English” という単語を正しく理解してパースできる能力は、英単語 “fustigate” の意味を知っていることとは別だ
  • 「だから明確な答えはない。知っているなら教えてほしい!」

    • 面白い説明を付けるなら、Android の秘密のブラウザ[1]が、この追跡不能に見える外れ値を作っている、と言うこともできそうだ :-) [1] https://news.ycombinator.com/item?id=39226754