I forgot to say: these are attributes which, in Blink, have *neither* [CustomElementCallbacks] *nor* [Reflect].

Last time I looked at this, I discovered a list much like this empirically by adding an 'else' branch to the bindings which asserted that when there's no CallbackDeliveryScope, absolutely no callbacks could be queued and hooking the points which insert into the queue to trigger the assertion. Let me see if I can dig that patch up...

Let me jot down some thoughts I've had rattling around:

- Back in the day there was pushback about this attribute because we worried it would be slow. I actually think it is fast--it just reads a static and branches--so we could measure the cost. I think this is probably fast enough to just do everywhere as part of the bindings. We could use an attribute to turn it off if there's something truly performance critical.

- If we don't do that, we should commit the 'else' branch and assertion that nothing is queued to the product so we never miss another one of these.

- Speaking of performance, esprehn has some concerns about style serialization; see  Issue 492176 . Mutation Events can kind of let you work around this because you can say you don't need the serialized values and do it lazily; Custom Elements do it eagerly. Serializing 'style' is expensive. Rock, meet hard place. You could fix this at the spec level by having Custom Elements say which attributes they want to watch and whether they need old and/or new values. It's a much more complicated interface though.

- One more catch: If any of these CustomElementCallbacks bindings can be touched in a worker, disaster will ensue because of that static. You don't want workers to clobber it. I think this could happen in practice with some mixin interface on URL parts, which sometimes updates an attribute of a LINK element or something but is also used in a worker for something entirely different, but it doesn't today because that's *another* one of these interfaces that is missing CustomElementCallbacks.

/end brain dump

We should make the mutation points assert if there's no delivery scope and there's script on the stack. Ex. Element::setAttribute should have a DCHECK. I don't think we want a branch for this in every bindings call. If our bindings were super fast maybe, but until we start winning those benchmarks we should be cautious of any global extra work.

The spec was actually changed to require an explicit attribute filter. We don't notify about attributes you don't ask about in v1.

Think through it carefully: It is valid to have mutations with script on the stack, for example, the HTML parser. So there's always a catch-all on the stack. We already have assertions if we ever tried to pop that.

Good news about the attribute filter.

Re: assertions, we can make that #ifndef NDEBUG. The only point would be to make the assertion for correctness. It is actually safe to be missing these CallbackDeliveryScopes, all that happens is the callbacks run a bit later than they should.

/with script on the stack/without script on the stack/

What do you think about WontFixing this? Because when Custom Elements V1 is implemented, we will deprecate Custom Elements V0. Making it work better probably isn't a top priority?

Well, custom elements v1 still needs [CustomElementCallbacks] (or, as the spec calls it, [CEReactions]). As long as you still intend to implement [CEReactions] everywhere the specs say to do so, that should cover the cases in the OP. Or you could use this bug as a tracking bug for aligning [CustomElementCallbacks] with [CEReactions].

Yes, we still need something for Custom Elements v1. I'm not sure if that should be CustomElementReactions, which gets to the purpose, or ModifiesDOM, which gets to the definition.

I don't think we should expand CustomElementCallbacks to more places; I want carrots for moving to Custom Elements v1, not the other way around. :)