This is the first attempt at #619 but with few remark: I'm completely buying the idea of "fixing" property names where both attr and property exists (ex. tabindex => tabIndex), but I'm less sure about the situation where there is no attribute but a property exists. Why do we want to "invent" attribute names? Shouldn't people simply bind to property names in this case?

@pkozlowski-opensource Seems Travis fails because of innerHtml vs innerHTML (case)

@vicb yeh. That's bad since in JS it is innerHTML.... OK, I will add special casing for inner html...

So, the solutions I can see right now is to:

• have a separate / different mapping tables for Dart and JS (this makes me sad...) + facade for a getter
• special-case inner-html

But yeh, I really don't feel good about "inventing" the inner-html attribute name.

@mhevery could we discuss this during / after the today's standup?

@mhevery I believe this is ready for the review. Just 2 items I'm unsure of:

• I had to hack a bit for innerHtml due to Dart's DOM facade and innerHtml #789
• I was kind of surprised to see that what I'm getting in the ElementBinderBuilder compilation step were "un-normalized" attribute names - that is - for <div [scroll-top]="expr"> I would get prop name being scroll-top while from your description I was assuming that it gets normalized to scrollTop in one of the previous steps. So the question is: should I expect scroll-top or scrollTop inside ElementBinderBuilder (currently it gets scroll-top)?

I don't really get the point to create fake attributes that don't exist in the first place.

@pkozlowski-opensource The goal being to be able to bind directly to properties, why not using directly the property name without any conversion (I know it is not solving the different case issue between Dart and JS, but from a user point of view, you will write either Dart or JS) ? Maybe I am missing the point on that topic...

Regarding inner-html what would be the difference between:

<div [innerHTML]="myContent"></div>

and

<div>{{myContent}}</div>

@benouat there are 2 things to observe here:

• if you type <div innerHTML="foo"> a browser will convert it to <div innerhtml="foo"> so we can't take advantage of mixed case in templates
• difference between [inner-html]="foo" and {{foo}} as the same as element.innerHTML = foo vs. element.textContent = foo

The conversion from dash-case to camelCase should happen in ElementBinderBuilder. Let's fix it there if it already is not fixed.

UPDAT: I see you have already added it. Perfect

Please fix the comments and it should be ready to go.

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.}