W3C validation for <ui-select>

C

3

8

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?

Carolinecarolingian answered 13/2, 2015 at 20:52 Comment(1)

I don't understand the question. The validator will never, ever pass that element since there is no such thing in the HTML spec. – Pedigree 14/2, 2015 at 0:51

C

5

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.

Cocci answered 13/2, 2015 at 22:48 Comment(7)

Thanks. This does work for attributes like ng-* but not for tags. Changing the tag to x-ui-select or data-ui-select does not change anything, its still invalid for the validator. – Carolinecarolingian 13/2, 2015 at 23:33

as an element it will be invalid, as an attribute <div x-ui-select> it should pass. – Cocci 13/2, 2015 at 23:34

With this pull request github.com/angular-ui/ui-select/pull/579 it would be the perfect solution. – Carolinecarolingian 14/2, 2015 at 7:59

Accepted your answer. May I ask you to edit your answer to format it a little better for a better overview for future readers? – Carolinecarolingian 14/2, 2015 at 8:27

"Angular expands the possibilities for HTML5 and the spec just hasn't followed yet". Not true: see Custom Elements, which allows having custom elements like ui-select. – Paranoiac 17/2, 2015 at 16:20

@Paranoiac Adjusted that sentence to a more accurate statement while preserving the same meaning. – Penguin 25/2, 2015 at 5:42

@Paranoiac your link points at a 'draft' which is 'for review and not for implementation' as stated by w3c itself. so it is not a spec yet. – Cocci 19/9, 2015 at 22:31

P

17

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 [email protected] mailing list https://lists.w3.org/Archives/Public/public-webapps/ and the [email protected] 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.

Protestantism answered 25/2, 2015 at 4:17 Comment(0)

C

5