<meta>要素
要点
metaは、ページ本文としては表示しない情報を文書に結び付けます。charset、name、http-equiv、itempropでは、値の意味と処理の相手が異なります。
同じように見える指定でも、HTTP response header、HTML Standard上のmetadata name、CSS Viewport、CSPなど別の仕様に処理が分かれます。属性名だけから効果を推測せず、対象仕様と適用時点を確認します。
役割と属性モデル
metaは文書レベルのmetadata、pragma directive、またはHTMLシリアライズ時の文字コード宣言に使われます。要素自身に表示内容はありません。通常はhead内に置きます。Microdataのitempropとして使う場合は、本文内に置ける例外があります。
| 属性 | 役割 | 主な条件 |
|---|---|---|
charset | 文書の文字コードを宣言する | 値はUTF-8。文書内に複数の宣言を置かない |
name + content | 名前と値の組で文書metadataを記録する | 使える名前と値の意味はmetadata nameごとに定義される |
http-equiv + content | 標準で定められたpragma directiveを指定する | すべてのHTTP headerを置き換える機能ではない |
itemprop + content | Microdataのproperty valueを与える | 要素の配置可能場所はMicrodataの条件にも従う |
通常、これら4つの識別属性のうち、指定するのは1つです。name、http-equiv、itempropを使う場合はcontentも必要です。仕様上の適合条件と、ブラウザーが不適合markupをどう処理するかは分けて記録します。
charsetと文字コード判定
<head>
<meta charset="utf-8">
<title>ページの名前</title>
</head>
charsetの値はASCII case-insensitiveにutf-8と一致する必要があります。適合するHTML内宣言は文書の先頭1024 bytes内に収めます。これはブラウザーのparserが先頭部分を調べ、文字をデコードするための条件です。
parserの文字コード判定では、たとえばBOMや、HTTP responseのContent-Typeにあるcharsetなど、HTML内宣言より先に確認される情報があります。HTML内の宣言だけを見て、実際に使われた文字コードを断定できません。別の情報と食い違った場合は、responseと文書の両方を確認します。
HTML Standardは、BOMがなく、HTTPのmetadataで文字コードが明示されず、iframe srcdocでもないHTML文書では、文書内に文字コード宣言を要求します。
nameとcontent
nameはmetadataの種類、contentはその値を示します。HTML Standardが定める名前ごとに、値の形式、重複条件、処理するuser agentが異なります。
| 名前の例 | 仕様上の役割 | 確認する境界 |
|---|---|---|
description | ページを説明する短い文字列 | 検索serviceが使うことはあるが、snippet表示や順位を保証しない |
referrer | 文書の既定referrer policy | Referrer Policyとの関係、response header、後から挿入・変更した場合の処理 |
theme-color | user agentの周辺UIに使う候補色 | 色の妥当性、任意のmedia条件、browser UIの対応 |
color-scheme | 文書が扱えるcolor schemeを伝える | CSS Color Adjustmentと表示・form controlの連携 |
viewportという名前は、モバイル向けlayout viewportを扱うCSS Viewport系の仕組みとして確認します。HTML Standardが定義する通常のmetadata nameと同じ処理モデルとは限らず、端末とbrowserの差も別に検証します。Open Graphなどのog:*は外部仕様の語彙であり、HTML Standard単独の機能として扱いません。
http-equivとresponse header
http-equivは、HTML Standardが定めるpragma directiveを選びます。属性名に「http」が含まれていても、HTTP response headerをそのまま代替する一般的な仕組みではありません。
content-security-policyは、parserがそのmeta要素へ到達した後のdocumentに関係します。先に処理済みの内容へ遡って適用できません。CSPのframe-ancestors、sandbox、report-uriなどはmeta経由のpolicyから取り除かれ、Content-Security-Policy-Report-Onlyもmetaでは使えません。security policyの配信にはresponse headerが優先されます。refreshは文書の再読込・遷移を起こす可能性があります。実行時の動作はWPTではなく、隔離した安全なfixtureで検証します。content-languageなど一部directiveには歴史的な動的処理規則があります。属性の追加・削除後の状態を、初期markupだけから推測しません。
directive keywordはASCII case-insensitiveに扱う規則を持つものがありますが、各directiveの値や適用時点は個別に確認します。
DOM interface
HTML文書中の要素はHTMLMetaElementとして公開されます。DOM propertyは要素が持つmarkup attributeを調べる入口です。property値だけで、response headerやuser agentの最終動作までは分かりません。
const description = document.querySelector('meta[name="description"]');
description instanceof HTMLMetaElement;
description.name;
description.content;
description.getAttribute("content");
仕様上の主張と根拠
主張と適用範囲、確認状態を分けます。browser implementation、WPT、accessibility APIの実測結果は下記のImplementation Evidenceに記録します。
| 種別 | 主張 | 条件・範囲 | 状態 | 根拠 |
|---|---|---|---|---|
| SPEC | metaはmetadata、pragma directive、または文字コード宣言を表します。 | 値の意味は指定した属性の組み合わせで決まります。 | 確認済み | HTML Standard: meta element |
| SPEC | 4種類の識別属性は、適合markupでは同じmeta上で1つを選びます。 | name、http-equiv、charset、itemprop。attribute omissionや不適合markupの処理は別問題です。 | 確認済み | HTML Standard: meta element |
| SPEC | HTML内の文字コード宣言はUTF-8で、先頭1024 bytes以内に完全に現れる必要があります。 | 適合性の要件。実際のdecode algorithmはBOM、transport metadataなども調べます。 | 確認済み | HTML Standard: character encoding declaration |
| SPEC | meta配信のCSPは、HTTP response headerと同じ対象範囲・時点・directiveを持ちません。 | response headerのCSPが推奨され、metaの解析より前の内容は保護できません。 | 確認済み | Content Security Policy: HTML meta element |
Evidence
- HTML Standard: The meta element — 属性の組み合わせ、metadata、pragma directive
- HTML Standard: Character encoding declaration — UTF-8宣言と配置条件
- HTML Standard: Determining the character encoding — parserのdecode手順と優先順
- Content Security Policy: HTML meta element — meta-delivered CSPの適用境界
- HTML Accessibility API Mappings 1.0: meta — roleとplatform mapping
- CSS Viewport Module Level 1: viewport meta — viewport記述子の処理
Browser、WPT、AAMの実測
標準の記述と実測を区別します。Chrome系ブラウザーの限定fixtureと選定したWPTを実測し、EdgeのWindows UI Automation treeも確認しました。HTML-AAMの表とBrowser accessibility treeの結果はWindows UIAとは分けて記録します。NVDAの読み上げは出力を取得できず未実測です。
実測状況: WPTは5 filesに限定し、Firefoxは使用していません。WPTのupstream revisionは未固定です。Windows UIAはEdgeで実測済みですが、NVDAの音声出力が未確認のため、AAMの実測は部分確認として扱います。
| 種別 | 再現確認の範囲 | 条件・記録 | 状態 |
|---|---|---|---|
| IMPL | 文書の文字コード、HTMLMetaElementのIDL値、itemprop属性、color-schemeが選ぶ表示scheme |
2026-10-04 / Windows 11 Pro build 26300。Codex In-app Browser(Chrome UA 154.0.0.0、viewport 1280×720 / DPR 1.25)とEdge(UA Edg/154.0.0.0、viewport 1028×624 / DPR 1.25)でbuild-config/yugien/research-results/meta-v1/を測定。fixture responseはContent-Type: text/html(charset parameterなし)、HTML先頭に<meta charset="utf-8">があり、両方でdocument.characterSet=UTF-8。name、content、httpEquiv、mediaのIDL値、charset属性、本文内itemprop属性を確認。両方でcharsetは属性として取得でき、要素のcharsetIDL propertyはありません。color-scheme=darkではrootのused schemeがdark、操作でlightへ変えるとlight。headの6個とbodyの1個のmetaはBrowser accessibility treeに個別nodeとして現れません。Chromium系2環境のみ。Firefox、Safari、他version・deviceは未観測。 |
部分実測(Chrome 154 / Edge 154) |
| WPT | color-schemeの変更・tree order、http-equivとnameの相互作用、directive keywordのASCII case-insensitive処理に関する5 test files |
2026-10-04 / Windows 11 Pro build 26300 / Codex In-app Browser(Chrome UA 154.0.0.0)とEdge(UA Edg/154.0.0.0)/ wpt.live。両browserでHarness status OK。meta-color-scheme-attribute-changes.html (8/8)、http-equiv-and-name-1.html (1/1)、http-equiv-and-name-2.html (1/1)、meta-color-scheme-first-valid-applies.html (1/1)、http-equiv-enumerated-ascii-case-insensitive.html (1/1)。Chrome 12/12、Edge 12/12、計24/24 selected test cases pass。wpt.liveのupstream revisionは表示されず、commit未固定。全directory、他browser engine、他versionは未実行。実測時のテスト版は未記録です。リンク先の内容は変わることがあり、当時と同じテストで再確認できるとは限りません。 |
部分実行(Chrome / Edge 各12/12 pass) |
| AAM | HTML-AAMのmeta mapping、EdgeのWindows UIA tree、Chrome / Edge Browser accessibility tree。NVDAの読み上げは未実測 |
HTML-AAM Editor’s Draft (2026-07-29), section 3.5.92 meta mapping: No corresponding WAI-ARIA role; Computed Role / UIA / MSAA+IA2 / ATK/AT-SPI / AX are Not mapped. 2026-10-04 / Windows 11 Pro build 26300 / Edge UA Edg/154.0.0.0. Read the native Windows UIA tree with System.Windows.Automation: the page was exposed as ControlType.Document, with Hyperlink, Text, Table, List, ListItem, Group, and DataItem descendants. The six head and one body meta elements were not exposed as individual UIA element nodes; visible words that mention “meta” were ordinary page text. Chrome and Edge Browser accessibility trees exposed the web area, headings, tables, links, and text, but no meta element nodes. NVDA was available and started, but its spoken output was not captured, so assistive-technology speech remains unmeasured. Firefox was not used; other browsers remain untested. |
部分確認(Edge UIA / Browser tree、NVDA未実測) |
Coverage / Open Issues
- SPECHTML Standardの属性モデル、文字コード宣言、主なmetadata/pragmaの境界を整理。
- AAM SPECHTML-AAMにある
metaのroleとplatform mappingを確認対象に含める。 - Assistive technologyNVDAの読み上げ・操作順と、他browserのWindows UIA treeは未実測。
- ViewportCSS Viewportの幅・zoom・
interactive-widgetと各browser/deviceの差は独立した実測が必要。 - Metadata vocabulariesOpen Graph、検索serviceごとのsnippet選択、非標準の
nameはHTML Standardの定義外として別途確認。
Related surface
まず使い方を短い例で確認する場合は、Yugienのmeta要素を参照してください。文書と外部resourceの関係はlink要素、ページの名前を定義する条件はHTML Standardのtitle要素で確認できます。