マークアップ

序章

ウェブはHTMLで構築されています。HTMLがなければウェブページも、ウェブサイトも、ウェブアプリケーションもありません。何もないのです。平文のドキュメントやXMLツリーは、このような特別な挑戦を楽しんでいる平行世界にあるかもしれません。この世界では、HTMLがユーザーフレンドリーなウェブの基礎となっています。ウェブの基盤となっている標準は数多くありますが、HTMLはもっとも重要な標準のひとつであることは間違いありません。

HTMLをどのように使うのかでは、どれだけ素晴らしい基盤があるのか。2019年版マークアップの章の序章で、著者のBrian Kardellは、長い間本当は分かっていなかったことを示唆しています。小さなサンプルはいくつかありました。たとえばIan Hicksonの研究（モダンHTMLの親玉の1つ）などがありましたが、昨年まで開発者である私たち、著者である私たちが、HTMLをどのように利用しているのかについて主要な洞察を欠いていました。2019年には、Catalin Rosuの研究（本章の共著者の1人）と2019年版Web Almanacの両方があり、実際のHTMLについて再び良い見解を得ることができました。

昨年は580万ページを分析し、そのうち440万ページをデスクトップで、530万ページをモバイルでテストしました。今年は2020年にユーザーが訪れるWebサイトに関する最新データを用いて750万ページを分析し、そのうち560万ページをデスクトップで、630万ページをモバイルでテストしました。昨年との比較も行っていますが、新たな洞察のために追加の指標を分析したのと同様に、私たち自身の個性や視点を章全体に付与しました。

このマークアップの章では、同じマークアップ言語であるSVGやMathMLではなく、ほぼHTMLのみを取り上げています。特に断りのない限り、この章で紹介する統計は、モバイルページのセットを指します。また、Web Almanacの全章のデータは公開されており、利用可能です。結果を見て、あなたの意見をコミュニティに伝えてください！

全般

このセクションではドキュメントタイプやドキュメントのサイズ、さらにはコメントやスクリプトの使用など、HTMLのより高度な側面を取り上げています。”生きたHTML “は、まさに生きているのです

Doctypes

96.82%のページがdoctypeを宣言しています。HTML文書がdoctypeを宣言することは、Ian Hickson氏が2009年に説明したように、「ブラウザのquirksモードのトリガーを避けるため」という歴史的な理由から有用です。もっとも人気のある値は何ですか？

XHTML1.0以降、数がかなり減り、いくつかの標準的なもの、いくつかの難解なもの、さらにはインチキなdoctypeを含むロングテールに入ることはすでにおわかりでしょう。

この結果から、2つの点が注目されます。

1. 生きた HTML（通称「HTML5」）の発表から約10年、生きた HTMLは明らかに当たり前のものになりました。
2. 生きたHTML以前のウェブは、XHTML1.0のような、次によく使われるdoctypにまだ見られます。XHTMLです。それらのドキュメントは、おそらくMIMEタイプがtext/htmlのHTMLとして配信されていますが、これらの古いdoctypesはまだ死んでいません。

ドキュメントサイズ

ページのドキュメントサイズとは、ネットワーク上で転送されたHTMLのバイト数のことで、圧縮が有効な場合はそれも含めて計算されます。630万のドキュメントのセットの両極端では

• 1,110個のドキュメントは空です（0バイト）。
• ドキュメントの平均サイズは49.17KBです（ほとんどの場合、圧縮されています）。
• 最大のドキュメントは61.19 MB で、Web Almanacの中でも独自の分析と章立てが必要なほどです。

では、この状況は一般的にどうなのでしょうか？　ドキュメントの中央値は24.65KBで、これは驚きがない状態です。

結果を調べる

• データを見る
• クエリを表示
• 画像を見る

図3.3の説明を表示

ドキュメントのサイズ（バイト）はパーセンタイルで、デスクトップでは中央値が25.99KB。

ドキュメント言語

html開始タグのlang属性に2,863の異なる値を確認しました（Ethnologueによる7,117の話されている言語と比較してみてください）。アクセシビリティの章によると、ほとんどすべての値が有効なようです。

