Будет ли проверка HTML 5 стоить свеч? - PullRequest
Новая
       25

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

28 голосов
/ 11 января 2009

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

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

Ответы [ 6 ]

56 голосов
/ 15 января 2009
  • Сначала существует уровень достоверности, соответствующий «ошибкам разбора» в алгоритме синтаксического анализа HTML5 *1003*. Этот уровень похож на правильность 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> устарел, потому что его соответствие заставит анти-1024 * стандартистов думать, что люди HTML5 сошли с ума, что может привести к плохому пиару. <applet> устарел в основном из-за отсутствия специальной разметки для одного конкретного плагина. Атрибут classid в <object> устарел, поскольку на практике он специфичен для ActiveX.
    • Некоторые вещи устарели на основе эстетики языкового дизайна. Сюда входит атрибут name для <a> и атрибут language для <script>.

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

6 голосов
/ 12 января 2009

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

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

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

6 голосов
/ 11 января 2009

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

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

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

4 голосов
/ 12 января 2009

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

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

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

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

3 голосов
/ 12 января 2009

Хороший вопрос.

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

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

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

Как всегда, я думаю, что это тот случай, когда ты знаешь свое ремесло.

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

Стивен

2 голосов
/ 27 февраля 2015

Сопровождающий валидатора 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.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Нет похожих вопросов

...