Курс верстки – валідація сторінки. Навіщо потрібен валідний код та як усунути помилки валідації Що таке перевірка на валідність

Головна / Google Play

Вітаю, дорогі друзі! Радий бачити вас на моєму блозі! Сьогодні мова піде про валідність HTML на сайті загалом та його окремі сторінки. Валідність – це відповідність коду певним стандартам. Над розробкою веб-стандартів працює Консорціум World Wide Web (W3C) – це міжнародне співтовариство, в якому перебувають організації, штатні співробітники та громадськість.

Місія консорціуму полягає в тому, щоб розкрити весь потенціал всесвітньої павутини, розробляючи та впроваджуючи протоколи та керівні принципи, що забезпечують довгострокове зростання мережі Інтернет.

На офіційному сайті W3C надані дуже корисні онлайн-інструменти для вебмайстрів, одним із них є валідатор - це безкоштовний сервіс, що дозволяє перевірити відданість сайту сучасним веб-стандартам.

На жаль, сервіс повністю англійською мовою, але якщо ви трішки знаєтеся на розробці та верстці, то неодмінно зрозумієте його суть і посил 😉

Отже, на головній сторінці розташовані три вкладки:

Validate by URI — перевірка вказаної URL-адреси;

Validate by File Upload - перевірка завантаженого файлу;

Validate by Direct Input – перевірка шляхом прямого введення вихідного коду.

Для запуску аналізатора потрібно перейти на необхідну вкладку, як приклад я розглядатиму перевірку за URL-адресою. Під посиланням More Options ховаються додаткові опції, натисніть на неї, щоб отримати доступ до налаштувань:

Character Encoding – кодування символів. WordPress використовує UTF-8, але можна залишити стандартне значення "Detect automatically" для автоматичного визначення кодування.
Document Type – тип документа (HTML, XHTML, SVG та ін.). Поставте прапорець Only if missing, якщо тип документа не заданий на сторінці і його потрібно вручну перевірити.
List Messages Sequentially - виводити помилки та попередження послідовним списком;
Group Error Messages by Type - групувати помилки та попередження за типом;
Show Source – показати вихідний код;
Show Outline – показати структуру документа;
Clean up Markup with HTML Tidy – очищення розмітки за допомогою HTML-Tidy;
Validate error pages — перевіряти сторінки з помилками, наприклад, із 404 помилкою;
Verbose Output – докладний висновок. Якщо чесно, я не помітив різниці при включенні цієї опції, якщо знаєте, за що вона відповідає — поділіться в коментарях, буду дуже вдячний.

Коли всі налаштування виставлені, натисніть кнопку Check для старту валідатора HTML. Якщо документ не має помилок, з'явиться напис:

Document checking сформульований. No errors or warnings to show.

У перекладі російською мовою це означає: «Перевірка документа завершена. Помилки чи попередження не знайдено». Чудово!

Якщо документ не пройде перевірку, побачимо простий напис про її завершення:

І звичайно ж, список повідомлень, які містять відомості про помилки та попередження з поясненнями, а також посилання на конкретні рядки документів, але тільки в тому випадку, якщо була включена опція Show Source.

На скріншоті нижче наведено фрагмент перевірки головної сторінки Яндекса. Дивно це бачити, навіть не очікував, адже Яндекс сам бере участь у розробці стандартів W3C… Ну гаразд, дотримуватися абсолютно всіх стандартів справді складно, тим більше для такого великого порталу.

На початку свого шляху Блог Вільного Вебмайстра містив дуже багато помилок та попереджень. У міру вивчення мені вдалося знизити їх кількість, а згодом і зовсім позбутися. Надалі дотримуватимуся стандартів W3C, хоча деякі плагіни додають ложку дьогтю в бочку меду… Час покаже!

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

Здійснює кілька перевірок Вашого коду. Основні з них:

Валідація синтаксису – перевірка на наявність синтаксичних помилок. є коректним синтаксисом, незважаючи на те, що не є допустимим HTML-тегом, тому перевірка синтаксису є мінімально корисною для написання хорошого HTML.

Перевірка вкладеності тегів - теги повинні бути закриті у зворотному порядку щодо їх відкриття. Наприклад, ця перевірка відловлює помилки з неправильно закритими .

Валідація DTD – перевірка відповідності Вашого коду вказаному Document Type Definition. Вона включає перевірку назв тегів, атрибутів та «вбудовування» тегів (теги одного типу всередині тегів іншого типу)

Перевірка на сторонні елементи – перевірка виявляє все, що є у коді, але відсутня у DTD. Наприклад, користувацькі теги та атрибути.

Майте на увазі, що це логічні перевірки, і не важливо, як реалізований валідатор. Якщо хоча б одна з перевірок не проходить успішно, HTML вважається невалідним. І в цьому полягає проблема. Аргументи Основним аргументом за валідацію HTML є забезпечення кросбраузерності. Кожен браузер має свій парсер і «годувати» йому те, що розуміють усі браузери – це єдиний шлях бути впевненим, що Ваш код працюватиме правильно у всіх браузерах. Оскільки кожен браузер має свій механізм корекції помилок HTML, Ви не можете покладатися на невалідний код.

