| 07:27 | <zcorpan> | Domenic: https://twitter.com/zcorpan/status/1202958734949060608 |
| 11:17 | <yhirano> | annevk: hi |
| 11:22 | <annevk> | yhirano: heya |
| 11:23 | <yhirano> | annevk: do we have a wpt for document.domain mutation and cross-origin isolated? |
| 11:23 | <yhirano> | annevk: https://github.com/whatwg/html/pull/4734 |
| 11:24 | <annevk> | yhirano: I don't recall; Tim Tung had that on his list, but maybe he didn't get to it |
| 11:24 | <annevk> | Tom Tung* |
| 11:24 | <yhirano> | annevk: ok then i'm going to add one. |
| 11:25 | <annevk> | yhirano: I think Domenic might have written some for Origin Isolation too |
| 11:25 | <annevk> | maybe that can be reused |
| 11:30 | <yhirano> | annevk: thanks |
| 12:47 | <andreubotella> | hm, looks like bikeshed builds are failing because TabAtkins added support for dark mode and v.Nu doesn't like the "color-scheme" CSS property |
| 12:50 | <annevk> | andreubotella: leave a comment on https://github.com/whatwg/meta/issues/188? |
| 12:50 | <annevk> | I guess we should figure out where this remaining CSS is added and try to get Bikeshed to not do that for WHATWG |
| 12:58 | <andreubotella> | annevk: that sounds like something that should be fixed in v.Nu, though |
| 13:41 | <Domenic> | Bikeshed really should not be injecting CSS into WHATWG specs... |
| 14:04 | <TabAtkins> | I filed an issue for y'all |
| 16:34 | <andreubotella> | croraf: https://github.com/heycam/webidl/issues/921 |
| 16:34 | croraf | likes |
| 16:56 | <annevk> | JakeA: are there no tests for openWindow()? |
| 21:19 | <croraf> | Hi. When I encounter something like this: https://heycam.github.io/webidl/#a-promise-rejected-with in WebIDL should I consider this as a "macro" or as a "function"? |
| 21:20 | <croraf> | The difference is, do I just replace the caller with this code, or do I actually call this code? |
| 21:21 | <Domenic> | Function |
| 21:21 | <Domenic> | Macros are very few and called out explicitly as such |
| 21:21 | <Domenic> | Example of a macro: https://html.spec.whatwg.org/#spin-the-event-loop |
| 21:21 | <croraf> | Another example is the "1. React to promise" here https://heycam.github.io/webidl/#upon-fulfillment Do I call react, or I just imagine this bullet is replaced with the list bullets. |
| 21:21 | <croraf> | Domenic, ok, thx |
| 21:24 | <croraf> | This basically means, (and I think andreubotella noted that ) that there is another bug in here, because "upon fulfillment" https://heycam.github.io/webidl/#upon-fulfillment returns nothing, while it should return a promise generally. |
| 21:24 | <croraf> | Same with "upon rejection" |
| 21:24 | <andreubotella> | I looked into the different specs that used react, upon fulfillment and upon rejection |
| 21:25 | <andreubotella> | most don't use the returned promise, but some do |
| 21:26 | <andreubotella> | so either each of those callers have to be changed, or the WebIDL definition |
| 21:26 | <andreubotella> | it makes more sense to do the latter |
| 21:27 | <croraf> | What do you mean by changing the callers? The caller in fetch requires the returned promise. |
| 21:28 | <croraf> | Only if you meant that it should call "react" directly, passing the steps? |
| 21:29 | <croraf> | andreubotella, but this not make much sense to me, so only the latter option is possible, I think |
| 21:29 | <Domenic> | The intention at the time we wrote the Web IDL algorithms was to change the callers; upon fulfillment should be used when you have no plans to use the returned promise, and react should be used if you do want to use the returned promise. |
| 21:29 | <andreubotella> | it's not the only option, but sure, I mispoke there |
| 21:29 | <Domenic> | Maybe in the meantime a bunch of specs have started assuming "upon fulfillment" returns a promise, so we should just have it do so. |
| 21:30 | <andreubotella> | I'll check again, but I believe there were just a few cases |
| 21:31 | <andreubotella> | Domenic: could you review https://github.com/heycam/webidl/pull/922 and point that out? |
| 21:31 | <Domenic> | andreubotella: on my list for tomorrow morning :) |
| 21:31 | <croraf> | To think again, I actually dont see the reason of having "upon fulfillment" and "upon rejection" at all. |
| 21:32 | <croraf> | They are even more erroneous. Check this, what I found with andreubotella : |
| 21:34 | <croraf> | (let me think a bit more actually :) ) |
| 21:35 | <andreubotella> | croraf: most of the things we talked about weren't bugs per se, they were either misunderstandings or editorial nitpicks |
| 21:36 | <croraf> | Actually I'm again not clear about this. |
| 21:37 | <croraf> | It says that "react accepts one or two sets of steps". But below it says: |
| 21:37 | <croraf> | React to promise: |
| 21:37 | <croraf> | - If promise was fulfilled with value v, then: |
| 21:37 | <croraf> | 1. Perform steps with v. |
| 21:38 | <andreubotella> | I might not have made that clear, but "if promise was fulfilled with value v, then" isn't really part of the algorithm |
| 21:38 | <andreubotella> | it's a bit of an odd way to specify a callback parameter |
| 21:42 | <croraf> | If "React to promise" is similar to promise.then() so when promise is fulfilled with value "v" I guess "onFulfilled" is called with "v". And here it says that the steps are performed with "v". |
| 21:42 | <croraf> | Something must be wrong here. |
| 21:44 | <andreubotella> | haven't we already gone through that? |
| 21:45 | <croraf> | I guess that here it should only say "upon fulfillment" = "React to promise with *steps* provided as steps to do when fulfilled" |
| 21:46 | <croraf> | And if this is true the "upon fulfillment" seems completely unnecessary! |
| 21:47 | <croraf> | ( we have andreubotella ) |