Переклад не закінчено. Будь ласка, допоможіть перекласти цю статтю з англійської.

Написати HTML добре, але що, якщо щось піде не так, і ви не можете з'ясувати, де помилка в коді? Ця стаття представить вам деякі інструменти, які допоможуть вам знайти та виправити помилки в HTML.

Передумови: Знайомство з HTML, як наведено в прикладі Початок роботи з HTML, Основи HTML та Створення гіперпосилань.
Мета: Дізнатись основи використання інструментів налагодження (дебаґінга), щоб знайти проблеми в HTML.

Дебаґінг не страшний

Коли ви пишете код певного виду, все, як правило, добре, доки не настає страшний момент, коли виникла помилка - ви зробили щось не так, тому ваш код не працює - або взагалі, або не зовсім так, як ви хотіли. Наприклад, наведене нижче показує помилку при спробі compile просту програму, написану на мові "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. Тут повідомлення про помилку досить легко зрозуміти — "неузгоджений подвійний ланцюг кодування". Якщо ви подивитеся на цей список, можливо, ви побачите, як це зробити println!(Hello, world!"); може логічно не вистачати подвійної цитати. Проте повідомлення про помилку можуть швидко ускладнюватися і менш легко інтерпретуватися, коли програми стають більшими, і навіть прості випадки можуть трохи налякати того, хто не знає про Руст.

Дебаґінг не повинен бути страшним - це ключ до комфортного написання і налагоджування будь-якої мови програмування або коду, знайомство як з мовою так і з інструментами.

HTML та дебаґінг

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

Дозвільний код

Отже, що ми маємо на увазі під дозвільним? Ну, звичайно, коли ви робите щось неправильне в коді, є два основних типи помилок, які ви зустрінете:

  • Синтаксичні помилки: Це орфографічні помилки у вашому коді, які фактично спричиняють непрацездатність програми, як-от помилка Rust, показана вище. Зазвичай їх можна легко виправити, якщо ви знайомі з синтаксисом мови та знаєте, що означає повідомлення про помилку.
  • Логічні помилки: Це помилки, коли синтаксис дійсно правильний, але код не є тим, що ви його намірили, а це означає, що програма працює неправильно. Ці помилки важче фіксувати, ніж синтаксичні помилки, тому що немає повідомлення про помилку, яка спрямовує вас до джерела помилки.

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

Примітка: Розібратись в HTML легко, тому що коли веб-мережа була тільки створена, було вирішено, що надання користувачам можливостей публікувати свій вміст було важливішим, ніж переконатися, що синтаксис абсолютно правильний. Веб-мережа, ймовірно, не була б настільки популярною, як є сьогодні, якщо б вона була більш складною від самого початку.

Активне навчання: вивчення допустимого коду

Настав час вивчити дозвільний характер HTML-коду.

  1. По-перше, завантажте наш debug-example demo і збережіть його локально. Ця демоверсія спеціально написана, щоб мати деякі помилки в ньому, щоб ми могли їх досліджувати (розмітка HTML, як наголошується, погано сформована, на відміну від добре сформованої).
  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. Це відразу не виглядає чудово; давайте подивимося на вихідний код, щоб побачити, чи зможемо ми зрозуміти, чому (показано лише вміст body);
    <h1>Приклади HTML дебаґінга</h1>
    
    <p>Що викликає помилки в HTML?
    
    <ul>
      <li>Незамкнені елементи: Якщо елемент <strong> не закрито належним чином, 
          його ефект може поширюватися на ті області, які ви не мали наміру ним огортати.
    
      <li>Погано вкладені елементи:  правильне вставлення елементів також дуже важливо 
          для правильного кодування. <strong>strong <em>виділено strong?</strong>
          що це таке?</em>
    
      <li>Незакриті атрибути: Інше поширене джерело HTML-проблем.
          Давайте розглянемо приклад: <a href="https://www.mozilla.org/>Посилання 
          на домашню сторінку Mozilla</a>
    </ul>
  4. Давайте розглянемо проблеми:
    • paragraph та list item елементи не мають закриваючих тегів. Дивлячись на зображення вище, це, здається, не вплинуло на рендеринг розмітки надто погано, оскільки легко визначити, де повинен закінчуватися один елемент, а інший повинен починатися.
    • Перший <strong> елемент не має закриваючого тега. Це дещо ускладнює, оскільки важко сказати, де елемент повинен закінчуватися. Фактично, всю решту тексту було виділено.
    • Цей розділ погано вкладено: <strong>strong <em>виділено strong?</strong> що це таке?</em>. Складно сказати, як це було інтерпретовано із-за попередньої проблеми.
    • href Значення атрибута має відсутні подвійні лапки закриття. Це, здається, викликало найбільшу проблему - посилання взагалі не відображається.
  5. Тепер давайте подивимось на розмітку браузера, на відміну від розмітки в вихідному коді. Для цього ми можемо використовувати інструменти розробника веб-браузера. Якщо ви не знайомі з використанням інструментів розробника веб-браузера, перегляньте кілька хвилин Discover browser developer tools.
  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?</em>
      </strong>
      <em> що це таке?</em>
    • Посилання з відсутніми подвійними лапками повністю вилучено. Останній елемент списку виглядає так :
      <li>
        <strong>Незакриті атрибути: Інше поширене джерело проблем з HTML.
        Давайте подивимось на приклад: </strong>
      </li>

