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

>>> I think the comparison with AppKit/UIKit and the WebKits is misleading. Since the AppKit/UIKit components are the lowest-level UI components (and the lowest-level, well-specified, reliable API to these components), the comparison should be with UA's native elements.
>>
>> We can agree to disagree on this point, and say this is a difference in our opinions.
>
> Since this is your basis for disagreeing with the proposal, I struggle to let it go. Could you clarify how the AppKit or UIKit components are comparable to custom elements with closed shadow roots in ways they are not comparable to UA native elements?

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

> > Also, social networks have incentives to make their widgets not customizable for branding purposes. Allowing random websites to allow changing the color of the buttons, etc... would be detrimental to their branding & marketing effort for example.
>
> Web standards are not the place to enforce trademarks, nor licensing arrangements or other branding concerns. These also don't preclude under-specification in other aspects.

Right, but 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.

> > This whole argument hinges on the existence of such a convincing use case in which developers try to access and mutate shadow tree, yet nobody has given one so the premise of the statement has not been well established.
>
> In my opinion, several were given in the original issue.

Again, we can agree to disagree on this. Since if we had accepted your use cases or you had accepted that there were no good use cases, then we wouldn't be having this conversation in the first place.

> Nonetheless: a great many websites monitor the actions a user takes, in order to calculate what made their interactions successful/failures. If these analytics record in insufficient detail -- or even fail to record -- actions in shadow DOMs, then document authors are measurably damaged by shadow DOMs, and have a convincing use case for inspecting both them and the user's interactions with them.

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.

By the way, that's a much better use case than polyfills or anything else presented thus far if it were true that you couldn't observe mouse and keyboard events that happen within a shadow tree. But that isn't. We specifically made mouse, keyboard, and other kinds of events that stem from user interaction composed so that web pages can observe them.

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