HTML：オプションの終了タグを含めるか、除外しますか？

149

一部のHTML ¹終了タグはオプションです。つまり、

</HTML>
</HEAD>
</BODY>
</P>
</DT>
</DD>
</LI>
</OPTION>
</THEAD>
</TH>
</TBODY>
</TR>
</TD>
</TFOOT>
</COLGROUP>

注：含めることが禁止されている終了タグと混同しないでください。

</IMG>
</INPUT>
</BR>
</HR>
</FRAME>
</AREA>
</BASE>
</BASEFONT>
</COL>
</ISINDEX>
</LINK>
</META>
</PARAM>

注： xhtml HTMLとは異なります。xhtmlはxmlの形式であり、すべての要素に終了タグが必要です。終了タグはhtmlでは禁止されていますが、では必須ですxhtml。

オプションの終了タグです

理想的には含まれていますが、忘れた場合は受け入れます。
理想的には含まれていませんが、あなたがそれらを入れれば私たちはそれらを受け入れます

言い換えれば、それらを含めるべきか、含めるべきではないのか？

オプションのものの要素タグを閉じるに関するHTML 4.01仕様の会談が、それはそれらを含めないためにそれら、または望ましいを含むことが好ましいかどう言いません。

一方、DevGuruに関するランダムな記事では、次のように述べています。

終了タグはオプションです。ただし、含めることをお勧めします。

私が尋ねる理由は、互換性の理由からオプションであることを知っているからです。そして、もし可能なら彼らを（強制 | 禁止）にしたでしょう。

別の言い方をすると、HTML 1、2、3はこれらのオプションに関して、現在はオプションの終了タグで何をしましたか。HTML 5は何をしますか？そして、私は何をすべきですか？

注意

HTMLのいくつかの要素がされている禁断の終了タグを持っていることから。あなたはそれに同意しないかもしれませんが、それは仕様であり、議論の余地はありません。オプションの終了タグと、その意図について尋ねています。

脚注

¹ HTML 4.01

html html4

— イアン・ボイド
ソース

4

難しい質問です。w3cの推奨事項には、両方を実行する例も含まれています。w3.org / TR / html401 / struct / global.html#id-and-class最初の例には終了</p>タグがあり、2番目の例では省略されています。

— Richard JP Le Guen

ただ、明確にする- HTML5で禁じられたタグの場合には、「明示的な」/ XMLの有効な解決策は、それらを閉じるためにある/>ような、<meta charset="utf-8" />たとえ<meta charset="utf-8">有効なHTML5のですか？

— cboettig 2012年

@cboettigはい。<meta charset="utf-8" />で、無効な HTML、それはしなければならないこと<meta charset="utf-8">。一方<meta charset="tuf-8">で、無効な XHTML、それはしなければならないこと<meta charset="utf-8" />

— イアン・ボイド

@IanBoyd本当に？HTML5で？polyglot html / xhtmlのドラフトW3Cマニュアルは<meta charset="UTF-8"/>、終了タグと一緒に使用することを述べています。それ以外の場合、どのようにしてポリグロットまたはxhtmlがhtml5およびxmlとして検証されますか？

— cboettig 2012年

@cboettigそうですね。ポリグロットマークアップ（つまり、HTML互換のXHTMLドキュメント）は、有効なHTML 4.01にすることはできません。HTML5（まだ作業中）には、Void要素（終了タグを付けることができない要素）という概念があります。おそらくほとんどのブラウザは穏やかで、マークアップエラーを許すでしょう。

— Ian Boyd

49

オプションのものは、終了タグを必要とせずに、それらがどこで終了するかを意味的に明確にする必要があるすべてのものです。EGはそれぞれ<li>、</li>直前に1つもない場合を意味します。

すべての禁止された終了タグの直後に終了タグが続くため、<img src="blah" alt="blah"></img>毎回入力する必要があるのは一種の冗長です。

私はほとんどの場合、オプションのタグを使用します（私が使用しない非常に正当な理由がない限り）。これは、より読みやすく更新可能なコードに役立つためです。

