Подтвердить что ты не робот

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

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

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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

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

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

Стивен

Ответ 6

W3C поддерживающий HTML5 валидатор. Недавно я написал короткое сообщение "Why Validate?". раздел "О программе" валидатора HTML5:

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

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

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

И тянуть запросы с предлагаемыми уточнениями/дополнениями приветствуются.

В настоящее время у меня есть это:

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

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

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

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

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