Должен ли я заботиться о валидации W3C?

Я изучаю AngularJS, и я нашел простой код, похожий на этот:

<!DOCTYPE html>
<html>
   <head>
    <meta charset='utf-8'>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.0.7/angular.js"></script>
</head>
<body ng-app ng-init="name = 'World'">
    <h1>Hello, {{name}}!</h1>
</body>
</html>

не проходит проверку валидации W3C, главным образом потому, что существуют нестандартные атрибуты (ng-app, ng-init).

Вопрос: должен ли я заботиться о валидации W3C моего приложения? Должен ли я отказаться от AngularJS?

Ответ 1

Вы можете использовать атрибут data - html5, который является стандартным, и насколько мне известно, работает одинаково для Angular. Что-то вроде:

data-ng-app=""
data-ng-init="xxx"

Будет работать то же самое в Angular и проверяется W3C.

Посмотрите также: ng-app vs. data-ng-app, в чем разница?

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

Ответ 2

W3C поддерживающий HTML5 валидатор. У Weve были дискуссии о том, как лучше справляться с проверкой документов, содержащих пользовательские атрибуты, такие как атрибуты Angular s ng-*-атрибуты, которые хотя в то время как нестандартные все еще очень широко и правильно используются, и поэтому наличие ошибки проверки подлинности "" Сообщения о них не помогают авторам.

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

http://validator.w3.org/nu/

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

Обновление 2017-02-06: предложение спецификации HTML для обсуждаемых пользовательских атрибутов

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

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

Ответ 3

То, что вы "должны" заботиться или нет, зависит от вас. Существует много страниц которые не соответствуют HTML.

HTML5 позволяет настраиваемые атрибуты при префиксе data-, поэтому вы можете использовать одна из других эквивалентных директив, например:

<span data-ng-bind="name"></span>

Ответ 4

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

Да. Вдоль этих строк, я писал об этом чуть более подробно недавно в "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.
Проверка ваших документов предупреждает вас об этих потенциальных проблемах.

Ответ 5

Используйте префикс "data-" в приложении angular. Пример:

<body data-ng-app data-ng-init="name = 'World'">
   <h1>Hello, {{name}}!</h1>
</body>

Ответ 6

Вы можете использовать систему сборки GulpJs и попробовать плагин, который я написал, который делает именно то, что вы хотите:

преобразование ng-directives в data-ng-directives, которое является спецификацией W3C для проверки html5.

Он сильно протестирован и найден здесь: https://github.com/pgilad/gulp-angular-htmlify

https://www.npmjs.com/package/gulp-angular-htmlify

Ответ 7

Вы можете install with npm:

$ npm install --save-dev gulp-angular-htmlify

Ответ 8

Это зависит от размера вашего проекта.

Как правило, существуют соглашения HTML, которые помогают предотвратить антипаттерны и поддерживать код обслуживаемым.

Это конкретное правило (требующее, чтобы тэг с префиксом -data был допустимым атрибутом), по-моему, немного постороннее, поскольку он имеет тенденцию продвигать дополнительную разметку, которая не имеет никакой цели.

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