Formalize custom element reactions

[domenic]

This executes a large portion of the plan laid out in
WICG/webcomponents#186, by introducing a new
[CEReactions] IDL extended attribute which can be used to indicate that
new steps should be inserted related to custom element reactions. It
replaces the previous handwaving of "every operation and attribute" with
an explicit annotation on every relevant operation, attribute, setter,
and deleter.

There remains work to do to annotate other specifications across the web
platform with this attribute (notably DOM), as well as deal with editing
operations. But all such updates will depend on the definition of
[CEReactions] contained here.

---

Based on top of #1066, so tagging "do not merge yet" until then.

The list of places to annotate was compiled via a multi-stage process:

• Use the list from Blink's source in Integrate callback invocation with IDL WICG/webcomponents#186 (comment) as a base
• While inserting the annotations derived from that list, notice nearby missing annotations which Blink failed to include, and add them. (Blink bug: https://bugs.chromium.org/p/chromium/issues/detail?id=604552)
• Finally, running Array.from(document.querySelectorAll("pre.idl")).map(el => el.textContent).join("\n\n") in the Chrome developer tools with the multipage HTML spec open, then manually checking every IDL block to see if anything was missed. This found a few other Blink omissions, as well as interfaces which Blink does not include at all (like HTMLAppletElement).

I think this should be pretty comprehensive for HTML. I'll update WICG/webcomponents#186 with a list of non-HTML specs that need updating.

Note that there's a slight output stylesheet bug: a <div class="note"> after a <dl> does not have enough space in between them. We should fix standard.css for that, separately.

[annevk]

[TreatNullAs=EmptyString, <span>CEReactions</span>] made me wonder if we should have a canonical order. Any reason you picked this order? (I would have picked the other way around.)

[annevk]

It's a little unclear that this attribute is defined here, while it's monkey patching algorithms defined in IDL. I imagine that just as with HTML monkey patching DOM event dispatch, this will move over time.

[domenic]

Any reason you picked this order?

No reason! I can rearrange if you'd prefer.

It's a little unclear that this attribute is defined here, while it's monkey patching algorithms defined in IDL.

I don't think of it that way. I think of it as monkeypatching algorithms defined here, since that's where the operation/attribute/deleter/setter algorithms themselves are defined.

[annevk]

I'd prefer CEReactions first so you can more easily tell when it's missing. Or perhaps simple alphabetical order which in this case has the same effect.

[domenic]

Rebased and made it first.

[annevk]

attributes should have

must have*

Does <input>.value really affect the DOM? It seems like that should not have an effect. Or valueAsNumber, why is that included?

[domenic]

must have*

Mehhh, it's about vendor-specific attributes being added; we only give "should" guidelines for naming those. But I guess I can see it.

Does <input>.value really affect the DOM? It seems like that should not have an effect.

Looking at https://html.spec.whatwg.org/multipage/forms.html#dom-input-value, it seems that while the value attribute is in the "default" mode, it can affect the DOM. At a glance, this mostly applies to buttonish elements (e.g. <input type="submit">)

Or valueAsNumber, why is that included?

Hmm, yes, valueAsNumber, valueAsDate, valueLow, and valueHigh seem to only affect the internal value slot, not any attributes or contents.

@dominiccooney, @esprehn, @kojiishi, @hayatoito --- do any of you know why Blink has valueAsDate and valueAsNumber annotated with [CustomElementCallbacks]?

[domenic]

@ajklein suggested that it could be because changing that could cause script to run (presumably via some event), which we would want to run custom element reactions after running script.

I am not sure exactly how that could happen right now though. I thought it might be input or change events but those don't trigger for programmatic changes. selectionchange events seem like they should trigger, but in my testing of browsers they don't.

[domenic]

Wait, no, that doesn't make sense. We don't need to run custom element reactions after author script, since author script cannot directly modify the DOM---to do so it must go through existing DOM APIs, which should already be decorated with [CEReactions].

[domenic]

@esprehn says this is probably a copypasta bug in Blink. So, I have pushed another commit removing the annotation for those properties.

[annevk]

LGTM with the change I just pushed.