We're looking for a user researcher to understand the needs of developers and designers. Is this you or someone you know? Check out the post: https://mzl.la/2IGzdXS

Перевод не завершен. Пожалуйста, помогите перевести эту статью с английского.

Написание HTML-это хорошо, но что делать если что-то пойдет не так, и ты не сможешь понять, где ошибка в коде? Эта статья познакомит тебя с некоторыми инструментами, которые могут помочь Вам найти и исправить ошибки в HTML.

Prerequisites: HTML familiarity, as covered in for example Getting started with HTML, HTML text fundamentals, and Creating hyperlinks.
Objective: Learn the basics of using debugging tools to find problems in HTML.

Отладка — это не страшно

Во время написания какого-нибудь кода, обычно все идет хорошо, пока не появляется тот момент, когда вы совершаете ошибку. Итак, ваш код не работает совсем, или работает не так, как вы задумывали. К примеру, нижеследующее покажет ошибку, когда вы попытаетесь скомпилировать простую программу на языке Rust.

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.В данном случае, сообщение об ошибке понять относительно просто — "unterminated double quote string". Если вы внимательно посмотрите на println!(Hello, world!"); , то заметите, что здесь отсутсвует двойная кавычка. Разумеется, сообщения об ошибках могут становиться куда более сложными для понимания по мере роста вашего кода, и даже самые простые случаи могут показаться пугающими для тех, кто ничего не знает о Rust'е.

Отладка не должна быть чем-то устрашающим —  ключ к комфортному написанию и отладке любого кода лежит в понимании языка и некоторых инструментов.

HTML и Отладка

HTML не так сложен к пониманию, как Rust. HTML не компилируется в какую-либо другую форму перед тем, как браузер проанализирует это и покажет результат (Он является интерпретируемым, а не компилируемым). Синтаксис HTML элементов  намного понятнее, чем "у настоящих языков программирования", таких как Rust, JavaScript, или Python. Способ, которым брузеры читают HTML более толерантен, чем у языков программирования, интерпретирующих свой код строже. Это можно рассматривать как нечто плохое и хорошее одновременно.

Толерантный код

Так что же означает толерантный? В общих чертах, когда вы напортачили в коде, есть два типа ошибок, с которыми вы столкнетесь:

  • Синтаксические ошибки (Syntax errors): Это ошибки в правильности написания, как это было выше, в примере с Rust. Такие обычно легко исправлять, в той мере, в какой вы знакомы с синтаксисом языка и знаете, что означают сообщения об ошибках.
  • Логические ошибки (Logic errors): Это ошибки, появляющиеся в том случае, если синтаксис корректен, но код не выполняет своего предназначения, то есть программа выполняется неверно. Такие исправлять сложнее, чем синтаксические, поскольку не выводится сообщений, указывающих место, где вы ошиблись.

HTML не страдает от синтаксических ошибок, потому что браузер читает код толерантно, в том смысле, что страницы могут отображаться даже если синтаксические ошибки присутсвуют. Браузеры имеют встроенные правила по интерпретации неверно написанной разметки, и вы можете запустить что-либо, даже если вы имели в виду другое. Это может стать настоящей проблемой!

На заметку: HTML читается толерантно, потому что когда веб только появился, было решено позволить людям публиковать контент даже при условии некорректностей в коде, так как это куда более важно, чем уверенность в абсолютно верном синтаксисе. Веб не был бы сейчас так популярен, если бы относился к новичкам строго.

Активное обучение: Знакомство с толерантным кодом

Время изучить природу толерантного кода в HTML.

  1. Для начала, скачайте наш пример отладки и сохраните локально. Эта демонстрация намеренно написана с ошибками, которые нам предстоит обнаружить.
  2. Далее, откройте её в браузере. Вы увидете нечто вроде этого :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. Сейчас документ выглядит не особо хорошо; Давайте посмотрим в код и выясним почему (Показано только тело документа):
    <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. Рассмотрим проблемы:
    • У параграфа и элемента списка не закрыты теги. На изображении выше видно, что разметка не пострадала, так как браузеру легко сделать вывод о том, где заканчивается один элемент и начинается другой.
    • Первый <strong> элемент также не имеет закрывающего тега. Это уже более проблематично, так как сложно сказать, где элемент должен заканчиваться. На деле, весь оставшийся текст был выделен жирным.
    • Следующая часть нарушает правила вложенности: <strong>strong <em>strong emphasised?</strong> what is this?</em>. В этом случае код тоже сложно проинтерпретировать по причине, описанной выше.
    • В атрибуте href отсутсвует закрывающая двойная кавычка. Это послужило причиной крупной проблемы — ссылка не воспроизвелась вовсе.
  5. Сейчас же посмотрим, как браузер сгенерировал собственную разметку, в противовес исходной разметке документа. Чтобы сделать это, воспользуемся инструментами разработчика. Если вы не знакомы с инструментами разработчика, потратьте несколько минут на Обзор инструментов разработки в браузерах.
  6. В DOM инспекторе вы можете увидеть как сгенерировалась новая разметка: 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. Используя DOM инспектор, давайте рассмотрим детали нашего кода, чтобы увидеть, как браузер пытается исправить наши ошибки в HTML (мы обозреваем в Firefox; другой современный браузер должен выдать те же результаты):
    • Параграфы и элементы списка получены с закрывающими тегами.
    • Было неочевидно, где элемент <strong> должен был закрыться, так что браузер обернул каждый отдельный блок текста своими собственными тегами 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 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 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, upload an HTML file, or directly input some HTML code.

Active learning: Validating an HTML document

Let's try this with our sample document.

  1. First, load up the Markup Validation Service in one browser tab, if it isn't already.
  2. Switch to the Validate by Direct Input tab.
  3. 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.
  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 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 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.
  • "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="https://www.mozilla.org/>link to Mozilla homepage</a> ↩ </ul>↩ </body>↩</html>

    Note: 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:

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

Summary

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.

 

In this module

 

Метки документа и участники

Внесли вклад в эту страницу: CruOne, MariyaSka
Обновлялась последний раз: CruOne,