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

I should note that the term "user-hostile" was not aimed specifically at this proposal.  Invisibility-by-default is everywhere, and always has been, with few exceptions (Smalltalk and Emacs come to mind).

I fully understand that "Every new API we add to the Web platform has a cost."  You can use that argument against anything, including this entire proposal, which is extremely costly.  The "shadow dom" alone adds immense complexity to the model and burden to [what implementors remain](https://blog.mozilla.org/blog/2018/12/06/goodbye-edge/).  Just this week [even Microsoft cried uncle](https://blogs.windows.com/windowsexperience/2018/12/06/microsoft-edge-making-the-web-better-through-more-open-source-collaboration/#86hdHmPeOj1Xq32Q.97).

However, I did not ask that anything be added to the API.  I did ask whether or not there is any *specific* rationale for excluding this "infinitesimally small" capability, so that it might be documented, since the API is specifically designed to prevent it. (The registry resembles a `Map` but omits `entries()`).  I provided a code example so that we could be 100% surely talking about the same thing.

Unlike native platforms, the web is positioned to universally empower rather than exploit users.  This is its key to long-term survival.  To understand the motivation for not adding more black boxes, you have to look to the use of browsers as dynamic modeling environments.  Discovery of capabilities is crucial to this potential.  You rightly ask 

> 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

That's exactly the point.  Suppose one component imports a date picker that's better than the native date input.  Other components have no idea that it's available.  Keep in mind that components (being functions) can be extended with metadata annotations describing more fully what they are and what they do.  This can be done by convention with no modification whatsoever to this proposal.  With that, you can make a query like "are any other date pickers available"?  That type of usage—fetching components by the qualities that they possess, rather than their exact identity or location—would open up great potential for a component ecosystem.  As things stand, the registry precludes this prospect (at least locally), since there is nothing to query.

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