| 00:34 | <Domenic> | TabAtkins: yeah, you can check "in a document tree" or "is connected". If you need to perform actions on every element being removed/inserted, then use removing steps I believe it's called. |
| 10:36 | <surma> | Streams spec q: Is there a reason why the class definitions are not more WebIDL-y? For example: I was surprised by the fact that the `closed` getter is in fact a promise. Would adding some sort of type annotation to the class definitions be desirable and acceptable? |
| 10:44 | <Domenic> | surma: I don't think we should add type definitions to the class definitions, since that is not how JS works |
| 10:45 | <Domenic> | surma: as for Web IDL vs. JS spec styles, see https://github.com/whatwg/streams/issues/45 |
| 10:46 | <surma> | I see |
| 10:46 | <surma> | You said in that issue “The class description is meant to be for web developers” — which I agree. I just think it’s currently somewhat hard to figure out that for example `closed` and `pipeTo()` return a promise |
| 10:47 | <surma> | Maybe there’s some other way we can make that more discoverable? Maybe we can just add type annotations for the return values? |
| 10:47 | <Domenic> | Hmm, doesn't it say "returns a promise" right in their web-developer facing descriptions? |
| 10:47 | <Domenic> | If not, indeed, perhaps we can make them say that |
| 10:47 | <surma> | Yeah I think it does |
| 10:47 | <surma> | The note does |
| 10:49 | <surma> | But for example the pipeTo note is quite long. The info is all there, I was just wondering if there’s an acceptable way to make it more structured and directly in the class definition. |
| 10:49 | <surma> | But it’s nbd, it definitely works as it currently is |
| 10:51 | <Domenic> | I think one way forward is noted in https://github.com/whatwg/streams/issues/907. Notably that would put an "await" before the usage. |
| 10:51 | <Domenic> | (and nuke the class definition entirely, since it seems less helpful than I was hoping.) |
| 10:54 | <surma> | (the #event-retargeting-steps anchor doesn’t seem to exist anymore btw) |
| 11:04 | <annevk> | surma: updated the link in OP to https://dom.spec.whatwg.org/#event-path |
| 11:04 | <annevk> | surma: (seems it was mostly about the domintro section; and we removed retargeting steps) |
| 11:04 | <surma> | ty! |
| 11:15 | <annevk> | surma: next time you fix something don't forget to add yourself to the Acknowledgments section |
| 11:16 | <surma> | I thought I was alreadfy listed in the stream spec |
| 11:16 | <annevk> | surma: I looked for "Surma" |
| 11:17 | <annevk> | foolip: in Chrome (maybe WebKit too), when would compatibility_mode_locked_ in Document.cpp be false? |
| 11:17 | <surma> | I could have sworn I added myself in with my first linkification PR |
| 11:18 | <surma> | Thanks for the hint. I will happily add myself with my current PR ;) |
| 11:18 | <annevk> | cool |
| 11:21 | <foolip> | annevk: it's initialized to false, and seems to be set to true in all Document subclasses except XMLDocument, although I didn't exhaustively check |
| 11:22 | <annevk> | foolip: I wonder why it exists then |
| 11:22 | <annevk> | foolip: document.open() tries to change mode to "no-quirks" in Chrome, but that can never succeed with such a setup |
| 11:24 | <annevk> | foolip: maybe just some dead code in Document.cpp's ImplicitOpen then |
| 11:24 | <foolip> | annevk: what are the per-spec situation when the compat mode should change? The comment "This is cheaper than making setCompatibilityMode virtual" suggests that the setup is a bit contrived for performance, but maybe the observable effect is correct? |
| 11:24 | <foolip> | annevk: dead code would not be surprising to find |
| 11:25 | <annevk> | foolip: per spec I don't know about any situation where it could change, though document.open() seems somewhat reasonable as a possible place (just not in the spec) |
| 11:25 | <foolip> | annevk: you suspect that the SetCompatibilityMode(kNoQuirksMode) call there never has any effect? |
| 11:26 | <annevk> | foolip: yeah, if all subclasses freeze the value per that variable and you can only invoke document.open() on HTML documents... |
| 11:27 | <annevk> | foolip: the only other "legit" caller that I found was cloneNode() and friends, and I guess there you want to set it to be the same as the document you are cloning, so that makes some sense |
| 11:28 | <foolip> | annevk: I'll try adding an assert and running it through all bots to see if that disproves the dead code hypothesis quickly |
| 11:30 | <annevk> | foolip: thanks |
| 11:30 | <foolip> | annevk: https://chromium-review.googlesource.com/c/chromium/src/+/986136 |
| 11:30 | <annevk> | I want to know how document.open() in non-Firefox works to see if we can just make the spec say that |
| 11:33 | <kochi> | annevk: the document seems to be only readable by @chromium.org :( I asked the author to change the permission. |
| 11:34 | <annevk> | kochi: ta |
| 12:41 | <smaug____> | annevk: isn't blink doing exactly what Gecko does with submit/reset |
| 12:42 | <annevk> | smaug____: maybe I got misled due to the nested form stuff |
| 12:43 | <annevk> | smaug____: I guess I should write some tests to make sure, but if my proposal matches Fx then hurray? |
| 12:44 | <smaug____> | annevk: yeah, I think you did describe what Gecko does |
| 12:44 | <smaug____> | er, except |
| 12:44 | <smaug____> | no no, it is fine. there is event's currentTarget != event's target |
| 12:55 | <annevk> | smaug____: it seems in theory get the parent could add an event listener that does this |
| 12:56 | <annevk> | smaug____: though if not implemented that way it would be observable so maybe not worth it |
| 13:16 | <Ms2ger> | What's the difference between [[Foo]] and [[foo]] in ES? |
| 13:47 | <annevk> | Ms2ger: I think one is the old convention |
| 15:18 | <Domenic> | One names an internal slot named "Foo", the other names an internal slot named "foo" |
| 15:18 | <Domenic> | It is similar to `x.Foo` vs. `x.foo` |
| 15:20 | <annevk> | Domenic: I think a decision was made about casing though |
| 15:20 | <annevk> | Domenic: to use uppercase throughout |
| 15:20 | <Domenic> | I'm not sure ES ever used lowercase |
| 15:21 | <annevk> | Domenic: https://github.com/tc39/ecma262/commit/a2f6bfd7c547a306f428f9ecde9baf5fe04f2c8f |
| 15:21 | <Domenic> | Hah wow, I've thoroughly adapted to the new world :). |
| 15:22 | <annevk> | Domenic: I guess technically you're no longer editing Streams |
| 15:22 | <annevk> | (it uses old-style) |
| 15:22 | <Domenic> | It's a multi-editor situation |
| 15:22 | <Domenic> | We have an open issue to update, but nobody feels strongly |
| 15:23 | <Domenic> | In practice, most of my work is in sprints when I visit Tokyo, with ricea holding down the fort most of the time |
| 15:24 | <Domenic> | He did pretty much all the work for transform streams though, which is the most recent big chunk |
| 15:24 | <annevk> | Seems pretty exciting |
| 15:24 | <annevk> | I wonder if ricea is interested in adding them to WebSocket |
| 15:25 | <Domenic> | We talked about it; the issue is prioritizing vs. other work (mostly on the implementation side) |
| 15:26 | <Domenic> | The naive wrapping, i.e. a productionized version of https://streams.spec.whatwg.org/#example-both with real backpressure support, might not be much |
| 15:26 | <Domenic> | A lgrahl-style stream-of-streams seems harder |
| 15:26 | <Domenic> | Unclear who the customers are though |
| 15:31 | <annevk> | It does seem there's still some interest in WebSocket given what I hear occasionally, but maybe not that much indeed |
| 15:31 | <annevk> | That might also due to it not supporting some features folks would really like though, such as being able to set an Authorization header |
| 15:39 | <lgrahl> | I do know of at least one customer :) |
| 15:40 | <lgrahl> | Domenic: And once we have them for data channels, we can pretty much c&p it for WebSockets |
| 15:40 | <Domenic> | that'd be a good order of operations, yeah |
| 15:42 | <lgrahl> | Yes and I'm also wondering whether QUIC will move into the WebSockets area |
| 17:21 | <domfarolino> | I thought I understood the purpose of WebIDL but now I'm a little confused. It seems that a big part of WebIDL is to facilitate the conversion of ECMAScript values to WebIDL values, and any language (like C++) can implement WebIDL and therefore have a proper conversion from ECMAScript values => C++ values etc. |
| 17:21 | <domfarolino> | But isn't this what each ECMAScript implementation already does? For example, in v8 there certainly are already bindings that take in JS values and eventually v8 uses them in C++-land. So it almost seems like WebIDL is just an extension of ECMAScript, further nailing down abstract conversions right? |
| 17:22 | <domfarolino> | could we not just write interfaces (in web specs) in the form of ECMAScript constructs (intrinsic objects, properties, etc). After all, this is what native ECMAScript objects are defined in right? |
| 17:30 | <domfarolino> | cc TabAtkins as I know he's answered a few WebIDL questions here before |
| 17:32 | <TabAtkins> | We avoid that because it's *incredibly* fiddly. Reading the ES spec is a high-level skill that very few people can actually do effectively (most implementors can't), and *writing* it is even harder. WebIDL just lets us abstract most of that away. |
| 17:33 | <TabAtkins> | The whole point of WebIDL is in the name - it's a language for describing web interfaces, so we don't have to actually *write* the interfaces, in their full gory details, by hand. (And get things wrong, and handle things inconsistently, etc.) |
| 17:34 | <domfarolino> | TabAtkins: Ok that makes sense, so WebIDL sort of packages some ECMAScript things together in a form to succinctly describe interfaces that use ECMAScript constructs. |
| 17:35 | <TabAtkins> | Yeah. This way all methods and properties are attached to classes in the same way, all arguments are converted in the same predictable manner, etc. We're left with mostly just the *relevant* details to specify, the parts that actually matter to authors. |
| 17:35 | <domfarolino> | TabAtkins: So it could almost be a subset of the ECMAScript spec that would allow other web standards to hook into it to more easily used the tricky and arduous constructs? |
| 17:35 | <domfarolino> | Ok that makes sense thank you. |
| 17:35 | <TabAtkins> | I guess that's basically what it is, sure? |
| 17:36 | <TabAtkins> | (What's the context of these questions, by the way?) |
| 17:36 | <domfarolino> | Giving a talk at my school tonight; just hammering down a few stray details |
| 17:39 | <domfarolino> | Previously I've read a good bit of the ECMAScript spec and it made sense (this was long after visiting WebIDL a while ago), then some thoughts hit me when I was connecting the dots. |
| 17:43 | <annevk> | domfarolino: the WebIDL repository has a bunch of issues labeled "jsidl" which is an idea to bring both ways of writing specifications closer to each other |
| 17:43 | <annevk> | domfarolino: if we succeed with that at some point it'd become much easier to define a new JavaScript class |
| 17:46 | <domfarolino> | annevk: Ah ok that's really exciting! |
| 17:51 | <domfarolino> | annevk: So given that web APIs are defined with WebIDL (and conversions here etc are specified), and ECMAScript built-in objects are *not* defined with WebIDL (obviously) (though they too appear on the web), you're saying the `jsidl` issues attempt to roughly converge on how the two standards express objects/APIs? Is that roughly correct? |
| 17:54 | <annevk> | domfarolino: yes |
| 17:56 | <railgun> | annevk: just to confirm I add the default values under "Value" right? https://html.spec.whatwg.org/multipage/indices.html#attributes-3 |
| 17:57 | <annevk> | railgun: I was thinking we'd add a new column |
| 17:58 | <annevk> | railgun: makes it easier to spot at a glance and such (and seems somewhat more correct too) |
| 17:59 | <railgun> | ok I'll try adding a new column |
| 18:01 | <annevk> | railgun: FWIW, I'm properly back at work Tuesday |
| 18:09 | <railgun> | ok |
| 18:10 | <domfarolino> | annevk: Ah https://github.com/heycam/webidl/issues/486 is really interesting |