| 01:00 | <jugglinmike> | Does anyone know which task source is used when queuing a task here? https://html.spec.whatwg.org/multipage/parsing.html#the-end:event-load |
| 01:11 | <TimothyGu> | jugglinmike: > Except where otherwise specified, the task source for the tasks mentioned in this section is the DOM manipulation task source. |
| 01:11 | <TimothyGu> | that's at the bottom of the section |
| 01:12 | <jugglinmike> | So it is. Thanks, TimothyGu! |
| 04:50 | <domfarolino> | annevk: Regarding lazy loading spec, would you like the PR to handle intersection observer more rigorously, or is what you mentioned non-blocker? |
| 04:52 | <domfarolino> | I am unsure what IO primitives we can use to make the section you outlined more-clear, but I could take a look.. |
| 06:06 | <annevk> | domfarolino: yeah, either more rigorous or some wording that doesn’t result in something weird |
| 08:09 | <MikeSmith> | TabAtkins: does Bikeshed not support using the caniuse="" attribute to link to Can I Use IDs for features where Can I Use gets the data from the browser-compat repo? |
| 08:11 | <MikeSmith> | TabAtkins: Can I Use has https://caniuse.com/#feat=mdn-api_abstractrange but if I try caniuse=mdn-api_abstractrange with the DOM spec, I get "FATAL ERROR: Unrecognized Can I Use feature ID: mdn-api_abstractrange" |
| 08:30 | <annevk> | MikeSmith: does Bikeshed have a cached copy perhaps? |
| 09:21 | <MikeSmith> | annevk: nah, after poking around a bit, I think the limitation is due to Can I Use upstream. It doesn’t expose JSON data for the features where the data comes from the MDN browser-compat repo |
| 09:21 | <MikeSmith> | as far as I can see, I think Bikeshed just copies the Can I Use JSON files from https://github.com/Fyrd/caniuse/tree/master/features-json |
| 09:23 | <MikeSmith> | ..and the only files there are for features where the data is maintained within Can I Use itself, but not for the (many other) features that only have data in MDN browser-compat |
| 14:36 | <annevk> | What capabilities does Native File System give beyond <input type=fiile webkitdirectory>? Is it basically writing? |
| 14:36 | <annevk> | foolip: ^ |
| 14:37 | <Domenic> | MikeSmith: did MDN ever get added to bikeshed directly? |
| 14:38 | <MikeSmith> | Domenic: nope, not yet |
| 17:21 | <annevk> | domfarolino: heya, we discussed loading=lazy a bit more and there's a couple things we might have to tweak further. I suspect I'll look into them tomorrow as well. 1) Have the specification advice developers to set width/height (and also in CSS as appropriate I suppose) to the extent it doesn't already. 2) Ensure the specification uses a replaced element from the get go and not an inline box. 3) In the intersection |
| 17:21 | <annevk> | observer integration we might also wanna hint at having margins there to start loading a bit before the image is visible. 4) We need to check that if you change the base URL the correct image is still loaded. That's basically a worse variant of the referrer policy problem. And also test this. |
| 17:21 | <annevk> | ecobos: ^ |
| 17:45 | <domfarolino> | annevk: I don’t think I understand (2). For (1) & (3), you’re saying this would be a note or something non-normative? (4) SGTM |
| 17:47 | <annevk> | Yes, for 2, there’s some text somewhere that says how img is rendered. It should render the same as an img waiting on a server. I was not sure if we covered that. |
| 17:51 | <Domenic> | Woohoo, same site all fixed up now. https://lists.w3.org/Archives/Public/public-webappsec/2019Nov/0004.html |
| 17:52 | <domfarolino> | Nice! |
| 17:53 | <domfarolino> | annevk: OK (feel free to mention that on the PR thread too). I'll add (4) to the list of things-to-test for this. |
| 17:53 | <domfarolino> | Intersection Observer things worry me a bit just because I don't really know much at all about the spec, but I'll think about it more |
| 17:54 | <Domenic> | I think IO is not so bad. Just gotta do a small refactoring PR to the IO spec to make its algorithm a bit more callable. |
| 17:59 | <annevk> | Took me a second to realize you were not talking about I/O |
| 18:10 | <domfarolino> | Ah I actually didn't take a close look at "compute the intersection" before, but I think see now |
| 18:10 | <domfarolino> | Lol the I/O algorithm |
| 18:38 | <domfarolino> | Domenic: Hm just reading around randomly...should https://www.w3.org/TR/intersection-observer/#queue-an-intersection-observer-task specify a task source (probably DOM task source)? |
| 18:50 | <Domenic> | domfarolino: yes. I wonder what task source implementations use. |
| 18:51 | <Domenic> | Also, avoid /TR, use https://w3c.github.io/IntersectionObserver/ |
| 18:53 | <domfarolino> | Domenic: Thanks. I was surprised to find the GitHub repo didn't link to that |
| 18:54 | <domfarolino> | Looks like Chrome uses its own IO task source https://cs.chromium.org/chromium/src/third_party/blink/public/platform/task_type.h?g=0&l=204, unsure about FF & friends |
| 18:54 | <Domenic> | That's the most flexible so I'd lean toward speccing that |
| 18:54 | <Domenic> | Maybe there is some global declaration in the spec... |
| 18:55 | <Domenic> | (no, there is not.) |
| 18:58 | <domfarolino> | Ya lol I also couldn't find it..will file an issue |
| 19:00 | <domfarolino> | Domenic: Also regarding the IO integration with lazy load..is it still weird that we'd be, in parallel, waiting for the "compute the intersection" algorithm to indicate an intersection? This kinda feels like it bypasses the convenience of just flat-out using an intersection observer in the lazy load PR |
| 19:01 | <domfarolino> | Or is OK that we write it that way, because it's flexible enough for implementations to implement that behavior with an IO under-the-hood (what Chrome does IIRC) |
| 19:01 | <Domenic> | domfarolino: hmm I hadn't considered that. I think chrishtr is concerned that we not cause synchronous layout janks, and so piggybacking on the asynchronous IO machinery seems better. |
| 19:01 | <Domenic> | s/janks// |
| 19:02 | <domfarolino> | Interesting, OK, SGTM |
| 22:09 | <domfarolino> | Domenic: Am I crazy or do we not need to reference the "compute the intersection" algorithm at all? It seems that IO only uses it when computing the exact |intersectionRatio|. |
| 22:09 | <Domenic> | Haha wow maybe, let's see |
| 22:09 | <domfarolino> | https://w3c.github.io/IntersectionObserver/#update-intersection-observations-algo |
| 22:10 | <domfarolino> | Otherwise, they compute |isIntersecting| by seeing if the targetRect and rect around the "root" intersect (these are both DOMRects from what I can tell) |
| 22:11 | <Domenic> | Fascinating |
| 22:11 | <Domenic> | So we just need the equivalent of "Let isIntersecting be true if targetRect and rootBounds intersect or are edge-adjacent, even if the intersection has zero area (because rootBounds or targetRect have zero area); otherwise, let isIntersecting be false." |
| 22:11 | <domfarolino> | Seems like it |
| 22:11 | <Domenic> | I think we all kind of assumed there would be a formal definition for "intersect", and thus went looking for one and found "compute the intersection" |
| 22:13 | <Domenic> | I'm not sure exactly what the right phrasing is for intersects the viewport then |
| 22:13 | <Domenic> | Well, shit, maybe it's https://html.spec.whatwg.org/#intersect-the-viewport |
| 22:13 | <Domenic> | This whole exercise may have been an overzealous demand for rigor... |
| 22:14 | <Domenic> | We should just copy what video does. (Probably abstract it out a bit?) |
| 22:14 | <Domenic> | This must be frustrating |
| 22:15 | <domfarolino> | Oof no it's interesting I'm glad we took a closer look. |
| 22:15 | <domfarolino> | Yeah using that dfn would probably make the most sense, seems that no dependency on IO would buy us any more than that I think? |
| 22:18 | <domfarolino> | Even IO is a little hand-wavey when computing an intersection with the viewport I think; I'm not sure what "the viewport's size" is in https://w3c.github.io/IntersectionObserver/#intersectionobserver-root-intersection-rectangle (a DOMRect, since that's what getBounding[...] returns?) |
| 23:26 | <JonasNZ> | Hi Folks, I believe I've found an inconsistency in the implementation of some behavior in the fetch spec between chrome and firefox. Wondering if anyone has thoughts before I go and file bugs with the relevant parties. |
| 23:26 | <JonasNZ> | The flow we're doing is roughly this |
| 23:26 | <JonasNZ> | fetch -> POST example.com/path1 (with body = a FormData object) |
| 23:26 | <JonasNZ> | This causes the request to have "Content-Type: multipart/form-data" |
| 23:26 | <JonasNZ> | The post body is properly encoded. |
| 23:26 | <JonasNZ> | The response is a 302 to example.com/path2 |
| 23:26 | <JonasNZ> | # fetch then follows the redirect (specifically step 11 of https://fetch.spec.whatwg.org/#http-redirect-fetch) |
| 23:26 | <JonasNZ> | fetch -> GET example.com/path2 |
| 23:26 | <JonasNZ> | This is where Chrome and Firefox behave differently. |
| 23:26 | <JonasNZ> | Chrome: drops Content-Type header and body. |
| 23:26 | <JonasNZ> | Firefox: only drops body. |
| 23:26 | <JonasNZ> | My feeling is that Chrome is behaving correctly here and firefox is misbehaving |