Should clarify the "scope" of [CEReactions]

[bzbarsky]

Consider an API like this:

[CEReactions]
void foo(long arg);

A call to foo would normally consist of two things:

1. Coercing the first arg to long.
2. Whatever the actual work is that foo does.

Is "the algorithm" for purposes of https://html.spec.whatwg.org/multipage/scripting.html#cereactions both 1 and 2, or just 2? Or does it not matter in practice? I haven't really wrapped my head around the custom element reactions stuff yet to tell whether it matters....

@domenic @annevk

[bzbarsky]

Also, for the [PutForwards] case, is it the entire get-and-set process that's in the "scope" of the [CEReactions]? Or just the set? And what actually defines this?

[annevk]

What the HTML Standard means by "main algorithm" is the bit that specificatiosn define and IDL defers to.

In practice it should not matter if you do it more than required though.

As for the [PutForwards] case, the description of [CEReactions] seems pretty clear that only the setter is affected, not the getter. (Again, if you also did it for the getter, that would not be observable.)

[bzbarsky]

What the HTML Standard means by "main algorithm" is the bit that specificatiosn define and IDL defers to.

OK. This might be good to clarify (ideally via a link or reference to the definition in IDL), because the implementor of this in Gecko didn't interpret it that way.

I'm a little confused by the PutForwards thing, still. Which part of the description makes that clear? Does PutForwards even have a "main algorithm" in the sense of "that specifications define"? It's defined entirely in IDL...

Then again does the [PutForwards] case ever need CEReactions at all? If I'm understanding this stuff correctly, I don't think it does.

[annevk]

Yeah, I think you're right that [PutForwards] doesn't need it. @domenic? (As for IDL formalizing things a bit more, please, been asking about that for a while now!)

[bzbarsky]

OK. Well, if we drop the putforwards thing, then we can define that the work is done around https://heycam.github.io/webidl/#dfn-create-operation-function step 2.1.5, right?

Or alternately and perhaps better, add a clear definition of a term for "the actions listed in the description of operation" to https://heycam.github.io/webidl/#idl-operations and reference it here.

[domenic]

PutForwards needs it, right? E.g. el.classList = "foo bar" needs to fire attributeChanged for the class="" attribute.

[bzbarsky]

Yes, but that will be handled by the [CEReactions] on the DOMTokenList "value" attribute, no?

[bzbarsky]

Oh, and I guess this does mean we need to define things for writable attributes, not just operations, right.

[domenic]

Ah, I didn't realize PutForwards actually did a Get() + Set(). Yeah, in that case I guess it is redundant.