| 06:56 | <Ms2ger> | Hixie's really made it now: https://twitter.com/CodeWisdom/status/898664302726356992 |
| 09:20 | <TimothyGu> | annevk: what do you mean by obj.trailer != obj.trailer? obj.trailer is a promise that AFAICT isn't changed? |
| 09:22 | <annevk> | TimothyGu: hmm I was thinking of an IDL exception which would always be wrapped in a new promise |
| 09:23 | <annevk> | TimothyGu: I guess this might be slightly different |
| 09:23 | <TimothyGu> | yeah IIRC it just rejects an existing promise, doesn't create a new one |
| 09:23 | <annevk> | TimothyGu: still not a big fan of making it reject though, we don't even do that for network errors atm |
| 09:24 | <annevk> | TimothyGu: it's not like we make accessing obj.headers throw |
| 09:24 | <annevk> | that's prolly the better rationale, JakeA ^^ |
| 09:30 | <JakeA> | annevk: hmm. We don't really return network error responses, but if headers works there I guess it makes sense. Although isn't it weird not being able to tell the difference between aborted response and no trailers? |
| 09:30 | <annevk> | JakeA: I think that is a bit weird |
| 09:31 | <annevk> | JakeA: okay, maybe we should just keep this as-is |
| 09:31 | <annevk> | JakeA: not a big fan of it, but adding response.aborted or some such also seems weird |
| 09:33 | <JakeA> | annevk: shall I try and fix up the trailer and response constructor stuff as part of the same PR? |
| 09:34 | <TimothyGu> | JakeA: would be good to add a [SameObject] to trailers, if you decide to work on the current PR a bit more |
| 09:35 | <JakeA> | TimothyGu: yeah, makes sense |
| 09:35 | <TimothyGu> | oh wait, https://github.com/heycam/webidl/issues/71... sigh never mind |
| 09:36 | <JakeA> | Hm |
| 09:37 | <annevk> | JakeA: what is wrong wit hthe trailer and response constructor? I might have missed something |
| 09:38 | <annevk> | TimothyGu: I think I explicitly removed [SameObject] at some point due to it being incompatible with promises |
| 09:39 | <JakeA> | annevk: https://fetch.spec.whatwg.org/#response-class always resolves the trailer promise with an empty set of headers |
| 09:40 | <JakeA> | So it can't later be resolved with the actual trailer headers |
| 09:41 | <JakeA> | annevk: oh, maybe I'm wrong, because the Response constructor isn't invoked |
| 09:41 | <JakeA> | It just creates a new Response object |
| 09:42 | <JakeA> | Sorry, my bad |
| 09:42 | <annevk> | TimothyGu: maybe you're up for reviewing the full changeset with Domenic being away? |
| 09:42 | <annevk> | TimothyGu: if you still have that free time that is |
| 09:43 | <JakeA> | Ah, you just posted that on the issue |
| 09:43 | <TimothyGu> | yeah I do, though I'm not sure I have the expertise to review properly. I'll try though. |
| 09:44 | <TimothyGu> | annevk: the language is "resolve the trailer promise" not "set the trailer promise to..." so I think it's still the same |
| 09:46 | <annevk> | https://github.com/heycam/webidl/pull/217 is why promise getters cannot use SameObject btw |
| 09:51 | <annevk> | JakeA: I guess what I meant is that if you have a late network error (something closes the connection) trailer will just be empty |
| 09:51 | <annevk> | JakeA: maybe that's okay though |
| 10:22 | <JakeA> | annevk: I don't have a strong opinion, but returning an empty set of headers on abort seems weird. Resolving with undefined is another option, but that's not what fetch() does in light of abort/failure |
| 10:24 | <annevk> | JakeA: that's fair, but it's also weird that early connection close does result in an empty set |
| 10:25 | <JakeA> | annevk: maybe networkError.headers should be null? |
| 10:25 | <JakeA> | or undefined. I'm never sure when we use one or the other |
| 10:28 | <annevk> | JakeA: sorry, networkError.headers doesn't matter as you said, I'm talking about response.trailer when there's an early connection close |
| 10:29 | <JakeA> | annevk: We error the stream in this case, so shouldn't we reject trailers with the same/similar error? |
| 10:30 | <annevk> | JakeA: yeah, I think that might make sense |
| 10:30 | <JakeA> | If response.text() rejects, but response.trailers fulfills, it's a little asymmetric |
| 10:31 | <JakeA> | But I take your point that's it'd be weird having a property throw (in a sync world), but I guess this is an async-only problem |
| 12:02 | <tobie> | annevk: do callback interfaces need [Exposed=Window] to? |
| 12:03 | <tobie> | annevk: or is that just relevant for those that have constants? |
| 12:03 | <annevk> | tobie: dunno, tbh I was looking at IDL yesterday and was surprised by dictionaries having them |
| 12:03 | <annevk> | tobie: and apparently dictionaries can have constructors |
| 12:04 | <annevk> | tobie: I forgot about all that and I'm not totally sure I like it |
| 12:04 | <tobie> | what? |
| 12:05 | <annevk> | tobie: it seems that self.EventListener returns undefined so I guess only those with constants really need it |
| 12:05 | <annevk> | tobie: [Exposed] is a thing you can use on dictionaries (hopefully only required when it has a constructor, I didn't investigate) |
| 12:08 | <tobie> | So [Exposed] and [Constructor] don't apply to dictionaries (phew!) |
| 12:08 | <tobie> | annevk: ^ |
| 12:11 | <annevk> | tobie: "The following extended attributes are applicable to dictionaries: [Constructor], [Exposed], [SecureContext]," |
| 12:11 | <annevk> | tobie: might wanna fix that then |
| 12:14 | <tobie> | annevk: weird. That doesn't seem to match the description of either extended attributes, nor (hopefully) actuals specs. |
| 12:15 | <tobie> | Same for SecureContext, really. What does it do to a dictionary? |
| 12:25 | <annevk> | I vaguely recall dictionaries having constructors somewhere |
| 12:25 | <annevk> | I don't know why that was done or how it works though |
| 12:27 | <tobie> | that's not defined anywhere |
| 12:34 | <annevk> | Maybe it got removed again? I'm pretty sure it was discussed |
| 12:41 | <Ms2ger> | Was that for DOMPoint? |
| 12:43 | <annevk> | Ms2ger: maybe |
| 12:48 | <annevk> | Ms2ger: https://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/0032.html indeed maybe |
| 12:48 | <annevk> | Ms2ger: still unclear and not going to dig further for now |
| 12:49 | <annevk> | I'll file an issue on that sentence anyway |
| 13:02 | <tobie> | annevk: ty |
| 13:02 | <annevk> | JakeA: thoughts on TimothyGu's comment in the PR? |
| 13:03 | <tobie> | annevk: do global interfaces also need to have an [=Exposed=] ext attr? |
| 13:03 | <annevk> | JakeA: I'm happy to merge at this point; just need an updated commit title/body with links to tests and such |
| 13:03 | <annevk> | tobie: yeah |
| 13:03 | <tobie> | annevk: ta |
| 13:03 | <annevk> | tobie: and [Global] |
| 13:04 | <annevk> | tobie: I was thinking they could maybe omit Exposed, but that does not work for [Global=(Worker,DedicatedWorker), Exposed=DedicatedWorker] and such (it would end up too widely exposed) |
| 13:05 | <annevk> | tobie: and to create a special rule if Global only lists one value seems like too much magic |
| 13:05 | <tobie> | annevk: agreed it seems easier and less error-prone to be explicit all the time. |
| 13:14 | <wanderview> | does anyone know the current status of "html modules"? es module semantics for loading html documents... I thought someone was working on a proposal for it |
| 13:23 | <annevk> | wanderview: https://github.com/w3c/webcomponents/issues/645 there's not much of a proposal thus far |
| 13:23 | <annevk> | wanderview: but there's some convergence on ideas it seems |
| 13:24 | <wanderview> | annevk: thanks |
| 13:25 | <wanderview> | annevk: ah, this was the last thing I had seen: https://github.com/dglazkov/webcomponents/blob/html-modules/proposals/HTML-Imports-and-ES-Modules.md |
| 13:26 | <annevk> | wanderview: that's pretty dated compared to that thread I'd say |
| 13:26 | <wanderview> | yea, just saying thats how old my info was before asking here |
| 13:33 | <annevk> | wanderview: I guess you'll be at TPAC? |
| 13:34 | <wanderview> | annevk: yes |
| 13:34 | <annevk> | wanderview: interested in also doing this? |
| 13:34 | annevk | isn't going |
| 13:34 | <wanderview> | annevk: I would sit in the meeting, but not sure I am very knowledgeable or on the same page as other folks at mozilla |
| 13:36 | <annevk> | wanderview: I don't think we really have a position per se, other than trying to work with library developers (including the non-Google ones) |
| 13:37 | <annevk> | wanderview: thus far our position has mostly been that we'd like to see <script type=module> roll out first and then see experimentation by libraries |
| 13:37 | <annevk> | wanderview: which hasn't really happened yet... |
| 13:37 | <wanderview> | yea |
| 14:39 | <zcorpan> | hmm, is Exposed needed even for NoInterfaceObject interfaces? |
| 14:40 | <zcorpan> | I thought first they were not allowed together |
| 14:46 | <tobie> | zcorpan: that'll be clearer once I include mixins |
| 14:47 | <tobie> | zcorpan: I think you want them to describe where they're exposed, as you can have a [NoInterfaceObject] that you want mixed-in in one global but not the other. |
| 14:47 | <annevk> | zcorpan: I think they are, but it should not be like that |
| 14:47 | <annevk> | hmm |
| 14:48 | <annevk> | tobie: I don't think that's a good model, since we don't assert which objects you can be mixed in with either |
| 14:49 | <annevk> | tobie: let me rephrase, I think it's good to allow, but I think by default it should inherit |
| 14:50 | <tobie> | annevk: OK, this is good stuff to get figured out. |
| 14:50 | <tobie> | annevk: (prior to adding mixins) |
| 14:51 | <tobie> | annevk: Do we have cases of mixins that choose where they're exposed? |
| 14:53 | <tobie> | annevk: or is it always the case that their exposition is decided by the interfaces which implement them? |
| 14:53 | <annevk> | tobie: mostly the latter, cannot think of cases for the former |
| 14:53 | <annevk> | tobie: note that the former can always be done by just putting [Exposed] on the member itself |
| 14:53 | <annevk> | tobie: as e.g. XHR does for responseXML (not a mixin, but same deal) |
| 14:54 | <tobie> | annevk: oh, right. |
| 14:54 | <annevk> | Navigator might have had more of that if it were designed in a time where we had [Exposed] |
| 14:54 | <annevk> | But now we have Navigator and WorkerNavigator |
| 14:54 | <annevk> | which is rather silly |
| 14:56 | <tobie> | annevk: so it optional if you have [NoInterfaceObject], but it's there, it must be a subset of what it gets implemented in. |
| 14:57 | <tobie> | annevk: let me rephrase that |
| 14:59 | <tobie> | annevk: so [Exposed] is optional if you have [NoInterfaceObject]. If it's nonetheless specified, then the exposed set must be a subset of what the exposed set of the interface it gets mixed-in to. |
| 15:02 | <annevk> | tobie: a subset of the union of the exposed sets of the interfaces it gets mixed into |
| 15:02 | <annevk> | tobie: I'd think |
| 15:03 | <annevk> | tobie: if you want to add something to Navigator and WorkerNavigator, but exclude the ServiceWorker global, for instance |
| 15:10 | <tobie> | annevk: the union or the intersection? |
| 15:10 | <annevk> | tobie: latter I guess |
| 15:11 | <annevk> | tobie: I think I continue to be confused by the word union when it comes to set theory |
| 15:11 | <annevk> | maybe back later, maybe tomorrow; good day all |
| 15:11 | <tobie> | have a nice evening |
| 15:14 | <zcorpan> | I didn't include Exposed for NoInterfaceObject interfaces in csswg-drafts, but can fix if they should have it |
| 15:30 | <Ms2ger> | I think you should |
| 19:32 | <tobie> | Relaxed the requirements for NoInterfaceObject |
| 19:34 | <zcorpan> | meanwhile I added Exposed in csswg-drafts :-P |
| 19:48 | <tobie> | I saw. |
| 19:49 | <tobie> | :) |
| 20:18 | <dmarr> | how does fetch know what credentials to send when the credentials: 'include' option is set? |
| 20:18 | <dmarr> | i am returning a 401 with WWW-Authenticate header from my api, and i want to basically have a client page that can send in the creds manually |
| 23:44 | <TabAtkins> | Domenic: I think I've hit my limit of obvious perf hacks for the moment, but the last few days of work have knocked off 15-20% of DOM's processing time, so yay! (And a bunch was changes that benefit short specs, too.) |