| 07:47 | <nox> | gsnedders: Don't know if you remember our past discussion about timeouts and load events, |
| 07:47 | <nox> | gsnedders: "By default the test harness will assume there are no more results to come when: * There are no Test objects that have been created but not completed * The load event on the document has fired" |
| 07:47 | <nox> | So that seems like if you delay the load event indefinitely, the test will timeout. |
| 09:22 | <JakeA> | annevk: Is it ok for specs to say "A {{Whatever}} object represents a [=whatever=]", where whatever is a concept, or should it be "A {{Whatever}} has a [=Whatever/whatever=] (a [=/whatever=])" |
| 09:23 | <JakeA> | The latter feels more precise. We went that way with headers in the fetch spec and it felt more precise and easier to reference. |
| 09:23 | <annevk> | JakeA: the former is okay if it's nothing else |
| 09:23 | <annevk> | JakeA: but if you then also add additional fields, it gets confusing |
| 09:24 | <JakeA> | annevk: yeah, results in a lot of text like "Let |foo| be {{Whatever}}'s associated [=whatever=]", which is difficult to track through the spec |
| 09:24 | <annevk> | JakeA: though in case of the former the question becomes why not flatten whatever into {{Whatever}}? |
| 09:25 | <JakeA> | annevk: because [=whatever=] can exist without {{Whatever}} |
| 09:25 | <annevk> | JakeA: e.g. DOM doesn't have a concept for elements and an Element object, it just has the latter |
| 09:26 | <JakeA> | annevk: In this case [=whatever=] is part of storage, and {{Whatever}} is an instance that exposes it |
| 09:26 | <annevk> | JakeA: okay, I think it's fine to just say represent then |
| 09:26 | <JakeA> | annevk: gotcha, cheers |
| 09:26 | <annevk> | Notification has something similar, but a tad more complex |
| 09:26 | <annevk> | There it's a M:1 relationship |
| 09:27 | <JakeA> | annevk: I've been pretty specific about it in background fetch https://wicg.github.io/background-fetch/#backgroundfetchregistration-background-fetch, but I can revisit that |
| 09:28 | <annevk> | JakeA: I think being specific is better |
| 09:29 | <annevk> | JakeA: I suspect that once we have internal slots we'll end up refactoring everything to use those, but there might be a case for some variant where an object exposes a concept 1:1 |
| 09:30 | <JakeA> | annevk: I'm not familiar with internal slots, is there somewhere I can read up on those? |
| 09:30 | <annevk> | JakeA: it's the [[slot]] notation ECMAScript uses for private fields of objects |
| 09:31 | <annevk> | JakeA: I've been lobbying to get something like that in IDL so we can stop with the informal "has an associated" language and actually define the private object layout more formally |
| 09:31 | <annevk> | JakeA: https://github.com/heycam/webidl/issues/258 |
| 09:32 | <JakeA> | Cheers! |
| 11:09 | <gsnedders> | nox: oh well |
| 11:10 | <gsnedders> | nox: if that's a problem, we should just add an explicit harness done function |
| 11:54 | <nox> | gsnedders: It’s not a problem. It’s just that this fact was my only explanation for a timeout in Servo. |
| 11:54 | <nox> | And it would have made me anxious if that wasn’t the actual cause of that timeout. |
| 12:35 | <annevk> | Pretty happy with https://tools.ietf.org/html/rfc7159#section-8.1 |
| 12:39 | <smaug____> | annevk: https://bugzilla.mozilla.org/show_bug.cgi?id=1403441#c13 ok so the plan is to actually modify session history. Drop the entries which have some state |
| 12:41 | <annevk> | smaug____: well that's my proposal, otherwise they can be used as a way to revive state |
| 12:41 | <smaug____> | sure, that is fine. I just wanted to make sure I understood the proposal. |
| 12:42 | <annevk> | kk |
| 12:42 | <smaug____> | So basically remove all the other entries except the first one for the domain |
| 12:42 | <smaug____> | or something like that |
| 12:42 | <annevk> | Oh, the RFC reading that way might be because of https://lists.w3.org/Archives/Public/www-tag/2013Nov/0074.html |
| 12:42 | <annevk> | I forgot I got myself involved somehow |
| 12:55 | <nox> | https://github.com/w3c/web-platform-tests/blob/master/html/semantics/embedded-content/media-elements/event_loadeddata.html#L29 Cute. |
| 13:36 | <Ms2ger> | Oops |
| 13:39 | <Ms2ger> | Broken in https://github.com/w3c/web-platform-tests/commit/1f1f813f93dd1084ea3656dec3f8907507e1bf34 |
| 13:40 | <Ms2ger> | Seems like it's the only case |
| 13:59 | <wanderview> | JakeA: I can fix this range request result you saw on FF: "fetch(event.request) - seems to lose the range header somewhere, so it appears like the 200 result above" |
| 13:59 | <wanderview> | JakeA: but wondering if I should just wait |
| 14:00 | <JakeA> | wanderview: depends how you fix it. I think we only want APIs to be able to set that header |
| 14:00 | <Domenic> | Bikeshedding/style question, input from spec consumers welcome https://github.com/whatwg/meta/issues/41 |
| 14:00 | <wanderview> | JakeA: I was going to set a hidden value on the Request... it would only get used if directly passed through... not persisted in Cache API, etc |
| 14:02 | <JakeA> | wanderview: yeah, I support that landing :D |
| 14:03 | <wanderview> | JakeA: the weird thing is if its really a Range header or something else... I'm confused now |
| 14:03 | <JakeA> | Pretty sure it's a range header, unless we're talking about different things |
| 14:04 | <wanderview> | JakeA: I meant in firefox we might be doing something different to ask for a range request instead of adding a header at that API point |
| 14:04 | <wanderview> | JakeA: like our "ResumeAt()" method which asks for maybe a range if its matches the previous response |
| 14:04 | <annevk> | Ms2ger: we have those "terms used from other specs" indexes with Bikeshed; perhaps that is indeed sufficient |
| 14:06 | <annevk> | TabAtkins: in case you didn't see Domenic's message above, your input on https://github.com/whatwg/meta/issues/41 would be appreciated |
| 14:06 | <annevk> | TabAtkins: seems like something you might have thought about given Bikeshed |
| 14:11 | <TabAtkins> | Thanks for the reference. |
| 15:00 | <Ms2ger> | annevk, oh, I looked at Fetch and didn't see it |
| 15:18 | <wanderview> | JakeA: I have to say, after using async functions and await a lot recently... I really like the decision not to put abort() on the fetch() promise |
| 15:50 | <JakeA> | wanderview: yeah, I think the model we have now is pretty good |
| 15:50 | <JakeA> | I love async/await too |
| 16:44 | <jyasskin> | JakeA: 2 cents re "represents a [=whatever=]": If the rest of the spec says "associated [=whatever=]", I'd like that to be a link to somewhere that talks about how the [=whatever=] gets associated. https://wicg.github.io/background-fetch/#backgroundfetchregistration-background-fetch is great IMO, but I've seen some specs by other people that are much less clear. |
| 16:45 | <jyasskin> | webidl#258 is even better when we get it. |
| 19:03 | <rniwa> | Domenic: yt? |
| 19:07 | <Domenic> | rniwa: yeah |
| 19:08 | <rniwa> | Domenic: who works on geolocation stuff these days at Google? |
| 19:09 | <Domenic> | rniwa: not sure, let me check around a bit and ask if there's no clear docs... |
| 19:09 | <rniwa> | Domenic: thanks |
| 19:19 | <Domenic> | (I found the person who used to own it and they redirected me to their most likely guess for who now owns it; currently waiting for that second person to confirm or redirect me again...) |
| 19:23 | Mek | wouldn't be surprised if the answer is "nobody"... |
| 19:31 | <JakeA> | jyasskin: cheers! |
| 20:02 | <scheib> | rniwa: Oh Hi, https://www.chromium.org/teams/device-team is looking after Geolocation now. |
| 20:02 | <scheib> | (I'm on that team) |
| 21:03 | <Domenic> | omg upcoming Web IDL mixins are so good. https://github.com/heycam/webidl/pull/433 |
| 21:03 | <Domenic> | so much simpler and better suited for their purpose |
| 21:03 | <Domenic> | So many Web IDL confusions just gone |
| 21:13 | <TabAtkins> | Agreed! |
| 21:58 | <jyasskin> | Domenic: https://github.com/travis-ci/dpl/pull/695 will make auto-gh-pages much simpler. |
| 21:59 | <jyasskin> | We'll be able to completely replace deploy.sh with https://github.com/jyasskin/testing/blob/master/.travis.yml |
| 21:59 | <Domenic> | jyasskin: oh wow, brilliant move |
| 21:59 | <jyasskin> | Domenic: The one maybe-downside is that their script doesn't keep any history in gh-pages. Do you think that matters? |
| 22:00 | <Domenic> | Now I'm feeling a little sad I never converted my gist into a blog post and garnered all the internet blog fame, but oh well, too late now! |
| 22:00 | <Domenic> | Hmm |
| 22:00 | <jyasskin> | Heh |
| 22:00 | <Domenic> | I used to not keep history |
| 22:00 | <Domenic> | But I like having it |
| 22:00 | <Domenic> | And it's not that hard |
| 22:00 | <Domenic> | Maybe worth modifying their script? |
| 22:01 | <jyasskin> | Yeah. I nominate you to write that PR. ;) |
| 23:35 | <rniwa> | scheib: hello |
| 23:35 | <rniwa> | scheib: are you still there? |
| 23:39 | <scheib> | rniwa: Yes about 10min |
| 23:53 | <jyasskin> | Is there a best practice for saying "specs that depend on this one need to do X"? https://w3c.github.io/webappsec-credential-management/#credential-internal-methods currently says "derived interfaces MUST override ...", but it's not really correct to MUST another specification. |