全ドキュメントの22.36%がlang属性を指定していません。一般的にはそうすべきだという意見は多いです、ソフトウェアが最終的に言語を自動的に検出するという事実を無視してドキュメントの言語はプロトコルレベルで指定することもできますが、これは私たちがチェックしなかったことです。

ここでは、サンプルの中でもっとも人気のある（正規化された）10の言語を紹介します。HTTP Archiveは米国のデータセンターから英語の言語設定でクロールしているため、ページが書かれている言語を見ると、英語に偏っていることに注意してください。とはいえ、分析したサイトのコンテキストを示すために、lang属性を提示します。

結果を調べる

• データを見る
• クエリを表示
• 画像を見る

図3.4の説明を表示

クロールで使用されたlang属性のトップ10を示す棒グラフ、デスクトップページの22.82%、モバイルページの22.36%が属性を設定しておらず、enはそれぞれ20.09%、18.08%、jaは15.17%、13.27%で使用されています。 また、esは4.86％、4.09％、pt-brは2.65％、2.84％、ruは2.21％、2.53％、en-gbは2.35％、2.19％、deは1.50％、1.92％、最後にfrは1.55％、1.43％で使用されていました。

コメント

コードにコメントを付けることは一般的に良い習慣であり、HTMLコメントはユーザーエージェントによってレンダリングされることなく、HTML文書にメモを付けるためのものです。

<!-- これは、HTMLのコメントです。 -->

多くのページでは制作のためにコメントが削除されているでしょうが90パーセンタイルのホームページでは、モバイルでは約73個、デスクトップでは約79個のコメントが使用されており、10パーセンタイルでは約2個のコメントが使用されていることがわかりました。 中央値のページでは、16個（モバイル）または17個（デスクトップ）のコメントが使用されています。

約89％のページには少なくとも1つのHTMLコメントが含まれており、約46％のページには条件付きのコメントが含まれています。

条件付きコメント

<!--[if IE 8]>
  <p>これは、Internet Explorer 8でのみ表示されます。</p>
<![endif]-->

上記は、非標準のHTML条件付きコメントです。過去にはブラウザの違いに取り組むためそれらが役立つことを証明されていましたが、MicrosoftがInternet Explorer 10でdropped conditional comments)を採用したことで、しばらくの間、歴史に名を残しました。

それでも上記のパーセンタイルの両極端では、90パーセンタイルで約6個、10パーセンタイルでは約1個の条件付きコメントを使用しているウェブページがあることをわかりました。 ほとんどのページでは、html5shiv、selectivizr、respond.jsなどのヘルパーのために条件付きコメントを使用しています。これらのページはきちんとしていて、まだアクティブなページですが、私たちの結論はこれらの多くが時代遅れのCMSテーマを使用していたということです。

本番環境では、HTMLコメントは通常、ビルドツールによって取り除かれます。以上のカウントとパーセンテージ、そして一般的なコメントの使用状況を考慮すると、多くのページがHTMLミニファイアーを介さずに提供されていると考えられます。

スクリプトの使用

以下の上位の要素のセクションで示すように、script要素は、6番目によく使われるHTML要素です。この章では、データセットの数百万ページの中で、script要素がどのように使われているかに興味を持ちました。

全体では、約2%のページにスクリプトがまったく含まれておらず、type="application/ld+json"属性を持つ構造化データスクリプトも含まれていません。最近では、1つのページに少なくとも1つの分析ソリューション用のスクリプトが含まれていることがかなり一般的になっていることを考えると、これは注目すべきことだと思います。

その反対に、約97％のページには、インラインまたは外部のスクリプトが少なくとも1つ含まれているという数字が出ています。

結果を調べる

• データを見る
• クエリを表示
• 画像を見る

図3.5の説明を表示

スクリプトを含むページ（ではない）の割合で、スクリプトはほぼすべてのページにほぼすべての形で存在しています。

ブラウザでスクリプトがサポートされていなかったり、オフになっている場合、noscript要素は、ページ内にHTMLセクションを追加するのに役立ちます。上記のスクリプト数を考えると、noscript要素についても気になりました。

