Get Element(s) from Shadow root 'using' xpath and tagname property

[sarvaje]

According to the documentation:
https://w3c.github.io/webdriver/#find-element-from-shadow-root step 2
https://w3c.github.io/webdriver/#find-elements-from-shadow-root step 2

the value for using has to be one of the Locator strategies table.
But for what I can see in https://dom.spec.whatwg.org/ there no method to get elements from a tag name in a shadow root.

Experimenting in Chromium and Firefox I can neither use xpath in a shadow root. For the xpath I'm not sure if is because is not defined in the standard or because they don't have it implemented, but right now is not supported.

For more context you can take a look to this thread in the WPT repository

[jimevans]

IIRC, there are some cases where using XPath outside of a shadow root will pierce into a shadow root to access elements (that's IIRC, and I may not be "recalling correctly"). This seems to indicate that it's possible to use XPath for a shadow root, at least in some cases.

Not having these two selector strategies makes the "Find Element(s) From Shadow Root" inconsistent with the other "Find Element(s)" commands, and that inconsistency should be avoided. Just because something can't be done via JavaScript doesn't mean it should be disallowed via WebDriver. It may not be easy for an implementer, but users shouldn't be penalized for that difficulty. I guarantee that supporting some but not all locator strategies will be a source of issue reports for implementers, even if we modify the spec to disallow the more challenging ones.

[AutomatedTester]

Unless I am misunderstanding, we should have support tag name as it is part of the DocumentOrShadowRoot mixin. If it's not working then we need to seek clarifications from DOM.

[sarvaje]

Not having these two selector strategies makes the "Find Element(s) From Shadow Root" inconsistent with the other "Find Element(s)"...

I don't agree 100%, IMO it would be inconsistent if they were the same, but an Element and a shadow root are not the same thing.
Also, even if the name is similar (“Find Elements”), the method you are using is not the same. Developers will be using different methods to get a shadow root or an element, so IMO, it is ok if those methods have different parameters.

[jimevans]

A shadow root may not be the same as an element, but it most certainly is analogous* to a document, from which one can also find an element. I stand by my analysis that not having this parity will be an unending source of bug reports from users who will not appreciate the inconsistency. This applies both to client implementations like Selenium, and to browser maintainers who will eventually get the upstream issue reports.

*”Analogous,” not identical, in case others are feeling pedantic.

[AutomatedTester]

Unless I am misunderstanding, we should have support tag name as it is part of the DocumentOrShadowRoot mixin. If it's not working then we need to seek clarifications from DOM.

@sarvaje @foolip can I get a response to my question? We seem to have removed something because of a misunderstanding of the DOM spec

[sarvaje]

The DocumentOrShadowRoot mixin is expected to be used by other standards that want to define APIs shared between documents and shadow roots.

@AutomatedTester I'm not an expert reading specs (neither English is my native tongue so can be misreading it), but for what I'm understand in the previous quote, the DocumentOrShadowRoot mixin should define APIs that both, Document and ShadowRoot, have in common, so if get an element by tag name is not supported (according to the spec) in ShadowRoot, it shouldn't be part of the mixin. But that is just my opinion supposing I'm reading the spec the right way.