- From: Marcos Caceres <marcos@marcosc.com>
- Date: Thu, 10 Feb 2022 15:13:40 +1100
- To: spec-prod <spec-prod@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Dominique Hazaël-Massieux <dom@w3.org>, Francois Daoust <fd@w3.org>
Hi Editors, Tab, As some of you are aware, Bikeshed/ReSpec (mostly automatically) classify `<dfn>`s in a spec of being a particular "type" [1]. For example, "sometag" is an "element", "MyFancyAPI" is a WebIDL "interface", and so on. In the platform, it's become common to define a token string that has security implications in various specs (namely the Permissions Policy, HTML, and Permissions specifications). For example, the token string "geolocation" can be used by both the in different ways by different technologies: * Permissions-Policy HTTP header * iframe's allow= attribute, where HTML checks if a document is "allowed to use" token string. * In the Permissions spec, when .query() is called, it checks if the feature identified by the token string is supported. * And so on... I'd like propose that we elevate these token strings from being a "concept" type to an explicit "permission" definition type. By making them an explicit type, it makes it will make it easier to find and identify them in the platform (for example, in xref [2]). If there are no objections (or someone has a better idea?), we'd like to add support this type more widely to the various systems and tooling. The idea would be that by identifying a "permission" type, it gets automatically exported to the cross reference database and tooling could do some validation checks (e.g., must be lowercase, no spaces, etc.) Thoughts? Kind regards, Marcos d [1] https://tabatkins.github.io/bikeshed/#dfn-types [2] https://respec.org/xref/
Received on Thursday, 10 February 2022 04:13:58 UTC