| 06:19 | <zcorpan> | Hmm, found a bug with the redirect script. Clicking Table of Contents redirects to indices.html#index |
| 07:27 | <tobie> | Can anyone enlighten me on the difference between these two things: https://gist.github.com/tobie/13840ae7dd7dae00ab498f5d55c82ca9? |
| 07:29 | <tobie> | What's the benefit of using a mixin over a partial in such cases? |
| 07:30 | <tobie> | What elements should editors consider when deciding between one or the other? |
| 07:31 | <annevk> | tobie: that should be a partial, but html-build is being annoying |
| 07:31 | <tobie> | annevk: Oh! |
| 07:32 | <tobie> | annevk: That was my impression too. Will add a note to this effect in mixins. |
| 07:32 | <annevk> | tobie: I might even just put it straight on Window actually when I have some time, it's all in the same spec anyway |
| 07:32 | <tobie> | I've seen that pattern elsewhere recently, hence the question |
| 07:33 | <tobie> | annevk: eg: https://gist.github.com/tobie/999f7d5bcc3a7767f75945ad683162bb |
| 07:35 | <annevk> | tobie: that's different |
| 07:35 | <annevk> | tobie: that's a mixin |
| 07:36 | <annevk> | tobie: that could use partial interface WindowOrWorkerGlobalScope though |
| 07:36 | <tobie> | yeah |
| 07:36 | <annevk> | tobie: for WindowOrWorkerGlobalScope we'll need partial mixins, not sure if you already identified that |
| 07:37 | <tobie> | annevk: yes. |
| 07:44 | <zcorpan> | annevk: https://github.com/whatwg/wattsi/issues/37 still applies? |
| 07:46 | <annevk> | zcorpan: oh maybe |
| 07:46 | <annevk> | zcorpan: yeah it does |
| 07:46 | <annevk> | zcorpan: when we made html.spec.whatwg.org cgi free we didn't fix wattsi |
| 07:46 | <annevk> | zcorpan: Domenic probably knows what to do |
| 07:47 | <zcorpan> | ok, I assigned the issue to him |
| 07:48 | <annevk> | I disabled the webhook for now |
| 09:28 | <tobie> | Interfaces vs mixins vs namespaces: https://user-images.githubusercontent.com/3392/29916512-4f6a5b98-8e3f-11e7-923d-6c465c6c2352.jpg |
| 09:30 | <annevk> | looks reasonable |
| 09:55 | <tobie> | good |
| 10:05 | <annevk> | JakeA: btw, can you make changes to https://github.com/whatwg/fetch/pull/523 as new commits? |
| 10:05 | <annevk> | JakeA: we can just squash & merge when landing |
| 10:06 | <JakeA> | annevk: ok. I was squashing as I went along because it was easier to deal with rebase conflicts. I've been trying to keep up with master |
| 10:06 | <JakeA> | but we can leave that until merge time |
| 10:10 | <annevk> | JakeA: I think it's fair to squash after a round of reviews, but for new feedback having separate commits makes it easy to see if the feedback got addressed |
| 10:11 | <JakeA> | annevk: gotcha |
| 12:52 | <TimothyGu> | question: is there any history behind "Please leave your sense of logic at the door, thanks!"? sounds like an inside joke or something that I havent' been able to figure out |
| 12:54 | <nox> | TimothyGu: The Web grew organically, |
| 12:54 | <gsnedders> | TimothyGu: much of the web platform being totally nonsensical and undesigned |
| 12:54 | <nox> | and sometimes make no sense. |
| 12:54 | <nox> | makes* |
| 12:54 | <TimothyGu> | ah okay, that |
| 12:55 | <gsnedders> | (it's been in the topic for idk how long, over a decade I'm pretty sure, back when most work in here was on HTML and trying to reverse engineer browser behaviour) |
| 12:55 | <TimothyGu> | thanks people |
| 12:56 | <Ms2ger> | Dates back to 2006 at least: https://krijnhoetmer.nl/irc-logs/whatwg/20061201 |
| 12:57 | <gsnedders> | pretty sure it was here when I joined a month or two before that |
| 12:57 | <Ms2ger> | What were you then, ten years old? |
| 12:57 | <gsnedders> | something like that |
| 12:59 | <TimothyGu> | hm |
| 12:59 | <TimothyGu> | is Hixie not active in whatwg anymore? |
| 13:00 | <Ms2ger> | Hasn't been for a few years now, I think |
| 13:00 | <TimothyGu> | ok.. |
| 13:01 | <TimothyGu> | i'm just looking over the irc channel stats lol |
| 13:03 | <gsnedders> | AFAIK he works on Flutter nowadays |
| 13:12 | <gsnedders> | so I'm calling Promise.resolve(promise) but promise.then seemingly never gets called? have I misudnerstood something? |
| 13:14 | <gsnedders> | like, even Promise.resolve(pending_promise).then(function(){alert(1);}); doesn't do anything |
| 13:18 | <wanderview> | Domenic: did I see you comment on a github issue about xhr not triggering an error event if the window is closed? |
| 13:22 | <Ms2ger> | (Two years, apparently) |
| 13:25 | <jgraham> | More than that I thought |
| 13:25 | <jgraham> | But maybe |
| 13:25 | <gsnedders> | nah, seems about right |
| 13:25 | <wanderview> | JakeA: do you know about my question above regarding XHR and window close? ^^^ |
| 13:25 | <Ms2ger> | That's what the git history claims |
| 13:26 | <Ms2ger> | But I guess he was starting to disappear for a while before that |
| 13:26 | <gsnedders> | a long while before that |
| 13:26 | <wanderview> | JakeA: we have a bug about FF rejecting fetch() promises when the window is navigated, but apparently chrome doesn't reject in that case... wondering if chrome is following some xhr behavior, etc? https://bugzilla.mozilla.org/show_bug.cgi?id=1280189 |
| 13:26 | <wanderview> | might be relevant for the abort spec PR |
| 13:28 | <gsnedders> | more completely, Promise.resolve(new Promise(function(){})).then(function(){console.log(1);}); returns a still pending promise |
| 13:28 | <gsnedders> | which isn't what I understood Promise.resolve to do with a promise as an argument? |
| 13:28 | <Ms2ger> | Doesn't it wait for microtasks? |
| 13:29 | <gsnedders> | it should still eventually resolve, then, though? |
| 13:30 | <JakeA> | wanderview: hmm, I'm not sure what the correct behaviour is here, but I agree we should spec it. I guess Firefox is performing https://fetch.spec.whatwg.org/#concept-fetch-group-terminate |
| 13:34 | <wanderview> | JakeA: not sure what the spec says, but it seems we may avoid doing the XHR event on navigation because we check to see if the window is still the current, active one: http://searchfox.org/mozilla-central/source/dom/xhr/XMLHttpRequestMainThread.cpp#1389 |
| 13:34 | <wanderview> | promise rejection probably doesn't do that |
| 13:35 | <wanderview> | maybe we shouldn't reject a promise on an inactive window? |
| 13:35 | <benjamingr_> | As a user I would not expect a rejection here - I would expect cancellation flow |
| 13:35 | <benjamingr_> | I would expect it to behave exactly like aborting with an AbortController |
| 13:35 | <JakeA> | That would be an AbortError rejection |
| 13:36 | <wanderview> | which currently gets converted to a NetworkError by fetch API, right? |
| 13:36 | <JakeA> | If it goes through a service worker, yeah |
| 13:36 | <wanderview> | hmm |
| 13:37 | <wanderview> | right, I guess my glitch test showed AbortError |
| 13:37 | <wanderview> | for some reason I thought fetch() always rejected with NetworkError |
| 13:37 | <JakeA> | Nah, almost always TypeError |
| 13:37 | <JakeA> | but now AbortError :D |
| 13:38 | <JakeA> | (if it's an abort) |
| 13:38 | wanderview | is getting himself confused. |
| 13:38 | <benjamingr_> | I gave a short talk on why fetch is cool after people complained about the API not being as nice as axios for some stuff - I used `AbortController` as if it has been there forever and no one called my bluff :D |
| 13:38 | <JakeA> | But if something else aborts the connection, like the browser, should that show up as an abort? |
| 13:38 | <JakeA> | Because the dev didn't abort it, the browser did |
| 13:39 | <wanderview> | JakeA: in my glitch test I seem to get TypeError |
| 13:39 | <benjamingr_> | I think so, I also think that's what XHR does |
| 13:39 | <benjamingr_> | (in terms of showing to the user) |
| 13:39 | <JakeA> | As in, if the server aborts, that *doesn't* show up as an abort error |
| 13:39 | <JakeA> | that's just a connection failure |
| 13:39 | <benjamingr_> | If the server aborts that's different because the server closed the socket and not the client |
| 13:39 | <wanderview> | well, I mean... I just tried loading my glitch test and navigated away while it was running... saw a TypeError displayed briefly before the next page appeared |
| 13:40 | <JakeA> | But if the browser cuts you off, is that "Ahh yes, this is just an abort", or "wtf I was cut off"? |
| 13:40 | <wanderview> | I kind of think it should be an AbortError |
| 13:40 | <wanderview> | but I dunno |
| 13:41 | <benjamingr_> | If the browser cuts you off for navigation, I'd expect "Ahh yes, this is just an abort" but not if the server aborts it. |
| 13:41 | <benjamingr_> | The reason is that if I have my own single page app - this is the behavior I'd expect navigation to have |
| 13:41 | <JakeA> | benjamingr_: what if the user cuts you off by hittin the X in their browser? |
| 13:49 | <benjamingr_> | That's still an abort |
| 13:50 | <JakeA> | Ok, cheers! |
| 13:50 | <benjamingr_> | I'm just going off my intuition here - none of what I'm saying is backed up by anything other than my feeling about what I'd expect, by the way :D |
| 13:57 | <JakeA> | yeah, I'm still trying to figure it out |
| 15:00 | <wanderview> | JakeA: riddle me this... outer fetch() is intercepted, FetchEvent is dispatched on worker thread, outer fetch() is aborted while FetchEvent is being processed... what should happen? |
| 15:00 | <wanderview> | should the outer fetch() reject with AbortError immediately? or should it wait for the FetchEvent in some way? |
| 15:01 | <JakeA> | wanderview: immediate abort |
| 15:02 | <JakeA> | wanderview: the worker is like the network at this point. It may or may not abort, it may abort after some time, but as far as the page is concerned, it's aborted |
| 15:02 | <wanderview> | JakeA: what about a respondWith() called after that? does it silently just eat the response or does it reject or something? |
| 15:03 | <wanderview> | does it keep the SW alive? |
| 15:03 | <JakeA> | wanderview: silent I think. It may not keep the sw alive, but waitUntil should. fetchEvent.request.signal will have signalled abort |
| 15:11 | <wanderview> | JakeA: in theory we could let respondWith() still keep the SW alive and trust that the FetchEvent.request.signal would abort that promise in most cases |
| 15:11 | <JakeA> | wanderview: true, I'm fine with that |
| 16:28 | <Domenic> | annevk: with the new scripts wattsi should be updated each time, in theory |
| 16:43 | <annevk> | Domenic: cool, so I can remove the Webhook completely then |
| 16:44 | <Domenic> | ah, yep |
| 16:44 | <annevk> | done |
| 16:45 | <tobie> | currently, NoInterfaceObject interfaces have an interface prototype object. Do we need to keep something similar for mixins (for web compat reasons) or can we basically treat mixins as a purely IDL construct (similarly to partials)? |
| 16:51 | <tobie> | Answering my own question: "If the interface is used solely as a supplemental interface, then there will be no way to access its interface prototype object, since no object will have the interface prototype object as its internal [[Prototype]] property value. In such cases, it is an acceptable optimization for this object not to exist." |
| 17:11 | <tobie> | Mmm, it seems https://heycam.github.io/webidl/#es-constants says nothing about constants defined on consequential interfaces. It that by design or is that a mistake? |
| 17:12 | <tobie> | (For comparison, https://heycam.github.io/webidl/#es-attributes is explicit about this: "For each exposed attribute of the interface, whether it was declared on the interface itself or one of its consequential interfaces, […]" |
| 17:13 | <tobie> | Domenic: ^ |
| 17:15 | <Domenic> | tobie: seems like an oversight, although maybe the intent was you can't declare constants on our current way of doing mixins |
| 17:15 | <tobie> | Domenic: some do declare constants (e.g. in WebGL) |
| 17:15 | <Domenic> | I see |
| 17:15 | <tobie> | Domenic: seems like an oversight, as operations is also missing this |
| 17:16 | <Domenic> | I mean maybe it's just a redundant clause |
| 17:16 | <tobie> | (again answering my own questions, I might be getting tired) |
| 17:16 | <tobie> | possibly. Would be good to be consistent. |
| 17:16 | <tobie> | Or better to move to a more imperative style. |
| 17:55 | <Domenic> | +1 imperative, as always |
| 18:33 | <gsnedders> | what are objects that define their own [[get]], [[set]], etc. called nowadays? |
| 18:34 | <gsnedders> | (or, rather, objects from WebIDL that do this) |
| 18:58 | <tobie> | gsnedders: https://heycam.github.io/webidl/#es-legacy-platform-objects ? |
| 19:45 | <gsnedders> | tobie: I guess I was thinking more something along the lines of what the ES spec used to call "host objects". Is there any term still defined in ES for such things? |
| 19:58 | <jsbell> | gsnedders: "exotic objects" |
| 19:59 | <jsbell> | semantics may not be identical, tho |
| 19:59 | <annevk> | Not quite the same, but new system has no place for host objects |
| 19:59 | <annevk> | All objects need to conform to the MOP |
| 20:01 | <tobie> | oh, yes, exotic objects. Defined here: https://tc39.github.io/ecma262/#sec-exotic-object |
| 20:04 | <tobie> | I need to distinguish "mixins included by interface A" from "mixins included by interface A and by inherited interfaces of A" |
| 20:05 | <tobie> | what can I call these knowing that the latter one is the one most commonly used across the spec? (Corresponds to the former "Consequential interfaces of A") |
| 20:06 | <TabAtkins> | "own interfaces"? |
| 20:07 | <tobie> | TabAtkins: "own mixins" would be for the former, right? |
| 20:07 | <TabAtkins> | yeah |
| 20:07 | <tobie> | TabAtkins: and you'd call the latter just "mixins of" |
| 20:07 | <TabAtkins> | yup |
| 20:08 | <tobie> | This is a lot more straightforward than consequential interfaces. I'm not sure it's acceptable. |
| 20:09 | <tobie> | WebIDL needs to be obscure and complicated, dammit! |
| 20:09 | <tobie> | That's super helpful, TabAtkins. Thanks. |
| 20:12 | <TabAtkins> | ^_^ |
| 20:26 | <gsnedders> | jsbell: ahhh, thx |
| 20:26 | <gsnedders> | annevk: yeah, I knew they'd been changed as part of the rename |
| 22:39 | <tobie> | Do callback interfaces support maplike and setlike declarations? The spec isn't clear about this. |
| 23:02 | <TabAtkins> | They shouldn't? They're just a legacy feature around callback functions. |
| 23:02 | <Domenic> | ^ that |
