"Additional WebDriver capabilities" vs "extension capabilities" clarification

[rakuco]

The terms look a bit confusing to me, so before I start using them in the Generic Sensor spec I'd like to double check I've understood everything correctly.

The way I've read it, other specs are supposed to provide "additional WebDriver capabilities" when necessary (along with a "additional capability deserialization algorithm" and a "matched capability serialization algorithm". These additional WebDriver capabilities must not have ':' in their name.

UAs, intermediary nodes and remote ends, on the other hand, may provide additional "extension capabilities" whose names must include ':'. The WebDriver spec does not put a lot of requirements on how these capabilities are supposed to be serialized or deserialized (there's no "extension capability deserialization algorithm" <dfn>, for example).

• If the above is right, other specifications may provide extension commands and additional WebDriver capabilities, while implementations may provide extension capabilities.
• Does it also mean that, consequently, specs like https://w3c.github.io/webauthn/#sctn-automation and https://fedidcg.github.io/FedCM/#automation are doing it wrong by defining "extension capabilities" instead of "additional WebDriver capabilities" (along with the appropriate serialization/deserialization algorithms)?

[rakuco]

@whimboo would you have more information about this by any chance?

[whimboo]

Not sure I understand. Both the referenced specifications use the correct prefix for the extension command, which is supposed to be used when a feature isn't directly specified in the WebDriver specification. Everything around those specified extension capabilities like types, parsing, handling etc would require explicit steps in the appropriate other specification.

@jgraham may be able to extend on that if further questions exist.

[rakuco]

My understanding reading the spec is that other specifications should define additional WebDriver capabilities, which are different from extension capabilities. The former provides hooks for specs that allow other specifications to have to write less prose than the referenced specs currently do, but the naming needs to be different.

The referenced specifications to the opposite, possibly because the names are confusing.

[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 capabilities that other specifications can define. Their names must not contain :.

If my understanding is correct, the name fedcm:accounts in https://w3c-fedid.github.io/FedCM/#webdriver-capability should change.