Re: [whatwg/dom] Match querySelector for pseudo elements (::slotted()) (#463)

> The problem is that accidentally passing a selector which crosses a shadow boundary isn't really explicit. Whether something is concerned as explicit is quite subjective so I'm not certain if we can come to an agreement on that.

Again, *how is that accidental*? You don't slip on the keyboard and, whoops, a `::slotted()` shows up in your selector. You write a selector like that *on purpose*. You are *trying* to target something outside your shadow. Why is it useful to prevent libraries from using this, when they can just walk outside the tree on their own?  In the cases where a library *explicitly* wants to allow targeting inside/outside a shadow tree, without this it would have to provide a side-channel for communicating that you want to hop into/out of a shadow before applying a selector, or do selector parsing on its own.

> Making querySelector and querySelectorAll work across shadow boundaries would require a substantial reworking of our CSS JIT engine, and we're quite frankly uninterested in implementing that.

This is substantially different from supporting the selectors in stylesheets?

> Now, such library/framework code can easily rely on the fact that the node returned by querySelector and querySelectorAll belong to the same node tree as the context object; e.g. library/framework might cache the results of querySelectorAll at the root node. The library could be adding properties returned by querySelectorAll for some processing. All these things are exactly the kind of things that ought to be avoided by the encapsulation shadow tree provides.

I still don't understand the failure mode being alluded to here. Can you give a concrete example?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/463#issuecomment-323422164

Received on Friday, 18 August 2017 18:05:45 UTC