Re: [w3c/webcomponents] Alternative proposal for closed shadow DOM (#499)

> we have never been able to do what we wanted on the page,
internals of user-agent own elements have always been hidden from us, no
difference here.

@BronislavKlucka As I mentioned above, the problem is that the resulting API will be unstandardised. If the component is incomplete/doesn't satisfy your requirements, you have to modify the code for it (if the licence allows you to) or write your own from scratch. With user-agent elements, the implementations are generally pretty complete (notable exceptions include selection API for some newer `<input>` elements, etc.).

For example, if a closed shadow DOM forgets to register an API for `addEventListener("input", ...)` and your application depends on it, I think it's a bad thing to try and stop you from working around it, even if it may cause breakage later.

> I wander... have you protested on WeakMaps or Symbols at TC39? Those
allow to create privates for plain ES... Where is any difference?

This is the DOM, not application logic. What we're talking about here is carving off **parts of the user interface** that the developer isn't allowed to affect. You're being made to hand over end-to-end control of user interaction and experience with parts of your application. In my opinion, this is worlds away from hiding members of behind-the-scenes libraries in an abstract object, and is not something to be desired.

> This simply creates a contract, contract between
a author and all developers using this component (not just the one who
want to screw it), it creates contact among different components on the
page, what they can or cannot do to each other.

Why must it be the developers of the component that get to enforce the contract? The component exists in a vacuum without the applications that include them, and keeping or breaking the contract only breaks that application. It seems clear to me that the application developer should be the one who has control over how stable/unstable, broken/unbroken and functionality-rich/-poor their application is.

The component is *not* more important than the application; it should be subservient to it. We seem to be rushing to forget that.

> if you ever find yourself relying on the internal DOM of
Shadow, either it's poorly written or you are using wrong component.

I completely agree. Problem is, "closed" looks like a big ribbon to wrap around your component when you decide that it's done.

You can quite happily write a component once, to a spec that fulfils your needs, and consider your project complete. You think, because you've matched your spec, that nobody will need to get inside it. Anyway, they might break it, and you might look bad if they do. So you tie it up with the nice "closed" ribbon and send it out into the world. It might be great at what it does, end up well-tested from widespread use, and work as intended. But you've made the decision for developers using your component that it is complete, regardless of whether it does what they're actually trying to use it for. This is not the decision you should have made, and you've stripped developers of opportunities for no good reason.

A more complex point is bundling. Say you've created the best spreadsheet web component ever, and you'd like to heavily brand it, or to advertise within it. By making it a "closed" web component, you're telling the application developer that they have no choice in this -- that they **must**  allow you to show their users these in your application, regardless of whether they disagree. I want it to be that the application developer retains final creative control, whether the web component developer likes their decisions or not.

---
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/499#issuecomment-218895255