As part of the beta release, we eliminated the requirement for kebab-case in Angular templates and replaced them with case-sensitive names for attributes. This makes it easier for you to write Angular 2 templates that are consistent with naming conventions used in directives.
For example, where you would previously write:
<my-widget (some-event)="someAction()" [some-property]="expression" #some-var>
You now write:
<my-widget (someEvent)="someAction()" [someProperty]="expression" #someVar>
Case-sensitivity solves a long-standing confusing issue in Angular 1 where you needed to just know the convention for mapping template attribute names to JavaScript names. This was an easy pit for novices and even experts to fall into.
Browsers don't differentiate tags by case. Solving the problem required Angular to do its own HTML parsing, so that we could retain the case-sensitive version, and lets us eliminate the mapping convention.
So are Angular 2 templates still valid HTML? Absolutely. Per the spec itself, HTML is case-insensitive. You can freely write whatever case you like and still work with every HTML browser, tool, parser, etc. ever written.
But what if you see validation errors in your favorite tool? It's possible that your tool doesn't follow the HTML specification, or it could be a bug. We're working with tool developers to ensure a smooth experience and would like to hear about issues you encounter. Please file them here.
Just as Angular has always made it possible to create your own elements and attributes that add behaviors beyond the browser's basic set of HTML, the new HTML parser provides benefits by extending the syntax available to templates.
More Benefits
Beyond eliminating the confusion of kebab/camel-case, the HTML parser brings many additional benefits including:- Better error messages. When there are errors, we can now tell you which line and column number they occur on in the template.
- More consistent. Whether you're on Chrome, IE, Safari, Firefox or even on the server in node.js we parse the template the same way. We were able to drop all of the heuristic code required in Angular 1 to account for differences.
- Enables offline compilation. We're nearly complete with our next phase of performance optimization where we move all parsing/compiling to a build step. To make integration with existing build systems as smooth as possible we need to parse the template using Node.js without requiring any browser.
- Catches errors that browsers don't. Web browsers are more lenient than the specification and auto-correct errors without telling you. We want templates to be correct, as these HTML errors can cause real problems when browsers guess wrong. With this new parser, we've already caught real errors in Google applications and in the Ionic 2 framework.
- Eliminates typos during development. You can think of the parser as an HTML validator built into your framework. We can catch typos in your attribute or tag names and tell you before you ever deploy.
- Better i18n support. Our new i18n support requires us to parse and understand the templates. Having a custom parser makes this job much easier, reliable and efficient.