drafts.csswg.org published specs are weeks/months out of date with repo sources #8809
Comments
|
Not my issue, drafts.csswg.org is currently proxying w3c.github.io/csswg-drafts for all built specs. Ping @tabatkins |
|
I'm confused. I just looked at the top half-dozen, and they're all exactly up-to-date. And as far as I can tell the "temporary fix" isn't relevant to this either, it just puts back the unlevelled versions (which I left broken under the assumption someone would complain if it was an issue; I'll take this as just such a complaint). But I'm still definitely confused what precisely is supposed to be broken, and how. |
https://drafts.csswg.org/css-animations-2/ shows “W3C First Public Working Draft, 2 March 2023”
And the https://github.com/w3c/csswg-drafts/commits/main/css-animations-2/Overview.bs shows more than a dozen changes have been committed to the spec source since 2 March 2023. …and so on, down the line, for all the specs listed in the issue description. |
Yes, to be clear: That’s exactly what it puts back (and all that it puts back). It’s not intended as a fix for the problem of all the drafts.csswg.org published specs being weeks or months out of date with the repo sources. I’m also confused by why all the drafts.csswg.org published specs are now out of date — because the w3c.github.io/csswg-drafts published specs were not. (And I’m certain that the w3c.github.io/csswg-drafts specs were not similarly out of date, for two reasons:
|
|
The 'Last-Revised' HTTP header is a non-standard header that the draft server uses to communicate with Shepherd's spec parser. It's not relevant here. Those headers haven;t been updated for a while because the git->mercurial sync has been offline for a few weeks. It's not relevant at the moment either because we're not serving anything directly from the mercurial repo at the moment. |
See mdn/content#26613. That 52077ef change broke every single CSS spec link in every CSS article in MDN article that has a spec link — which is more than 1000 MDN articles. |
|
And the git->hg sync was broken because of the github ssh key change, should be fixed now. So the 'Last-Revised' headers should be in sync shortly. Note that this has nothing to do with the content of the specs, which apparently has been in sync all along. |
Given #8806, that doesn’t seem to be true. Please look at these lines in the current source: csswg-drafts/cssom-1/Overview.bs Lines 2043 to 2049 in c5dff3b …and then look at https://drafts.csswg.org/cssom-1/#the-cssimportrule-interface — The published spec is missing the |
If the |
Not sure what you're looking at: |
I was looking at what I posted a screenshot of in #8809 (comment) — and which I gave the URL for. So either something’s changed in the meantime, or else it was caused by caching somewhere, because I now do also see the And I also see that https://drafts.csswg.org/css-position-4/ is no longer 404. |
|
Also, the 'Last-Revised' header hasn't been served since we started proxying the github.io drafts, so not sure where you're even seeing that |
I’m still seeing it right now, just seconds ago, from running a |
|
And from the US: You must have a caching proxy inline somewhere. |
|
Or... your DNS is way out of date and somehow you're seeing the old server directly and not the new proxy |
OK, thanks much — I’m not aware of any relevant caching proxy anywhere, so I guess the only thing it could be is my DNS being out of date. I wasn’t aware there was an old server vs the new proxy, but I’m guessing if there’s an old server that’s not up to date, then the behavior I’m seeing is because I’ve still been getting responses from that old server. I’ll see what I can do about troubleshooting my DNS — but in the meantime, I guess I should go ahead and close this, since it seeming clear now that has to just be a local problem. |
|
OK, for the record here, it seems I had been getting routed to 173.230.149.95 (which I assume must be the old server) but now I’m finally getting consistently routed to 45.79.94.155 (which I assume must be the correct server, the new proxy). I have no idea how I “fixed” it — all I did was to run a few tools like dig, traceroute, and mtr. I hope it was in fact just some weird local issue, and not something caused by some broader network problem that other people (e.g., other people in Japan where I’m connecting from) might also run into. Because if they did run into it, it likely wouldn’t be obvious to them that they were seeing stale content. Would it be possible to shut down the 173.230.149.95 server so that anybody else who might be still getting routed to it now would see hard 404s rather than stale content? |
Ah actually mea culpa; I'd left those files ungenerated because I'd assumed that the drafts server was still doing the redirecting that it used to, and we didn't need them here. (That is, I thought only |
|
Fixed by 70fe674 |
A large number of the CSS specs published on drafts.csswg.org are many weeks or even months out of date with their git sources — or in several cases even more than a year out of date.
The following table shows the date when each spec was last published, and compares that with the date for the most-recent commit to the git source for the spec.
last published
last changed
It seems reasonable for the wider web-developer community and PR contributors and browser implementors and spec editors to expect that whenever a change is made to any CSS spec source in the git repo, the corresponding drafts.csswg.org spec will get automatically rebuilt and republished.
(That auto-publishing behavior is what was happening with the w3c.github.io/csswg-drafts specs. And speaking from my perspective as an MDN/BCD contributor, I can say it’s the behavior that MDN and BCD maintainers have been relying on when reviewing MDN and BCD PRs related to CSS features — and I can imagine it also being the behavior that other groups of stakeholders are similarly expecting).
The text was updated successfully, but these errors were encountered: