Re: [whatwg/webidl] record with arbitrary value types as keys? (#509)

tidoust left a comment (whatwg/webidl#509)

Reopening this issue may not be warranted, but I thought I would document a few other examples of specs in 2026 that still try to use enumerations to constrain the set of strings that record keys can take, typically when representing capabilities:

- [`SecurePaymentConfirmationCapability`](https://w3c.github.io/secure-payment-confirmation/#sctn-secure-payment-confirmation-capability-enumeration) for [`SecurePaymentConfirmationCapabilities`](https://w3c.github.io/secure-payment-confirmation/#typedefdef-securepaymentconfirmationcapabilities) in Secure Payment Confirmation.
- [`ClientCapability`](https://www.w3.org/TR/webauthn-3/#enumdef-clientcapability) in Web Authentication.

The resulting `enum` is essentially unused, it just squats a name in the Web IDL namespace. Also, values typically do not follow the naming recommendation to use lowercase and dash-separated, because using camelCase for record keys is more developer-friendly (it allows to use the dot notation instead of square brackets).

Other specs have similar needs, and currently list possible values in the prose directly. For example:
- [supported limits](https://www.w3.org/TR/webgpu/#supported-limits) for [`requiredLimits`](https://www.w3.org/TR/webgpu/#dom-gpudevicedescriptor-requiredlimits) in WebGPU.
- [seller capability](https://wicg.github.io/turtledove/#seller-capability) for [`sellerCapabilities`](https://wicg.github.io/turtledove/#dom-generatebidinterestgroup-sellercapabilities) in Protected Audience.

Not sure Web IDL needs to change here but it may be worth providing guidance in the Web IDL spec about this pattern to discourage the use of `enum` to constrain record keys or to scope the naming recommendation warning.


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

Message ID: <whatwg/webidl/issues/509/4070570916@github.com>

Received on Monday, 16 March 2026 21:01:36 UTC