Should I care about W3C validation?

I'm learning AngularJS and I found a simple code like this one:

<!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>

does not pass W3C validation test, mainly because there are non standard attributes (ng-app, ng-init).

The question is: should I care about W3C validation of my application? Should I abandon AngularJS?

Solution 1:

You could use the data- html5 attribute which is standard and as far as I know works the same for Angular. Something like:

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

Will work the same in Angular and are validated by W3C.

Look also at this: ng-app vs. data-ng-app, what is the difference?

Aside from that, from my experience working with standards is always better when your product will be delivered to a possible large crowd (so you'r building a website or a public webapp and so on) with different clients, versions etc. If you're building a SPA using angular and maybe phonegap to create a mobile app which will be installed on mobile devices as a native app, standard could not be that important, the important thing is that it will work on your target devices.

Solution 2:

W3C HTML5 validator maintainer here. We’ve had discussions about how to deal with better facilitating validation of documents that contain custom attributes like Angular’s ng-* attributes—attributes which though while non-standard are still very widely and correctly used, and so having the validator emit “error” messages about them isn’t really helping authors.

One feature I’ve added to the HTML5 validator to mitigate this is a “Message filtering” feature that lets you persistently ignore error/warning messages that aren’t important or useful to you. The frontend is here:

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

After you submit a document for checking, on the results page you’ll see a Message filtering button, and if you press that, you’ll get a list of all the error messages grouped into sets, with Show/Hide checkboxes.

validator screen shot showing Message Filtering button

Update 2017-02-06: HTML spec proposal for custom attributes

I added support for custom elements to the HTML Checker (W3C validator)—so, to add support for custom attributes, I could use a mechanism similar to what I used for implementing that.

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 in the HTML-spec issue tracker.

Solution 3:

Wheter you "should" care or not is up to you. There are many pages out there which are not valid HTML.

HTML5 allows custom attributes when prefixed with data-, so you can use one of the other equivalent directives like:

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

Solution 4:

HTML conventions are there to help prevent antipatterns and keep code maintainable.

Yeah. Along those lines, I wrote about that in a little more length recently in a “Why Validate?” section I added to the “About” section of the HTML5 validator:

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

The source for the text of that section is here:

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

And pull requests with suggested refinements/additions are welcome.

What I have there currently is this:

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.