MDN’s new design is in Beta! A sneak peek:

Debugging HTML


写HTML是容易的, 但如果某部分出了问题而你找不到错误代码在哪里的时候, 这篇文章会介绍一些工具来帮助您.

先决条件: 熟悉HTML , 例如已经阅读了 Getting started with HTML, HTML text fundamentals, 和 Creating hyperlinks.
目标: 学习基础使用调试工具查找HTML中的错误     .


在编写某种代码时, 通常一切都是正常的, 直到你犯了某个错误那可怕的时刻便发生了, 你的代码无效了 — 无论这是不是你想要的. 例如下面,当我们想用compileRust语言去写一个简单的程序的时候,错误报告便会出现。

A console window showing the result of trying to compile a rust program with a missing quote around a string in a print statement. The error message reported is error: unterminated double quote string.这里错误信息比较容易理解 — "双引号字符串未闭合". 如果你查看列表, 你大概会看到(Hello, world!"); 这里缺少了一个双引号 ,然而当程序变庞大的时候错误信息也会变得更复杂和更难解释, 甚至上面这样简单的例子对于不了解Rust语言的人来说就会有点吓人。

调试没有那么可怕 —  编写和调试任何编程语言的关键是熟悉这门语言和工具。

HTML and 调试

HTML并不像Rust语言那么难以理解 — 在浏览器解析和显示它之前HTML不会被编译成其他形式  (这是解析而不是编译) HTML的element 语法可以说比“像Rust的”JavaScriptPython这样“真正的编程语言”更容易理解. 然而浏览器运行HTML比编程语言的运行更宽松,这可以说是好事也是坏事。


宽容的意思是什么呢? 通常当你写错代码的时候,你会遇到以下两种主要类型的错误:

  • 语法错误: 由于拼写错误导致程序无法运行, 就像上面Rust的例子. 修正这些错误是没问题的,只要你熟悉正确的使用工具和知道错误信息的意思。
  • 逻辑错误: 实际上语法是正确的,但代码不是你想要的,这意味着程序运行不正确. 逻辑错误通常比语法错误更难修复,因为没有一个错误信息指示你到错误的来源。

HTML本身不容易因语法错误出错,因为浏览器是以宽松模式来运行, 这意味着即使出现语法错误浏览器依然会运行。Browsers have built-in rules to state how to interpret incorrectly written markup, so you'll get something running, even if it might not be quite what you expected. This of course can still be a problem!

Note: HTML is run 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 all 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.

Active learning: Studying permissive code

It's time to study the permissive nature of HTML code for yourselves.

  1. First, get hold of a copy of our debug-example demo and save it somewhere locally. This 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.)
  2. Next, try opening it in a browser — you will see something like this: A simple HTML document with a title of HTML debugging examples, and some information about common HTML errors, such as unclosed elements, badly nested elements, and unclosed attributes.
  3. 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?
      <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=">link to Mozilla
  4. Let's review the problems we can see here:
    • 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 looks to have 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.
    • The href attribute value has a missing closing double quote. This seems to have caused the biggest problem — the link has not rendered at all.
  5. 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 out to review Discover browser developer tools, then come back.
  6. In the DOM inspector, you can see what the rendered markup looks like: The HTML inspector in Firefox, with our example's paragraph highlighted, showing the text "What causes errors in HTML?" Here you can see that the paragraph element has been closed by the browser.
  7. 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:
        <em>strong emphasised?</em>
      <em> what is this?</em>
    • The link with the missing attribute double quote has been deleted altogether. The last list item just looks like this:
        <strong>Unclosed attributes: Another common source of HTML problems.
        Let's look at an example: </strong>

HTML validation

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 pretty 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.

The HTML validator homepage

To specify the HTML to validate, you can give it a web address to point to, upload an HTML file, or directly input some HTML code.

Active learning: Validating an HTML document

Let's give this a try, and have a go at validating our sample document.

  1. First, load up the Markup Validation Service in one of your browser tabs, if it isn't already.
  2. Click on/activate the Validate by Direct Input tab.
  3. Copy the whole of the sample document's code (not just the body) and paste it into the large text area shown in the Markup Validation Service.
  4. Press the Check button.

This should give you a list of errors and other information.

A list of of HTML validation results from the W3C markup validation service

Interpreting the error messages

The list of error messages you are presented with by the validator is usually helpful, sometimes 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 messages comes with a line and column number, to help you to locate the error more easily.

  • End tag 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 up.
  • 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 strong violates 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:
    example: <a href=">link to Mozilla homepage</a> ↩ </ul>↩ </body>↩</html>

    Note: An attribute missing a closing quote mark can result in an open element, as 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 multiple 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:

Banner that reads "The document validates according to the specified schema(s) and to additional constraints checked by the validator."


So there we have it, an introduction to debugging your 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.


 此页面的贡献者: huixiaomu
 最后编辑者: huixiaomu,