We'll take a look at fixing this.

However, it's an odd construction to set an attribute on yourself to initialize your own property, and we'd probably consider this an anti-pattern; is there a reason you don't just use value: 'foo' for the target property?

We generally try to avoid using attributes for anything dynamic, and only for initial configuration in markup, since dynamic attribute manipulation is detrimental to performance

@kevinpschaaf The sample code here is intentionally short to make the bug easier to see; the actual use case is slightly more complex.

We have a Polymer behavior that defines an attribute like target here. Components that mix in this behavior want to be able to set that attribute on themselves. A concise and convenient way to do that is via hostAttributes. The component can declaratively set that value instead of having to write, e.g., a ready handler that sets the value imperatively. This effectively falls under the "initial configuration" case you describe above, albeit in JS instead of markup.

So, while the result is that a component is ultimately setting an attribute on itself, it feels pretty different, because the attribute was defined separately in the behavior. We think this is a use case worth supporting.

Components that mix in this behavior want to be able to set that attribute on themselves.

Ok, but is there a reason it is important to think about target as an attribute, rather than a property? Again, we basically only ever think about API in terms of properties, with attributes just as a way to set initial property values via static markup. Behaviors support filling in default property values of properties defined on the base element, ala http://jsbin.com/migozeqowo/2/edit, and this is preferred over attributes because it avoids a needless serialization/deserialization round-trip (and the non-negligible costs of setAttribute/getAttribute).

First: that's an interesting jsBin. I hadn't known that a property could be defined in both a behavior and the component. That's cool! But also, as far as I can tell, undocumented.

Second: Your jsBin example somewhat flips around what I'd described. We have a behavior that defines an attribute (including a changed handler), and the component wants to set that. Your solution has the component define the attribute, and the behavior provides a default value, which is somewhat the opposite. That said, your solution works for the particular use case that motivated us filing this issue.

While I think we're unblocked for the moment, we'd still like to see this fixed. To answer your question, yes, there are reasons for using attributes instead of properties: the former can be referenced in styles.

As a case in point, we have another behavior called Generic that defines a generic attribute on a component mixing in that behavior. The intention of the Generic behavior is to allow the construction of styles that can easily be added/removed by setting/clearing that generic attribute. A component mixing in this attribute might very well want to set this attribute on initialization, and hostAttributes seems like the clearest and most efficient place to do that.

Thanks for bearing with me-- glad you're unblocked. Understanding the use case and available workarounds helps set priority. We took a quick look today and it is related to differences in polyfill timing of attributeChanged when nested inside createdCallback -- the fix will likely be in the polyfill.

Filed webcomponents/webcomponentsjs#325 on webcomponents.js.

The issue can probably be worked around by reordering _marshalHostAttributes and _marshalInstanceEffects in _initFeatures for the short-term.

Thanks for the update.