— アスラム
ソース

18

今見えます。 <LI>弾丸のようなものです。箇条書き全体をで囲む必要はありません<LI>...</LI>。したがって、そのようにして、LIマークアップ中に人々が自然に書くものと一致します。段落記号（<P>）の場合も同様です。ワードプロセッサでは、段落の先頭に段落記号を追加します。全員の終わりではありません。したがって、この解釈では、通常の人がそれらを持っているとは考えないため、終了タグはオプションです。さらに、要素自体にはコンテンツがありません。要素はコンテンツです。

— Ian Boyd 2010年

8

私がほとんど常にオプションのタグを使用しているとはどういう意味ですか？終了タグを含めることを意味しますか、それとも省略しますか？（私はあなたの答えを読んだとき、あなたはそれを含んでいるという印象を受けました—しかし、Ian Boydによる上記のコメントはあなたがそれを除外したという印象を私に与えます。）

— KajMagnus

3

@IanBoydそして最後の段落について？

— パチェリエ

22

@Pacerier人々は何百年もの間テキストの段落を書いてきました。段落が終わっても混乱する人はいません。

— Ian Boyd

4

実際のリファレンスドキュメントを見つけようとしたときにこの答えを見つけた人のためのHTML5の関連リンク：w3.org/TR/html5/syntax.html#optional-tags

— Mike 'Pomax' Kamermans

59

明示的なタグが役立つ場合がありますが、時々それは不必要な歩みです。

HTML仕様では、タグの省略が有効な場合を明確に指定しているため、常にエラーになるとは限りません。

たとえば、あなたは決して必要としません</body></html>。誰も入れたことを覚えていない<tbody>（XHTMLが例外を作成するまで）明示的に記述した。

</head><body>実際に検索するDOM操作スクリプトがない限り、必要はありません<head>（暗黙の終わりのルール<head>があなたを驚かせる可能性があるため、明示的に閉じることをお勧めします）。

ネストされたリストは、実際にはなしのほうが適し</li>ていul > ulます。それは、誤ったツリーを作成するのが難しいためです。

有効：

<ul>
  <li>item
  <ul>
    <li>item
  </ul>
</ul>

無効：

<ul>
  <li>item</li>
  <ul>
    <li>item</li>
  </ul>
</ul>

また、すべての要素を閉じようとするかどうかにかかわらず、終了タグは暗黙に含まれることに注意してください。終了タグを付けても、解析が自動的に堅牢になるわけではありません。

<p>foo <p>bar</p> baz</p>

次のように解析されます：

<p>foo</p><p>bar</p> baz

ドキュメントを検証するときにのみ役立ちます。

— コーネル
ソース

4

待って、なぜ<p>foo <p>bar</p> baz</p>2つのネストされたpタグとして解析されないのですか？

— Eric

19

ため<P>の要素はブロックレベル要素を含むことができない、と <P>ブロックレベル要素です。から（w3.org/TR/REC-html40/struct/text.html#edef-P）「P要素は段落を表します。ブロックレベルの要素（P自体を含む）を含めることはできません。」

— Ian Boyd 2010年

1

@IanBoyd CSSルールに関係なく、ブロックレベルの要素を含めることはできませんか？

— パチェリエ

6

@Pacerier CSSは、DOMに影響を与えることはできません。DOMが最初に解析され、次にCSSがそれを表示します。CSSのblock表示は、HTMLのブロックレベルのコンテンツとはまったく異なります（ほとんどのHTMLブロックレベルの要素がデフォルトでCSSブロックとして表示されることはありません）。

— Kornel

2

@ anton1980いいえ、これは同じではありません。省略されたオプションの終了タグの処理は明確に指定されており、すべての準拠ブラウザーで確実に機能します。OTOHのメイクアップ<t>はのようには機能しません<title>。

— Kornel 2012

18

さまざまな矛盾を理解できるように、HTMLの歴史に役立つリンクをここにいくつか追加します。これはあなたの質問への答えではありませんが、これらのさまざまなダイジェストを読んだ後、あなたはより多くを知るでしょう。