分析の結果、約49％のページがnoscript要素を使用していることがわかりました。同時に、約16%のnoscript要素が、”googletagmanager.com “を参照するsrc値を持つiframeを含んでいます。

これは、実際のnoscript要素の総数が、ページのbody開始タグの後にnoscriptスニペットを追加するようにユーザーに強制するGoogleタグマネージャーなどの一般的なスクリプトの影響を受ける可能性があるという理論を裏付けているようです。

スクリプトの種類

script要素で使用されるtype属性値は何ですか？

• text/javascript: 60.03%
• application/ld+json: 1.68%
• application/json: 0.41%
• text/template: 0.41%
• text/html: 0.27%

type="module"を使用してJavaScriptモジュールスクリプトを読み込む場合、現在、0.13%のscript要素がこの属性と値の組み合わせを指定していることがわかりました。また、nomoduleは、テストした全ページの0.95%で使用されています。(1つの指標は要素に関するもので、もう1つの指標はページに関するものであることに注意してください。)

全スクリプトの36.38%は、typeの値がまったく設定されていません。

要素

このセクションでは、要素に焦点を当てています。どのような要素が使用されているのか、どのくらいの頻度で使用されているのか、どのような要素が特定のページに表示される可能性があるのか、カスタム要素、廃止された要素、独自の要素についてはどのような状況なのか、などです。 divitis はまだありますか？　はい。

要素の多様性

では、実際にHTMLがどのように使われているのかを見てみましょう。作者はさまざまな要素を使っているのか、それとも比較的少ない要素しか使っていないのか。

ウェブページの中央値では、30種類の要素が587回使用されていることがわかります。

結果を調べる

• データを見る
• クエリを表示
• 画像を見る

図3.6の説明を表示

要素の種類はパーセンタイルで、90％のページが20種類以上の要素を使用しています。

結果を調べる

• データを見る
• クエリを表示
• 画像を見る

図3.7の説明を表示

1,665個以上の要素を採用しているページが全体の10%であることを示す。

生きたHTMLが現在112個の要素を持っていることを考えると、90パーセンタイルが41個以上の要素を使用していないということは、ほとんどの文書でHTMLがほとんど使い尽くされていないことを示唆しているかもしれません。しかしHTMLが提供する意味的な豊かさは、すべての文書がそのすべてを必要とすることを意味しないので、これがHTMLとその使用にとって実際に何を意味するかを解釈するのは難しいです。HTMLの要素は、利用可能かどうかではなく、目的（セマンティクス）に応じて使用されるべきです。

これらの要素はどのように配分されていますか？

結果を調べる

• データを見る
• クエリを表示
• 画像を見る

図3.8の説明を表示

興味深いのは約7,500ページの大規模なグループで、それぞれが約250の要素を使用しており、その後はページ数が減りより多くの要素を使用するようになっていることです。

2019年と比べてそんなに変わっていない！

トップ要素

2019年、Web AlmanacのMarkupの章では、2005年のIan Hicksonの仕事を参考に、もっとも頻繁に使用されている要素を紹介しました。私たちはこれを参考にして、もう一度そのデータを見てみました。

トップ7には何の変化もありませんでしたが、option要素は少し人気がなくなり、8位から10位に下がり、link要素とi要素が人気を失ってしまいました。これらの要素が使用されるようになったのは、おそらくresource hints の使用が増加したことや、Font Awesomeのようなアイコンソリューションが使用されるようになったからでしょう。

detailsとsummary

もうひとつ気になっていたのは、とくに2020年にdetailsとsummary要素が導入されてから、その使用状況です。これらは使われていますか？　それらは著者にとって魅力的で、人気もあるのでしょうか？　結果的には、テストした全ページのうち0.39%しか使用されていませんでした。ただし必要な場面で、正しい方法で使用されているかどうかを判断するのは難しいので、「人気がある」という表現は間違っています。

ここでは、details要素の中でsummaryを使用する簡単な例を紹介します。

<details>
  <summary>ステータス 動作確認済み</summary>
  <p>速さ：12m/s</p>
  <p>方向：北</p>
