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

I see the gap that @tabatkins asking *any concrete example* that can accidentally get the node outside the tree, while @rniwa saying it's technically possible that happens, without concrete example.
Possibly you can make an example that you take user input as a selector string and just run querySelector() with the input literally without any sanitization.  But I don't think this a good argument.

My take on the gap is that where you are coming from, i.e. the world that "open" shadow root is the default or the world that "closed" shadow root is the default. But there is no such default for the current `Element.attachShadow` and you have to specify either mode. The world needs both.

In general, we allowed access from inner to outer, such as `ShadowRoot.host` or `HTMLSlotElement.assignedNodes()`, whereas we are restrictive from outer to inner, especially for closed shadow trees, such as `Element.shadowRoot`.

So what is wrong with this?: allow cross-boundary element to be returned for querySelector() if the selector explicitly contains cross-boundary pseudos such as `:host`, `::slotted()`, `::part()` if the matching element is *visible* from the context object?  I.e. you can get `querySelector(":host")` from either in open or closed shadow tree, while `querySelector("::part()")` or `querySelector("::-webkit-progress-bar")` would never match any element under closed or user-agent shadow tree.

I think nothing is wrong, the only justification for not returning those that I can agree is at the last line in @rniwa's response, "querySelector returning a node outside of its own tree" (its = context object's).

I haven't heard anyone requesting `querySelector(":host")` to return shadow host (Blink currently returns null).  Probably this is because we already have `ShadowRoot.host`. `querySelector("::slotted(...)")` is also possible with existing APIs (though it needs extra steps - so developers may ask in the future). So unless we have compelling use cases that
1. using querySelector() is far easier than mix of existing APIs (polyfilling)
2. querySelector() can perform much better than using polyfilled one

I think it's fine to restrict
1. no matched pseudo elements returned for querySelector
2. querySelector doesn't return any element outside its context object's node tree

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