Будет ли проверка HTML 5 стоить свеч?

StackOverflow https://stackoverflow.com/questions/432933

  •  10-07-2019
  •  | 
  •  

Вопрос

Широко распространено мнение, что лучшая причина для проверки HTML — это убедиться, что все браузеры будут обрабатывать его последовательно и предсказуемо.

Однако проект HTML 5 содержит две спецификации в одной.Сначала спецификация автора, описывающая элементы и атрибуты, которые должны использовать авторы HTML, а также их взаимосвязи.Проверка страницы HTML 5 основана на этой спецификации.Включенные элементы и атрибуты не взяты напрямую из HTML 4, но их необходимо обосновать с учетом основных принципов. Это означает, что некоторые функции HTML 4, такие как атрибут summary в <table>, longdesc в <img> и атрибут профиля на <head>, в настоящее время не отображаются в этом черновике.Такие функции не считаются устаревшими, они просто не включены.(Их отсутствие в проекте остается предметом споров, хотя их включение в ближайшее время маловероятно.)

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

В частности, поскольку HTML 5 определен как 100% обратно совместимый с современным Интернетом, весь действительный HTML 4 и вся недопустимая, но часто используемая разметка будут продолжать обрабатываться точно так же, как сегодня, независимо от того, будет ли он обработан. действителен HTML 5 или нет.

Поэтому, как минимум, любой, кто использует любую функцию HTML 5, HTML 4 или любой предыдущей версии HTML, а также множество собственных расширений, может быть уверен, что его HTML будет последовательно и предсказуемо обрабатываться во всех браузерах.

Учитывая это, имеет ли смысл ограничивать HTML 5 тем, что будет проверяться, и какую практическую выгоду мы получим от этого?

Это было полезно?

Решение

  • Во-первых, есть уровень достоверности, соответствующий «ошибкам синтаксического анализа» в Алгоритм анализа HTML5.Этот уровень аналогичен правильному форматированию XML.Основная причина, по которой следует избегать ошибок в документах на этом уровне, заключается в том, что вы можете получить неожиданное дерево синтаксического анализа.Если ваш документ не содержит ошибок на этом уровне, у вас будет меньше сюрпризов для отладки при написании JS или CSS, которые работают с DOM.
  • В качестве частного случая вышеупомянутого слоя существует тип документа HTML5: <!DOCTYPE html>.Причина, по которой здесь хотелось бы соблюдать требования, заключается в том, чтобы получить стандартный режим самым простым способом.Это то, что вы можете запомнить, в отличие от типов документов HTML 4.01 или XHTML 1.0, которые вам нужно каждый раз искать, копировать и вставлять.Конечно, причина, по которой вам нужен стандартный режим, заключается в меньшем количестве сюрпризов на уровне CSS.
  • Основная причина, по которой нужно заботиться о проверке на уровне выше алгоритма синтаксического анализа, — это выявление опечаток, чтобы вы тратили меньше времени на отладку того, почему ваша страница не работает так, как вы ожидаете.
  • Предыдущий пункт не объясняет, почему вам следует заботиться о проверке, если данный элемент или атрибут, который вы не допустили с ошибкой, поддерживается браузерами как наследие, но спецификация HTML5 по-прежнему избегает его.Вот почему в HTML5 устаревший синтаксис:
    • HTML5 использует устаревание, чтобы сигнализировать авторам, что некоторые функции — пустая трата их времени.К ним относятся longdesc, summary и profile.(Обратите внимание, что люди расходятся во мнениях относительно того, действительно ли это пустая трата времени, но в нынешней редакции HTML5 делает их устаревшими.) То есть, если у вас ограниченные ресурсы для улучшения доступности, ваши ограниченные ресурсы лучше потратить на что-то другое, а не на что-то другое. longdesc и summary.Если у вас ограничены ресурсы для семантической чистоты, лучше потратить их на что-то другое, а не на то, чтобы убедиться, что у вас есть правильное заклинание в profile.
    • HTML5 упраздняет некоторые функции представления, которые можно дублировать в CSS, чтобы помочь авторам использовать CSS для собственного блага.Таким образом, авторы, которые не рассматривают возможность сопровождения самостоятельно, тем не менее, должны ориентироваться на более удобный в сопровождении код.Лично я бы предпочел сделать больше устаревших презентационных материалов соответствующими и предоставить авторам самим решать, какой способ ведения дел им подходит.
    • Некоторые вещи устарели по политическим причинам.А <font> элемент устарел, потому что приведение его в соответствие сделало бы анти-<font> Сторонники стандартизма считают, что люди, занимающиеся HTML5, сошли с ума, что может привести к плохому пиару. <applet> устарел главным образом из-за принципа отсутствия специальной разметки для одного конкретного плагина.А classid атрибут включен <object> устарел, поскольку на практике он специфичен для ActiveX.
    • Некоторые вещи устарели из-за эстетики языкового дизайна.Это включает в себя name атрибут включен <a> и language атрибут включен <script>.