Валідація HTML

Таким чином, ви можете побачити з наведеного вище прикладу, що ви дійсно хочете, щоб ваш HTML був добре сформований! Але як? У невеликому прикладі, подібному до вищенаведенного, легко пройти по строках та знайти помилки, а як при величезному, складному HTML-документі?

Найкраща стратегія полягає в тому, щоб запустити HTML-сторінку за допомогою Markup Validation Service — сервісу, що створений та підтримується W3C, організацією, яка стежить за специфікаціями, що визначають HTML, CSS та інші веб-технології. Ця веб-сторінка приймає HTML-документ у вигляді входу, проходить через нього і дає вам звіт, в якому показує, що неправильно з вашим HTML.

The HTML validator homepage

Щоб вказати HTML для перевірки, ви можете надати цьому сервісу адресу свого сайту, завантажити файл HTML або безпосередньо ввести якийсь HTML-код.

Активне навчання: перевірка документа HTML

Давайте спробуємо це з нашим sample document.

  1. По-перше, завантажте Markup Validation Service в одній із вкладок браузера, якщо вона ще не відкрита.
  2. Перейдіть на вкладку Validate by Direct Input (Перевірити за прямим введенням).
  3. Скопіюйте весь приклад коду документу (а не тільки body) і вставте його у велику область тексту, показану в Markup Validation Service.
  4. Натисніть кнопку Check (Перевірити).

В результаті з'явиться список помилок та інша інформація.

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

Інтерпретація повідомлень про помилки

