可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

I am using angular-ui-select within a website where the styled select fields are configured with an own tag named ui-select. This works great, but doing a W3C validation leads to this error:

Element ui-select not allowed as child of element div in this context. (Suppressing further errors from this subtree.)

Here's an example code:

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

I understand that <ui-select> is not expected to be there but how can I handle this better?

Can I wrap it into a different tag or is there a different approach for ui-select instead of using HTML markup?

回答1:

That's indeed a long-known issue with AngularJS.

A few things you can do:

Instead of using the element <ui-select>, you can use <div ui-select>, but that will still fail on the argument.

An argument prefixed with x- or data- will pass but I am not sure ui-select supports that.

HTML W3C validation is useful, but I think mostly important for HTML emails so they don't get screened as spam. It's also good for search engines, but really not that critical.

If you look at 'why validate', the reasons are mostly for cleanliness, ease of debugging, and overall good practice.

Angular (un?)fortunately expands the realm of possibilities for HTML5, in a way that, naturally, deviates from the latest specifications for HTML.

回答2:

W3C HTML5 validator maintainer here. The short answer with regard to the validator behavior right now is, the validator's going to emit errors for any custom elements you use in documents, and currently there's no way you as a user can work around it doing that—and it's going to continue that way for some time longer until we get around to figuring out a solution.

We're having some ongoing discussions about how to solve this. Changing the validator to just ignore any element name with a hyphen is not viable as a complete solution, because the consequence of that is we could then not practically check any child elements it might have—we'd just have to ignore the entire subtree, because to do otherwise would lead to other errors. So that's way short of being an ideal solution.

Anyway, I'd love to find a good way to solve this, so if others have ideas I'd like to hear them. Two good places to send ideas/proposals on this are the public-webapps@w3.org mailing list https://lists.w3.org/Archives/Public/public-webapps/ and the whatwg@whatwg.org mailing list https://whatwg.org/mailing-list#specs

One idea I've thought of myself is, we could just have the validator treat all custom elements in the same way it currently treats the <div> element (as far as where it's allowed in a document and what child elements it's allowed to contain). That's also short of ideal, but at least it would give a way to check for errors in descendant elements in the custom element's subtree.

Update 2017-02-06: the W3C HTML Checker now supports custom elements

So, I added support for custom elements to the W3C HTML Checker (validator) on 2016-12-16 and a few days later refined it to do more detailed checking for prohibited names.

The trick I ended up figuring out to implement it in the checker architecture—which is at its core a RelaxNG grammar/schema-based validator—was to add a pre-processing filter that take any elements that have a hyphen in their element name, and puts them in a separate XML namespace.

Then I updated the RelaxNG schema to allow any elements from that XML namespace anywhere. (Which is ironic because I pretty much hate XML namespaces and all the problems they cause.)

So we’re now looking at doing something similar for custom-attribute names—probably just by defining those as being any attribute names that contain a hyphen (like custom-element names).

But the HTML checker can’t be changed to allow custom-attribute names until the HTML spec is updated to allow them. For that, see the proposal being discussed in the HTML-spec issue tracker.

回答3:

We are having the same problem using Knockout custom components. http://knockoutjs.com/documentation/component-overview.html

I added a suggestion how to enhance the validator with a minor enhancement for users wanting to use custom elements even if the specification is not yet final (http://w3c.github.io/webcomponents/spec/custom/#custom-tag-example):

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