[0.8-preview] Throws exception if left-hand-side of a property binding contains a dash

[ssorallen]

Properties starting with "on-" are interpreted as event listeners, but any other property containing a dash causes Polymer to throw an exception while binding:

Uncaught ReferenceError: Invalid left-hand side in assignment

This is because of the compiled effects assuming they can use dot notation on nodes:

["this._nodes[0].data-foo = ..."]

[sjmiles]

Soon, any left-hand side of a binding that includes dashes will be converted to camel-case, so:

data-foo="{{bar}}"

will be interpreted as a request to bind dataFoo to bar.

Therefore it will be impossible to bind to a property that has dashes in it's name, and you will not hit this problem.

If the user's actual intent is to bind to an attribute, then they must use $= notation.

data-foo$="{{bar}}"

binds bar to the data-foo attribute of the target node.

In particular, we expect data-* to intend attribute binding almost 100% of the time. We have to consider making this an exception (and forcing an attribute binding regardless of $).

[ssorallen]

This becomes strange for attributes that are named differently from their JS properties like "class" -> "className" and "for" -> "htmlFor". If I bind to an element's "class" and inside the element it sets "className", do I get notified? Should I even bind to "class" or use "className" instead?

[sjmiles]

Those particular nasty bits are part of the HTML technical debt IMO. This case-sensitivity problem has historically been solved in an ad-hoc manner. We could (and may) add special-cases for such things (similar to data-*) but we invite leakier abstractions.

As it stands now we have eschewed magic in favor of explicit rules, such that:

1. bindings are to properties by default:
   class="{{something}}" operates on elt.class
className="{{something}}" operates on elt.classname
class-name="{{something}}" operates on elt.className (which elements will reflect back to class attribute).
2. bindings to attributes require '$'
   class$="{{something}}" operates on class attribute (which will affect elt.className)
   className$="{{something}}" operates on classname attribute
   class-name$="{{something}}" operates on class-name attribute

This is more complicated than we would like, but it is at least possible to express many cases without ambiguity. We're always looking for suggestions for improvement, but the best suggestions must consider all constraints.

[ssorallen]

I find limiting the amount of magic makes this easier to follow. The bit that still seems magic is the translation of camel case to lower case for properties. That is implied for attributes because HTML attributes are not case-sensitive, but JS properties are.

I'd expect:

className="{{something}}" to set elt.className

and

className$="{{something}}" to set the classname attribute on elt.

[peterwmwong]

@ssorallen I don't think it's possible to recover the original casing from DOM attributes (like when annotations are parsed)...
http://jsbin.com/fetena/1/edit?html,console

[ssorallen]

@peterwmwong Yup good point.

[sjmiles]

Yes, this entire bag of hurt comes from the fact that when we interrogate DOM for attribute names we only get lower-cased strings no matter what was in the original HTML.

[ssorallen]

Yeah, a downside of using rendered HTML (as opposed to a string) for templating. You're bound by the rules of the HTML processor whether you want 'em or not.

Thanks for the explanations. 👍

[kevinpschaaf]

Closing, as the error is no longer thrown for binding to dash-case properties (which are converted to camel case, added in #1191), and $= attribute binding works for dash-case attributes (added in 3f95fe3).