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.

> I'll happily agree with [@dylanb's statement](https://github.com/w3c/webcomponents/issues/640#issuecomment-301070698) that UA elements *should not* expose their shadow DOMs, and by analogy that AppKit/UIKit should not expose their internals, since they are not described in a well-specified, reliably manipulated format. (WebKit is another beast, and an entire browser engine is far removed from a DOM, so any comparisons there are sketchy at best.)
>
> 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?

>> Don't use a badly written component, or a component you don't like. Nobody is forcing you to use a component that you don't like so much that you want to go in & modify its shadow tree.
>
> This argument looks reasonable at first, but once you consider vendor lock-in, things start to change. If you want to add e.g. twitter integration to your document and their component is under-specified, your only option is put up and shut up.

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

>> page author can just copy / fork the component and modify its script not to use a shadow tree
>
> This seems like an inconvenient and roundabout way of achieving the same behaviour as my proposal, except without the fine-grained control. If the developer wants to make changes to the component, then yes, they should fork and modify. If they plan to use its DOM for any other purpose, having to modify the component for mere access seems unduly heavy-handed.

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.

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