| 08:33 | <JakeA> | wanderview: I am now! |
| 09:32 | <zcorpan> | TabAtkins: ping about fingerprint :-) |
| 13:30 | <wanderview> | JakeA: any thoughts on this? https://github.com/w3c/ServiceWorker/issues/1163 |
| 13:32 | <JakeA> | wanderview: I assume it follows the same weird replacement rules as about:blank iframes? |
| 13:33 | <JakeA> | If so, yeah I agree with you |
| 13:33 | <wanderview> | JakeA: well, its the difference between parent and opener... I guess I was asking from a "what would a web developer expect" point of view? |
| 13:35 | <JakeA> | wanderview: I don't think many developers understand about:blank's relationship to the parent/opener. But I think making iframe about:blank and window.open about:blank behave the same is the best thing |
| 13:35 | <wanderview> | ok |
| 13:36 | <wanderview> | JakeA: we have some bugs that make window.open() not behave the same as about:blank iframe, unfortunately |
| 13:38 | <JakeA> | wanderview: it's pretty edge-casey I think |
| 13:39 | <wanderview> | JakeA: yea... and lots of compat issues except for a few narrow cases |
| 13:39 | <wanderview> | JakeA: about:blank replacement is only really handled the same between browsers when you do `<iframe src="nested.html"></iframe><script>/* poke frame */</script>` |
| 13:42 | <JakeA> | wanderview: it blew my mind when I learned about it. Especially that the global survives. |
| 13:44 | <wanderview> | I guess I will just focus on the iframe case for now |
| 14:58 | <wanderview> | JakeA: using waitUntil in an async function event handler is kind of awkard |
| 14:58 | <wanderview> | awkward |
| 15:00 | <wanderview> | is there some trick? |
| 15:20 | <JakeA> | wanderview: what's the benefit of an async function event handler? |
| 15:20 | <wanderview> | JakeA: being able to use await? |
| 15:20 | <JakeA> | wanderview: I sometimes do event.waitUntil(async function() { … }()) |
| 15:20 | <wanderview> | hmm |
| 15:20 | <wanderview> | yea. I guess that makes sense |
| 15:21 | <JakeA> | wanderview: I suggested that we should implicitly pass the handler return value to waitUntil, but that's kinda weird as handler return values are already used |
| 15:21 | <JakeA> | returning false calls preventDefault |
| 15:21 | <wanderview> | JakeA: I guess I got confused because I was writing a delayed response thing... so was using a different pattern |
| 15:23 | <wanderview> | JakeA: I guess the immediately invoked pattern is a bit weird to me |
| 15:23 | <wanderview> | but I know its common in web dev |
| 15:24 | <JakeA> | wanderview: I wonder if module scripts are an opportunity to provide a convenience API. Eg export async function install() { … } |
| 15:25 | <wanderview> | JakeA: I guess you have to use `async function() {}()` and not `async _ => { }()`> |
| 15:25 | <wanderview> | ? |
| 15:26 | <JakeA> | wanderview: you could export const install = async () => {…} |
| 15:26 | <wanderview> | JakeA: oh, I was asking about the immiediately invoked syntax |
| 15:27 | <JakeA> | oh sorry |
| 15:27 | <wanderview> | JakeA: module exports seem interesting |
| 15:27 | <wanderview> | JakeA: I think it would behave different with exceptions thrown from the event handlers today, though |
| 15:27 | <JakeA> | wanderview: you can do waitUntil((async () => {…})()) but it looks really messy |
| 15:27 | <wanderview> | or maybe we would just have to spec it to work the same |
| 15:28 | <JakeA> | wanderview: yeah, I'm not sure how exporting a fetch function would work, given that you have to call respondWith sync |
| 15:28 | <JakeA> | also, these exported functions receiving an event object might be a little weird |
| 15:51 | <Domenic> | One day we think we might have `async do { ... }` which is like a less-messy `(async () => { ... }())` |
| 15:51 | <Domenic> | But first we need to figure out sync `do { ... }` |
| 15:51 | <Domenic> | Which is unfortunately nontrivial because `var` hoisting |
| 15:58 | <TabAtkins> | Domenic: Just exclude `var` from do statements, simple. ^_^ |
| 16:29 | <wanderview> | JakeA: fun about:blank test case: https://github.com/w3c/web-platform-tests/pull/6304 |
| 19:20 | <wanderview> | JakeA: ok, I added a window.open() case as well |
| 19:24 | <zcorpan> | MikeSmith: i managed to write something to the <title> (for https://github.com/whatwg/wattsi/issues/50 ) ^_^ |
| 20:37 | <Domenic> | People may enjoy: https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-for-spec-authors |
| 20:41 | <Domenic> | tobie: getting all those closed issue emails in a row was fun :D |
| 21:11 | <tobie> | Domenic: :) |
| 21:12 | <tobie> | Domenic: shouldn't FrozenArray be a valid JSON type? |
| 21:12 | tobie | is asking for a friend. |
| 21:31 | <Domenic> | tobie: I can't see how it would arise, since they really only occur as attributes on interfaces, right? |
| 21:33 | <tobie> | Domenic: step 2.3 of https://heycam.github.io/webidl/#collect-attribute-values |
| 21:33 | <tobie> | Domenic: checks whether an attribute is of JSON type before adding it to the object returned by the default toJSON operation |
| 21:34 | <Domenic> | Ah right, for the default one, yes |
| 21:34 | <Domenic> | Then yeah, agreed |
| 21:34 | <tobie> | OK, fixing. |
| 21:34 | <tobie> | Domenic: (needed for https://heycam.github.io/webidl/#collect-attribute-values) |
| 21:36 | <tobie> | Domenic: additional quick help request for |target| variable used here: https://heycam.github.io/webidl/#ref-for-get-the-underlying-value-1 |
| 21:37 | <tobie> | Domenic: this is supposed to be a reference to the object that implements `Transaction`. Should I just use <emu-val>this</emu-val> instead? |
| 21:38 | <tobie> | or "the object implementing Transaction"? |
| 21:38 | <Domenic> | tobie: I've been doing "this Transaction object", although the exact phrasing here is an open issue. |
| 21:40 | <tobie> | Domenic: "the current ..." ? |
| 21:41 | <tobie> | Domenic: I just want the "The following <var>s were only used once in the document" warning to go. :D |
| 21:47 | <Domenic> | Well "this" has the right connotation |
| 21:48 | <Domenic> | tobie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27301 |
| 21:49 | <tobie> | Domenic: heh |
| 21:50 | <tobie> | Should bump this in the list of priorities |
| 21:51 | <tobie> | Domenic: I went with: "Let value be result of getting the underlying value of the attribute identified by attr, for the given Transaction object." bad? |
| 21:51 | <Domenic> | I just don't understand why you prefer "the given" (who gave it to you?) instead of "this" |
| 22:02 | <tobie> | Domenic: I don't. I just went from "given |target|" to "given this Transaction object" to ", for the given Transaction object" instead of "for this Transaction object". |
| 22:03 | <Domenic> | Oh! |
| 22:03 | <Domenic> | I misunderstood. |
| 22:04 | <Domenic> | You are not wanting to modify the example, you are wanting to modify the definition? |
| 22:04 | <Domenic> | No, nevermind |
| 22:05 | <tobie> | Domenic: no, I actually had "given |target|" in the example (don't ask) |
| 22:05 | <Domenic> | Yeah ok. Seems fine I guess. I would have done "given this Transaction object". |
| 22:06 | <tobie> | Domenic: contemplating force pushing. |
| 22:51 | <MikeSmith> | zcorpan: cool 👉 > i managed to write something to the <title> |