Основним аргументом проти валідації є те, що вона надто строга і не відповідає тому, як насправді працюють браузери. Так, HTML може бути невалідним, але всі браузери можуть обробляти певний невалідний код однаково. Якщо я готовий взяти на себе відповідальність за неправильний код, який я пишу, я не повинен турбуватися про перевірку. Єдине, про що я мушу дбати - це щоб воно працювало.

Моя позиція Це один з небагатьох випадків, коли я публічно говорю про свою позицію щодо чогось. Я завжди був серед противників валідації, ґрунтуючись на тому, що валідатор надто суворий, щоб бути практичним у реальних додатках. Є речі, які підтримуються більшістю браузерів ( в , після ), які є невалідними, але іноді дуже потрібні для правильної роботи.

Взагалі моєю найбільшою проблемою валідації є перевірка #4 (на сторонні елементи). Я прихильник використання атрибутів користувача в HTML тегах для зберігання додаткових мета-даних, що відносяться до певного елементу. У моєму розумінні, це, наприклад, додати атрибут foo, коли я маю дані (bar), які мені треба асоціювати з певним елементом. Іноді люди перевантажують існуючі атрибути для цього лише для того, щоб пройти валідацію, незважаючи на те, що атрибут буде використовувати не за призначенням. Для мене це безглуздо.

Секрет браузерів полягає в тому, що вони ніколи не перевіряють відповідність HTML коду зазначеному DTD. Doctype, який Ви вказали в документі, перемикає парсер браузера у певний режим, але це не призводить до завантаження doctype та перевірки коду на відповідність йому. Тобто парсер браузерів обробляє HTML з деякими припущеннями невалідності, на кшталт самозакриваються тегів і блокових елементів усередині рядкових (я впевнений, що є й інші).

У випадку атрибутів користувача, всі браузери парсят і розпізнають синтаксично коректні атрибути як допустимі. Це дозволяє отримати доступ до таких атрибутів через DOM за допомогою Javascript. То чому я мушу турбуватися про валідність? Я продовжуватиму використовувати свої атрибути і я дуже радий, що HTML5 формалізує їх.

Найкращий приклад технології, яка призводить до невалідного HTML, але має величезне значення - це ARIA. ARIA працює за допомогою додавання нових атрибутів у HTML 4. Ці атрибути надають додаткове семантичне значення HTML-елементам і браузер здатний передати цю семантику допоміжним пристроям для допомоги людям з обмеженими фізичними можливостями. Усі основні браузери зараз підтримують розмітку ARIA. Однак, якщо ви будете використовувати ці атрибути, у вас буде невалідний HTML.

Щодо користувацьких тегів - я думаю, що в додаванні на сторінку синтаксично коректних нових тегів немає нічого поганого, але я не бачу особливого практичного сенсу в цьому.

Щоб прояснити мою позицію: я вважаю, що перевірки #1 і #2 є дуже важливими і мають проводитися завжди. Перевірку #3 я теж вважаю важливою, але не такою, як перші дві. Перевірка #4 дуже сумнівна для мене, так як вона зачіпає атрибути користувача. Я вважаю, що, як максимум, атрибути користувача повинні бути позначені як попередження (а не помилки) в результатах перевірки, щоб була можливість перевірити, чи не помилився я при введенні назви атрибута. Позначка користувацьких тегів як помилок, можливо, хороша ідея, але також має деякі проблеми, наприклад, при вбудовуванні вмісту в іншій розмітці - SVG або MathML.

Валідація заради валідації? Я вважаю, що валідація заради валідації – це дуже безглуздо. Валідний HTML означає тільки те, що всі чотири перевірки пройшли без помилок. Є кілька важливих речей, яких не гарантує валідний HTML:

валідний HTML не гарантує accessibility;
валідний HTML не гарантує добрий UX (user experience);
валідний HTML не гарантує сайт, що функціонує;
валідний HTML не гарантує коректне відображення сайту.

Валідний HTML може бути приводом пишатися самим собою, але саме по собі це не є показником майстерності. Ваш валідний код не завжди краще виконує свої функції ніж мій невалідний.Валідація HTML5 Валідація HTML5 виправить деякі проблеми, які були з валідацією HTML 4. Вона явно дозволяє вживання атрибутів користувача (вони повинні починатися з data-). Це дозволить моєму коду пройти перевірку на валідність для HTML5. Звичайно, є деякі моменти у валідаторе HTML5, з якими я не згоден, але я вважаю, що він набагато більше відповідає практичним потребам, ніж валідатор HTML 4. Висновок Я вважаю, що деякі складові HTML-валідації вкрай важливі та корисні, але я не хочу бути її заручником, тому що я використовую свої атрибути. Я пишаюся тим, що я використовую ARIA в моїй роботі і мені байдуже, що це вважається невалідним кодом. Знову ж таки, з чотирьох перевірок валідатора у мене є проблеми тільки з однієї. І HTML5 валідатор позбавить мене більшості цих проблем.

