I was in San Francisco two weeks ago. Always fun to see friends and complain about how poorly Caltrain compares to trains in most civilized countries. Custom elements day was at Apple where you cannot reasonably get to via public transport from San Francisco. The “express” Caltrain to Mountain View and a surged Uber is your best bet. On the way back you can count on Ryosuke, who knows exactly how much gas is in his car well after the meter indicates it’s depleted.
While there are still details to be sorted with both custom elements and shadow DOM, we have made major headway since last time. Getting cross-browser agreement on the contentious issues:
If a custom element definition has been registered, the parser will synchronously invoke its constructor, similarly to how the parser executes script synchronously upon seeing </script> today, but then for the custom element start tag. Attributes will be added after this, synchronously one-by-one.
Everywhere else “upgrade” semantics will be used. Basically meaning that the browser creates the element, then invokes the constructor and callbacks at a later point. The timing of this was dubbed “nanotasks”, though it does not really involve tasks. It is basically a queue that is emptied just before the browser returns from IDL land (and at some other places).
div.innerHTML = "<sw-rey>...</sw-rey>" // nanotasks happened console.log(div.innerHTML)
For those paying attention, none of this provides a consistent world view throughout. We gave up on that and hope that the combination of the parser doing things synchronously and other contexts not doing that will be enough to get folks to write their components in a way that is resilient to different developer practices.