ハクソク

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

HTMLを思い通りに動かすために忘れてはいけないタグ

210日前原文(blog.jim-nielsen.com)

概要

HTMLファイルを正しく動作させるための必須スニペットを解説。 各タグの役割と重要性を簡潔に整理。 初心者でも分かるようにポイントごとに説明。 よくあるミスや注意点も補足。 最後にジョークを交えた締めくくり。

HTMLが正しく動作するための呪文

  • HTMLファイル作成時 に最低限含めるべきスニペットの紹介。
  • Alex Petrosのスライド 「Incantations that make HTML work correctly」に着想を得た解説。
  • ブラウザで直接開く場合 やローカルでテストする際にも有効な基本構成。

doctype宣言

  • <!doctype html>はブラウザの 標準モードを強制する宣言。
    • これがないと quirks mode（互換モード） で動作し、レイアウトやサイズ計算が崩れる原因。
  • 記述例：<!doctype html>（大文字小文字は問わない）
  • 1998年風に<!DOCTYPE HTML>でもOK、変則的な表記でも動作。
  • 一貫した表示 や予期しない動作防止のため、必ず先頭に記述。

html lang属性

  • <html lang="en">で 文書の言語を明示。
  • スクリーンリーダー や 検索エンジン、 自動翻訳 などが正確に動作。
  • スペルチェック や ローカル固有ツール にも影響。
  • 省略しても見た目は変わらないが、 周辺ツールの精度低下 リスク。
  • サーバーから HTTPヘッダー で返すことも可能だが、 HTML内で明示 推奨。

meta charset="utf-8"

  • <meta charset="utf-8">で 文字エンコーディングを指定。
  • é, ü, “”や👍、非ラテン文字 などが正しく表示。
  • これがないと 文字化け や 記号の崩れ が発生。
  • 例：このタグなしでHTMLを開くと スマートクォートや絵文字 が化ける。
  • 必ずhead要素内 に記述。

meta viewport

  • <meta name="viewport" content="width=device-width,initial-scale=1.0">で モバイル表示を最適化。
  • これがないと スマホで極端に縮小表示 されることが多い。
  • レスポンシブデザイン や モバイル対応 には必須。
  • うっかり忘れると 「あれ？小さすぎ！」 となる典型的ミス。

よくあるジョークと補足

  • 「最重要スニペット」 として<div id="root"></div>や<script src="bundle.js"></script>を挙げるジョーク。
    • ReactやモダンJS 開発でよく使われる構成。
  • ただし、 HTMLの基本構成 としては上記4つが最重要。

まとめ：

  • <!doctype html>で標準モード宣言
  • <html lang="en">で言語指定
  • <meta charset="utf-8">で文字化け防止
  • <meta name="viewport"...>でモバイル最適化
  • これらを押さえれば HTMLが期待通り動作

Hackerたちの意見

こういう時には、よくHTML5ボイラープレートを使うよね。https://github.com/h5bp/html5-boilerplate/blob/main/dist/ind...

└

その当時のFacebookの独自メタデータライン（"og:..."のライン）が入ってるのはちょっと皮肉だよね。今や彼らの名前が"Meta"になったから、前よりもさらに独占的に見える。もしかしたら、名前は最初からメタバースとは関係なかったのかも…。

└

これ、必要なときにどうやって見つけるの？

自動で閉じるタグは、終わらせる必要がないってことに注意してね。それに、タグを実際にで囲むのはオプションだよ。属性にスペースとかがなければ、引用符もいらないし、もOKだよ。（今の時代、平均的なウェブサイトはページを読み込むたびにバズリオンバイトのJavaScriptを取得するから、ちょっと無意味な感じもするけど、たまにはできるだけスリムにするのが楽しくて満足感があるよね。）

└

、開始タグと終了タグは全部オプションだよ。実際には、lang属性があるから開始タグを省略しない方がいいけど、他のタグには属性が必要ないことが多いよ。（ボディ要素に属性やクラスを付けるなら、html要素の方が適切か考えてみてね。）は、や、や、を書くのはかなり前のことだな。

└

