-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should clarify the "scope" of [CEReactions] #2362
Comments
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? |
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.) |
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. |
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!) |
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. |
PutForwards needs it, right? E.g. |
Yes, but that will be handled by the [CEReactions] on the DOMTokenList "value" attribute, no? |
Oh, and I guess this does mean we need to define things for writable attributes, not just operations, right. |
Ah, I didn't realize PutForwards actually did a Get() + Set(). Yeah, in that case I guess it is redundant. |
This fixes #2362, by: * Making it clearer that the steps inserted by [CEReactions] apply before/after what Web IDL calls "the actions listed in the description of" a given construct. * Removing [CEReactions] from [PutForwards]-decorated readonly attributes, as it is redundant there.
This fixes #2362, by: * Making it clearer that the steps inserted by [CEReactions] apply before/after what Web IDL calls "the actions listed in the description of" a given construct. * Removing [CEReactions] from [PutForwards]-decorated readonly attributes, as it is redundant there.
This fixes whatwg#2362, by: * Making it clearer that the steps inserted by [CEReactions] apply before/after what Web IDL calls "the actions listed in the description of" a given construct. * Removing [CEReactions] from [PutForwards]-decorated readonly attributes, as it is redundant there.
Consider an API like this:
A call to
foo
would normally consist of two things:long
.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
The text was updated successfully, but these errors were encountered: