Перевірка HTML: чи варто цього?

Які переваги та недоліки (якщо такі є) в тому, щоб переконатися, що всі сторінки перевірені, порівняно з недійсним HTML, який працює у всіх основних браузерах?

Крім того, чи є дійсний HTML після виконання Javascript так само важливим?

Я думаю, що це, безумовно, варто зробити , але ти ніколи не повинен бути рабом валідації - це гра дурня.

http://www.codinghorror.com/blog/2009/03/html-validation-does-it-matter.html

1. Підтвердьте свій HTML-код. Знайте, що означає мати дійсну розмітку HTML. Розуміти інструментарій. Більше інформації завжди краще, ніж менше інформації. Чому літати сліпо?

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

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

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

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

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

Великим плюсом дійсного HTML є те, що Ваша сторінка стає доступнішою для речей, окрім "основних браузерів". Усі "основні браузери" мають нескінченні способи вирішення всіх недійсних мотлоху, який заповнює WWW. Однак дотримання дійсного HTML допомагає, наприклад, якщо хтось використовує браузер для людей із вадами зору або отримує доступ до ваших сторінок в режимі офлайн та ін.

Перевірка сама по собі не є настільки важливою, оскільки мало браузерів на 100% сумісний, а специфікація не на 100% зрозуміла, як інтерпретувати правила.

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

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

Найкращий підхід - дізнатися, який недійсний HTML поганий, а який недійсний HTML не має значення.

Наприклад, забути закрити <div>тег дуже погано , оскільки ваш макет майже напевно виявиться в одному чи кількох браузерах.

Однак використання <br>замість <br />XHTML не має значення - усі браузери інтерпретуватимуть як розрив рядків без проблем. Використання targetатрибута на посиланнях є недійсним, але найгірший сценарій - браузер не відкриває посилання у новому вікні.

Під час запуску валідатора вам потрібно буде вивчити помилки, які він дає вам у кожному конкретному випадку. Чи важлива перевірка? Мені так, це дуже важливо. Але це вимога? Немає.

Такі речі, як використання одного і того ж ідентифікатора кілька разів (замість класу), введення елементів рівня блоку всередину елементів прямолінійного рівня (зазвичай ці елементи теж не підходять семантично), відсутні атрибути alt на зображеннях (погана доступність для людей з обмеженими можливостями ), всі важливі. Такі речі, як невідомі атрибути в тегах, НЕ важливі. Зовсім. Рамки Javascript, такі як Dojo або жахлива панель соціальних медіа Meebo, використовують спеціальні атрибути як гачки, а специфікація HTML зазначає, що вони дозволені, і будь-який невідомий атрибут слід ігнорувати. Валідатор не ігнорує їх, однак видає помилки. Ці помилки можна ігнорувати.

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

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

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

Я дійсно не думаю, що це вже має значення. Раніше я був рабом валідації, тепер я рідко коли-небудь перевіряю це. Можливо, я згорів від переконання, що мій сайт є дійсним, або, можливо, я просто не хвилювався, бо більше ніхто цього не зробить. Я можу гарантувати, що 99,9% наших відвідувачів навіть не знають, що це таке, а навіть небайдуже, якщо вони це зробили. Майбутнє програмне забезпечення для браузера може, але коли настане цей день, я тоді про це потурбуюся.

Перевірка корисна, тому що вона може допомогти вам виявити деякі важкі помилки, такі як

<input name=foo value=<?php echo htmlspecialchars($_GET['foo']); ?> />

або непередбачувана поведінка веб-переглядача (наприклад, розміщення блокових елементів у файлі aіноді може порушуватися некрасиво у Firefox)

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

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

в основному, все, що ви отримуєте, - це відповідати характеристикам. що в свою чергу означає, що програми, написані для читання html (браузери, боти), не можуть звинувачувати ВАС за те, що ви не відповідали специфікаціям, якщо щось пішло не так. і деякі з цих програм дають додаткові бали (більш високий рейтинг у пошукових системах, якщо бот повідомляє "відповідає специфікації"). якщо ви зустрінетесь із специфікаціями, вас здивує набагато менше, якщо деякі веб-переглядачі не надаватимуть зламаний HTML так, як ви вважаєте, що це повинно.

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

Деякі помилки перевірки HTML можуть спричинити не очевидні проблеми з компонуванням (наприклад, неправильно вкладені / незакриті теги), помилки JavaScript (наприклад, використання idдекількох разів) та проблеми для деяких користувачів (наприклад, не включаючи значущий або порожній altатрибут на зображеннях).

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

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

В майбутньому виробники браузерів забезпечуватимуть, щоб їх веб-браузери працювали за стандартами HTML / XHTML, тож саме про це повинні вражати і веб-розробники. Просто тому, що певний біт недійсної розмітки працює зараз, не гарантує, що він буде працювати в майбутніх браузерах.

Дійсність допомагає уникнути несумісності та підтримує збереження коду. Браузери відновлюються після помилок розмітки, але іноді дуже неінтуїтивно.

• На основі DTD (HTML4, XHTML1 @ W3C) - Можливо, цього не варто. DTD є примітивним і, наприклад, не може перевірити дійсність більшості атрибутів. В основному вам важко зрозуміти помилки щодо об'єктів та вкладень.

• Валідатор HTML5 - Так . Безумовно. HTML5 є більш прагматичним і допускає деякі нешкідливі конструкції, які раніше були помилками. Валідатор OTOH Henri набагато ретельніше та краще розкриває реальні проблеми.

Дійсність коду, створеного JS, може мати значення, оскільки браузери працюють на DOM, незалежно від того, як він створений. Якщо ви користуєтесь document.write(), то вам навіть доведеться подбати про правильність синтаксису (він проходить через аналогічний аналізатор, як джерело сторінки).

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

http://www.codeproject.com/KB/server-management/Google_Indexing_Problem.aspx

Google і Bing не використовують, не мають і ніколи не використовуватимуть перевірку CSS або HTML як фактор ранжування.

Більшість веб-сайтів мають десятки-сотні помилок, і вам не потрібно хвилюватися про них, оскільки всі пошукові системи дбають про те, як відображається сторінка. Просто переконайтеся, що ваш веб-сайт відображається правильно у всіх основних веб-переглядачах та програмі Google Fetch .