Dive Into HTML5からの抜粋：

「壊れた」HTMLマークアップがWebブラウザーでも機能するという事実により、作成者は壊れたHTMLページを作成するようになりました。壊れたページがたくさん。一部の推定では、今日のWeb上のHTMLページの99％以上に少なくとも1つのエラーがあります。ただし、これらのエラーが原因でブラウザに目に見えるエラーメッセージが表示されることはないため、誰もエラーを修正しません。

W3CはこれをWebの根本的な問題と見なし、彼らはそれを修正しようとしました。1997年に発表されたXMLは、寛容なクライアントの伝統を破り、XMLを使用するすべてのプログラムは、いわゆる「整形式」エラーを致命的なものとして扱わなければならないことを義務付けていました。最初のエラーで失敗するというこの概念は、彼の法律の比較的軽微な違反に対して死刑を制定したギリシャの指導者ドラコの後、「厳格なエラー処理」として知られるようになりました。W3CがHTMLをXMLボキャブラリとして再定式化したとき、新しいapplication/xhtml+xmlMIMEタイプで提供されるすべてのドキュメントは厳格なエラー処理の対象になることを義務付けました。XHTMLページに整形式エラーが1つでもあった場合は[…] Webブラウザーは処理を停止してエンドユーザーにエラーメッセージを表示するしかありません。

このアイデアは広く普及していませんでした。既存のページの推定エラー率は99％であり、エンドユーザーにエラーが表示される可能性が常にあり、コストを正当化するためのXHTML 1.0および1.1の新機能が不足しているため、Web作成者は基本的に無視しましたapplication/xhtml+xml。しかし、それは彼らがXHTMLを完全に無視したという意味ではありません。ああ、間違いなく。XHTML 1.0仕様の付録Cは、世界のWeb作成者に抜け穴を与えました。「XHTML構文のようなものを使用しますが、text/htmlMIMEタイプでそれを提供し続けてください。」そして、まさにそれが何千人ものWeb開発者がしたことです。彼らはXHTML構文に「アップグレード」しましたが、text / html MIMEタイプでそれを提供し続けました。

今日でも、何百万ものWebページがXHTMLであると主張しています。彼らは、最初の行にXHTMLのDOCTYPEで始まる使用小文字のタグ名、属性値の周りに引用符を使用、など空要素の後に末尾にスラッシュを追加<br />して<hr />。しかし、これらのページのごく一部のみが、application/xhtml+xmlXMLの厳格なエラー処理をトリガーするMIMEタイプで提供されます。MIMEタイプで提供されるページtext/html doctype、構文、またはコーディングスタイルに関係なく、「寛容な」HTMLパーサーを使用して解析され、マークアップエラーは無視され、エンドユーザー（または他のユーザー）に警告することはありません。技術的に壊れています。

XHTML 1.0にはこの抜け穴が含まれていましたが、XHTML 1.1はそれを閉じ、決して確定されていないXHTML 2.0は、過酷なエラー処理を要求するという伝統を継続しました。そして、それがXHTML 1.0であると主張するページが数十億あり、XHTML 1.1（またはXHTML 2.0）であると主張するほんの一握りのページがある理由です。それで、本当にXHTMLを使用していますか？MIMEタイプを確認してください。（実際、使用しているMIMEタイプがわからない場合でも、引き続きを使用していることはほぼ保証できますtext/html。）MIMEタイプがのページを提供している場合を除きapplication/xhtml+xml、いわゆる「XHTML」名前のみのXMLです。

[T]進化するHTMLとHTMLフォームを提案していた人々は、2つの選択肢に直面しました：あきらめるか、W3C外で作業を続けるかです。後者を選択してwhatwg.orgドメインを登録し、2004年6月にWHATワーキンググループが誕生しました。

