| 05:04 | <MikeSmith> | for Github PRs and Travis, has anybody ever run into a problem where Travis is green but Github doesn’t recognize it’s green? |
| 05:04 | <MikeSmith> | https://github.com/w3c/webdriver/pull/1382 |
| 05:05 | MikeSmith | tries restarting the Travis build |
| 05:07 | <MikeSmith> | nm, just restarting the build fixed it |
| 14:35 | <jgraham> | MikeSmith: Yeah, the API is not infallible |
| 14:45 | <annevk> | hsivonen: in https://github.com/whatwg/encoding/issues/115#issuecomment-447773485 I'm not sure what the non-committal middle ground is given that the document lists two alternatives |
| 14:46 | <annevk> | hsivonen: anyway, both of those seem reasonable to me |
| 19:46 | <domfarolino> | Domenic: First, thanks for the review. WRT to providing a rel="stylesheet" override for concept-link-obtain, my plan is to also do this for preload too, since there will be more preload-specific logic w/ image{srcset, sizes}. |
| 19:46 | <domfarolino> | With these complete overrides, I think there will be nothing left referring to the non-override steps, and some duplication in each. That’s why I was originally doing some delegating, but do you think it is fine to just have separate algorithms specifically? |
| 19:50 | <Domenic> | domfarolino: I'm not sure I quite see your vision; could you explain more? All the other link types (besides preload, stylesheet, and modulepreload) would still use the default link-obtain algorithm, right? |
| 19:53 | <domfarolino> | Domenic: Oh geez, yeah, I guess I was just looking at cross-links, but I guess any link type that creates an "external resource link" sorta implicitly uses concept-link-obtain, though I think it is only linked to from preload, stylesheet, and one or two other places |
| 19:54 | <domfarolino> | Ok so providing those obtain overrides seems good |
| 20:29 | <Domenic> | domfarolino: Yeah I'm not sure on the exact best strategy, in particular for avoiding too much duplication. modulepreload and default link-obtain are different enough that a complete override makes sense, but the others may be very similar... |
| 20:30 | <Domenic> | Maybe the simplest thing is to just write out 4 separate algorithms, duplication be damned, and then consider refactoring to remove duplication afterward. |
| 20:53 | <domfarolino> | Domenic: Yeah that's what I was thinking. Now I'm just trying to figure out the best way to coordinate creating/adding CSS style sheets in a way such that scripts don't get unblocked before the style sheet fire/load event gets fired (hence some of the acrobatics in that PR) |
| 20:54 | <Domenic> | Yeah. I wonder if just a counter on the document would suffice. |
| 20:56 | <domfarolino> | Right, seems to be similar to Chrome's impl. |
| 22:13 | <domfarolino> | Domenic: So setting the ready/done flag, or equivalently decrementing a counter, will indeed well-specify the order between link load/error events and pending parsing-blocking script execution (https://github.com/whatwg/html/issues/4020). The benefit of "adding" the sheet in the queued task though well-specifies the order of the sheet becoming "available to scripts" and the load/error event |
| 22:14 | <domfarolino> | For example: https://script-blocking-styles.glitch.me is sometimes inconsistent in Chrome, but the opposite of Firefox's result |
| 22:14 | <Domenic> | Ah OK, that makes sense |
| 22:14 | <Domenic> | I guess "adding" is the right formalization of "available to scripts", indeed |
| 22:14 | <Domenic> | But it still seems possible to do the create and add atomically, right? |
| 22:15 | <domfarolino> | As long as you did both either before the queued task (and make Chrome change), or in the task (and make FF change) right? |
| 22:16 | <Domenic> | What would before the queued task mean? |
| 22:22 | <domfarolino> | Before the queued task executes. Oh shoot so the steps here (https://html.spec.whatwg.org/multipage/links.html#link-type-stylesheet:external-resource-link-9) run _after_ the queued task (the one that gets queued in concept-link-obtain) executes right? |
| 22:23 | <Domenic> | Ehhhhh I wouldn't say the spec is clear on that point -_- |
| 22:24 | <Domenic> | I think the ideal flow though is as annevk outlined. In parallel, fetch, parse, then queue a task to do everything else (= fire events, create/add) |
| 22:24 | <Domenic> | The question is what order the everything-else goes in, I guess |
| 22:24 | <Domenic> | I guess everything else = fire events, create/add, decrement the counter |
| 22:36 | <domfarolino> | Domenic: ^Indeed. Ok, what do you think of defining "post-obtain" steps to essentially be the current paragraph under concept-link-obtain (that queues a task), and having rel="stylesheet" defer to the concept-link-obtain algorithm (for generic loading), but then run its own specific post-obtain steps, which fires events, creates/adds the sheet, and decrements the counter |
| 22:38 | <domfarolino> | Alternatively I'm OK with an entirely separate loading algorithm too, however it just seems the biggest difference will be in the steps after the resource is obtained (hence the sketchy "an optional styleSheet", in my PR) |
| 22:40 | <Domenic> | That makes sense as a general direction. Specifically, what structure were you thinking? One idea would be to have "obtain the resource" and "post-obtain steps" both be algorithms with default definitions, where the default "obtain the resource" calls the (polymorphic) "post-obtain steps". Then rel="stylesheet" only overrides "post-obtain steps". |
| 22:41 | <Domenic> | (Whereas rel="modulepreload" overrides "obtain the resource", so it reuses none of the shared infrastructure.) |
| 22:47 | <Domenic> | I'm writing something up real quick... |
| 22:51 | <domfarolino> | That's quite close to what I was thinking. I am also writing up something lol |
| 22:58 | <Domenic> | domfarolino: https://gist.github.com/domenic/8758cd7b8feeb8034996b9f13090dc34 |
| 23:00 | <Domenic> | (refresh, some Markdown errors) |
| 23:01 | <Domenic> | (refresh, added handling of content type) |
| 23:02 | <domfarolino> | Ok at first glance it seems pretty similar in concept to what I did: https://docs.google.com/document/d/15plRAvijIkk4ZIcXR2_VI8Ut7lQsSOjCZnlSQOcoJzk/edit?usp=sharing, btw I used a "drawing" because I thought I was going to have more arrows lol |
| 23:02 | <domfarolino> | Everything in bold is a dfn. Will check out the gist in more detail now |
| 23:03 | <Domenic> | Ah yeah pretty similar. I guess the main difference is I went away from having everyone define their own "obtain the resource" if they don't have to. |
| 23:03 | <Domenic> | (even though that's what I advised you to do earlier ;) ) |
| 23:07 | <domfarolino> | Haha right. I'm fine with either, though I tend to lean towards more <dfn>s when possible. |
| 23:07 | <domfarolino> | Cool, I think I can take what we came up with and run with it |
| 23:07 | <Domenic> | \o/ |
| 23:08 | <Domenic> | I'm probably signing off for the night, and not working next week, but I'll still be around if there's any specific questions or thoughts you have |
| 23:08 | <Domenic> | Thanks for taking this on; it's a big mess but I see the light. Really appreciated. |
| 23:09 | <domfarolino> | Sure, yeah we'll see when/if time permits and all. Thanks for the help and insight! Equally appreciated |