| 07:59 | <sideshowbarker> | Andreu Botella: https://andreubotella.com/csswg-auto-build/ doesn’t seem to mirror https://drafts.csswg.org/scroll-animations/ … |
| 08:01 | <sideshowbarker> | as far as I can tell, that’s the only CSS spec that it’s not mirroring |
| 08:27 | <Andreu Botella> | Andreu Botella: https://andreubotella.com/csswg-auto-build/ doesn’t seem to mirror https://drafts.csswg.org/scroll-animations/ … |
| 08:27 | <Andreu Botella> | but weird that the shortname https://andreubotella.com/csswg-auto-build/scroll-animations doesn't link to it |
| 08:27 | <sideshowbarker> | aha |
| 08:29 | <Andreu Botella> | That's of course because the shortname in the bikeshed metadata is given as scroll-animations-1, of course: https://github.com/w3c/csswg-drafts/blob/main/scroll-animations-1/Overview.bs#L10 |
| 08:29 | <Andreu Botella> | I've had to special case some shortnames so they show up linked in the index, I guess I missed this one because it has a single level |
| 08:33 | <sideshowbarker> | it is easy to fix/workaround on your side? |
| 08:33 | <Andreu Botella> | I just did |
| 08:34 | <Andreu Botella> | give it a few minutes so it builds |
| 08:34 | <sideshowbarker> | ah cool — thanks |
| 08:34 | <sideshowbarker> | hai |
| 08:56 | <annevk> | Mattias Buelens: hey, do we have some kind of "peek" primitive yet for streams? |
| 08:58 | <annevk> | Mattias Buelens: I'm guessing I might be stuck with some kind of transform stream? |
| 09:00 | <Mattias Buelens> | Mattias Buelens: hey, do we have some kind of "peek" primitive yet for streams? |
| 09:01 | <sideshowbarker> | Andreu Botella: so in my https://github.com/w3c/mdn-spec-links/ build automation, I’m trying to replace requests to https://drafts.csswg.org/ URLs with requests to https://andreubotella.com/csswg-auto-build/ URLs — but what I’m finding is that a lot of the documents at the URLs I’m requesting actually just have client-side redirects — e.g., <meta http-equiv="refresh" content="0; URL=../css-variables-1/" /> — which the documents at the equivalent https://drafts.csswg.org/ URLs don’t seem to have. Instead the documents at the https://drafts.csswg.org/ URLs seem to be copies… |
| 09:01 | <annevk> | Thanks; for ORB I need to look at the first 1024 bytes of a response, so I guess I essentially have to replace the underlying stream with a transform stream where I collect the first 1024 bytes, scan them, and then forward them |
| 09:02 | <Andreu Botella> | sideshowbarker: Github Pages doesn't let you do server-side redirects, so I'm making all of them client-side |
| 09:03 | <Andreu Botella> | if you link to the actual level of a spec, it shouldn't redirect |
| 09:03 | <sideshowbarker> | yeah I can’t link to the leveled versions |
| 09:03 | <sideshowbarker> | for MDN and BCD we have a policy of intentionally not linking to the leveled versions |
| 09:05 | <Mattias Buelens> | Thanks; for ORB I need to look at the first 1024 bytes of a response, so I guess I essentially have to replace the underlying stream with a transform stream where I collect the first 1024 bytes, scan them, and then forward them |
| 09:09 | <annevk> | I will also have another place where I need to look at the full response before forwarding it. Might look at whether that makes it worth abstracting somehow. |
| 09:10 | <sideshowbarker> | with jsdom, anybody know if I can get it to follow a <meta http-equiv="refresh" content… and load the contents of the document that’s redirecting to? |
| 09:34 | <sideshowbarker> | Andreu Botella: OK I reckon I’ll try grabbing out the redirect URLs with jsdom, and re-requesting with those URLs. I think it should work. Because it’ll be making additional requests, I guess it’ll end up being a bit slower than using drafts.csswg.org — but today after the Nth time of drafts.csswg.org unreliability completely breaking my build, it’s worth the added effort and time to have something else that’ll actually work reliably rather than totally break every week |
| 11:06 | <sideshowbarker> | Andreu Botella: OK, with https://github.com/w3c/mdn-spec-links/commit/18de692 my build tooling is now switched over to making requests to your mirror rather than to drafts.csswg.org — and it seems to be working as expected. Dunno if GitHub has request/bandwidth limits for Pages content, but anyway that part of the build normally only runs once a day, so I don’t think it will generate a huge amount of extra traffic |
| 11:06 | <Andreu Botella> | sounds good |
| 11:06 | <sideshowbarker> | thanks much for providing that mirror |
| 14:54 | <annevk> | Noam Rosenthal: could you perhaps triage the issues here that are filed by me: https://github.com/WICG/background-fetch/issues? Now that HTML depends on some of this stuff, it would be good to know if we should move some of these definitions to Fetch |
| 14:55 | <annevk> | Noam Rosenthal: my interest atm is mainly with "validate a partial response" which ORB needs, but all of it seems important |
| 14:56 | <Noam Rosenthal> | annevk: I don't know much about the background-fetch spec but would be happy to give it a go |
| 14:59 | <annevk> | Noam Rosenthal: this is mainly about the range thingies that media elements now depend in part on |
| 15:00 | <Noam Rosenthal> | annevk: ah yes, I originally used some of the definition from background-fetch with small but important modifications |
| 15:13 | <annevk> | It seems HTML only has "extract content-range values", so maybe I'm on my own |
| 15:14 | <annevk> | Well maybe not, "validate a partial response" depends on that |
| 15:18 | <Noam Rosenthal> | yea the validation bit is semi-duplicated between HTML and background-fetch with minor differences and both depend on "extract content-range values" IIRC |
| 15:24 | <annevk> | I see, if you could it would be great to have some follow-up issues documenting what would make things more usable for HTML |
| 15:24 | <annevk> | I suspect that in implementations these don't have different code paths per se so might also be good to test |
| 15:29 | <Noam Rosenthal> | annevk: sure, will get to it soon-ish |
| 15:57 | <Noam Rosenthal> | annevk: I wanted to finish with https://github.com/whatwg/html/pull/7782 before the next steps with range-responses though, waiting for a final merge |
| 16:40 | <annevk> | Noam Rosenthal: added a comment |
| 16:48 | <sefeng> | Noam Rosenthal: annevk sorry for coming back with another TAO check question. For a simple redirect, A->B, when doing the serializing a request origin check for B, Should it return...null? |
| 16:51 | <Noam Rosenthal> | sefeng: I was surprised with this as well about a month ago :) |
| 16:52 | <sefeng> | Noam Rosenthal: yeah I mean..it looks like B has to have * specified to make TAO passes, it can't just have A's origin |
| 16:53 | <annevk> | sefeng: so request's URL list is [A, B], what's request's origin? |
| 16:53 | <sefeng> | annevk: B |
| 16:54 | <annevk> | Yeah then it's tainted |
| 16:54 | <Noam Rosenthal> | sefeng: It can theoretically have the string "null" though I don't think that's tested or implemented |
| 16:54 | <annevk> | If it wasn't A could make requests on B with the authority of B |
| 16:54 | <annevk> | If request's origin was A, it would end up saying A to B |
| 16:57 | <sefeng> | annevk: maybe I misunderstanding something. So when an redirect like this, I should use A as the origin? |
| 16:58 | <annevk> | sefeng: in the scenario you described a website B does a fetch to A and A redirects to B, right? |
| 17:01 | <sefeng> | annevk: I think it's just website A fetches B |
| 17:01 | <sefeng> | I am looking at this particular test https://searchfox.org/mozilla-central/source/testing/web-platform/tests/resource-timing/TAO-match.html#21-24 |
| 17:03 | <annevk> | sefeng: I'm not familiar with those tests, but in that case request's origin would be A and request's URL list would be [B]; so looking at https://fetch.spec.whatwg.org/#concept-request-tainted-origin ... |
| 17:04 | <annevk> | sefeng: we'd end up returning false since after we set lastURL to B we continue and thus exit the loop as there are no more URLs |
| 17:04 | <annevk> | sefeng: and returning false means there's no tainting thus Origin becomes A |
| 17:08 | <sefeng> | annevk: so request origin should always be the origin of who started the request? |
| 17:13 | <annevk> | sefeng: yeah, it typically gets set based on the global involved in creating the request |
| 17:22 | <sefeng> | thanks! |
| 17:25 | <annevk> | sefeng: I guess an important thing to understand here is that request's origin is essentially immutable (these days anyway) and request's URL list gets updated as you come across redirects |
| 19:59 | <smaug> | Hmm, why is test_driver.bless called bless? |
| 20:00 | <smaug> | Couldn't have guessed it has something to do with user interaction |
| 21:08 | <jfernandez> | it took me time to figure that out as well |