[T] WHATワーキンググループは他にもいくつか静かに取り組んでいました。それらの1つは、最初はWebフォーム2.0と呼ばれていた仕様で、HTMLフォームに新しいタイプのコントロールが追加されました。（A Form of MadnessでWebフォームについて詳しく説明します。）もう1つは、「Webアプリケーション1.0」と呼ばれるドラフト仕様で、ダイレクトモードの描画キャンバスやプラグインなしのオーディオとビデオのネイティブサポートなどの主要な新機能が含まれていました。

2009年10月、W3C はXHTML 2ワーキンググループを閉鎖し、彼らの決定を説明するために次の声明を発表しました。

W3Cが2007年3月にHTMLおよびXHTML 2ワーキンググループを発表したとき、XHTML 2の市場を引き続き監視することを示しました。W3Cは、HTMLの将来についてコミュニティに明確な信号を送ることの重要性を認識しています。

長年にわたるXHTML 2ワーキンググループの貢献の価値を認識していますが、参加者との議論の後、W3Cの経営陣は、ワーキンググループの憲章を2009年末に期限切れにし、更新しないことを決定しました。

勝つものは出荷するものです。

— スリカル・ドディ
ソース

12

私が尋ねる理由は、互換性の理由からオプションであることを知っているからです。そして、もし可能であれば、彼らはそれらを作成しました（必須|禁止）。

それは興味深い推論です。私が読んだのは、タグが確実に推測できるときはいつでも、タグはオプションです。デザインは、意図がそれを素早く簡単に書けるようにすることであったことを示唆しています。

HTML 1、2、3はこれらの、現在はオプションの終了タグに関して何をしましたか。

HTML 2のDTDはRFCに埋め込まれており、元のHTML DTDとともに、オプションの開始タグと終了タグがいたるところにあります。

HTML 3は（ブラウザ戦争のおかげで）放棄され、HTML 3.2（当時のWebの状態を説明するために設計された）に置き換えられました。

HTML 5は何をしますか？

HTML 5は、当初から「牛の道を舗装する」ことを目指していました。

そして、私は何をすべきですか？

ああ、今それは主観的で議論的です:)

一部の人々は、明示的なタグは読者の目の前にいるため、読みやすさと保守性に優れていると考えています。

一部の人々は、エディターを散らかさないので、推測されたタグは読みやすさと保守性に優れていると考えています。

— クエンティン
ソース

1

+1私は「確実に推論される」という概念を考えていませんでした。つまり、どちらにしても意図はまったくなかったという考えを支持しています。仕様は、既存のHTMLコンテンツおよびHTML仕様と可能な限り互換性があるようにしようとしていると想定しました。

— Ian Boyd 2010年

すみません、デイブ、私はアスラムにそれを与えました。彼は担当者が必要です:)しかし、あなたは同じ考えを持っています。しかし、いい答えです。

— Ian Boyd 2010年

8

HTML 5は何をしますか？

この質問に対する回答は、W3Cワーキングドラフトにあります。http： //www.w3.org/TR/html5/syntax.html#syntax-tag-omission

そして、私は何をすべきですか？

それはスタイルの問題です。終了タグは絶対に省略しないようにします。厳密にするのに役立ち、必要なタグを省略しないようにするためです。

— グッペ
ソース

HTML 5仕様のドラフトへのリンクと適切なセクションの+1。しかし、html 5はどちらかといえば言いません。

— Ian Boyd

6

不要な場合は省略してください。

それが目的を果たしている場合は（IDEを緩和したり、目を緩和したりするなど、一見些細な目的であっても）、そのままにしておきます。

明確に定義された仕様では、動作に影響を与えないオプションの項目を確認することはまれです。もちろん、「コメント」を除いて。しかし、HTML仕様は設計仕様ではなく、現在の主要な実装の状態に関するドキュメントの詳細です。そのため、アイテムがHTMLでオプションであり、それが目的を果たさないように見える場合、オプションの性質は特定のブラウザーの癖のドキュメントにすぎないと推測する場合があります。

上記のHTML-5仕様のRFCセクションを見ると、オプションのタグがコメントの存在に奇妙にリンクされていることがわかります。これで、作成者はデザイン帽子をかぶっていないことがわかります。代わりに、主要な実装で「癖を文書化」するゲームをプレイしています。したがって、この点について仕様を真剣に受け止めることはできません。

