[0.8] Consider always assigning to native properties

[ssorallen]

Currently the effect of the left side of an assignment is determined by the value on the right side. If the right side contains a binding, i.e. it's wrapped in [[]] or {{}}, the left side is treated as a property assignment. If the right side contains no binding, the left side is treated as an attribute assignment.

This behavior forces the developer to alter assignments based on whether binding is happening or not and leads to an inconsistent API. For example:

Currently:

<!-- attribute assignment -->
<div data-bar="baz"></div>
<div class-name="foo"></div>
<label html-for="bar"></label>

<!-- camel case translated property assignment -->
<label html-for="{{bah}}"></label>
<div class-name="{{bar}}"></div>

For any assignment that would result in writing to a native property, it would be more consistent to always make the assignment to the property. Non-native / custom / data- prefixed assignments should likely not be affected.

Proposed:

<!-- attribute assignment -->
<div data-bar="baz"></div>

<!-- camel case translated property assignment -->
<div class-name="foo"></div>
<label html-for="bar"></div>
<label html-for="{{bah}}"></label>
<div class-name="{{bar}}"></div>

[ssorallen]

This leads to inconsistent behaviour with data- properties as well. Consider:

<!-- The value is available at `element.dataset.foo` -->
<x-x data-foo="bar"></x-x>

<!-- The value is available at `element.dataFoo` -->
<x-x data-foo="{{bar}}"></x-x>

[kevinpschaaf]

The current recommended way to assign and bind to attributes is below:

Attribute assignment:

<div data-bar="baz"></div>
<div class="foo"></div>
<label for="bar"></label>

Attribute binding:

<div data-bar$="{{baz}}"></div>
<div class$="{{foo}}"></div>
<label for$="{{bar}}"></label>

This is a clear rule that avoids a.) a whitelist of attribute->property name mappings, b.) avoids strange exceptions (e.g. style attribute maps to style.cssText) that would have to be specially explained, c.) sidesteps intractable issues with IE's inability to have invalid text (e.g. {{...}}) in style and href attributes.

It has the unfortunate quality that the left hand changes as a result of whether the right-hand is a binding or not. We understand this is potentially unsatisfying, but any other rule has equally unsatisfying ramifications on explainability and robustness. This is on the backlog to reconsider.

[ssorallen]

The whitelist would only have to be for properties that were renamed in the HTML spec so the properties wouldn't use keywords in JavaScript: className and htmlFor. Would there have to be others?

For class there are 3 ways to assign:

class="foo"
class$="[[foo]]"
class-name="[[foo]]"

The biggest problem I see is the difference between the first two. I'd like to be able to say, "always use class$ for consistency", but I can imagine resistance to another character.

[kevinpschaaf]

style and href are the other problems, and the most problematic.

Bind to style property via whitelist (map style attribute to style.cssText property):

<!-- NOT POSSIBLE.  IE punts style attribute with non-parsing CSS text.  Same for href.  -->
<div style="{{myStyle}}">

Which leaves us with this:

Assign to style attribute:

<div style="background: red">

Bind to style attribute:

<div style$="{{myStyle}}">

So, in the end a whitelist is ultimately unsatisfying because it's a bunch of exceptions we have to explain, and it still doesn't satisfy the issue for style and href on IE, which would require us to have and even more confusing set of exceptions. Given whitelist isn't an obvious slam dunk, the recommendation for 0.8 is going to be #1226 (comment), and consider other options for 0.9.

[sorvell]

We've decided to leave this functionality as is for now based on the discussion and browser limitations. We'll definitely continue to evaluate refinements to the binding syntax based on user feedback.