こういうのは、俺にはいつも雑に感じる。タグをちゃんと閉じるのはそんなに手間じゃないし、節約できるバイト数なんて、ウェブサイトの他のどの側面と比べても微々たるものだよ。必要のないdivスパムを避けるだけでも、もっと節約できるし、CSSが膨れ上がらないようにするのも大事だよね。もちろん、3MBのJSをダウンロードしないようにするのもね。これが達成するのは、構文をより不規則にして、解析しづらくすることだと思う。HTML5にはこういう緩和がなくて、ブラウザが単にエラーを表示してくれたらいいのに。そうすれば、ブラウザのコードやHTMLの仕様がかなりシンプルになると思う。

└

省略できるって知らなかったけど、明確さのために保持する方が好きだな。

└

タグを開いたままにするのが満足だとは言えないけど、面白い事実だね。

バンドルせずにウェブコンポーネントを使うのが好きな人、他にもいる？正直言うと、Lit Elementsを生のJavaScriptコードで使ってるんだけど、オートコンプリートを使うのをやめちゃったからね。今の時点でTypeScriptを使わないのは、今の多くの人にとってパンチカードを使ってるって言ってるのと同じようなもんだと思う。

└

37 Signals [0] は自社のほとんどの製品で独自のStimulus [1] フレームワークを使ってることで有名だよね。彼らのCEOは、追加の複雑さを加えるから、ノービルドアプローチを支持してるし、他の人が自分のコードを見たり学んだりするのが難しくなるからって言ってるよ。[0]: https://basecamp.com/ [1]: https://stimulus.hotwired.dev/

└

TSをJSに落とすのにはあまり賛成できないけど、小さなプロジェクトだとその方が議論しやすいのかもね。でも、君に同意する人がいるよ、あまり条件をつけずにね。https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701... これはLex Fridman/DHHのポッドキャストで知ったんだ。彼はTypeScriptがメタプログラミングをすごく難しくするって話してた。確かにそういうこともあるだろうけど、JSでどんなメタプログラミングができるのかはあまり理解できてないんだ。一般的な動的さはわかるけど。

└

他にバンドルなしでウェブコンポーネントを使うのが好きな人いる？ うん！それだけじゃなくて、ShadowDOMなしでもね。

└

TSを使っている場合でも、フルフレームワークではなくウェブコンポーネントを作るなら、バンドルしない方が好きです。そうすれば、各ページが必要なコンポーネントだけを読み込むことができますし、http/2を使えばファイルを別々にしても問題ありません。ハッシュを付けて不変のキャッシュヘッダーを設定すれば、変更があってもユーザーは実際に変わったものだけの新しいバージョンを引っ張ってくればいいんです。

└

そうそう、できるだけツールチェーンを少なくしたい。

面白い事実: HNと（偶然ではないだろうけど）paulgraham.comはどちらもDOCTYPEがなくて、Quirks Modeで表示されてるんだよね。これ、devtoolsでdocument.compatModeを評価すればわかるよ。僕は、ホバーした要素のテキストをコピーするためのちょっとしたユーザースクリプトをどこにでも入れてるんだけど（リンクだけじゃなくてね）。それがやるのは、最も内側のホバーした要素を取得するために[...document.querySelectorAll(":hover")].at(-1)ってやつ。スタンダードモードのページではうまくいくけど、クイークスモードのページではちょっと不安定なんだ。質問なんだけど、ユーザーとしてクイークスモードのページをスタンダードモードで表示させる簡単でクリーンな方法ってあるのかな？document.write("" + document.documentElement.innerHTML);みたいなこともできるけど、それだと全体のドキュメントが吹き飛んじゃって、いろんな問題が出てくるんだよね。もっとクリーンなトリックはないかな？

└

dangがウェブサイトを見直して、使いやすさのアップデートをしてくれたらいいな。HNは今でもデフォルトで12pxに表示されるフォントサイズを使ってるから、ほとんどの現代のデバイスではめちゃくちゃ小さく見えるんだよね。ざっと見た感じ、約13年前に公開された同じCSSを使ってるみたいだよ。https://github.com/wting/hackernews/blob/5a3296417d23d1ecc90...

└