</details>

しばらく前に、Steve Faulkner氏が、この2つの要素がいかに不適切に使われているかを指摘していました。上の例からわかるように、details要素ごとに、detailsの最初の子としてのみ使用可能なsummary要素が必要になります。

そこで、details要素とsummary要素の数を調べてみたところ、引き続き誤用されていることがわかりました。また、summary要素の数は、モバイルとデスクトップの両方で多く、モバイルではdetails要素1つに対してsummary要素が1.11、デスクトップでは1.19となっています。

要素使用の確率

要素のポピュラリティについてもう一度見てみましょう。あるページのDOMで特定の要素が見つかる確率はどのくらいでしょうか？　確かに、html、head、bodyはすべてのHTMLページに存在し（これらのタグはすべてオプションであるにもかかわらず）、一般的な要素となっていますが、他にどのような要素がよく見られるのでしょうか？

標準要素とは、HTMLの仕様に含まれている、あるいは含まれていた要素のことです。では、どの要素が珍しいのでしょうか？　私たちのサンプルでは、次のようなものがあります。

私たちは、どのような要素が廃れてしまったのかを知るために、これらの要素を含めています。しかし、dirとbasefontはXHTML1.0(2000)で最後に指定され、もはやHTMLの一部ではありませんが、rpの稀な使用（これは1998年の早い段階で、still part of HTMLに言及されており）は、Rubyマークアップがあまり普及していないことを示唆しているのかもしれない。

カスタム要素

Web Almanac2019年版では、いくつかの非標準的な要素を取り上げてカスタム要素を扱いました。今年は、カスタム要素を詳しく見てみることに価値があると考えました。どのようにしてこれらを決定したのでしょうか？　大まかには、その定義を見て、特にハイフンの使用を確認しています。ここでは、サンプル内の全URLの1%以上に使用されている要素に焦点を当ててみましょう。

これらの要素は3つのソースから来ています。昨年も紹介した分析ソリューションのYandex Metrica（ym-）、Slider Revolution (rs-)は、WordPressのスライダーで、サンプルのトップ付近にもっと多くの要素があります。そして、ウェブサイトビルダーのWix (wix-)があります。

また、AMPマークアップのamp-img（11,700ページ）、amp-analytics（10,256ページ）、amp-auto-ads（7,621ページ）などのamp-要素を持つグループや、Angularの app- 要素である app-root (16,314)、app-footer (6,745)、app-header (5,274) なども含まれています。

廃止された要素

HTMLの使用については、廃止された要素（applet、bgsound、blink、center、font、frame、isindex、marquee、spacerなどの要素）の使用を含め、さらに多くの疑問があります。

630万ページのモバイルデータセットでは、約90万ページ（14.01％）にこれらの要素が1つ以上含まれています。ここでは、10,000回以上使用された上位9つの要素を紹介します。

また、spacerでさえも1,584回使用されており、5,000ページごとに存在しています。Googleが自社のホームページで22年前から、center要素を使用していることは知っていますが、なぜこれほど多くの模倣者がいるのでしょうか。

isindex

気になっていたら: このデータセットに含まれるisindex要素の総数は1です。ちょうど1つのページがisindex要素を使用していました。isindexはHTML4.01とXHTML1.0 までは仕様の一部でしたが、2006年になってようやく 仕様化され（ブラウザでの実装方法に合わせて）、2016年には廃止されました。

独自要素と作り込み要素

その中には標準的なHTML（SVG、MathML）要素でも、カスタム要素でも、廃止された要素でもない独自の要素も含まれていました。私たちが確認したトップ10は以下の通りです。

これらの要素の出所は、不明なものもあれば追跡可能なものもあり、混在しているようです。もっともポピュラーなものであるnoindexは、Yandexがページのインデックス作成を禁止するために推奨していることに起因すると思われます。jdivは昨年の Web Almanacで指摘された、JivoChatのものです。mediaelementwrapperはMediaElementというメディアプレイヤーから来ています。yymapsとyatagもYandexのものです。また、ss要素は、eBayの元eコマース製品であるProStoresからのものである可能性があり、olarkは、Olarkチャットソフトウェアからのものである可能性があります。h7 は間違いのようです。limespotは、おそらくeコマース用のパーソナライゼーションプログラムであるLimespotに関連していると思われます。これらの要素はいずれもウェブ標準の一部ではありません。

