WebDriver capability might have an invalid name

[rakuco]

While adding some WebDriver extension commands to another spec, I've come across the extension commands that this spec and WebAuthn define.

I'm filing this issue just to let people know that I've recently created w3c/webdriver#1749 to try to get some clarification on the distinction between "extension capabilities" and "additional WebDriver capabilities". My understanding so far is that specs like FedCM should define the latter, not the former. Doing so allows hooking into "additional capability deserialization algorithm" and "matched capability serialization algorithm" for example, but does require a different naming scheme.

[cbiesinger]

link: https://w3c.github.io/webdriver/#dfn-additional-webdriver-capability

I did indeed miss the distinction between an "additional" and an "extension" capability. I would love input from someone who knows webdriver better than me about what to do here.

[cbiesinger]

thanks for filing this issue.

@mathiasbynens any advice?

@stephenmcgruer fyi

[npm1]

Friendly ping @mathiasbynens

[mathiasbynens]

My understanding is:

• Extension capabilities are meant for vendor-specific extensions of the form moz:foo or webkit:bar. They must contain : in their name as part of the namespacing, and it’s recommended to reuse CSS vendor keywords for the prefix. These capabilities with prefixed names are not meant to be part of specifications; rather, they are non-standard features that the remote end (e.g. the server in ChromeDriver) decides to make available.
• Additional capabilities are what you want here. They must not contain : in their name, and can be defined by other specifications.

I agree that an “additional capability” is what we want here.

Practically this means that the name fedcm:accounts in https://w3c-fedid.github.io/FedCM/#webdriver-capability must change.

---

For completeness sake, I’ll also point out that so far, we’ve only talked about the WebDriver “Classic” spec. WebDriver BiDi also allows other specs to define their own modules that extend the WebDriver BiDi protocol, and unlike WebDriver Classic, it supports bi-directionality and events. Web Bluetooth is an example of a spec that extends WebDriver BiDi, here: https://webbluetoothcg.github.io/web-bluetooth/#automated-testing This might be helpful for future specs that require functionality that doesn’t exist in WebDriver Classic.