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

> If you have people on your team committing this sort of code and you don't like it, you don't fix that by going to the standards body and asking them to disallow this. You fix it by changing your coding standards and the culture of your team - or voting with your feet.
You misunderstand. The users of the library aren't part of my team, nor under my control. Nor do I, or any of my immediate colleagues oversee the work they do.  In many cases they're external clients and have only a basic knowledge of web technologies. These are the ones I'd like to protect from themselves.  Considering that the API is used in ads and a single client could have many (_many_) creatives with copy/pasted code, I think it's a valid concern.  Frequent backwards incompatible releases would adversely impact our support channels and require us to maintain several versions of the product simultaneously.

> If it is a closed source component that has a closed flag and I cannot do that, then my only options are to switch your component out, write an entirely new component or do without the calendar picker feature.

For custom elements using `shadowRoot`, you could easily subclass and prevent the super constructor from attaching a closed shadow root: 

```javascript
class YourElement extends MyElement {
    attachShadow(o) {
        o.mode = 'open';
        Element.prototype.attachShadow.call(this, o);
    }
}
customElements.define('my-element', YourElement);
```

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