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

> The problem is that we've already seen a [similar problem with the shadow piercing combinator](https://github.com/w3c/webcomponents/wiki/Shadow-piercing-Combinators-in-the-Wild).

I can't necessarily see that these are problems. Allowing a document author to theme a component, or to use a library that does so, seem like completely reasonable use cases. That shadow DOMs prevent the *unintentional* downward leaking of styles is excellent, but it shouldn't mean that they should be completely unstylable from the outside.

(Also, the `:part()` selector seemed like a nice go-between for component theming: well-specified components can be styled in a non-implementation-dependent way, and under-specified components can still be styled by `/deep/`.)

>> If a page breaks, is it not an issue for the page's author, rather than the component developer?
>
> The unfortunate reality is that library and framework authors would have to worry about those dependency. We deal with those issues all over the place in AppKit and UIKit or even WebKit / WebKit2 themselves embedded in other applications, and it imposes serious constrains on what we can and cannot change in our implementations.

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.

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.

> The problem is that it quickly becomes library & framework author's problem once enough websites decide to take that risk.

Beyond styling, it doesn't seem likely that many websites will depend on specific implementation details of specific components -- it's quite a headache to retrofit extras into an existing custom element so they're more likely to just modify it directly. For e.g. analytics libraries, or any of my other examples, the code is component-agnostic, and so the implementation can change without breaking anything.

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

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

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