見出し

見出しは、sectioningやaccessibilityで重要な役割を果たす、特別なカテゴリーの要素です。

標準的な<h1>から<h6>までの要素しか見られないと思っていたかもしれませんが、実際にはもっと多くのレベルを使用しているサイトもあります。

最後の2つは、もちろんHTMLの一部ではありませんので、使用しないでください。

属性

このセクションでは、ドキュメントで属性がどのように使用されているかに焦点を当て、data-*の使用パターンを探ります。その結果、classがすべての属性の女王であることがわかりました。

トップの属性

もっとも人気のある要素のセクションと同様に、このセクションではウェブ上でもっとも人気のある属性について掘り下げます。href属性がウェブそのものにとってどれほど重要か、またalt属性が情報をアクセシブルにするため、どれほど重要かを考えると、これらはもっとも人気のある属性でしょうか？

もっとも人気のある属性はclassで、データセットに30億回近く出現し、使用されている全属性の34％を占めています。

トップ10には、意外にもinput要素の値を指定するvalue属性がランクインしています。私たちの主観では、value属性がそれほど頻繁に使われている印象を受けなかったからです。

ページの属性

すべてのドキュメントに見られる属性はあるのでしょうか？　ありませんが、ほとんど:

これらの結果は、私たちが答えられない問題を提起しています。たとえば、typeは他の要素でも使用されていますが、なぜこのように絶大な人気があるのでしょうか。とくに、CSSやJavaScriptがデフォルトとされている中で、スタイルシートやスクリプトに対して指定する必要がないのは普通であることを考えると。またaltは実際にはどうなのでしょうか。9.25%のページには画像が含まれていないのでしょうか、それとも単にアクセスできないだけなのでしょうか。

data-*属性

HTML仕様によると、data-*属性は、”カスタムデータ、ステート、アノテーション、および同様のものをページまたはアプリケーションに対してプライベートに保存することを目的としており、これ以上適切な属性または要素がない場合に使用されます。”とあります。どのように使われていますか？　人気のあるものは何ですか？　何かおもしろいものはありますか？

もっとも人気のある2つの属性は、その後に続く各属性（使用率1％以上）よりも2倍近く人気があるため、際立っています:

data-type、data-id、data-srcのような属性は、複数の汎用的な用途がありますが、data-srcはJavaScriptによる遅延画像読み込みで多く使用されています（例：Bootstrap 4）。Bootstrapでも、data-toggleの存在が説明されており、トグルボタンの状態スタイリングフックとして使用されています。data-slick-index は Slick carousel plugin が、data-element_type は Elementor’s WordPress website builder が持っています。つまり、data-requiremoduleとdata-requirecontextは、どちらもRequireJSの一部なのです。

興味深いことに、画像に対するネイティブ遅延ローディングの使用率は、data-srcの場合と同様です。3.86%のページが<img>要素にloading="lazy"を使用しています。2月の時点ではこの数字は0.8%程度だったので非常に、急速に増加しているようです。これらは、クロスブラウザソリューションのために併用されている可能性があります。

その他

これまで、HTMLの一般的な使い方や、上位の要素や属性の採用について説明してきました。このセクションでは、ビューポート、ファビコン、ボタン、入力、リンクなどの特殊なケースを確認しています。ここで注意しなければならないのは、あまりにも多くのリンクがいまだに「http」のURLを指していることです。

viewportの仕様

viewportメタ要素は、モバイルブラウザでのレイアウトを制御するために使用されます。数年前まではWebページを構築する際に「viewport meta要素を忘れないように」というモットーのようなものがありましたが、やがてこれが一般的になり、「ズームやスケーリングが無効になっていないか確認する」というモットーに変わりました。