したがって、解決策は次のとおりです。発汗しないでください。実際に重要なことに移りましょう。:)

— ジョン
ソース

5

最良の答えは、読みやすさやエラー検出のために終了タグを含めることだと思います。ただし、生成されたHTML（たとえば、データのテーブル）がたくさんある場合は、オプションのタグを省略して、帯域幅を大幅に節約できます。

— ガベ
ソース

2

リチャード：構造が深くネストされている場合、終了タグが意図に関する詳細情報を提供するため、エラーを見つけるのがはるかに簡単になります。

— Gabe

1

「閉じるタグは意図についてのより多くの情報を与える」と私はこの質問に対する最良の簡潔な答えだと思います。いずれにせよ、明確な理由を主張します。

— squarecandy 2015年

4

私の推奨は、ほとんどのオプションの終了タグと、回避できるすべてのオプション属性を省略することです。多くのIDEは文句を言うので、これらのいくつかを省略しても問題を回避できない場合がありますが、一般的にはファイルサイズが小さく、煩雑さが少ない方が適しています。コードジェネレーターを使用している場合は、そこから終了タグを削除してください。通常、それはどちらにしても関係ありません。

しかし、それが重要な場合は、それに基づいて行動します。私の最近のいくつかの作業では、要素のテキストが同じであったオープンタグの生成された終了および冗長な値属性のほとんどを排除することにより、レンダリングされたHTMLのサイズを1.5 MBから800 KBに減らすことができました値。約200のタグがあります。これを別の方法で完全に実装することもできますが、作業量が増えるため（$$$）、ページの応答性を簡単に高めることができます。

好奇心から、必要のない属性の周りの引用符を削除すると、20 KBを節約できることがわかりましたが、私のIDE（Visual Studio）はそれを好みません。また、ASP.NETが生成する非常に長いIDが私のファイルの20％を占めることにも驚きました。

厳密に有効なHTMLの関連部分を得ることができるという考えはそもそも誤解されていたので、あなたとあなたの顧客に最も効果的なものを何でもしてください。私がこれまでに見たり使用したりしたほとんどのツールは、xhtmlを生成すると言っていますが、実際には100％機能するわけではなく、厳密に準拠しても何のメリットもありません。

— user1777246
ソース

オプションの終了タグの省略はほとんど受け入れられませんが、属性の引用符を省略するのはかなり悪い考えです。あなたはあなたのサイトをそのようにいくつかのブラウザで壊す危険を冒しています。800kbのhtmlファイルがある場合、深刻な問題が発生しています。

— クリストフ

2

@Christoph：HTMLの仕様によれば、オプションの終了タグ（</p>または</li>）を省略しても問題ありません。ブラウザーがそれを理解できない場合は、ブラウザーに問題があります。

— Konrad Borowski 2013

2

個人的には、XHTMLのファンであり、ghoppeのように、「必要なタグを厳密に省略せずに済むようにするため、終了タグは絶対に省略しないようにしています」

だが

意図的にHTML 4.nを使用している場合、有効性ではなく整形式という概念はXMLの概念であるため、HTML 4.nを含めるとドキュメントの利用が容易になるとは言えません。特定の終了タグを禁止します。したがって、唯一の問題は有効性になります...そして、それなしでも問題が解決しない場合は...帯域幅を節約することもできますか？

— リチャードJPルグエン
ソース

2

終了タグを使用すると、フラグメントの動作が兄弟要素に依存しないため、フラグメントの処理が容易になります。この理由だけで十分説得力があります。一体型のhtmlドキュメントを扱う人はいますか？

— CurtainDog
ソース

1

C＃などのいくつかの中括弧言語では、2行しかないifステートメントの周りの中括弧を省略できます。例えば...

if（[条件]）
[コード]

しかし、これはできません...

if（[条件]）
[コード]
[コード]

3行目はifステートメントの一部にはなりません。それは読みやすさを損ない、バグは簡単に持ち込まれ、見つけるのが難しくなります。

