Integrate callback invocation with IDL #186
Labels
Comments
|
Also see the issue #225. |
annevk
changed the title
|
So, I started on this in a branch: https://rawgit.com/w3c/webcomponents/ce-reactions-idl/spec/custom/index.html#web-idl-customelementreactions (the list of integrations is rather incomplete) Please read the "NOTE" about why we're doing this to make sure I haven't misinterpreted. Here are some problems I foresee, after spending about an hour going through all of Blink's annotations:
I kind of want to give up and go back to the "every attribute and every property do this; optimize away unnecessary cases" idea. Are we sure that explicitly annotating everything is the right move? |
Presumably these operations are (will be, more likely, if ever) defined as running these as part of some kind of task. So perhaps the microtask checkpoint also needs to run element callbacks if they haven't been run yet? As for the rest, IDL needs to be changed to account for this. Whether we enumerate the places for which it matters or leave that up to implementations is less important, but it seems that if everyone needs to do that work anyway, it might help if we did it for everyone. |
It's not that simple. You need to push an element queue on when the operation starts, and pop it when it stops. I guess we could push one on at the start of every task, and pop at the end? @dglazkov, @esprehn, do you know how Blink handles this with regard to editing operations?
Why, and how, would we change IDL if we don't enumerate the places that need the extended attribute? Do you have thoughts about how to handle reflection, and how to handle the things that don't have a spec? |
|
We'd just do it for everything (which will result in a no-op mostly, since no callbacks will have been queued). Changing IDL makes it much more clear where in the flow of code this happens, which will be in IDL in all implementations. Things that don't have a spec will need to be defined, since it's unclear how they work anyway, with or without this feature. |
|
Ah, I see, so you're saying change the definition of IDL attributes and operations to include these before/after steps in all of them, instead of having the monkeypatch be in HTML. OK, that's certainly doable and reasonable. I'm going to tag this "needs consensus" since if we have time I'd like to discuss it on the telecon today. It seems largely a question of what implementers would prefer, since from a spec side, doing it everywhere is equivalent to annotating everything individually. We'll need to solve the editing operations issues separately of course. |
|
FWIW, editing operations was the other reason for base element queue, I guess 😄 |
|
Now you tell me 👿 Seems like editing spec needs a monkeypatch too... ick. |
|
👀 |
|
Telecon implementer feedback: everyone wants me to patch all the specs with [CustomElementReactions]. Will do. |
|
Documenting my progress: gives I've also noticed a few missing ones so far which I am tracking separately and will report on when I have a comprehensive list. |
domenic
added a commit
to whatwg/html
that referenced
this issue
Apr 18, 2016
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.
|
OK, I went through HTML and found all the places that need to be annotated in whatwg/html#1069. Looking at the above printout of Blink's IDL files, I see the following left on the hitlist:
Regarding SVG and MathML: we don't allow SVG/MathML elements to be custom, but I think they can still affect the world in interesting ways. For example, if there are setters that allow you to clear out the contents of an element (like the many |
|
If we added |
domenic
added a commit
to whatwg/html
that referenced
this issue
Apr 19, 2016
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.
domenic
added a commit
to whatwg/html
that referenced
this issue
Apr 19, 2016
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.
domenic
added a commit
to whatwg/html
that referenced
this issue
Apr 19, 2016
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.
annevk
pushed a commit
to whatwg/html
that referenced
this issue
Apr 20, 2016
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] added here.
|
@esprehn yeah, I plan to add [Reflect] later, which will in many cases supercede the need for [CEReactions]. But I didn't want to block this work on figuring out [Reflect] (which is fairly complicated). |
domenic
added a commit
to whatwg/dom
that referenced
this issue
Apr 20, 2016
Part of WICG/webcomponents#186, and using whatwg/html@27aa7bc. Depends on a fix for speced/bikeshed#677 to get proper linking to the definition of CEReactions.
This was referenced Apr 20, 2016
domenic
added a commit
to domenic/DOM-Parsing
that referenced
this issue
Apr 20, 2016
This is part of the effort in WICG/webcomponents#186 to annotate all parts of the platform that cause DOM mutations and thus need to set up state for custom element reactions. [CEReactions] is defined in https://html.spec.whatwg.org/multipage/scripting.html#cereactions. Also normalizes whitespace to spaces instead of a mix of spaces and tabs.
domenic
added a commit
to domenic/mediacapture-main
that referenced
this issue
Apr 20, 2016
Since the allowUserMedia attribute can change the DOM in ways that may impact custom elements, it needs to be annotated with the [CEReactions] attribute. This is part of the larger effort at WICG/webcomponents#186. [CEReactions] is defined in https://html.spec.whatwg.org/multipage/scripting.html#cereactions.
domenic
added a commit
to domenic/html-media-capture
that referenced
this issue
Apr 20, 2016
Since the capture attribute can change the DOM in ways that may impact custom elements, it needs to be annotated with the [CEReactions] attribute. This is part of the larger effort at WICG/webcomponents#186. [CEReactions] is defined in https://html.spec.whatwg.org/multipage/scripting.html#cereactions.
domenic
added a commit
to domenic/DOM-Parsing
that referenced
this issue
Apr 20, 2016
This is part of the effort in WICG/webcomponents#186 to annotate all parts of the platform that cause DOM mutations and thus need to set up state for custom element reactions. [CEReactions] is defined in https://html.spec.whatwg.org/multipage/scripting.html#cereactions. Also normalizes whitespace to spaces instead of a mix of spaces and tabs.
This was referenced Apr 20, 2016
domenic
added a commit
to domenic/remote-playback
that referenced
this issue
Apr 20, 2016
Since the disableRemotePlayback attribute can change the DOM in ways that may impact custom elements, it needs to be annotated with the [CEReactions] attribute. This is part of the larger effort at WICG/webcomponents#186. [CEReactions] is defined in https://html.spec.whatwg.org/multipage/scripting.html#cereactions.
domenic
added a commit
to domenic/selection-api
that referenced
this issue
Apr 20, 2016
Since the deleteFromDocument() method can change the DOM in ways that may impact custom elements, it needs to be annotated with the [CEReactions] attribute. This is part of the larger effort at WICG/webcomponents#186. [CEReactions] is defined in https://html.spec.whatwg.org/multipage/scripting.html#cereactions.
This was referenced Apr 20, 2016
annevk
pushed a commit
to whatwg/dom
that referenced
this issue
Apr 21, 2016
Part of WICG/webcomponents#186, and furthering whatwg/html@27aa7bc. Linking [CEREactions] will happen once speced/bikeshed#677 is fixed.
|
Is there any issue against the WebIDL spec for this yet? |
|
@sideshowbarker the current idea is to just define it in HTML directly. IDL might want to mention specifications can do that of course. |
tabatkins
added a commit
to tabatkins/dom
that referenced
this issue
Apr 28, 2016
* Add more legacy event types for createEvent() Approximately as requested at https://bugzilla.mozilla.org/show_bug.cgi?id=1251198#c7. This is the list of events supported in createEvent() by at least two of Firefox, Chrome, and IE 11. The one exception is I omitted MutationEvent, which all three support, because apparently spec-land has decided to deny its existence in the hope that it will go away. Bikeshed does not know about all of the added interface names, hopefully that will sort itself out over time. * Meta: improve pull request instructions for DOM See whatwg/fetch#276 for context. * Enable an event listener to be invoked just once * Editorial: web compatibility typically remains relevant Fixes whatwg#210. * Shadow: define attachShadow() for custom elements * Meta: make it easier to reference participate in a tree PR: whatwg#216 * Define node document for new Text nodes Fixes whatwg#224 and part of whatwg#212. Also fix part of whatwg#209 by stating these algorithms can rethrow exceptions. * Use a single concept for attribute changes This setup is still a little sketchy I think, but not more so than the insertion and removing steps. * SVGEvent is only Gecko, Blink also has SVGEvents As pointed out by zcorpan in whatwg#227. * Set createDocument()'s content type based on namespace Fixes whatwg#217. PR: whatwg#218 * Make document.createEvent("touchevent") sometimes throw Browsers typically disable touch events on non-touch devices, and there exists web content that detects this difference using document.createEvent(). Fixes whatwg#227. * Shadow: define slotchange event Shadow: define slotchange event Fixes WICG/webcomponents#288. This defines the slotchange event in response to remove/insert operations, changes to a slot’s name attribute, and changes to an element’s slot attribute. This also introduces the assigned nodes concept for slots, and assigned slot concept for slotables. Slotables now also have a name, rather than a “get name”. The slotchange event dispatches just after mutation observers have their callbacks invoked. The slotchange event is not yet marked scoped as scoped events are not yet defined in the DOM Standard. Note: although the original issue did not mention it, this also suppresses signaling when slots are removed from a tree. Not just when they are inserted. * Editorial: update custom element cross-spec references * Editorial: fix a few cross-linking missteps * Editorial: make "is" and "prefix" optional in "create an element" * Use "create an element" in createHTMLDocument Takes care of part of whatwg#212. * Editorial: align exception language with IDL * Editorial: introduce more shadow-including terms for CSS Fixes whatwg#225. * Editorial: distributed -> flattened * Meta: export more terms Fixes whatwg#233. * Editorial: add "shadow host" and "assigned" as terms This makes a couple of non-null checks read better and enshrines a term we had already been using. * Editorial: flip non-null/otherwise conditions PR: whatwg#234 * Shadow: <slot> is now defined in HTML * Remove passive as event listener key This changes makes passive no longer contribute to the uniqueness of an event listener. It therefore also no longer needs to be supported as part of removeEventListener(). Fixes WICG/EventListenerOptions#27. PR: whatwg#236 * Meta: point out event's timeStamp is likely to change See whatwg#23 for details. * Add [CEReactions] annotations to mutating methods Part of WICG/webcomponents#186, and furthering whatwg/html@27aa7bc. Linking [CEREactions] will happen once speced/bikeshed#677 is fixed. * Editorial: check stop propagation flag at start of invoke * Editorial: deduplicate Veli Şenol * Editorial: define defaults for EventListenerOptions Although this is also done in prose, this nonetheless simplifies the prose a bit and makes it clearer to those skimming the standard what is going on (although skimming is not recommended). Fixes whatwg#239. * Meta: link to Japanese translation See triple-underscore/triple-underscore.github.io#1 for more details.
igrigorik
added a commit
to w3c/preload
that referenced
this issue
Apr 29, 2016
Since the as attribute can change the DOM in ways that may impact custom elements, it needs to be annotated with the [CEReactions] attribute. This is part of the larger effort at WICG/webcomponents#186. [CEReactions] is defined in https://html.spec.whatwg.org/multipage/scripting.html#cereactions. Credit to @domenic. Closes #63
domenic
added a commit
to whatwg/html
that referenced
this issue
Jun 9, 2016
As discussed in WICG/webcomponents#186, there are certain scenarios where custom element reactions could be enqueued, but the custom element reactions stack is empty. The most prominent of these is editing operations. We solve this issue in two parts: - First, introduce the backup element queue (similar to the old "base element queue" concept; see WICG/webcomponents#457). This takes care of cases like editing which cannot be solved in any other way. - Also, we mandate that [CEReactions] be applied to nonstandard APIs that modify the DOM, including a list of what we've identified so far. Closes WICG/webcomponents#186.
This was referenced Jun 9, 2016
domenic
added a commit
to whatwg/html
that referenced
this issue
Jun 29, 2016
As discussed in WICG/webcomponents#186, there are certain scenarios where custom element reactions could be enqueued, but the custom element reactions stack is empty. The most prominent of these is editing operations. We solve this issue in two parts: - First, introduce the backup element queue (similar to the old "base element queue" concept; see WICG/webcomponents#457). This takes care of cases like editing which cannot be solved in any other way. - Also, we mandate that [CEReactions] be applied to nonstandard APIs that modify the DOM, including a list of what we've identified so far. Closes WICG/webcomponents#186.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Title: [Custom]: make callbacks more explicit (bugzilla: 24579)
Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579
comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579#c0
Anne wrote on 2014-02-07 11:00:05 +0000.
"Any time a script calls a method, reads or sets a property that is implemented by the user agent, the following actions must occur: "
This needs to become part of the actual algorithms such as innerHTML, cloneNode(), etc. The easiest way to do that is tying it to IDL I think just as is done in the Chrome implementation.
I recommend working with heycam on doing that per my outline in http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0142.html as that makes it much more explicit when everything happens relative to each other.
comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579#c1
Anne wrote on 2014-02-07 11:01:53 +0000.
Note that we also need this mechanism for callbacks implemented by the user agent. E.g. when adoption happens we want to queue a callback that runs before the method that caused the adoption to return and mangles prototypes.
comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579#c2
Dimitri Glazkov wrote on 2014-05-09 20:32:46 +0000.
I was just reading up on extended attributes: http://heycam.github.io/webidl/#idl-extended-attributes.
A simple ExtendedAttributeNoArgs thingy should suffice in this case -- something like [InvokesCustomElementCallbacks] or [ProcessesCustomElementCallbacks] or [ElementCallbackBarrier]?
Heycam, should I just write this down in custom elements spec, or should it be part of Web IDL spec, like ES-specific attributes: http://heycam.github.io/webidl/#es-extended-attributes?
comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579#c3
Dimitri Glazkov wrote on 2014-10-27 17:34:02 +0000.
*** Bug 27179 has been marked as a duplicate of this bug. ***
comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579#c4
Anne wrote on 2014-10-27 17:42:42 +0000.
(Currently Web IDL offers no way for other specifications to define extended attributes.)
The text was updated successfully, but these errors were encountered: