HTML / Element / 初期Coverage

<meta>要素

状態: 初期Coverage 対象: HTML Living Standard 確認日: 2026-10-04

要点

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 + contentMicrodataの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 policyReferrer Policyとの関係、response header、後から挿入・変更した場合の処理
theme-coloruser 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に記録します。

主要な仕様上の主張
種別主張条件・範囲状態根拠
SPECmetaはmetadata、pragma directive、または文字コード宣言を表します。値の意味は指定した属性の組み合わせで決まります。確認済みHTML Standard: meta element
SPEC4種類の識別属性は、適合markupでは同じmeta上で1つを選びます。name、http-equiv、charset、itemprop。attribute omissionや不適合markupの処理は別問題です。確認済みHTML Standard: meta element
SPECHTML内の文字コード宣言はUTF-8で、先頭1024 bytes以内に完全に現れる必要があります。適合性の要件。実際のdecode algorithmはBOM、transport metadataなども調べます。確認済みHTML Standard: character encoding declaration
SPECmeta配信のCSPは、HTTP response headerと同じ対象範囲・時点・directiveを持ちません。response headerのCSPが推奨され、metaの解析より前の内容は保護できません。確認済みContent Security Policy: HTML meta element

Evidence

  1. HTML Standard: The meta element — 属性の組み合わせ、metadata、pragma directive
  2. HTML Standard: Character encoding declaration — UTF-8宣言と配置条件
  3. HTML Standard: Determining the character encoding — parserのdecode手順と優先順
  4. Content Security Policy: HTML meta element — meta-delivered CSPの適用境界
  5. HTML Accessibility API Mappings 1.0: meta — roleとplatform mapping
  6. 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の実測は部分確認として扱います。

meta要素の実装Evidence登録表
種別再現確認の範囲条件・記録状態
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要素で確認できます。