Я знаю, що для багатьох це спірна тема, тож, будь ласка, утримайтеся від суто емоційних висловлювань у коментарях.

UPD: дякую за карму, переніс у тематичний. Повторю слова автора: я розумію, це спірна тема, але будь ласка, утримайтеся від суто емоційних коментарів, наводьте аргументи.

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

На моєму ж блозі зараз немає подібних помилок, я їх позбувся (всього було більше 70 помилок і більше 80 попереджень). Щоб внести ясність, розповім, що таке валідний код, і навіщо він нам необхідний.

Валідний код – це код, який відповідає стандартам.

На валідність можна перевірити HTML, CSS, всілякі мікророзмітки та інше. Сьогодні я розповім про валідність у HTML.

Валідний код необов'язковий, але кількість помилок має бути мінімальною, інакше ваш сайт не буде кросбраузерним. Валідність коду потрібна насамперед для того, щоб ваш сайт відображався правильно у всіх браузерах.
Пошукові роботи "розмовляють" з вашим сайтом на мові HTML, тому важливо віддавати чітко та ясно контент на сайті з усіма "закритими тегами" та інше.
Валідність HTML впливає на SEO, але досить незначно (якщо, звичайно, у вас не сотні, а то й тисячі помилок). Рекомендую почитати цікаві спостереження Девакі "Вплив якості HTML на їх ранжування".
Коли я робив на своєму сайті код валідним, знайшов і виправив свої дурні помилки (повторення тегів, пропущена літера і т.п.).
Не варто "рвати собі опу", якщо якусь помилку складно виправити, або її виправлення завдасть шкоди функціональності сайту. Головне, щоб було зручно користувачеві.

Нижче я розберу основні помилки, які вказував валідатор. Якщо раптом у списку нижче не виявиться вашої помилки, впишіть її в коментарях, спробуємо разом розібратися і я додам вирішення цієї проблеми на цей урок. До речі, так, помилки, на які вказує валідатор w3c дивимося тут:

У кожній помилці є підказка - це номер рядка у вихідному коді сторінці, а з неї вже можна визначити приблизно в якому файлі теми розташований цей рядок. Вихідний код сторінки дивимось за допомогою CTRL+U (в основних браузерах).

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

Також для спрощення знаходження помилок у вихідному коді можете використовувати HTML валідатор для Mozilla Firefox. Встановивши його, перейшовши у вихідний код сторінки, ви побачите ті самі помилки, що вказує сервіс validator.w3.org. Клікнувши за назвою помилки (у лівому нижньому кутку), вас автоматично перекине на той рядок, де знаходиться цей невалідний код.

Знаходження помилок у HTML за допомогою валідатора w3c та їх виправлення

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

1. No space between attributes.

…rel="shortcut icon" href="http://arbero.ru/favicon.ico" ; type="image/x-icon" Просто прибираємо "точку з комою".

2. The width attribute on the td element is obsolete. Use CSS instead.

td valign="center" width="80" height="80" >

Подібне перетворюємо на вигляд

td style="align:center; width:80; height: 80;">

3. Натисніть, щоб задовольнити параметри, except un certain conditions. Для details, consult guidance on providing text alternatives for images.

Одна з найчастіших помилок. Просто не вистачає альтернативного тексту для картинки. Прописуємо тег alt.

4. Section lacks heading. Посібник з використанням h2-h6 елементів до іншого identifying headings до всіх розділів.

section id="comments" >

Всередині блоку section повинні утримуватися щось із тегів h2-h6, якщо їх немає, просто перейменовуємо слово section на div

5. The hgroup element is obsolete. Натисніть на підзаголовки, вивчайте їх тільки натиснувши на підзаголовок до пункту p після h1-h6 пункту, натиснувши на головний heading,

або власне керування subheading directly within the h1-h6 element containing the main heading, але separated from the main heading punctuation and/or within, for example, a span class="subheading" element with differentiated styling. До групи headings і subheadings, alternative titles, або taglines, consider using the header or div elements.

Аналогічно до попереднього пункту. Просто змінюємо фразу hgroup на div. Ви можете використовувати інструмент "Знайти/замінити все" у текстовому редакторі, щоб прискорити подібні процеси.

6. Element "noindex" undefined

Щоб тег noindex став валідним, пишемо його у вигляді коментування, тобто так:

Неіндексуємо

7. End tag for element "div" which is not open

Закриваючий тег div зайвий. Забираємо його.

8. Document type does не дозволяє елемент "li" here; missing one of "ul", "ol", "menu", "dir" start-tag

Неправильне використання тега "li": відсутній тег "ul", "ol" та ін. Перевірте.

9. Затверджений tag для "div", заміщений, але OMITTAG NO був specified

Не вистачає тег div.

10. There is no attribute "border"

alt="" width="1" height="1" border="0"/>

Просто вилучаємо фразу border="0".

11. Character "

Вибір редакції