-
Notifications
You must be signed in to change notification settings - Fork 55
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
Custom Elements #16
Comments
See also #13. It seems that monkey patching http://dom.spec.whatwg.org/ as done in this specification is very bad. |
There's something going on here around "nanotasks" http://w3c.github.io/webcomponents/spec/custom/#enqueuing-and-invoking-callbacks @annevk had a conversation with @dglazkov in #whatwg about it that may have cleared things up, but I had a hard time following along. It's definitely worth figuring out what's going on there though. |
This line in particular is very worrying:
Since that is pretty much the role of the event loop, and having it superceded by one line of prose seems... bad. |
Well, no. Transitions from UA code to script occur much more frequently. Anytime you call a DOM method, you're leaving script and going into UA code, and back. Here's a simple example:
The user of In the example above, the This type of write barrier will be especially necessary when we try to make DOM self-hosted. There are many places where the UA needs to ensure that the user code doesn't run. The bug with all the gory details: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22459 |
Running callbacks just before you return from a large number of methods and getters that previously did not have that behavior is a new concept. I guess we might need it, but I would like us to be much more clear and explicit about it. |
I would assert that the concept of running callbacks as an effect of executing a method/getter is not new. This happens all the time in JS frameworks. What's new is a mechanism that enables web platform to do this without jeopardizing integrity of DOM operations. I wonder if the right way to define it is as a separate DOM write barrier abstraction that could be used to provide "synchronous on the outside, asynchronous on the inside" semantics. I could give it a shot. WDYT? |
I am having a hard time understanding this; it seems to contradict the earlier description of the situation as simply running some callbacks before returning (which seems like it has nothing to do with asynchronicity). I know it's a lot to ask, but could you provide some JS code samples to explain what exactly is going on here? E.g., if we were to implement this behavior purely in JS, by monkeypatching a bunch of DOM methods, what would that look like? |
Sure. First, the setup:
Now, let's suppose
From the perspective of the HTML parser, the operation is asynchronous -- it only enqueues the callbacks. |
Ah! Thank you, that clears things up immensely. However, I'd encourage you to not use the term "asynchronous" for this, as traditionally in JS we use that to refer to defering something outside of the current event loop tick. This behavior would definitely be called synchronous, at least how we normally use the terms in JS. With that cleared up, I think my concerns reduce to match those of @annevk, namely that the blanket monkey-patching of "when transitioning back from the user agent code to script" is a bit more wishy-washy than we'd hope for. I'll leave it to @annevk as Master of the DOM to say what the best way of addressing that is though, whether via the write-barrier abstraction you mention or something else. |
I think making it explicit in the binding layer (IDL) as I suggested on public-webapps would make the most sense conceptually. |
Discussed at London F2F; needs to be transferred to a bug. @domenic to do. |
Discussed in NYC; dominic following up. |
Found the bug, was filed already https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579 and has recently come up again on public-webapps. |
LC As of http://www.w3.org/TR/2013/WD-custom-elements-20131024/
Edcopy: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html
The text was updated successfully, but these errors were encountered: