Проверка W3C для <ui-select>

Я использую angular -ui-select на веб-сайте, где настроенные поля выбора настроены с собственным тегом с именем ui-select. Это отлично работает, но выполнение W3C-проверки приводит к этой ошибке:

Элемент ui-select не разрешен как дочерний элемент div в этом контексте. (Подавление дальнейших ошибок из этого поддерева.)

Вот пример кода:

<!doctype html>
<html lang="en">
<head><title>x</title></head>
<body>
 <div>
  <ui-select></ui-select>
 </div>
</body></html>

Я понимаю, что <ui-select> не ожидается, но как я могу справиться с этим лучше?

Можно ли обернуть его в другой тег или есть другой подход для ui-select вместо использования разметки HTML?

Ответ 1

Это действительно давняя проблема с AngularJS.

Несколько вещей, которые вы можете сделать:

Вместо использования элемента <ui-select> вы можете использовать <div ui-select>, но это все равно будет терпеть неудачу в аргументе.

Аргумент с префиксом x- или data- пройдет, но я не уверен, что ui-select поддерживает это.

HTML Валидация W3C полезна, но я думаю, что в основном важна для электронных писем HTML, поэтому они не отображаются в качестве спама. Это также хорошо для поисковых систем, но на самом деле это не так важно.

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

Angular (un?), к счастью, расширяет сферу возможностей HTML5, что, естественно, отличается от последних спецификаций HTML.

Ответ 2

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

У нас есть некоторые текущие дискуссии о том, как это решить. Изменение валидатора, чтобы просто игнорировать любое имя элемента с дефисом, не является жизнеспособным как полное решение, потому что последствие этого - то, что мы могли бы тогда практически не проверять любые дочерние элементы, которые он мог бы иметь - нам просто нужно было бы игнорировать все поддерево, потому что иначе это приведет к другим ошибкам. Таким образом, это не идеальное решение.

В любом случае, я бы хотел найти хороший способ решить эту проблему, поэтому, если у других есть идеи, я бы хотел их услышать. Два хороших места для отправки идей и предложений по этому поводу - это список рассылки [email protected] https://lists.w3.org/Archives/Public/public-webapps/ и whatwg @whatwg. org https://whatwg.org/mailing-list#specs

Одна идея, о которой я подумал, - это просто, чтобы валидатор обрабатывал все пользовательские элементы таким же образом, как в данный момент обрабатывает элемент <div> (насколько он разрешен в документе и какие дочерние элементы он разрешено содержать). Это также не соответствует идеалу, но, по крайней мере, это даст возможность проверить ошибки в элементах-потомках в поддереве настраиваемых элементов.

Обновление 2017-02-06: W3C HTML Checker теперь поддерживает пользовательские элементы

Итак, Я добавил поддержку настраиваемых элементов в W3C HTML Checker (валидатор) в 2016-12-16 и через несколько дней уточнил его, чтобы выполнить более подробную проверку запрещенных имен.

Трюк, который я закончил тем, что решил реализовать его в архитектуре checker, которая в своей основе является валидатором на основе грамматики/схемы на основе RelaxNG, заключалась в том, чтобы добавить фильтр предварительной обработки, который принимает любые элементы, имеющие дефис в их имя элемента и помещает их в отдельное пространство имен XML.

Затем я обновил схему RelaxNG, чтобы разрешить любые элементы из этого пространства имен XML в любом месте. (Что иронично, потому что я очень ненавижу пространства имен XML и все проблемы, которые они вызывают.)

Итак, теперь мы смотрим на то, что похоже на имена пользовательских атрибутов, возможно, просто определяя их как имена атрибутов, содержащие дефис (например, имена пользовательских элементов).

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

Ответ 3

Мы сталкиваемся с той же проблемой, используя пользовательские компоненты Knockout. http://knockoutjs.com/documentation/component-overview.html

Я добавил предложение о том, как улучшить валидатор с незначительным улучшением для пользователей, желающих использовать пользовательские элементы, даже если спецификация еще не окончательная (http://w3c.github.io/webcomponents/spec/custom/#custom-tag-example):

https://github.com/validator/validator/issues/94