-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error concerning "Due to how often https://drafts.csswg.org is down..." leads to incorrect redirects #19797
Comments
I hope that this means that drafts.csswg.org finally has a more stable build system that we can rely on. @sideshowbarker, do you have more information about this by chance? |
As I understand it, there is actually no build system at all on drafts.csswg.org any longer. Instead, the only build system is what’s in the https://github.com/w3c/csswg-drafts/ repo — specifically, in https://github.com/w3c/csswg-drafts/blob/main/.github/workflows/build-specs.yml and in https://github.com/w3c/csswg-drafts/blob/main/bin/build-index.py In other words, the only build system is the system for serving content at https://w3c.github.io/csswg-drafts/. But, what apparently happens now is that https://drafts.csswg.org proxies the content served from https://w3c.github.io/csswg-drafts/. However, as we can observe, if you try to navigate to any https://w3c.github.io/csswg-drafts content in your browser, you will now somehow get redirected back to https://drafts.csswg.org, which, as mentioned above, is somehow just proxying https://w3c.github.io/csswg-drafts — despite the fact that https://w3c.github.io/csswg-drafts then just redirects to https://drafts.csswg.org. If that all sounds very odd to anybody… well, it guess it should sound very odd. It’s not an arrangement I would have voted for as being the best way to be doing things — but I had no say at all in the matter. I found out about it after the fact, just like everybody did — after things started breaking. And speaking of breaking:
The cause of that particular breakage is apparently the code at https://github.com/speced/bikeshed-boilerplate/blob/53bed3c85985d5cd39973389667b54c0611181a9/boilerplate/csswg/abstract.include#L9-L17. I’ve opened a PR at speced/bikeshed-boilerplate#39 to fix that. Once that PR is merged, the redirections should start “working” again. However, from our end, to avoid making MDN users have to go through the (client-side) redirects, we’ll still need to change all the spec URLs in BCD to use the https://drafts.csswg.org URLs — and to change any incidental URLs we have in the body of any MDN articles (as opposed to those being pulled in from BCD). I will do PRs for both BCD and MDN once the dust has finally settled on the redirection situation. (Which I think should be after that speced/bikeshed-boilerplate#39 PR gets merged.) |
How dusty is the weather this week, Mike? Seems like the PRs got merged? |
All w3c.github.io/csswg-drafts URLs now redirect to drafts.csswg.org URLs. Relates to mdn/content#26613 Related MDN change: mdn/content#26833 Fixes #19797 Fixes mdn/content#26613
Yup — and I just now opened #19890 and mdn/content#26833. Merging those should resolve this issue and also resolve mdn/content#26613. |
All w3c.github.io/csswg-drafts URLs now redirect to drafts.csswg.org URLs. Relates to mdn/content#26613 Related MDN change: mdn/content#26833 Fixes #19797 Fixes mdn/content#26613
What type of issue is this?
Infrastructure issue
What is the issue?
When entering data for CSS
text-wrap
, I gave it aspec_url
ofhttps://drafts.csswg.org/css-text-4/#text-wrap
. It gave me the following error message:✖ css.properties.text-wrap - Error → Due to how often https://drafts.csswg.org is down, use https://w3c.github.io/csswg-drafts instead.
◆ Tip: replace https://drafts.csswg.org/css-text-4/#text-wrap with https://w3c.github.io/csswg-drafts/css-text-4/#text-wrap
The trouble is that when you go to
https://w3c.github.io/csswg-drafts/css-text-4/#text-wrap
, you end up being redirected back tohttps://drafts.csswg.org/css-text-4/#text-wrap##text-wrap
, which also won't resolve to the correct fragment. But I had to give it the redirecting URL to be allowed to get past the error.Is it time to remove or reevaluate this error?
What behavior were you expecting?
The URL to not result in an error?
What version(s) of BCD is the issue present in?
main
branchDo you have anything more you want to share?
No response
The text was updated successfully, but these errors were encountered: