Writing HTML is fine, but what if something goes wrong, and you can't work out where the error in the code is? This article will introduce you to some tools that can help you find and fix errors in HTML.
| Prerequisites: | HTML familiarity, as covered in, for example, Getting started with HTML , HTML text fundamentals ，和 Creating hyperlinks . |
|---|---|
| Objective: | Learn the basics of using debugging tools to find problems in HTML. |
When writing code of some kind, everything is usually fine, until that dreaded moment when an error occurs — you've done something wrong, so your code doesn't work — either not at all, or not quite how you wanted it to. For example, the following shows an error reported when trying to compile a simple program written in the Rust 语言。
Here, the error message is relatively easy to understand — "unterminated double quote string". If you look at the listing, you can probably see how
println!(Hello, world!");
might logically be missing a double quote. However, error messages can quickly get more complicated and less easy to interpret as programs get bigger, and even simple cases can look a little intimidating to someone who doesn't know anything about Rust.
Debugging doesn't have to be scary though — the key to being comfortable with writing and debugging any programming language or code is familiarity with both the language and the tools.
HTML is not as complicated to understand as Rust. HTML is not compiled into a different form before the browser parses it and shows the result (it is interpreted , not compiled ). And HTML's element syntax is arguably a lot easier to understand than a "real programming language" like Rust, JavaScript ，或 Python . The way that browsers parse HTML is a lot more permissive than how programming languages are run, which is both a good and a bad thing.
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:
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!
注意： 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.
<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 emphasized?</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>
<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 emphasized.
<strong>strong <em>strong emphasized?</strong> what is this?</em>
. It is not easy to tell how this has been interpreted because of the previous problem.
href
attribute value is missing a closing double quote. This seems to have caused the biggest problem — the link has not rendered at all.
<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!
<strong>strong
<em>strong emphasized?</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>
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 provide a web address, upload an HTML file, or directly input some HTML code.
Let's try this with our sample document .
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 see what they mean. You'll see that each message comes with a line and column number to help you to locate the error easily.
lang
属性到
html
start tag to declare the language of this document.": This is not an error but a warning. The
recommendation
is to always define a language, and this warning explains how to do it.
li
implied, 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.
strong
": This is really easy to understand — a
<strong>
element is unclosed, and the line/column information points right to where it is.
strong
violates nesting rules": This points out the incorrectly nested elements, and the line/column information points out where they are.
example: <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.
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:
So there we have it, an introduction to debugging HTML, which should give you some useful skills to count on when you start to debug CSS, JavaScript, and other types of code later on in your career. This also marks the end of the Introduction to HTML module learning articles — now you can go on to testing yourself with our assessments: the first one is linked below.
最后修改： , 由 MDN 贡献者