forced lower case in binding declarations means <h1 [innerHTML]="title"> won't work

[wardbell]

Yes, I know this is issue #1447 again.

That issue is closed ... as if closing it solved the problem. Well this is ANOTHER example of the problem and it means that we can't write simple binding declarations that touch existing DOM properties that happen to be mixed case (and there are a ton of them). We'll be force to write directives when we shouldn't have to do that.

This example expression <h1 [innerHTML]="title"> throws the error:

EXCEPTION: Can't bind to 'innerHTML' since it isn't a known property of the '<h1>' element and there are no matching directives with a corresponding property

I feel we ought to be able to do something about this. Perhaps some kind of special syntax to indicate upper case? <h1 [inner^html^]="title">? We need some creativity here.

[pkozlowski-opensource]

@wardbell there is a special syntax for this already: <h1 [inner-html]="title"> should do the trick. There are 2 things at play here:

• we've got snake-case to camelCase convention, so writing foo-bar will bind to fooBar
• the above doesn't solve the pb for innerHTML (one would have to write inner-h-t-m-l which isn't pretty) so few commonly used properties are special-cased in the compiler (this is why inner-html works)

[pkozlowski-opensource]

@tbosch @mhevery I'm wondering if we couldn't allow mixedCase attributes with the new compiler? It should be technically possible now, as we are parsing string representation of a template, no?

I know that it would be depart from the HTML standard but soooooo many people are bumping into it....

[wardbell]

Oooo. I was about to change this to "textContent" which is safer but your comment makes a much more interesting observation so I reverted.

We HAVE to document this!!!

[pkozlowski-opensource]

We HAVE to document this!!!

@wardbell totally!!!!

There are probably other "goodies" in the compiler that are not well known. Ping me on slack so we can discuss those

[mhevery]

@pkozlowski-opensource we can't allow this with new compiler. It may work at build time, bit it would fail in the browser always. So for the sake of consistence we have to honor the browser.

[pkozlowski-opensource]

@mhevery oh, I was under the impression that we are going to use the same text-based compiler in both build-based compilation and in a browser.

What is the advantage of having 2 different code paths in the compiler? I was assuming that we are always getting text of a template and not DOM tree so could use the same code....

[mhevery]

Sorry closed by accident.

I was not aware that we are not going to use the browser parser. @tbosch can you comment?

[pkozlowski-opensource]

@mhevery @tbosch I'm not sure how the new compiler works so I don't know if it is using browser parser or not. I was just wondering why we would have 2 different compilers when we can parse text in both cases?

What would be the advantage of such approach?

[mhevery]

I think we should do #4417 which would then solve all of these issues once and for good.

[pkozlowski-opensource]

Fixed by a8edc1e

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}