ユーザーは、テキストを最大500%まで拡大・縮小できる必要があります。これが、Lighthouseやaxeのような人気のあるツールの監査が、meta name="viewport"要素内でuser-scalable="no"が使用され、maximum-scale属性値が5未満の場合に失敗する理由です。

データを見てみると結果をよりよく理解するためにスペースを削除し、すべてを小文字に変換し、content属性のコンマ値で、ソートすることでデータを正規化しました。

その結果、分析したページのほぼ半分が、典型的なviewport content 値を使用していることがわかりました。しかし約10％のモバイルページでは、viewport meta要素の適切なcontent値が完全に欠落しており、残りのページでは、maximum-scale、minimum-scale、user-scalable=no、またはuser-scalable=0の不適切な組み合わせが使用されています。

しばらく前から、モバイルブラウザEdgeでは、viewport meta要素を採用しているWebページで定義されているズーム設定に関わらず、最低でも500%までWebページを拡大することができるようになりました。

ファビコン

ファビコンを取り巻く状況は非常に興味深いものがあります。あるブラウザは ドメインのルートを見るに戻り、いくつかの画像フォーマットを受け入れ、さらに数十種類のサイズを促進します（いくつかのツールはそのうちの45種類を生成すると報告されています。realfavicongenerator.netはすべてのケースを処理するように要求されると 37 を返します）。この記事を書いている時点では、この状況を改善するために、HTML仕様のopen issueがあります。

テストを作成する際には、画像の有無はチェックせず、マークアップのみを見ていました。つまり以下の内容を確認する際には、ファビコンが使用されているか、または使用頻度よりもファビコンはどのように参照されているかが重要であることに注意してください。

ここにはいくつかのサプライズがあります:

• 他のフォーマットにも対応していますが、ウェブ上のファビコンのフォーマットとしてはICOが主流です。
• JPGは比較的人気のあるファビコン形式ですが、多くのファビコンサイズでは最良の結果が得られない（または重量が比較的大きくなる）場合があります。
• WebPはSVGの2倍の人気があります。しかし、SVG favicon supportの改善により、この状況は変わるかもしれません。

ボタンと入力タイプ

最近、ボタンに関する議論が盛んに行われており、ボタンがどれほど頻繁に誤用されているかが明らかになっています。私たちは、いくつかのネイティブなHTMLボタンについての調査結果を発表するために、これを調べました。

分析の結果、約60％のページにボタン要素が含まれており、そのうち半数以上（32.43％）のページに、type属性の指定に失敗したボタンが少なくとも1つ存在していることがわかりました。button 要素のdefault type がsubmitであることに注意してください。したがって、これらの32%のページにおけるボタンのデフォルトの動作は、現在のフォームデータを送信することです。このような予期せぬ動作を避けるためには、type属性を指定するのがベストです。

10パーセンタイルと25パーセンタイルのページにはボタンがまったく含まれていませんが、90パーセンタイルのページには13個のネイティブなbutton要素が含まれています。つまり、10％のページが13個以上のボタンを含んでいることになります。

リンク対象

アンカー要素、つまりa要素は、ウェブリソースをリンクするものです。本節では、それぞれのリンク先に含まれるプロトコルの採用状況を分析します。

また、httpsやhttpがもっとも多く、次いでメールの作成や電話、メッセージの送信を容易にする「良心的」なリンクが続いていることがわかります。javascriptは、JavaScriptがネイティブで緩やかに機能を低下するオプションが用意されているにもかかわらず、いまだに人気のあるリンクターゲットとして際立っています。

リンクは新規ウィンドウで表示

target="_blank"を使用することは、以前からセキュリティ上の脆弱性であることが知られていました。しかし、71.35%のページがtarget="_blank"を使ったリンクを含んでおり、noopenerやnoreferrerを使っていません。

経験則として、また、使いやすさの観点から、そもそもtarget="_blank"を使用しないことをオススメします。

最新のSafariとFirefoxでは、a要素にtarget="_blank"を設定すると、rel="noopener"を設定するのと同じrelの動作が暗黙的に提供されます。これはすでにChromiumでも実装されており、Chrome 88にも搭載される予定です

。

結論

