Стоит ли проверки HTML 5 свеч?

Given this, does it make any sense to limit ones HTML 5 to that which will validate, and what practical benefit will we get from doing so?

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

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

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

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

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

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

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

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

Стивен

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В настоящее время у меня есть следующее:

The core reason to run your HTML documents through a conformance checker is simple: To catch unintended mistakes—mistakes you might have otherwise missed—so that you can fix them.

Beyond that, some document-conformance requirements (validity rules) in the HTML spec are there to help you and the users of your documents avoid certain kinds of potential problems. To explain the rationale behind those requirements, the HTML spec contains these two sections:

• rationale for syntax-level errors
• rationale for restrictions on content models and on attribute values

To summarize what’s stated in those two sections:

• There are some markup cases defined as errors because they are potential problems for accessibility, usability, interoperability, security, or maintainability—or because they can result in poor performance, or that might cause your scripts to fail in ways that are hard to troubleshoot.
• Along with those, some markup cases are defined as errors because they can cause you to run into potential problems in HTML parsing and error-handling behavior—so that, say, you’d end up with some unintuitive, unexpected result in the DOM.

Validating your documents alerts you to those potential problems.