| 07:20 | <annevk> | rbyers: I'm probably not the right person to ask, smaug____ et al designed that |
| 07:52 | <annevk> | rbyers: aklein is probably closer to you timezone wise, although you never know with smaug____ |
| 07:53 | <annevk> | Is there something like ripgrep for blame? |
| 07:56 | <Ms2ger> | smaug____ tends to hover between US west coast and US east coast as far as timezones go |
| 08:22 | <JakeA> | wanderview: https://github.com/WICG/background-fetch/issues/47 might explain the use-cases better. Supporting list[index] should be fine. The JS equivalent for getRange is list.slice, but it doesn't seem like that comes by default with webidl iterators. |
| 08:32 | <tobie> | JakeA: I guess you can always file an issue. We'd need to check whether adding it in WebIDL would conflict with other interfaces implementing iterators and then whether there's implementor interest. |
| 08:39 | <JakeA> | It makes me sad the number of MDN pages that suggest APIs are "unstable". Who has the power to change policy here? Who do I have to convince? |
| 08:39 | <JakeA> | Eg, two unflagged stable implementations shouldn't be considered experimental/unstable (eg https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API) |
| 08:41 | <Ms2ger> | Talk to sheppy |
| 08:41 | <Ms2ger> | On irc.m.o |
| 08:45 | smaug____ | pings sheppy on this matter |
| 08:51 | <zcorpan> | http://www.w3.org/mid/BAA808E3-0BCA-45AF-845C-541D35D7A330⊙wo ... wonder if i should point Tim to crbug.com/new ? Also shouldn't it be Vary: access-control-allow-origin ? |
| 08:56 | <annevk> | zcorpan: Vary: Origin is correct, I suspect it's credentials that's biting him |
| 08:57 | <annevk> | zcorpan: https://github.com/whatwg/fetch/issues/307 |
| 08:58 | <zcorpan> | ah right, I somehow thought Vary was for response headers |
| 09:05 | <zcorpan> | annevk: so one of https://github.com/whatwg/fetch/pull/496#issuecomment-287659974 ? |
| 09:13 | <annevk> | zcorpan: no |
| 09:13 | <annevk> | zcorpan: the spec still doesn't specify that behavior because only Fx implements it and Chrome is opposed (well Ryan Sleevi is) and I dunno about Safari and Edge |
| 10:10 | <smaug____> | rbyers: FWIW, I think MutationObserver part of the spec is quite reasonable. |
| 10:11 | <smaug____> | (I do regret microtasks a bit, but that isn't so much to do with MutationObserver anymore.) |
| 11:04 | <MikeSmith> | annevk: I’m pretty sure Tim’s case is that he is sending credentials. Otherwise he’d just have the server responding with the wildcard in the ACAO value, instead of an origin |
| 11:05 | <MikeSmith> | but I don’t understand why it’s not just a Chrome bug, regardless of whether the request includes credentials |
| 11:06 | <MikeSmith> | I mean, on the face of it at least, it seems like Chrome is ignoring the Vary: Origin header and not invalidating its cache when it should be |
| 11:09 | <annevk> | MikeSmith: oh, that does seem like a more basic bug, yes |
| 11:11 | <MikeSmith> | yeah to be clear, as far as I understand, Tim’s issue isn’t about credentialed and non-credentialed requests and expecting the cache to be shared between those |
| 11:11 | <MikeSmith> | his issue is sorta the oppositi |
| 11:11 | <MikeSmith> | he described this problem to me a long time ago but I didn |
| 11:12 | <MikeSmith> | didn’t know what to say other than that it sounded like a browser bug to meーnon-conformant behavior |
| 13:35 | <wanderview> | JakeA: MDN is also a wiki... you can make changes directly |
| 13:38 | <wanderview> | JakeA: I guess I still just wish IDB had a bulk getter that didn't require contiguous ranges |
| 14:03 | <yoav_> | annevk: So, I'm looking at https://github.com/w3c/preload/issues/95 and I think we need to say (in HTML) that `as` defines both the potential destination as well as the resulting request type |
| 14:04 | <yoav_> | and wondered what's the best way to define destination=>type mapping |
| 14:04 | <yoav_> | it's already "defined" in the non-normative note table in Fetch |
| 14:04 | <yoav_> | but could probably benefit from a normative definition |
| 14:04 | <yoav_> | where is request type set today? |
| 14:15 | <annevk> | yoav_: it's set by the places that create a request to fetch |
| 14:16 | <annevk> | yoav_: there's not really a destination=>type mapping though, they are separate things |
| 14:37 | <yoav_> | annevk: so if I want to define such mapping for preload, should I do that in the preload spec? |
| 14:41 | <annevk> | yoav_: I don't think it makes sense |
| 14:41 | <annevk> | yoav_: they're intentionally separate |
| 14:41 | <yoav_> | annevk: What I want to define is that for `<link rel=preload as=image>` the a |
| 14:41 | <yoav_> | Accept headers will state supported image types |
| 14:41 | <yoav_> | similarly to <img src> |
| 14:42 | <yoav_> | that's currently vaguely defined in the preload spec, in the section that you said is a duplicate in https://github.com/w3c/preload/issues/95 |
| 14:46 | <rbyers> | smaug____, annevk: thank you! |
| 14:46 | <annevk> | yoav_: looking over the current setup I wonder if we can do away with type now that destination is a strict superset (I don't think it was before) |
| 14:47 | <annevk> | yoav_: we'd have to define some shorthand for "is a script destination" though and update CSP and such |
| 14:47 | <yoav_> | that'd be good from my perspective |
| 14:48 | <annevk> | yoav_: (in particular, I think before media was a destination and types had audio and video) |
| 14:48 | <yoav_> | yeah, and then we broke them up |
| 14:49 | <annevk> | yoav_: I think that's probably the best course of action; we'd need review from mkwst and some other folks and figure out who depends on the current setup, would have to change quite a few standards I think |
| 17:23 | <Yuhong> | I do agree that caniuse.com etc probably does a better job than spec snapshots, but this is intended to be a compromise. |
| 17:46 | <Domenic> | annevk: I think rbyers was also asking about spec style. |
| 17:48 | <rbyers> | Domenic: Yeah, I just watched your "how to write good specs" talk, so am extra motivated to get better at using very precise style :-) |
| 17:49 | <annevk> | Domenic: oh, I haven't reviewed that section in a while, but it's probably okay |
| 17:50 | <Domenic> | It does seem OK |
| 17:50 | <Domenic> | DOM still does a lot of foo's <b>bar</b> instead of foo's <a>bar</a> |
| 17:50 | <Domenic> | But it seems to use internal slots correctly and such |
| 17:51 | <annevk> | Except for Event |
| 17:51 | <Domenic> | Oh, no, MutationRecord doesn't use slots properly |
| 17:51 | <Domenic> | Basically because MutationRecord should be a dictionary |
| 17:51 | <annevk> | And DOM has a problem in general with not having [[PlatformBrand]] in IDL |
| 17:52 | <Domenic> | rbyers: so yeah, MutationRecord being an interface instead of a dictionary seems not so good; otherwise things seem reasonable. |
| 17:55 | <rbyers> | Domenic: Thanks! |
| 17:59 | <annevk> | Domenic: note that esprehn will argue strongly for not using dictionaries for such things as it's hard for Chrome to cope |
| 18:00 | <TabAtkins> | For return values? |
| 18:00 | <annevk> | Yeah |
| 18:01 | <Domenic> | It's not really a return value, it's passed to a callback |
| 18:01 | <TabAtkins> | Yeah, agree; records are a bad pattern that we shouldn't be using. :( |
| 18:01 | <TabAtkins> | Domenic: Same diff really. |
| 18:01 | <annevk> | smaug____: I thought you said https://bugzilla.mozilla.org/show_bug.cgi?id=825057 was something we supported |
| 18:02 | <TabAtkins> | annevk: Note that esprehn has left Chrome to work elsewhere in Google. :( |
| 18:02 | <annevk> | TabAtkins: you agree with esprehn? |
| 18:02 | <annevk> | o_O |
| 18:02 | <TabAtkins> | I often do? |
| 18:02 | <smaug____> | annevk: hmm, I thought data was working |
| 18:02 | <annevk> | I do too, but for this issue |
| 18:03 | <TabAtkins> | Yeah, we shouldn't have done records, returning "dumb data objects" makes it user-observable if/when we change it to something with methods on it or with more complicated behavior. |
| 18:03 | <TabAtkins> | And passing to a callback is functionally identical to returning. |
| 18:06 | <smaug____> | annevk: data: seems to work here |
| 18:06 | <smaug____> | oh, silly me |
| 18:06 | <smaug____> | that was inside data: page |
| 18:06 | <smaug____> | not data: worker |
| 18:07 | <smaug____> | but I get PASS with the testcase there |
| 18:25 | <Yuhong> | If there are any other problems, I want to ask about them. |
| 20:24 | <jyasskin> | Has anyone started writing down the matching algorithm between request headers within Fetch and the request headers in a PUSH_PROMISE frame? |
| 23:54 | <luxio> | why do we only have one option for client-side scripting languages? |