Re: [w3c/webcomponents] How to define APIs only for custom element authors (#758)

So, reporting back from the TC39 thread in a bit more detail. A few takeaways:

- There may be an elegant future solution with decorators. However, decorators are a "stage 2" feature and move very slowly through the standards process; indeed at stage 2 it's unclear whether they will be implemented at all. So we should proceed with an interim solution, and in some years maybe decorators will be available and we can consider that. We should not take on a dependency.
- At the same time, we may want to contemplate whether there are features of our interim solution that we could tweak to make it more upgradeable to a decorator future.
- TC39 provided some useful feedback on our existing solution at https://github.com/tc39/ecma262/issues/1341#issuecomment-435492456 which I think we should take into account. In particular it seems like subclassing does not work well with our existing solution, so the needsInternals placement on the class instead of as an option to customElements.define() is a bit questionable now.
- Again about subclassing, there was the insight that basically if you want subclassing to work, you're going to lose the protection of disallowing arbitrary consumers from attaching ElementInternals. This insight emerged in https://github.com/tc39/ecma262/issues/1341#issuecomment-435519499.

Taking all this advice in to account, my proposed solution is that we go with `attachInternals()` but no `needsInternals`. Thus, `attachInternals()` becomes similar to the (closed) shadow DOM model:

- It's somewhat "uncoupled" from custom elements. The main coupling is that we restrict it to only be callable on custom element instances, just like `attachShadow({ mode: 'closed' })` is only callable on custom elements + a safelist of elements.
- If a custom element doesn't call `attachShadow({ mode: 'closed' })`/`attachInternals()` in its constructor, then any consumer of that element can call the method and start messing with the element's shadow tree/internals. Oh well.
- If a custom element does call `attachShadow({ mode: 'closed' })`/`attachInternals()` in its constructor, then subclasses are screwed. (I.e., they need to coordinate with their superclass if they want access to the shadow root/internals.)

This also has the benefit of only adding one API, so that in some glorious decorators future, we can explain the decorator as sugar over one old API, instead of two, and we don't have to worry about interactions (e.g. what if someone uses the decorator + needsInternals?).

What do folks think?
 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/758#issuecomment-436676008