(Я разрабатываю валидатор HTML5 Validator.nu, который также является механизмом проверки HTML5, используемым валидатором W3C.)

Другие советы

  

Учитывая это, имеет ли смысл ограничивать те HTML 5 тем, что будет проверять, и какую практическую выгоду мы получим от этого?

Да, конечно. Вы забываете, что будущее не установлено. В частности, вы неявно предполагаете, что спецификации HTML 5 никогда не изменятся и никогда не устаревают ни перед какими функциями. Это, конечно, только цементирует статус-кво. Определенно желательно отказаться от поддержки некоторых функций в долгосрочной перспективе, чтобы облегчить новые разработки (в частности, если они могут противоречить друг другу).

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

В действительности, валидация никогда не сводилась к получению согласованных результатов в разных браузерах, даже до начала HTML5. Это миф, распространяемый теми, кто не понимает, о чем говорит, даже если они думают, что понимают.

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

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

Это действительно одна из моих претензий к HTML5. Нет смысла определять подмножество потоков как «допустимые», если браузер все равно должен обрабатывать все потоки одинаково. Эоны, потраченные на обсуждение WHATWG механизмов резервирования, являются огромной тратой времени каждого, особенно когда XML уже должен был решить все проблемы синтаксического анализа.

Было бы полезно подготовить документ с рекомендациями по анализу устаревших недействительных документов, но он не имеет отношения к веб-стандарту, это просто еще один ингредиент, который еще больше запутывает воду вокруг HTML5, которая не может решить, он хочет кодифицировать существующее поведение (как в HTML 3.2), переопределить более чистую платформу (как пробовал HTML 3.0) или добавить новые расширения по частям.

В любом случае, вопрос может быть неуместным, потому что никогда не будет браузера, который & полностью поддерживает HTML5 " ;. Их слишком много, слишком много: производители браузеров не могли бы реализовать абсолютно все до мелочей, даже если бы захотели, чего, по крайней мере, Microsoft явно не делает. Вместо этого, очевидно, что полезные функции будут отобраны у поставщика и получат более широкое признание.

HTML5 - это не связная спецификация HTML, это разросшийся, нечитаемый и незаконченный рецепт Хикси для каждой случайной вещи, которую, по его мнению, должен делать веб-браузер. Это не удастся. И альтернативный подход W3, XHTML2, уже потерпел неудачу. Нет единого будущего направления для веб-стандартов. Мы упали мяч.

Это хороший вопрос.

Основная цель проверки (по крайней мере, для меня) — помочь мне обнаружить ошибки в разметке и дать мне хорошую основу для дальнейшего тестирования страниц в разных браузерах;если разметка действительна, а страница не работает в IE6, это проблема IE6.

Тот факт, что все браузеры должны вести себя предсказуемо, даже если ваша разметка включает технически недопустимый HTML5, такой как сводка таблицы или ключ доступа к привязке, несколько мутит воду.

Как правило, я всегда хочу, чтобы мои страницы проходили проверку по вышеупомянутой причине.Однако, если (например) атрибут был исключен из спецификации HTML5 без добавления очевидно подходящей замены, я мог бы быть склонен продолжать использовать устаревший или устаревший атрибут и принять ошибки проверки.

Как всегда, я думаю, что это вопрос знания своего ремесла.

Если вы знаете, что делаете, и сделали осознанное решение создать страницу, которая не проходит проверку по веским причинам, это не проблема.Если вы просто пишете код, который не проверяется, потому что вы ничего не знаете, это совсем другое дело.

Стивен

Сопровождающий валидатора W3C HTML5 здесь.Я недавно написал короткий «Зачем проверять?» Раздел для разделения «О» валидатора HTML5:

http://validator.w3.org/nu/about.html#why-validate

Источник текста этого раздела находится здесь:

https://github.com/validator/validator/blob/master/site/nu-about.html#L160

Запросы на включение с предлагаемыми улучшениями/дополнениями приветствуются.

На данный момент у меня есть следующее:

Основная причина запустить ваши документы HTML через проверку соответствия, проста:Чтобы поймать непреднамеренные ошибки - переживания, которые вы могли бы пропустить, - так что вы можете их исправить.

Кроме того, некоторые требования к документу-конформации (правила достоверности) в спецификации HTML, которые помогут вам и пользователям ваших документов избежать определенных видов потенциальных проблем.Чтобы объяснить обоснование этих требований, HTML -спецификация содержит эти два раздела:

Подводя итог тому, что сказано в этих двух разделах:

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

Проверка ваших документов предупреждает вас об этих потенциальных проблемах.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top