Повідомлення про помилки зазвичай корисні, але іноді вони не настільки корисні; трохи попрактикувавшись, ви зможете розібратися, як інтерпретувати їх, щоб виправити ваш код. Давайте пройдемось по повідомленням про помилку і що вони означають. Ви побачите, що кожне повідомлення містить номер рядка та стовпчика, які допоможуть легко знайти помилку.

  • "Кінцевий тег li мається на увазі, але були відкриті елементи" (2 випадки): Ці повідомлення вказують на те, що відкритий елемент, який має бути закритим. Кінцевий тег мається на увазі, але насправді не існує. Інформація про строку/стовпчик вказує на перший рядок після рядка, де дійсно повинен бути тег закриття, але це досить хороша підказка, щоб побачити, що не так.
  • "Не закритий елемент strong": Це досить просто зрозуміти — <strong> елемент не є закритим, та інформація про строку/стовпчик вказує на те, де він знаходиться.
  • "Кінцевий тег strong порушує правила вкладенності": Це вказує на неправильно вкладені елементи, а інформація про строку/стовпець вказує, де вона знаходиться.
  • "Кінець файлу досягнуто, коли знаходиться значення атрибута. Ігнорування тегу": Це досить загадково; це стосується того, що значення атрибута десь неправильно сформовано, можливо, поблизу кінця файлу, тому що кінець файлу з'являється всередині значення атрибута. Той факт, що браузер не відображає посилання, має дати нам хорошу підказку щодо того, який елемент винен.
  • "Файл переглянуто до кінця і з'явились відкриті елементи": Це трохи неоднозначно, але в основному стосується того, що є відкриті елементи, які повинні бути належним чином закриті. Номери рядків вказують на останні кілька рядків файлу, і це повідомлення про помилку поставляється з рядком коду, який вказує на приклад відкритого елемента:
    приклад: <a href="https://www.mozilla.org/>Посилання на домашню сторінку Mozilla</a> ↩ </ul>↩ </body>↩</html>

    Повідомлення про помилки зазвичай корисні, але іноді вони не настільки корисні; трохи попрактикувавшись, ви зможете розібратися, як інтерпретувати їх, щоб виправити ваш код. Давайте пройдемось по повідомленням про помилку і що вони означають. Ви побачите, що кожне повідомлення містить номер рядка та стовпчика, які допоможуть легко знайти помилку.

  • "Кінцевий тег li мається на увазі, але були відкриті елементи" (2 випадки): Ці повідомлення вказують на те, що відкритий елемент, який має бути закритим. Кінцевий тег мається на увазі, але насправді не існує. Інформація про строку/стовпчик вказує на перший рядок після рядка, де дійсно повинен бути тег закриття, але це досить хороша підказка, щоб побачити, що не так.
  • "Не закритий елемент strong": Це досить просто зрозуміти — <strong> елемент не є закритим, та інформація про строку/стовпчик вказує на те, де він знаходиться.
  • "Кінцевий тег strong порушує правила вкладенності": Це вказує на неправильно вкладені елементи, а інформація про строку/стовпець вказує, де вона знаходиться.
  • "Кінець файлу досягнуто, коли знаходиться значення атрибута. Ігнорування тегу": Це досить загадково; це стосується того, що значення атрибута десь неправильно сформовано, можливо, поблизу кінця файлу, тому що кінець файлу з'являється всередині значення атрибута. Той факт, що браузер не відображає посилання, має дати нам хорошу підказку щодо того, який елемент винен.
  • "Файл переглянуто до кінця і з'явились відкриті елементи": Це трохи неоднозначно, але в основному стосується того, що є відкриті елементи, які повинні бути належним чином закриті. Номери рядків вказують на останні кілька рядків файлу, і це повідомлення про помилку поставляється з рядком коду, який вказує на приклад відкритого елемента:
    приклад: <a href="https://www.mozilla.org/>Посилання на домашню сторінк
  • Примітка: Атрибут, який не містить замикаючих лапо́к, може призвести до відкритого елемента, оскільки решту документа інтерпретують як вміст атрибута.

  • "Незакритий елемент ul": Це не дуже корисно, як <ul> елемент є закритим правильно. Ця помилка виникає через те, що <a> елемент є незакритим, через відсутність кінцевих лапо́к.

Якщо ви не можете з'ясувати, що означає кожне повідомлення про помилку, не хвилюйтеся - хороша ідея - спробувати одночасно виправити кілька помилок. Потім спробуйте повторно підтвердити свій HTML, щоб показати, які помилки залишаються. Іноді виправлення попередньої помилки також позбуває інших повідомлень про помилку - деякі помилки часто можуть бути викликані однією проблемою, що тягне інші, як ефект доміно.

Ви будете знати, коли всі ваші помилки виправлені, коли ви побачите наступний банер у вашому виводі:

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

Тобто, "Документ перевірений відповідно до зазначених схем та додаткових обмежень, перевірених валідатором".

Резюме

Отже, у нас є вступ до дебаґінга в HTML, який повинен надати вам деякі корисні навички, щоб розраховувати, коли ви почнете налагоджувати CSS, JavaScript та інші типи коду пізніше в своїй кар'єрі. Це також означає завершення вивчення статей "Введення в модулі HTML" - тепер ви можете продовжувати тестування самостійно з нашими оцінками: перший з них за посиланням нижче.

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

 Зробили внесок у цю сторінку: websunsey
 Востаннє оновлена: websunsey,