この章では、いくつかの見解に触れてきましたが2020年のマークアップのあり方を振り返る意味で、いくつか目についた点をご紹介します。

癖のあるモードに着地するページが減りました。2016年には、その数は約7.4%でした。2019年の終わりには、4.85%と観測されました。そして今は、約3.97%となっています。この傾向は、本章のレビューに登場したSimon Pietersの言葉を借りれば、明確で励みになると思われます。

開発の全体像を把握するための歴史的なデータはありませんが、「無意味な」div、span、iのマークアップは、1990年代から2000年代前半に見られたtableのマークアップをほぼ置換しています。意味的により適切な代替手段がないのに、常にdivやspan要素が使用されていることに疑問を感じるかもしれませんが、これらの要素はtableマークアップよりも好ましいものです。表形式のデータ以外のすべてに使用されます。

ページあたりの要素とページあたりの要素タイプはほぼ変わらず、2019年と比較して、私たちのHTMLの書き方に大きな変化はないことを示しています。このような変化は、顕在化するまでに時間を要する可能性があります。

g:plusone（モバイルサンプルでは17,607ページで使用）やfb:like（11,335ページ）のような独自の製品固有の要素は、昨年は[もっとも人気のある要素の1つ]（../2019/markup#products-and-libraries-and-their-custom-markup）だったのですが、ほとんどなくなっています。しかし、Slider RevolutionやAMP、Angularなどのカスタム要素が多く観測されます。また、ym-measure、jdiv、ymapsなどの要素もまだ多く見られます。ここで私たちが想像するのはゆっくりと変化するプラクティスの海の下で作者が廃止されたマークアップを捨て、新しいソリューションを採用することでHTMLが非常によく開発され、維持されているということです。

さて、2019年Web Almanacマークアップの章では、このテーマに関する前回の大規模な調査から14年分の追記があったため、それからの1年間ではあまりカバーできないと思われるかもしれません。しかし、今年のデータで観察されたのは、HTMLの海の底や岸辺付近で多くの動きがあったということです。私たちは、生きたHTMLをほぼ完全に採用しようとしています。GoogleやFacebookのウィジェットのような流行のページはすぐに削除されています。AngularやAMP（「コンポーネントフレームワーク」と呼ばれています）の人気が著しく低下しReactやVueのようなソリューションが求められているように、私たちはフレームワークを採用するのも、避けるのも早いです。

それでも、HTMLが与えてくれる選択肢を使い切った形跡はありません。あるページで使われている30種類の要素の中央値は、HTMLが提供する要素の約4分の1であり、HTMLがかなり一方的に使われていることを示唆しています。これは、divやspanのような要素の絶大な人気によって裏付けられており、これらの2つの要素が表す可能性のある需要を満たすカスタム要素はありません。残念ながら、サンプルの各文書を検証することはできませんでした。しかし、注意が必要な逸話として、W3Cでテストされた文書の79%には検証エラーがあることを知りました。これだけ見ても、私たちはまだまだHTMLの技術を習得するには程遠いようです。

だからこそ、私たちは訴えたいことがあるのです。HTMLに注意を払ってください。HTMLに注目してください。HTMLに投資することは重要であり、価値があります。HTMLはドキュメント言語であり、プログラミング言語のような魅力はありませんが、それでもウェブはHTMLの上に構築されています。HTMLの使用量を減らし、本当に必要なものを学びましょう。もっと適切なHTMLを使いましょう、何が使えるのか、何のために存在するのかを学びましょう。そして、あなたのHTMLを検証しましょう。誰でも無効なHTMLを書くことができますが（次に会う人にHTML文書を書いてもらい、その出力を検証してみてください）、プロの開発者は有効なHTMLを作成することが期待できます。正しくて有効なHTMLを書くことは、誇りを持って行うべき技術です。

次回のWeb Almanacの章では、HTMLを書く技術を詳しく見て、できれば私たちがどのように改善してきたかを見ていく準備をしましょう。

あとは、あなたにお任せします。あなたの観察力はどうですか？何があなたの目に留まりましたか？何が悪くなって、何が良くなったと思いますか？Leave a commentであなたの意見を聞かせてください。