より良い選択肢はありますが、一般的には「いいえ」というのが答えです。最良の解決策は、WHATWGがdocument.compatModeを読み取り専用ではなく書き込み可能なプロパティとして定義することです。より良い選択肢は、古いノードへの参照を作成して保持すること（var old = document.documentElementのように簡単です）で、document.writeで全てを消去した後（空のhtml要素を使って；全体のツリーをシリアライズしないで）、新しいdocument.documentElementの下に再挿入します。 あなたのアプローチではhtml要素の属性が保持されないことに注意してください。これは、document.write呼び出しの前に子ノードを積極的に削除し、元のように属性をシリアライズするためにdocument.documentElement.outerHTMLに頼るか、古い要素の属性を一つずつ再設定することで修正できます。

└

uBlockフィルターでできるよ：||news.ycombinator.com/*$replace=/<html/

これはジョークだってわかってるけど、最後のタグが欠けてる気がするな…それがあればスクリーンリーダーがページの「クローム」をスキップして、たくさんの人にとって生活がずっと楽になると思う。ボーナスとして、メイン内のナビゲーション要素には(role="navigation")を使ってマークしておくといいよ。

└

僕は盲目の人じゃないけど、超最適化されたウェブサイトを作ろうとしたときに気になったことがある。スクリーンリーダーを喜ばせるためには、ナビゲーションのHTMLを最後に持ってくるのがベストみたいだったけど、視覚的には最初に来るようにスタイルを設定するのが良さそうだった（スマホでは上のナビバー、広い画面では左のナビメニュー）。

「著者は代わりに考えるかもしれません:」

└

面白いね。どうやらこれで一部のスクリーンリーダーが特定のアクセントを選べるみたい。ブラウザも適切なスペルチェッカー（アメリカ英語とイギリス英語）を選べるんだって。

TFA自体には間違ったDOCTYPEがあります。「DOCTYPE」と「html」の間に空白が欠けています。また、HTML属性の間のスペースも削除されていますが、HTML仕様では「ダブルクォート属性構文を使用する属性の後に別の属性が続く場合、二つの間にはASCII空白が必要です」と言っています。（https://html.spec.whatwg.org/multipage/syntax.html#attribute...）ブラウザはそれを理解していると思いますが、これはおそらくHTMLミニファイアによって自動的に行われたものでしょう。実際、ミニファイアは引用符なしの属性値構文（lang=en-us id=topではなくlang="en-us" id="top"）を使うことで、もっとバイト数を減らせたかもしれません。編集: minify-html Rustクレートでは「enable_possibly_noncompliant」を指定でき、そういったことが起こります。HTMLパーサーは（解析）仕様に従ってこれを受け入れなければならないという事実を利用していますが、（著作）仕様に従うと有効なHTMLではありません。

明確さと一貫性のために、最近はオプションですが、私はメタ情報を中に配置することにこだわっています。

まだ理解できないんですが、lang属性で何を達成しようとしているのか、みんなはどう思っているんでしょうか。言語を判断するのは簡単ですし、判断できない場合でも、読者にとっては簡単ではありません。

└

記事に書いてなかったっけ？ > ブラウザ、検索エンジン、支援技術などはこれを利用して： > - スクリーンリーダー用に発音や声を正しくする > - インデックス作成や翻訳の精度を向上させる > - ロケール特有のツール（例：スペルチェック）を適用する

私はウェブ開発者ではないので、誰か教えてくれませんか？なぜこのサイトや同じような「モダン」なサイトは、実際のコンテンツが画面の20%しか占めていないのでしょうか？私のブラウザウィンドウは2560x1487です。画面の80%が空白です。コンテンツを読むために170%にズームしなければなりません。古いブログではこの問題はなく、普通に動作します。これは意図的なのか、それとも悪いCSSのせいなのか？投稿のタイトルを考えると、これは少し関連があると思います。

└

よくわからないけど、数年前にUXの仕事をしていたとき、彼らは全てを固定幅でデザインして、画面の中央に配置していました。HackerNewsのように、中央に配置されていて、モニターの全幅にはスケールしない感じです。

└

よくあるのは、快適な読み幅を作るためだね。

└

おそらく、すごく広い段落を避けるためだろうね。ただ、俺はブラウザを150%くらいのズームで表示するように設定してる。デフォルトのフォントサイズはもうちょっと大きくしてもいいと思うけど、モバイルでは問題ないよ。