この翻訳は不完全です。英語から この記事を翻訳 してください。
何かのコードを書いている時、まったく、いや少しもあなたがそれを望んでいないとしても、エラーが発生する（何かしらの間違いを犯したため、あなたのコードは動作しなくなる）その瞬間までは、全てが問正常です。例えば、 Rust 言語で書かれている簡単なプログラムを compile しようとしている時のエラーレポートを以下にお見せします。ここに、比較的理解しやすいエラーメッセージがあります。 — "終わりのない二重引用符文字列"。もしあなたがこのリストを見る時、 おそらく論理的に
println!(Hello, world!"); に二重引用符がない可能性があるとわかるでしょう。しかし、プログラムが大きくなるにつれ、エラーメッセージはすぐに複雑になり、解釈するのが難しくなります。そして簡単な場合でも、Rustについて何も知らない人には少し脅迫的に見えるかもしれません。
デバッグを怖がる必要はありません — プログラミング言語やコードの作成やデバッグに慣れ親しむための鍵は、言語とツールの両方に精通していることです。
So what do we mean by permissive? Well, generally when you do something wrong in code, there are two main types of error that you'll come across:
- Syntax errors: These are spelling errors in your code that actually cause the program not to run, like the Rust error shown above. These are usually easy to fix as long as you are familiar with the language's syntax and know what the error messages mean.
- Logic errors: These are errors where the syntax is actually correct, but the code is not what you intended it to be, meaning that program runs incorrectly. These are often harder to fix than syntax errors, as there isn't an error message to direct you to the source of the error.
HTML itself doesn't suffer from syntax errors because browsers parse it permissively, meaning that the page still displays even if there are syntax errors. Browsers have built-in rules to state how to interpret incorrectly written markup, so you'll get something running, even if it is not what you expected. This, of course, can still be a problem!
Note: HTML is parsed permissively because when the web was first created, it was decided that allowing people to get their content published was more important than making sure the syntax was absolutely correct. The web would probably not be as popular as it is today, if it had been more strict from the very beginning.
It's time to study the permissive nature of HTML code.
- First, download our debug-example demo and save it locally. This demo is deliberately written to have some errors in it for us to explore (the HTML markup is said to be badly-formed, as opposed to well-formed).
- Next, open it in a browser. You will see something like this:
- This immediately doesn't look great; let's look at the source code to see if we can work out why (only the body contents are shown):
<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>
- Let's review the problems:
- The paragraph and list item elements have no closing tags. Looking at the image above, this doesn't seem to have affected the markup rendering too badly, as it is easy to infer where one element should end and another should begin.
- The first
<strong>element has no closing tag. This is a bit more problematic, as it isn't easy to tell where the element is supposed to end. In fact, the whole of the rest of the text has been strongly emphasised.
- This section is badly nested:
<strong>strong <em>strong emphasised?</strong> what is this?</em>. It is not easy to tell how this has been interpreted because of the previous problem.
hrefattribute value has a missing closing double quote. This seems to have caused the biggest problem — the link has not rendered at all.
- Now let's look at the markup the browser has rendered, as opposed to the markup in the source code. To do this, we can use the browser developer tools. If you are not familiar with how to use your browser's developer tools, take a few minutes to review Discover browser developer tools.
- In the DOM inspector, you can see what the rendered markup looks like:
- Using the DOM inspector, let's explore our code in detail to see how the browser has tried to fix our HTML errors (we did the review in Firefox; other modern browsers should give the same result):
- The paragraphs and list items have been given closing tags.
- It isn't clear where the first
<strong>element should be closed, so the browser has wrapped each separate block of text with its own strong tag, right down to the bottom of the document!
- The incorrect nesting has been fixed by the browser like this:
<strong>strong <em>strong emphasised?</em> </strong> <em> what is this?</em>
- The link with the missing double quote has been deleted altogether. The last list item looks like this:
<li> <strong>Unclosed attributes: Another common source of HTML problems. Let's look at an example: </strong> </li>
So you can see from the above example that you really want to make sure your HTML is well-formed! But how? In a small example like the one seen above, it is easy to search through the lines and find the errors, but what about a huge, complex HTML document?
The best strategy is to start by running your HTML page through the Markup Validation Service — created and maintained by the W3C, the organization that looks after the specifications that define HTML, CSS, and other web technologies. This webpage takes an HTML document as an input, goes through it, and gives you a report to tell you what is wrong with your HTML.
To specify the HTML to validate, you can give it a web address, upload an HTML file, or directly input some HTML code.
Let's try this with our sample document.
- First, load up the Markup Validation Service in one browser tab, if it isn't already.
- Switch to the Validate by Direct Input tab.
- Copy all the sample document's code (not just the body) and paste it into the large text area shown in the Markup Validation Service.
- Press the Check button.
This should give you a list of errors and other information.
The error messages are usually helpful, but sometimes they are not so helpful; with a bit of practice you can work out how to interpret these to fix your code. Let's go through the error messages and what they mean. You'll see that each message comes with a line and column number to help you to locate the error easily.
- "End tag
liimplied, but there were open elements" (2 instances): These messages indicate that an element is open that should be closed. The ending tag is implied, but not actually there. The line/column information points to the first line after the line where the closing tag should really be, but this is a good enough clue to see what is wrong.
- "Unclosed element
strong": This is really easy to understand — a
<strong>element is unclosed, and the line/column information points right to where it is.
- "End tag
strongviolates nesting rules": This points out the incorrectly nested elements, and the line/column information points out where it is.
- "End of file reached when inside an attribute value. Ignoring tag": This one is rather cryptic; it refers to the fact that there is an attribute value not properly formed somewhere, possibly near the end of the file because the end of the file appears inside the attribute value. The fact that the browser doesn't render the link should give us a good clue as to what element is at fault.
- "End of file seen and there were open elements": This is a bit ambiguous, but basically refers to the fact there are open elements that need to be properly closed. The lines numbers point to the last few lines of the file, and this error message comes with a line of code that points out an example of an open element:
例: <a href="https://www.mozilla.org/>link to Mozilla homepage</a> ↩ </ul>↩ </body>↩</html>
メモ: An attribute missing a closing quote can result in an open element because the rest of the document is interpreted as the attribute's content.
- "Unclosed element
ul": This is not very helpful, as the
<ul>element is closed correctly. This error comes up because the
<a>element is not closed, due to the missing closing quote mark.
If you can't work out what every error message means, don't worry about it — a good idea is to try fixing a few errors at a time. Then try revalidating your HTML to show what errors are left. Sometimes fixing an earlier error will also get rid of other error messages — several errors can often be caused by a single problem, in a domino effect.
You will know when all your errors are fixed when you see the following banner in your output:
- 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