| 10:19 | <smaug> | selection in shadow DOM issue will have its birthday in a month: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444 , later https://github.com/WICG/webcomponents/issues/79 |
| 10:23 | <jgraham> | Maybe make a cake in the shape of a "10", and give it a selection of fillings. |
| 10:23 | <jgraham> | (I'm so sorry) |
| 12:19 | <annevk> | Noam Rosenthal: ≫ is not » |
| 12:19 | <annevk> | Noam Rosenthal: if they are indistinguishable in your editor, I recommend copying from https://infra.spec.whatwg.org/#lists |
| 12:21 | <Noam Rosenthal> | gotcha annevk. I must say I find these ambiguous unicode characters in specs somewhat cumbersome... |
| 12:24 | <Noam Rosenthal> | annevk: regarding allow preloads and custom headers, how would you suggest to ignore preloads when custom XHR/fetch() headers are present? |
| 12:25 | <annevk> | Noam Rosenthal: I think the presence of any header would indicate a custom header |
| 12:25 | <Noam Rosenthal> | annevk: ok |
| 12:26 | <annevk> | Noam Rosenthal: you can guard the check with "unsafe-request flag" which only fetch() and XHR set |
| 12:26 | <annevk> | As for the Unicode characters, they generally seem to work okay for me as long as I copy-and-paste. Could you elaborate on what makes them cumbersome? |
| 12:27 | <Noam Rosenthal> | they're cumbersome because mistakes are not visible to the naked eye |
| 12:27 | <Noam Rosenthal> | and they're not common characters in other forms of programming, and don't appear on keyboards |
| 12:28 | <Noam Rosenthal> | I think that makes them unique among characters used in specs, but I might be wrong about that |
| 12:29 | <annevk> | Well, the precedent here is JavaScript, which uses the same characters for its internal List type |
| 12:29 | <Noam Rosenthal> | Yea, I figured there's some historical reason for this |
| 12:32 | <Noam Rosenthal> | @annevk: regarding "allow preloads", I thought to keep it for now for the "sync XHR" case, I don't think there's another way for fetch to know that this is a case where preload should be avoided |
| 12:36 | <annevk> | Noam Rosenthal: sync xhr always bypasses preloads? I didn't know. Seems somewhat unfortunate to give sync xhr a special ability. Might make people want to use it more. |
| 12:38 | <Noam Rosenthal> | annevk: yea, actually I should dig more into why chrome does that. I don't think other implementations do. Maybe that part should be outside the spec for now and added separately with a separate discussion |
| 12:42 | <annevk> | Noam Rosenthal: to be clear, "done" running before "end-of-body" is also bad |
| 12:45 | <Noam Rosenthal> | annevk: not sure why, but I can follow along |
| 12:46 | <annevk> | Noam Rosenthal: because whoever is passing these callbacks might set up state accordingly, if they get them out of order that could lead to unexpected results |
| 12:46 | <Noam Rosenthal> | annevk: right, and I thought that saying that done always come before end of body is equivalent to the opposite |
| 12:47 | <Noam Rosenthal> | though maybe it's less intuitive, naming-wise |
| 12:47 | <annevk> | "done" is the last thing, after "end-of-body" you might get trailers (though they are not exposed atm) |
| 12:48 | <annevk> | In any event, we wouldn't want to change the order as part of a PR to expose network errors better, right? |
| 12:51 | <Noam Rosenthal> | annevk: currently there are no callers of both "done" and "end of body". maybe they should be either/or? It would make things clearer. IMO having both callbacks doesn't make sense |
| 12:51 | <Noam Rosenthal> | "end of body" sort-of encapsulates "done" |
| 12:54 | <annevk> | Noam Rosenthal: we could merge them potentially |
| 12:54 | <annevk> | Noam Rosenthal: oh wait, end-of-body does its reading thing |
| 12:55 | <Noam Rosenthal> | yes exactly, we added done for fetch() and for random things which don't need the response body, such as sendBeacon |
| 12:55 | <annevk> | I think it's okay to use both, especially once we have trailers, but I could see adding that requirement for now |
| 12:56 | <Noam Rosenthal> | annevk: OK, so I can keep the order as is, but add an assert at the beginning of fetch. would that work? |
| 12:58 | <annevk> | Noam Rosenthal: I'm not sure I follow, what kind of assertion? |
| 12:59 | <Noam Rosenthal> | Noam Rosenthal: I'm not sure I follow, what kind of assertion? |
| 12:59 | <annevk> | Noam Rosenthal: I suggest we leave that to a follow-up PR, I'm not entirely convinced yet it's worth doing |
| 13:00 | <Noam Rosenthal> | annevk: ok, so is it still necessary to change the order right now? it complicates the logic a bit but doable |
| 13:05 | <annevk> | Noam Rosenthal: yeah, because we should set things like the done flag in the right order |
| 13:24 | <Noam Rosenthal> | annevk: updated both PRs, thanks for your time. btw with the » thingy, maybe it's worthwhile to add a lint rule to disallow the character that looks like it? |
| 13:26 | <annevk> | Noam Rosenthal: https://github.com/whatwg/whatwg.org/blob/main/resources.whatwg.org/build/deploy.sh has some lint rules you could update |
| 13:37 | <Noam Rosenthal> | Noam Rosenthal: https://github.com/whatwg/whatwg.org/blob/main/resources.whatwg.org/build/deploy.sh has some lint rules you could update |
| 15:02 | <sideshowbarker> | https://stackoverflow.com/questions/70261043/fetch-cancels-with-an-abortsignal-does-res-json-too |
| 15:37 | <annevk> | Added an answer |
| 19:15 | <Nghien Con> | cac |
| 22:07 | <kaleidea> | kaleidea: WICG/webcomponents is prolly a better starting point; you'll also run into it if you try to implement it in a browser @annevk I've dug through webcomponents. I've found the following worth to investigate: https://wiki.whatwg.org/wiki/Custom_Elements#Subclassing_existing_elements Are these the ones you've hinted at? |