00:55:32  * cloudshuquit (Quit: Connection closed for inactivity)
01:36:48  * aki_joined
01:37:36  * akirosequit (Ping timeout: 252 seconds)
01:37:37  * aki_changed nick to akirose
02:21:47  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
02:24:09  * AtumTquit (Quit: AtumT)
02:38:42  <Domenic>For WHATWG there's a service/bot that uses webhooks and renders every incoming PR and edits the OP of the PR with links to the preview
03:43:34  * akirosequit (Ping timeout: 240 seconds)
03:43:52  * akirosejoined
03:48:44  <ljharb>Domenic: where does it host them, on the service?
04:11:43  * jmdyckquit (Remote host closed the connection)
04:34:00  * Sirisian_joined
04:37:34  * Sirisianquit (Ping timeout: 240 seconds)
05:51:08  * akirosequit (Ping timeout: 272 seconds)
05:51:32  * akirosejoined
06:58:16  * brandonmatthewsquit (Quit: Connection closed for inactivity)
07:57:41  * aki_joined
07:59:06  * akirosequit (Ping timeout: 252 seconds)
07:59:06  * aki_changed nick to akirose
09:15:04  * dpkquit (Ping timeout: 240 seconds)
09:32:54  * dpkjoined
10:03:26  * aki_joined
10:04:07  * akirosequit (Ping timeout: 240 seconds)
10:04:07  * aki_changed nick to akirose
11:30:52  * gibson042quit (Ping timeout: 250 seconds)
12:10:54  * akirosequit (Ping timeout: 244 seconds)
12:14:06  * akirosejoined
12:48:42  * jmdyckjoined
12:49:24  * AtumTjoined
13:29:06  * Aquazijoined
13:31:18  <Domenic>Yes, AWS
14:17:04  * cloudshujoined
14:20:57  * aki_joined
14:22:08  * akirosequit (Ping timeout: 244 seconds)
14:22:08  * aki_changed nick to akirose
14:40:50  <jmdyck>Hm, anyone else having problems connecting to github.com?
15:08:34  <devsnek>nope
15:08:52  <devsnek>github has been known to go down in specific regions though
15:09:08  <devsnek>https://status.github.com/messages
15:50:01  <jmdyck>thanks for the link. Perhaps I'm in the "small portion of users unable to access the site"
16:28:08  * aki_joined
16:28:34  * akirosequit (Ping timeout: 246 seconds)
16:28:36  * aki_changed nick to akirose
16:35:42  * jwaldenjoined
18:25:58  * howdoiquit (Quit: Connection closed for inactivity)
18:28:38  * gskachkov_quit (Quit: Connection closed for inactivity)
18:30:46  * plumaquit (Quit: Connection closed for inactivity)
18:36:07  * akirosequit (Ping timeout: 240 seconds)
18:36:12  * aki_joined
18:36:36  * aki_changed nick to akirose
19:04:09  * akirosequit (Quit: 👋🏻)
19:06:25  * akirosejoined
21:12:35  <Bakkot>why did I decide to start looking at for-in behavior. this is terrible.
21:13:53  * aki_joined
21:14:10  * akirosequit (Ping timeout: 246 seconds)
21:14:25  * aki_changed nick to akirose
21:16:27  <Bakkot>also, bterlson, ping re: https://github.com/bterlson/eshost-cli/pull/58
21:34:38  <gsathya>Bakkot, typo on coalsece
21:36:35  <Bakkot>gsathya, thanks, fixed
21:38:12  <ljharb>Bakkot: yes, for-in is terrible
21:41:12  <Bakkot>ljharb: I think I'm gonna propose (informally; I'd build a PR and come back for formal consensus) that we nail down the behavior precisely for at least one or two cases
21:41:40  <Bakkot>the current spec fails to capture some things which are, per implementors, actual requirements for an engine which wants to not break websites
21:41:47  <ljharb>SGTM
21:41:53  <cloudshu>Bakkot: what'd you have in mind?
21:41:59  <cloudshu>if it can be summarized
21:42:01  <Bakkot>and as of a couple years ago there's an intersection semantics as long as you "don't do anything dumb"
21:42:03  <ljharb>if it's web reality then i'd think you can go right to a needs consensus PR, personally
21:43:07  <Bakkot>cloudshu: there's a reference implementation which all engines match in the common case (except for an open bug in Chakra), where "common case" is https://gist.github.com/bakkot/85611eccde8c8ca425e1d6c86741194c
21:43:13  <Bakkot>(this gist refers to files which are not yet public)
21:43:56  <Bakkot>(the engines listed after bullet points differ from majority in that case)
21:44:33  <cloudshu>i regret reading that lits
21:44:35  <cloudshu>list
21:44:38  <Bakkot>cloudshu: so my proposal is essentially: if you are in the "common case", you must observably match the reference implementation
21:44:39  <Bakkot>lol
21:44:40  <Bakkot>yeah.
21:45:35  <Bakkot>cloudshu: oh, also I want to say that you must observably match the reference implementation when given a proxy.
21:46:25  <ljharb>so wouldn't we just make the spec steps have that observable behavior, and unobservable parts can get optimized away at engines' preference?
21:46:55  <Bakkot>ljharb: the problem is that when you are not in that common case, observable behavior differs, not just unobservable behavior.
21:47:06  <ljharb>oh :-/
21:47:19  <cloudshu>Bakkot: that sounds good to me. what are your thoughts about the observable differences
21:47:31  <cloudshu>is there explicit allowance now?
21:48:23  <Bakkot>yeah, the current spec text is "do whatever you want, as long as they adhere to these extremely loose and difficult to interpreter longform-prose rules which are not even well-defined in a world with proxies"
21:48:36  <Bakkot>s/interpreter/interpret/
21:48:47  <cloudshu>that sounds good. i am against us trying annex b-like heroics here
21:48:51  <Bakkot>see https://tc39.github.io/ecma262/#sec-enumerate-object-properties
21:49:13  <cloudshu>since i regard annex b as an unfortunate state of affairs that ended up introducing more weirdness
21:50:26  <Bakkot>cloudshu: my two big problems with the existing spec text are 1) it fails to capture de-facto constraints, like "you can't enter the loop with a property which has been added to the base object since the start of iteration" and 2) it is literally meaningless when there are proxies
21:50:36  <cloudshu>+2
21:51:14  <Bakkot>so, my proposal is to nail it down in the common case and in the case of proxies, and leave it as loose as currently the rest of the time
21:51:22  <cloudshu>it's definitely worth our time to find and state the intersection
21:52:01  <cloudshu>my only concerns are i don't want it to be normative optional or use any weird spec mechanics (like the counterfactual stuff)
21:52:35  <Bakkot>yeah, would definitely not want it to be Annex B. Spec mechanics are going to be really hard to pin down.
21:53:12  <cloudshu>i'm going to quote waldo here
21:53:15  <cloudshu>good luck, we're all counting on you
21:54:12  <Bakkot>:|
21:54:28  <Bakkot>Anyway, not gonna present a PR at this meeting, just basically the above things and ask if it's worth trying to write a PR.
23:20:53  * aki_joined
23:21:07  * akirosequit (Ping timeout: 240 seconds)
23:21:07  * aki_changed nick to akirose
23:21:56  * Sirisian_part
23:22:05  * Sirisianjoined