Re: [w3c/webcomponents] Generic programs can't reliably use/manipulate documents via the DOM (#640)

> Perhaps you are proposing that we should remove the `<video>` element, since "parties that are supposed to enforce the policy [of video copyright] doesn't have an incentive to do so";
the `<img>` element, since "parties that are supposed to enforce the policy [of image copyright] doesn't have an incentive to do so";
> and DOM text APIs, since "parties that are supposed to enforce the policy [of literary copyright] doesn't have an incentive to do so".
> I am not an advocate of this position.

That's not all all what I'm saying. The point you were making is that with closed shadow trees, it's hard to modify components made by social networks. I'm saying that given they have incentives not to let this happen, they can already make this hard e.g. by using a cross origin iframe. They can also add a licensing terms which prohibits you from messing with their UI, etc... So your argument that closed shadow tree makes it harder for third party page authors to customize those social widgets isn't convincing given that social networks can already circumvent this, and even in the presence of shadow trees, page authors can still use a hyperlink or simply override `Element.prototype.attachShadow` before those social widgets are loaded as the last resort.

> > Why? Regardless of the mode, mouse and keyboard events that got dispatched inside a shadow tree will propagate outside the shadow tree unless they're stopped to propagate.
>
> If the component has any kind of complex state and/or user-specific variation, it can become extremely hard to reverse engineer what these meant originally. This seems like a waste, when the information could have all been there to start with.

That's precisely what encapsulation should hide. Those semantics should be communicated via ARIA attributes, slotted contents, public methods, etc... of custom elements.

>> By the way, that's a much better use case than polyfills or anything else presented thus far ...
>
> I still maintain that a page should be able to provide keyboard shortcuts without munging user input into components' inputs.

And I would disagree to that position.

-- 
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/640#issuecomment-302592133