同じ理由で、すべてのタグを閉じます。imgタグなどのタグは、個別の終了タグを使用するのではなく、まだ終了する必要があります。

— ミゲルR
ソース

トリッキーなHTMLの例を教えてください。私の経験では、オプションの終了タグはそれほど欺瞞的ではありません。

— Kornel

数年前にIE7に問題があったことを覚えています。ここでは、含まれているテキストとは別の行に開始liタグがあり、終了liがないため、IE7はすべての弾丸を1つの大きな弾丸のように扱いました。タグとテキストを1行に配置するか、タグを閉じると、問題が解決します。私は今これを再現することができないようです、それでおそらくそれはまた場のcssと関係があるのかもしれません。でも「これはカナダにガールフレンドがいるんだ！」と思ったからといってあなたを責めることはないでしょう。物語。

— MiguelR 2010年

0

HTMLパーサーを作成している場合、オプションの終了タグを含むHTMLを解析する方が簡単ですか？終了タグがどこにあるべきかを推測する必要がないので、オプションの終了タグが存在する方が簡単になると思います。

そのため、常にオプションの終了タグを含めています。ブラウザのHTMLパーサーで作成する作業が少ないため、ページのレンダリングが速くなるという理論に基づいています。

— ジョエル・ミュラー
ソース

1

同意しません; 有効性ではなく整形式性の概念はXMLのみの概念であり、終了タグが禁止されている要素がある場合は無関係になります。

— Richard JP Le Guen

1

私はそれを理解していますが、HTMLタグにない場合でも、レンダリングされたDOM要素には最初と最後の両方があります。<li>終了タグのないタグを含めると、ある時点で、ブラウザは要素の終了位置を決定し、そのポイントに終了タグを配置したかのように動作する必要があります。これは比較的ささいな量のロジックかもしれませんが、「一部」はまだ「なし」よりも多く、オプションの終了タグを省略することでそれらを含めるよりブラウザの作業が増えると考えるのは不合理ではないと思います。

— Joel Mueller

それは興味深い点ですが、私はまだ同意しません。クローズタグは、パーサーがポイントに達したときに...検証ルールに従って、彼らが必要とされるであろうと、オプションであり、したがって、暗黙の持つ検証によると終了タグであることをを、それが消費するタスクと主張することができませんでした終了タグ（存在する場合）が遅くなるだけですか？

— Richard JP Le Guen

@Richard-特定のブラウザでの実際の実装に依存すると思いますが、要素を終了する場所を明示することは、ブラウザにそれを理解するように指示するよりもパフォーマンスが悪いという考えを信じるのに苦労します君は。

— Joel Mueller

@RichardJPLeGuenたぶん、それはすべて、ルールがどのように正確に見えるかに依存します。を閉じているときに</table>スタックにが含まれている<table><tbody><tr><td>場合は、に一致するまですべてを閉じることができます<table>。同様に、<p>クロック以外のコンテキストで開く場合。しかし、もっと難しいケースがあるかもしれません、私にはわかりません。

— maaartinus 2014年

-1

コードをより読みやすく、保守しやすくなると思われることなら何でもしてください。

個人的に私は常に閉じるように傾斜されるだろう<td>と<tr>、私は頭を悩ますことはありません<li>。

— マシューウィルソン
ソース

1

私は元の設計決定についてのガイダンスを期待しており、可能であればxを実行していたでしょう。

— Ian Boyd

違いは何だ<td>と<li>あなたが気にしないで作りますか<li>？私にはほとんど違いがありません。

— ghoppe

技術的な違いはなく、純粋に主観的なものです。tdとtrを閉じると、HTMLを読みやすくなります。しかし、私は李で必要を感じたことがありません。

— マシューウィルソン

-2

禁止された終了タイプの場合<img />は、次のような構文を使用します/>。XMLで受け入れられるタグを閉じるには

— ダニ
ソース

1

HTML4では機能しません（少し異なる動作をするあいまいなSGML構文に一致します）。HTML5では許可されていますが、意味がありません。

— Kornel