HTML のデバッグ

HTML を書くことは良いですが、何か問題が生じた場合どうなります？また、コード内のどこにエラーがあるか見つけられますか？この記事では HTML 内のエラーの発見、および修正の手助けをしてくれるいくつかのツールを紹介します。

デバッグは怖くない

何かのコードを書いている時、エラーが起きる (何かしらの間違いを犯したため、コードが機能しない、あるいは望んでいた方法でもない) その恐ろしい瞬間まで、通常は全く問題ありません。たとえば、以下は Rust 言語で書かれた単純なプログラムを compile しようとしたときに報告されるエラーを示しています。ここに、比較的分かりやすいエラーメッセージがあります。 — "終わりのない二重引用符文字列"。リストを見れば、おそらく論理的に println!(Hello, world!"); に二重引用符がない可能性があるとわかるでしょう。しかし、プログラムが大きくなるにつれてエラーメッセージはすぐに複雑になり、解釈しにくくなります。簡単な場合でも、Rust について何も知らない人には少し威圧的に見えるかもしれません。

デバッグを怖がる必要はありません —  プログラミング言語やコードの作成、デバッグに慣れるための鍵は、言語とツールの両方に精通していることです。

HTML とデバッグ

HTML は Rust ほど理解するのが複雑ではありません。ブラウザが解析して結果を表示するまで、HTML は別の形式にコンパイルされません (解釈されますが、コンパイルはされません)。そして HTML の element 構文は、Rust、JavaScript、または Python のような "実際のプログラミング言語" よりはるかに理解しやすいです。ブラウザが HTML を解析する方法は、プログラミング言語の実行方法よりもはるかに寛容です。これは良いことと悪いことの両方です。

許容コード

では寛容とはどういうことでしょうか。まあ、一般的にコードで何か間違ったことをするとき、出くわすことになる2つの主なタイプのエラーがあります：

• シンタックスエラー: 上記の Rust エラーのように、コード内のスペルミスで実際にはプログラムが実行されません。言語の構文に精通していて、エラーメッセージが何を意味するのか知っている限り、これらは通常修正が簡単です。
• ロジックエラー: これらは、シンタックスは実際には正しいのですが、コードが意図したものではないため、プログラムが正しく実行されないエラーです。エラーの原因を特定するためのエラーメッセージがないため、シンタックスエラーよりも修正が困難です。

HTML 自体は構文エラーに悩まされていません。ブラウザが構文解析エラーを許容して解析するからです。つまり、構文エラーがあってもページは表示されたままです。ブラウザには、誤って書かれたマークアップを解釈する方法を記述するための組み込みのルールがあるので、たとえそれが期待したものでなくても、実行することはできます。もちろん、これはまだ問題になる可能性があります。

アクティブラーニング: 許容コードの学習

HTML コードの寛容な性質を学習する時が来ました。

1. まず、debug-example のデモをダウンロードしてローカルに保存します。このデモは、調査するために意図的にエラーを含むように書かれています (HTML マークアップは整形式ではないと言われており、整形式とは対照的です)。
2. 次にブラウザで開きます。 このようなものを見るでしょう：
3. これはすぐには良く見えません。ソースコードを調べて、問題が解決できるかどうか確認しましょう (本文の内容だけが表示されます)。

   <h1>HTML debugging examples</h1>
   
   <p>What causes errors in HTML?
   
   <ul>
     <li>Unclosed elements: If an element is <strong>not closed properly,
         then its effect can spread to areas you didn't intend
   
     <li>Badly nested elements: Nesting elements properly is also very important
         for code behaving correctly. <strong>strong <em>strong emphasised?</strong>
         what is this?</em>
   
     <li>Unclosed attributes: Another common source of HTML problems. Let's
         look at an example: <a href="https://www.mozilla.org/>link to Mozilla
         homepage</a>
   </ul>

4. 問題を見てみましょう。
   • paragraph と list item 要素には終了タグがありません。上の画像を見ると、ある要素がどこで終わり、別の要素が始まるべきかを推測するのは簡単なので、これはマークアップのレンダリングにあまり悪い影響を与えていないようです。
   • 最初の <strong> 要素には終了タグがありません。要素がどこで終了するのか分かりにくいので、もう少し問題があります。実際、残りのテキスト全体が強調されています。
   • このセクションはひどくネストされています： <strong>strong <em>strong emphasised?</strong> what is this?</em>。前の問題もあって、これがどのように解釈されたかを見分けるのは容易ではありません。
   • href 属性値に、閉じ二重引用符がありません。これが最大の問題を引き起こしているようです。リンクはまったくレンダリングされていません。
5. それでは、ソースコードのマークアップに対して、ブラウザがレンダリングしたマークアップを見てみましょう。これを行うには、ブラウザの開発者ツールを使用できます。ブラウザの開発者ツールの使い方に慣れていない場合は、Discover browser developer tools を数分確認してください。
6. DOM インスペクタでは、レンダリングされたマークアップがどのように見えるかを見ることができます。
7. DOM インスペクタを使用して、ブラウザが HTML エラーを修正しようとしている方法を確認するためにコードを詳しく調べてみましょう (もちろん Firefox で確認していますが、他のモダンなブラウザでも同じ結果が得られるはずです)。
   • 段落とリスト項目には終了タグが付けられています。
   • 最初の <strong> 要素がどこで閉じられるべきかは明確ではないので、ブラウザはそれぞれ別々のテキストブロックをそれぞれ独自の強力なタグで、ドキュメントの一番下まで閉じています。
   • 不正確なネスティングはブラウザによってこのように修正されました：

     <strong>strong
       <em>strong emphasised?</em>
     </strong>
     <em> what is this?</em>

   • 二重引用符がないリンクは完全に削除されました。 最後のリスト項目は次のようになります。

     <li>
       <strong>Unclosed attributes: Another common source of HTML problems.
       Let's look at an example: </strong>
     </li>

HTML バリデーション

上記の例から、HTML が整形式であることを本当に確認したいことがわかります。しかし、どうですか？上のような小さな例では、行を検索してエラーを見つけるのは簡単ですが、巨大で複雑な HTML 文書についてはどうでしょうか。

最良の戦略は、HTML、CSS、およびその他の Web テクノロジを定義する仕様を管理する組織である W3C によって作成および管理されている Markup Validation Service を介して HTML ページを実行することです。この Web ページは入力として HTML ドキュメントを受け取り、それを通して、あなたの HTML の何が悪いのかを伝えるレポートを提供してくれます。

検証する HTML を指定するには、Web アドレスを指定するか、HTML ファイルをアップロードするか、または HTML コードを直接入力します。

アクティブラーニング: HTML ドキュメントの検証

サンプル文書でこれを試してみましょう。

1. まず、Markup Validation Service を1つのブラウザタブに読み込みます (まだ読み込まれていない場合)。
2. Validate by Direct Input タブに切り替えます。
3. 本文だけでなく、すべてのサンプルドキュメントのコードをコピーして、Markup Validation Service に表示される大きなテキスト領域に貼り付けます。
4. Check ボタンを押します

これでエラーと他の情報のリストを提供してくれるはずです。

エラーメッセージの解釈

エラーメッセージは通常役に立ちますが、あまり役に立たないこともあります。少し訓練すれば、これらを解釈してコードを修正する方法を考え出すことができます。エラーメッセージとその意味を見ていきましょう。各メッセージには行番号と列番号が付いているので、エラーを簡単に見つけることができます。

• "End tag li implied, but there were open elements" (2 instances): これらのメッセージは、要素が開いていて閉じる必要があることを示しています。終了タグは暗示されていますが、実際にはありません。行/列情報は、終了タグが実際にあるべき行の後の最初の行を指していますが、これは何が問題なのかを確認するのに十分な手掛かりです。
• "Unclosed element strong": これは理解するのが本当に簡単です — <strong> 要素は閉じられておらず、行/列情報はそれがどこにあるかを指し示しています。
• "End tag strong violates nesting rules": これは間違って入れ子になった要素を指摘し、行/列情報はそれがどこにあるかを指摘します。
• "End of file reached when inside an attribute value. Ignoring tag": これはかなり不可解です。ファイルの末尾が属性値の内側に表示されるため、おそらくファイルの末尾近くのどこかに適切に形成されていない属性値があるという事実を意味します。ブラウザがリンクをレンダリングしないという事実は、どの要素が問題になっているかについての良い手がかりを与えるはずです。
• "End of file seen and there were open elements": これは少しあいまいですが、基本的には適切に閉じる必要がある開いている要素があるという事実を指します。行番号はファイルの最後の数行を指しており、このエラーメッセージには open 要素の例を示すコード行が付いています。

  example: <a href="https://www.mozilla.org/>link to Mozilla homepage</a> ↩ </ul>↩ </body>↩</html>

  メモ: 閉じ引用符が抜けている属性は、文書の残りの部分が属性の内容として解釈されるため、open 要素になる可能性があります。

• "Unclosed element ul": <ul> 要素は正しく閉じられているので、これはあまり役に立ちません。閉じ引用符がないために <a> 要素が閉じられないため、このエラーが発生します。

すべてのエラーメッセージが何を意味するのかわからない場合でも、心配しないでください — 一度にいくつかのエラーを修正してみることをお勧めします。 それから、どんなエラーが残っているかを示すためにあなたの HTML を再検証することを試みてください。以前のエラーを修正すると他のエラーメッセージも消えてしまうことがあります。つまりはドミノ効果で、単一の問題が原因でいくつかのエラーが発生することがあるということです。

出力に次のバナーが表示されたら、エラーがすべて解決したことがわかります。

まとめ

ここでは HTML のデバッグについて紹介しました。これは、後で CSS、JavaScript、およびその他の種類のコードのデバッグを始めるときに頼りになる便利なスキルです。
また HTMLモジュールの学習に関する記事の紹介の終わりにもなります。今、あなたは私たちの評価で自分自身をテストすることに進むことができます。最初のものは以下にリンクされています。

このモジュール

• Getting started with HTML
• What’s in the head? Metadata in HTML
• HTML text fundamentals
• Creating hyperlinks
• Advanced text formatting
• Document and website structure
• Debugging HTML
• Marking up a letter
• Structuring a page of content