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

> if we want new XElement() to continue to work, I can't see how we'd be able to turn on access to the thing only inside constructors.

I think I'm fine with that. Let's not bend backward for this feature, and keep the `new XElement()` intact.

> to prevent non-ce-authors from using it perfectly

I agree with @tkent-google, it should be fine, just like it is fine for attachShadow. It you claim it during the construction process, no one else can claim it after that.

> Opt-in sounds a good idea. Adding a flag to ElementDefinitionOptions would be an easy way.

@tkent-google no, it is not. In many cases, an author produces a component, and the consumer of that component is responsible for registering, and decide what tagName to use. This model works pretty well for us today, and having to have a coordination between the registerer and the author is going to be pretty bad. The static field as the opt-in described by @rniwa is more realistic since it is described by the author.

> I guess `element.attachElementInternal()` which would throw on a second invocation would be fine

@rniwa I think that breaks any possibility for multiple classes in your hierarchy to tap into the internals. It is not a deal breaker IMO, but will require some coordination by the subclass to wrap the call to `attachElementInternal` is it needs access to the internals, but I do agree that this is probably our best option so far.


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