CSS spec names have become "Unknown specification"
MDN URL
https://developer.mozilla.org/en-US/docs/Web/CSS/width
What specific section or headline is this issue about?
Specifications
What information was incorrect, unhelpful, or incomplete?
The name of the specification is "Unknown specification".
What did you expect to see?
For this particular page, it should be "CSS Level 2" (or CSS2).
Do you have any supporting links, references, or citations?
No response
Do you have anything more you want to share?
No response
MDN metadata
Page report details
- Folder:
en-us/web/css/width - MDN URL: https://developer.mozilla.org/en-US/docs/Web/CSS/width
- GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/css/width/index.md
- Last commit: https://github.com/mdn/content/commit/78e760fc3e361af718d78c7e60200d9b5a7302ce
- Document last modified: 2022-09-13T09:29:55.000Z
I just saw that the links are updated to use csswg-drafts GitHub pages. https://github.com/mdn/browser-compat-data/commit/085deec40921b076bb12376339263875ee52a77b That may have broken the spec name matching...?
Ah, perhaps https://github.com/w3c/browser-specs/pull/706 will solve the issue?
Ah, perhaps w3c/browser-specs#706 will solve the issue?
Partially, yes. I guess we still need to implement looking for the alternateUrls property if it gets introduced in that PR.
I don't know when the issues with drafts.csswg.org will be resolved and BCD changes back to these URLs. So, maybe we need to go down the alternateUrls route, but the browser-specs PR seems like a prerequisite here.
cc @queengooborg @sideshowbarker
This will be tracked in https://github.com/mdn/yari/issues/7173!
Closing in favor of https://github.com/mdn/yari/issues/7173 since it doesn't seem actionable on the content side
FYI for the record here — it looks like we now have an upstream solution, per https://github.com/w3c/browser-specs/issues/704#issuecomment-1255147490:
Browser-specs now lists
https://w3c.github.io/csswg-drafts/URLs for CSS specs under the nightly.alternateUrls.
So it seems we can fix this by updating our browser-specs client/consumer code to check the nightly.alternateUrls value in addition to the nightly and nightly.url values.