Custom elements pre-F2F thoughts

Hi all,
 
In preparation for the meeting Monday, Google wanted to provide our thoughts on the issues at hand. We think the agenda is pretty well captured by https://github.com/w3c/webcomponents/wiki/Custom-Elements:-Contentious-Bits so I'll go through each of the issues there in turn.
 
## Previously contentious bits
 
### Constructor vs. createdCallback
 
We are happy to move ahead with the constructor idea
 
### Symbol-named properties for lifecycle hooks
 
We are happy to do symbol-named properties for the lifecycle hooks (whatever they end up being)
 
### Calling attributeChanged for all attributes on creation
 
We are happy to do this, but note that it impacts the issue around style="" attribute spam (see below)
 
## Contentious bits
 
### The general timing of lifecycle hooks
 
We still feel very strongly that synchronously calling lifecycle hooks is not an option. "Nanotask" timing (i.e., right before returning to author code) is much preferable to us. This avoids a whole class of correctness and security bugs that we have spent years stamping out as fallout from mutation events and other problematic parts of the platform; indeed, we hope to attempt moving mutation events to nanotask timing, as Gecko has (sort of) done.
 
We hope this isn't too controversial, as from an author-facing perspective the behaviors are almost always the same modulo the behavior during complicated composite algorithms like cloning, editing, and assigning innerHTML. And it's not even clear authors benefit in those cases from synchronous timing over nanotask.
 
In short, this is our one "cannot live with" issue (in Chaals's hand-raising game).
 
### The specific timing of the constructor, and the consistent world view issue
 
Our understanding is that there is tentative agreement on how to address these issues, with two cases being potentially controversial:
 
1. Elements which are upgraded will be able to see all their children and attributes inside their constructor. Last meeting there was talk of figuring out some impressive tricks that could be done to fix this (remove all the attributes/children, run constructor, move them back, all the while suppressing the normal behaviors that come along with such removal/addition). Since then we haven't really seen any progress on that approach, and we'd rather not block further progress on custom elements on figuring out something like that. So it seems like upgrades should probably just stay with the children-present, attributes-present world view.
 
2. Elements which are created via the parser. These could be specced in either direction. Although our initial impulse was to have the constructor called once all attributes and children are present, we understand the argument that this will make it too easy for authors to write constructors that depend on the presence of children/attributes, and are sympathetic. So we are prepared to accept suspending the parser after encountering the open tag, and running the constructor then, before then adding attributes (and calling attributeChanged), and then going on to add children.
 
### Attached/detached vs. inserted/removed hooks
 
After some discussion, we came to the conclusion that both hooks are valuable, and propose that the spec include both of them. The low-level inserted/removed hooks map to current engines' internals, and can be useful for implementing behaviors similar to certain native HTML elements. The higher-level attached/detached hooks serve as optimized fast-paths for components which care about that particular type of insertion/removal, which based on the experience of framework authors is quite common. We hope this makes everyone happy :)
 
## Other things to work out
 
### registerElement or something new?
 
We do not have an opinion on how to spell the API and are happy to change the name to help compatibility.
 
### A solution for the style="" attribute spamming
 
This is a somewhat crucial issue (it's a big hole in the existing spec). After considering the alternatives, we think the first two are the most viable: either push attributeChanged to v2 entirely, relying on mutation observers in the meantime, or provide a (mandatory) attributeFilter which custom elements use to say which attributes they care about.
 
## Other issues worth mentioning
 
### Should we consider adding a childrenChanged callback?
 
Upon reflection, we are not OK with this idea in its most naïve form. We are concerned about cases like appending tens or hundreds of children, which (if this uses nanotask timing like other callbacks) would generate tens or hundreds of children changed notifications. We are open to exploring a better form of this in the future, and are especially optimistic about evolving mutation observers to be more useful in this regard, but some form of batching is necessary for this. It's basically the attributeChanged problem, but much worse.
 
### What is the fate of is=""?
 
We recognize there has not been much appetite for is="" from other vendors, but are concerned about the important use cases that are being left on the table by omitting it. Additionally, some sites have seen significant performance advantages using is="" instead of a wrapper (in Chrome), and we are hoping that we could bring these advantages to the standard. We wonder if the feature could be salvaged by only pushing for supporting it on a whitelist of elements, similar to shadow DOM. For example, only allowing <template is=""> and maybe <a is="">.
 
 
Thanks all! Looking forward to seeing you Monday, and getting this all hashed out.
 
-Domenic

Received on Saturday, 23 January 2016 00:31:37 UTC