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?

>> We don't and can't expect to hold non-UA component developers to the same standards as UA component developers, so it's hard to justify giving them the same carte blanche.
>
> Why not?

In theory? There are a long tail of developers where we might expect consistency and competence to degrade. In practise? Experience.

> We already live in that world. If some social network only provides their social engagement widget in HTTP, for example, there is nothing you can do to make them use HTTPS instead.

Sure. That's bad. I'm even less inclined to surrender them complete control over parts of the DOM on this basis.

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

> Again, this should really be left to each social network site to decide. If one doesn't like the default UI provided by a social network, once could either not put their widget or use a hyperlink with a custom UI, etc...

Only if such a hyperlink exists. Otherwise, I think 'put up and shut up' is a fair appraisal.

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

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.

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