Проверка 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 Анри гораздо тщательнее и лучше обнаруживает реальные проблемы.

Корректность JS-сгенерированного кода может иметь значение, так как браузеры работают с DOM, независимо от того, как он был создан. Если вы используете document.write(), то вам даже нужно позаботиться о том, чтобы получить правильный синтаксис (он проходит через тот же парсер, что и источник страницы).

Даже если ваш HTML работает во всех основных браузерах, это все же стоит сделать, поскольку иногда это может вызвать проблемы с поисковыми системами, такими как googlebot. Например, посмотрите это:

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

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

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