03:50:05  * tcarequit (Quit: Connection closed for inactivity)
04:09:33  * jmdyckquit (Quit: Leaving.)
04:56:05  * gskachkov_joined
04:56:24  * dilijevquit (Quit: Connection closed for inactivity)
05:54:57  * gskachkov_quit (Quit: gskachkov_)
06:07:07  * dilijevjoined
06:31:54  <ljharb>annevk: since we seem to be going back and forth; TC39 has refused, many times, to solve this problem in a generic way - so instead it's solved in a unique and different way for each type. i don't think HTML can just pass the buck by saying "TC39 should solve it" while they're simultaneously trying to solve a problem (cancellation) that TC39 should also
06:31:54  <ljharb>solve :-)
06:33:32  <annevk>ljharb: it seems more by accident that it's solved for most types as it's not solved for Error
06:33:56  <annevk>ljharb: so it's not clear TC39 actually thinks this is a problem worth solving
06:33:58  <ljharb>the accident is that it's not solved for error, indeed
06:34:17  <annevk>ljharb: and therefore, it's not clear to me we should consider it a problem worth solving
06:34:19  <ljharb>the committee's decision when i tried to get toStringTag pulled before ES6 was that every type, forever, would have *some* method of brand checking
06:34:34  <ljharb>in other words, it's worth solving, but not worth solving generically.
06:34:44  <annevk>ljharb: but they didn't solve it for Error
06:34:48  <ljharb>that was an oversight
06:34:55  <annevk>ljharb: so that is being fixed?
06:34:55  <ljharb>had i noticed that at the time, we'd have had to
06:34:57  <ljharb>yes
06:35:01  <ljharb>in the error stacks proposal
06:35:14  <ljharb>`System.getStack` or whatever it ends up being called, will throw if given a non-Error object.
06:35:20  <annevk>ljharb: then it would also be solved for DOMException
06:35:33  <ljharb>that will solve "is it an Error"
06:35:39  <ljharb>not "is it this specific type of Error"
06:35:56  <annevk>ljharb: okay, so is that being fixed?
06:35:58  <ljharb>so it wouldn't help me distinguish between a DOMException and a TypeError
06:36:02  <ljharb>no
06:36:14  <annevk>ljharb: then we're back to does TC39 think this is worth solving
06:36:14  <ljharb>but i'm sorry, that doesn't relieve you of the responsibility imo
06:36:23  <annevk>Well, imo it does
06:36:30  <ljharb>that's really reductionist and lazy :-
06:36:32  <ljharb>:-/
06:36:49  <annevk>It's not lazy, it seems pretty clear TC39 is not aligned on whether this is a problem
06:36:55  <ljharb>that is somewhat accurate
06:37:02  <annevk>If they were, they'd solve it in a way that would make it efficient
06:37:03  <ljharb>but that doesn't mean it's not a problem
06:37:10  <ljharb>checking internal slots is already efficient
06:37:16  <ljharb>it's just a bit in the underlying C++ or similar
06:37:19  <annevk>Not for programmers
06:37:25  <annevk>Not for folks writing JavaScript
06:37:34  <ljharb>oh you mean, efficient for JS devs
06:37:37  <annevk>They have to use rather weird hacks
06:37:39  <ljharb>yes, that's true
06:37:46  <annevk>So again, is it worth solving needs to be solved first, imo
06:38:08  <ljharb>the problem is that if it's not solved by *something* soon then there will be a period of time where it *can't* be done
06:38:20  <ljharb>in other words, i'm saying it's critical to ship *something* that brand checks, pending a better solution
06:38:32  <ljharb>because it's impossible to brand check, or polyfill the better solution later, if there's no underlying primitive method
06:38:48  <ljharb>absolutely i will be pursuing further improvements on brand checking
06:38:57  <ljharb>but right now i'm just trying to stop the bleeding
06:39:26  <ljharb>adding a `Symbol.asInstance` method that's cross-realm *would*, btw, be efficient for JS devs
06:39:56  <ljharb>it would mean `foo instanceof DOMException` worked cross-realm (altho it thus wouldn't tell you if DOMException.prototype was the __proto__, ofc, but that's easy to check directly)
06:42:34  <ljharb>if you want to hold off on shipping cancellation entirely, until TC39 has a generic solution, then fine
06:42:43  <annevk>It's extremely easy to add brand checking later
06:42:58  <annevk>Because we already have brands for all platform objects
06:43:04  <annevk>They're just not always exposed
06:43:04  * gskachkov_joined
06:43:26  <ljharb>it's easy for implementations to add them, sure
06:43:38  <ljharb>it's *impossible* for JS devs to polyfill them in those browsers after the fact tho.
06:43:54  <ljharb>like for Map - if we add `Map.is` or something, that's only polyfillable because Map.prototype has brand-checking methods already
06:44:02  <ljharb>ie, some brand checking primitive must exist
06:44:17  <ljharb>so if you're concerned about efficiency or ergonomics for JS devs…
06:44:32  <annevk>FWIW, I'd love to add Symbol.isInstance or some such, but we'd really need TC39 on board
06:44:42  <ljharb>? Symbol.asInstance already exists
06:44:50  <ljharb>you'd just define your own implementation, which is totally allowed in the spec
06:45:09  <annevk>Oh right, Firefox does that, but no other browser wants to
06:45:17  <annevk>So that likely won't work out
06:45:22  <ljharb>wants to implement the instanceof hook?
06:45:30  <ljharb>i was not aware there was any delay in implementing it
06:45:49  <annevk>No, Firefox implements it for platform objects in a way that makes it work cross-realm
06:45:55  <annevk>No other browser wants to do that
06:46:06  <ljharb>oh
06:46:08  <ljharb>why not?
06:46:10  <annevk>Because TC39'rs recommended against it
06:46:13  <ljharb>what, where?
06:47:14  <annevk>ljharb: see all the links from https://github.com/heycam/webidl/issues/129
06:47:35  <annevk>ljharb: mostly Allen and Mark
06:47:52  <annevk>ljharb: I referenced that issue from the DOM PR too btw
06:47:56  <ljharb>hm, which links?
06:48:00  <ljharb>neither of them are commenting on that thread
06:48:19  <ljharb>ah, the esdiscuss one
06:48:47  <annevk>ljharb: also the Bugzilla links at the end
06:48:52  <ljharb>ok so i see a comment from allen that "instanceof should probably be fixed for everything", which it totally should
06:48:56  <annevk>ljharb: the mailing list link points to the "Solving the "how do I tell whether I have an HTML element?" (or image element, or whatever) problem" thread, btw
06:49:07  <ljharb>right
06:49:14  <annevk>which is totally about this issue
06:49:30  <ljharb>indeed
06:49:40  <ljharb>altho i suspect the 2011 comments are based on obsolete proxy specs
06:49:59  <annevk>they're still the same sentiment, solve generally or bust
06:50:02  <ljharb>but sure, i'm not attached to using `Symbol.hasInstance`
06:50:15  <ljharb>right, but i think those arguments are flawed
06:50:36  <ljharb>because they ignore that there needs to be a primitive so that it can be polyfilled later
06:51:45  <annevk>That hasn't been a huge source of problems for platform objects over many years of existence, though I agree it would be good to solve and I don't understand why TC39 doesn't want to solve it
06:51:53  <ljharb>right, neither do i
06:52:04  <ljharb>but does that mean we shouldn't make the problem worse now?
06:52:16  <ljharb>it hasn't been a huge source of problems because working with realms sucks
06:52:25  <ljharb>but the realms api will make that easier. and it will be polyfillable back to very old browsers via iframes.
06:52:42  <annevk>We could block that API on solving this
06:52:46  <ljharb>and forcing people to not use a feature unless they drop old browser support is not a great path to adoption
06:52:55  <ljharb>i am totally fine with blocking on solving this.
06:53:12  <ljharb>i just don't want more things shipped that provide no primitive to let this be solved later.
06:53:19  <annevk>But I don't see how blocking any new object on solving this is fair
06:53:29  <ljharb>i also agree
06:53:37  <ljharb>which is why i think providing some form of brand check now is a good compromise
06:53:38  <annevk>If the reams API is the problem, let's block on that
06:53:50  <ljharb>the realms api will make the problem bigger. it's not the problem
06:53:55  <ljharb>the problem has always existed
06:54:18  <annevk>Right, so adding a couple new objects for cancel/abort is not making it worse
06:54:25  <ljharb>i don't know about web builtins; but with JS builtins, only Error has this problem, and nobody knew that until a few months ago
06:54:30  <ljharb>i think it is
06:54:46  <ljharb>because it creates a window of browsers where brand-checking detection is *not possible*
06:54:57  <annevk>that's already the case though
06:55:10  <ljharb>not for cancellation
06:55:26  <ljharb>that it's the case for some things, does not mean it's not worse to make it the case for more things
06:55:48  <ljharb>ie, it's not "it's a problem, therefore it doesn't matter if we make it worse", making it worse is making it worse
06:56:04  <annevk>I'm not really convinced we're making it worse
06:56:22  <annevk>anyway, gotta go
06:56:28  <ljharb>considering how eager people are to use fetch and stop using jquery, i think it will be a big problem.
06:56:44  <ljharb>k, ttyl
07:19:58  * gskachkov_quit (Quit: gskachkov_)
09:38:53  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
09:46:48  * gskachkov_joined
10:08:22  * sebmckjoined
10:25:10  * mylesborinsquit (Quit: farewell for now)
10:25:50  * mylesborinsjoined
10:31:15  * sebmckquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:56:51  * gskachkov_quit (Quit: gskachkov_)
11:01:48  * sebmckjoined
11:08:21  * gskachkov_joined
11:13:21  * gskachkov_quit (Quit: gskachkov_)
11:42:08  * gskachkov_joined
12:34:01  * jmdyckjoined
12:41:34  * gskachkov_quit (Quit: gskachkov_)
12:51:51  * bradleymeckjoined
13:13:24  * bradleymeckquit (Quit: bradleymeck)
13:24:57  * bradleymeckjoined
13:32:13  * bradleymeckquit (Quit: bradleymeck)
14:43:15  * gskachkov_joined
15:07:21  * gskachkov_quit (Quit: gskachkov_)
15:08:18  * gskachkov_joined
15:11:29  * gskachkov_quit (Client Quit)
15:44:43  <Domenic>One of the benefits of not doing cancelation in TC39 is that we don't have to block on concerns from 1-person TC39 factions like ljharb's "everything must be brand-checkable" faction.
15:45:20  * sebmckquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:45:50  <Domenic>Instead we can just solve the web's problems which is canceling fetch/streams/credentials requests/etc.
15:47:30  <Domenic>You can see how successful this has been because we've been able to add many many DOMException types over the last few years without being blocked by ljharb every step of the way.
15:48:54  <annevk>If we were in charge branding would've been a thing too, so that objection would no longer be there 😊
15:49:20  <annevk>Branding exposed in a reasonable manner to JavaScript developers, that is
15:49:27  <Domenic>Well, if bz was in charge, at least :)
15:51:03  <annevk>We use branding checks ourselves all the time, not exposing them to developers is very much against the extensible web manifesto, though that whole thing kinda faded
15:51:31  <Domenic>We don't "brand"-check DOMExceptions
15:53:26  <annevk>Fair
15:55:14  <annevk>Domenic: you're with awb then that this shouldn't be a thing?
15:55:20  <Domenic>Pretty much
15:55:57  <annevk>Domenic: so when I write some custom code and need to branch on whether something is an element or text node, you'd argue for just using some property?
15:56:04  <Domenic>Yeah
15:56:12  <annevk>Domenic: which would be very different from how the platform itself behaves?
15:56:23  <Domenic>Yeah
15:56:42  <Domenic>It allows better flexibility on the part of someone passing things in to you to pass mocks etc.
15:57:40  <Domenic>The platform sometimes needs private data (which causes an effective brand check), but ideally it would only rely on public data. In practice it always relies on public data because the first thing implementations do is go grab the private C++ "data" and use that.
15:57:54  <Domenic>s/In practice it/In practice the platform/
15:58:10  <Domenic>Author code has the choice to only rely on public data, which is great
15:58:24  <Domenic>Author code should not be introducing artificial brand checks and then relying on public data anyway
15:58:30  <annevk>You mean in practice it relies on private data?
15:58:38  <Domenic>Oops, yeah
16:00:36  <Domenic>The only other argument I've heard relies on security model where you're protecting against malicious code injected into your origin. Which is a threat model certain TC39 members endorse, but definitely not one we worry about on the web.
16:02:46  <annevk>I mean, we do worry about it to some extent. That's why we added sandboxing, CSP, etc.
16:03:56  <Domenic>There's a distinction between "preventing injection of such code" (sandboxing/etc.) and "encouraging the injection of such code but programming super-carefully so such code cannot break your code's invariants"
16:04:10  <annevk>Rereading https://github.com/whatwg/dom/pull/434#issuecomment-292640413 it still doesn't have much justification, but maybe what you're saying here is it
16:04:35  <annevk>Domenic: so does Mark Miller want this?
16:05:06  <Domenic>He's happy with non-ergonomic ways, and IIRC he only needs it for specific classes?
16:05:21  <annevk>Domenic: I tend to agree that on the web the view is that if untrusted code executes in your origin you're hosed
16:05:39  <annevk>Domenic: I see
16:06:32  <annevk>Domenic: maybe with the Realms API folks think they can run untrusted code safely there somehow?
16:06:48  <Domenic>That does seem to be an emerging design tension
16:07:15  <annevk>So many subtle bugs will emerge from that
16:09:04  <annevk>TabAtkins: ^^ (re Twitter)
16:10:57  <annevk>TabAtkins: Domenic is in favor of "looks like" tests (and so are others in TC39), personally I'm not sure I know enough to go either way, so I guess I'm happy with the status quo
16:15:23  <dilijev>Was reading the notes from the last tc39 meeting and laughed a bit when 402 update was delayed for a second time due to technical difficulties. Every conference is the same :-P
16:50:38  <ljharb>Domenic: let's not claim i'm "blocking every step of the way", i don't think it'll be productive to try to count up how many times an individual was the sole dissenter on something.
16:50:55  <Domenic>Definitely, productivity is not TC39's strong suit.
16:51:40  <ljharb>while it's been made clear that there are people who aren't convinced that brand-checking is a good idea, what has not been made clear is what the harm would be if these brand-checking methods - which are easy to implement, and don't break other aspects of the semantics - were just added.
16:51:42  * sebmckjoined
16:51:52  <ljharb>iow i *do* hear that i haven't yet made a convincing enough case to persuade everybody
16:52:03  <ljharb>but i don't hear why it's necessary to block *a brand-checking method*
16:52:20  * gskachkov_joined
16:53:13  <ljharb>(considering this isn't enabling a new programming model, it's just extending an existing one to fill the holes where it's not possible)
17:02:29  * gskachkov_quit (Quit: gskachkov_)
18:28:09  * sebmckquit (Read error: Connection reset by peer)
18:34:27  <dilijev>Devil's advocate: harm is adding more things to the spec, producing more changes that web devs need to wait for the whole web to adopt before they can be used.
18:35:02  <dilijev>FWIW I think that spec self-consistency of an already-mostly-possible thing is a laudable goal, and I don't see any harm in adding them.
18:35:27  <dilijev>(my 2c as an idealist and not as a spec writer, only informed in a limited way by being an implementer)
18:37:10  * not-an-aardvarkjoined
19:28:14  * gskachkov_joined
20:14:55  * gskachkov_quit (Quit: gskachkov_)
20:27:58  * jmdyckquit (Ping timeout: 240 seconds)
20:30:05  * jmdyckjoined
21:01:37  * gskachkov_joined
21:47:04  * gskachkov_quit (Quit: gskachkov_)