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

> Because we see web components something akin to views in UIKit and windows in Win32 API. But this is just one perspective and heavily subjective matter so I don't think keep discussing this matter is useful.

More than anything, I'm trying to understand. I can't see how the DOM is deficient (if not better) as compared to its UIKit and Win32 analogues under my proposal.

> At the end of the day, we don't really need to convince one or other; we just need to move the standards forward based on rough consensus.

Great! Hopefully we can move the standards forward towards my proposal. I'll start making efforts to build rough consensus on this.

> we also have to take different parties' incentives into mind. Any feature is not useful if parties that are supposed to enforce the policy doesn't have an incentive to do so.

I'm accustomed to "useful" meaning that things may be used to achieve something productive that wasn't possible/as easy without it.

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.

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

I'll also mentioned nested scrolling elements in passing, to highlight how non-trivial this might be for stateless, user-agnostic components.

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

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