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

@rniwa @annevk can you say why you are OK with `attachShadow({ mode: 'closed' })` being called without the knowledge of the custom element itself, but not OK with the same for `attachInternals()`?

The reasons I think `needsInternals` is subpar are:

- It adds more surface area to obsolete in a decorator-friendly future. In that future (and I don't share @littledan's optimism on the timeline, but it may indeed happen eventually), we could straightforwardly explain `@HTMLElement.internals` as sugar on top of `attachInternals()`. But explaining its interactions with a two-API feature is harder. E.g. what happens if you use `@HTMLElement.internals` + `needsInternals` together, or a base class uses one but not the other.
- To make it tamper-proof we have to move it to `customElements.define()`, or do a custom prototype walk that checks own properties until it hits a built-in element prototype. The former option conflicts with @caridy's desire to separate class definition from registration, and the latter option is really weird and unprecedented in both JS and web specs. On the other hand, if we don't make it tamper-proof, it doesn't have any real benefits. Which leads me to just omitting it.

I think there is consensus/agreement on how protected state is done in TC39; it's not built in to the language, but decorators provide a powerful enough mechanism to enable patterns like `protected`, `friend`, .NET-style `internal`, etc.

-- 
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-437040070