tidoust
commented
7 months ago I agree that it would be valuable information to have.
Of course, the question becomes: to avoid having to maintain the information manually, can we compute it automatically? Some ways to do that, on top of my head:
- Look for an
auto-publish.ymlfile. But then that's just a naming convention. Some groups use other job names (e.g. WebGPU/WGSL). Or use their own logic (e.g., WebAssembly). Also, there are cases where thespec-prodaction is used to deploy the spec automatically to GitHub Pages, but not to /TR (as done for WebTransport, WebAuthn, or MathML Core), which could create false positives. - Compare the
revisionthat appears in a<meta>tag in the /TR version with the latest repo commit. Now, that's not enough in itself to claim that the spec is published automatically to /TR. Also, commits may have touched other parts of the repo and not lead to a new published version of the spec. Or publication may still be pending when we check specs. Or publication may have failed temporarily, as happens from time to time. - See whether the W3C API could be extended somehow to report on what triggered last call to Echidna. I'm not sure the system sees a difference and colelcts that information at all, though.
- Make the spec-prod action inject a
<meta>tag to the spec published on /TR to make it explicit that the spec was published automatically. That would not capture cases where a group decided to stop automatic publications, but that should remain fairly exceptional.
Now, it's not clear to me that "most don't" is still a valid statement: a growing number of W3C working groups have switched to automatic publication in practice (including Device and Sensors, Immersive Web, Media, Pointer Events, Second Screen, WebApps, WebAppSec, WebAssembly, Web Editing). The main exception is going to be the CSS WG.
Perhaps this could be a good opportunity to assess whether linking to the Editor's Draft is still needed, and to take an opposite approach: instead of identifying which specs can be referenced using the /TR version, identify those that should not.
I'll try to create a first draft split of /TR specs (auto-published, non auto-published, don't know) to inform the discussion.
foolip
dontcallmedom
Some W3C specs are published to /TR/ for every commit, while most don't and require github.io URLs to lead the latest.
In https://github.com/mdn/browser-compat-data/pull/22694 I learned of one such case – WebNN – and it looks like https://github.com/webmachinelearning/webnn/blob/main/.github/workflows/auto-publish.yml is how that works.
I would be great if browser-specs could provide the information needed for other projects like BCD or web-features to know when a /TR/ is autopublished and not. This would avoid the need to keep track of which WGs prefer these URLs, and can lint for most up-to-date and preferred spec URLs more easily.
One possible implementation is to use /TR/ as nightly URL if /TR/ is autopublished, and put the github.io URLs in as alternatives, not the canonical.