Re: [w3c/webcomponents] Why can't the registry enumerate the custom elements? (#775)

> Invisibility-by-default is a user-hostile paradigm. I could ask, what problem are we trying to prevent by hiding them? After all, in JavaScript it takes more effort to hide something than to expose it. As this is a design decision, it should be stated somewhere.

We're not hiding anything. Making the list of custom elements enumerable is a new API surface we need to add. Like any other feature, then, I'd like to understand why such a new API surface is needed because in some cases the API you want is the best API we should be providing.

Every new API we add to the Web platform has a cost. I don't actually agree with your point that there is any material benefit in hiding event listeners on a given event target. However, for the sake of the discussion, let's say it is beneficial. If, as you're arguing here, followed the principle of being not *user-hostile* as you defined, and allowed the enumeration of the event listeners without realizing the benefit you've just mentioned (again, which I don't really agree to but that's beside the point), then we would not have been able to hide event listener after the fact short of adding a new non-enumerable event listener type.

This is why, in general, the burden of proof of adding any infinitesimally small API surface is on the party who is proposing to add it.

> Since the user might not know all of the new components that have been loaded in a given context, enumeration of the registry would be the most direct way to make their availability known.

I'm failing to see how can some script on a website can dynamically detect an existence of an element of which it has no idea, and make use of it. What is a concrete scenario that makes such a thing useful?

A use case of a new API is a concrete scenario in which some need for a new capability comes up. For example, the following is a use case for the shadow DOM:
> I want to build a custom flight date picker. This picker can be used multiple times within a given page, and may appear in many different pages across variety of websites. The websites which sues this picker should be able to use this picker, receive the events when the user picks a certain date range. The date picker shouldn't affect the styles of other elements in a given document, nor should it be affected by style rules in the document. Finally, the internal implementation details of such a date picker should be encapsulated; meaning that it shouldn't easily discoverable & manipulative by scripts in a given document via `querySelector`, 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/775#issuecomment-443365430