attributeChangedCallback may be expensive for some attributes

[dominiccooney]

Implementer feedback: In Blink, the "style" attribute is serialized lazily so that a code block like:

 elem.style.color = 'red';
 elem.style.textDecoration = 'underline';
 elem.style.fontWeight = 'bold';

only generates one serialization of the properties. This is because realizing the string could be expensive. With Custom Elements, you would reasonably expect this to generate three attributeChangedCallback invocations with three serializations of the string.

There are a lot of design alternatives that would avoid this, with various trade-offs. For example, the UA could be permitted to dispatch those callbacks later and coalesce them; the API could let authors specify specific attributes to watch; the attributeChangedCallback could be supplied with only the attribute name and make the author responsible to poll the attribute; etc. (Some of these options have been discussed in the past in other contexts.)

[domenic]

Gut reaction: I like both the "supply only the attribute name" and "supply a list of attributes to watch" ideas.

[annevk]

This is why mutation observers have several configuration options for attributes: https://dom.spec.whatwg.org/#dictdef-mutationobserverinit. attributeFilter and attributeOldValue. We should probably copy that in some way.

[WebReflection]

only generates one serialization of the properties

if the purpose is to be able to understand old and new value, why wouldn't that be notified only once, after such serialization happens?

I personally think it would be way more useful to receive one style changed notification instead of N times per each single change, for the very same reason it's useful in Blink ( less operations per time, snappier, happy UI and developers )

... or ... is the problem that each of those should trigger different event? what would be the attribute name then, if not just style ?

[hayatoito]

Let's merge this issue to #367