| 00:44 | jsbell | *shakes fist* at difference in microtask behavior between normal event dispatch and dispatchEvent(). |
| 05:55 | <annevk> | Well, https://annevankesteren.nl/2012/07/passion "making HTML great again" reads awkward today |
| 07:51 | <foolip> | tobie: https://bugs.chromium.org/p/chromium/issues/detail?id=591919 covers the weirdness with NodeFilter I think, that is why the prototype is wrong |
| 07:52 | <tobie> | foolip: good. |
| 07:59 | <tobie> | foolip: you might have some comments to make about https://github.com/heycam/webidl/pull/283 |
| 08:00 | <foolip> | tobie: so many changes together, are they all co-dependent? |
| 08:01 | <tobie> | Arguably the last one isn't. But it's a one liner. |
| 08:04 | <foolip> | tobie: made one comment :) |
| 08:04 | <tobie> | foolip: I saw. :) |
| 08:04 | <foolip> | clairvoyant |
| 08:05 | <tobie> | foolip: you're probably better off just looking at the output. It's mostly a complete rewrite of those sections. |
| 08:06 | <foolip> | tobie: even so it's a bunch of ES-style algorithms that I don't have much experience in reading. maybe Domenic would do a better job? |
| 08:12 | <tobie> | foolip: oh, I wasn't asking for a review. Just making sure you were aware of the upcoming changes and that they matched your expectations. |
| 08:13 | <foolip> | tobie: ah, well the summary all makes sense to me |
| 08:14 | <foolip> | callback interfaces are silly :) |
| 08:14 | <tobie> | Good. |
| 08:14 | <tobie> | Indeed. |
| 10:07 | <mkwst> | annevk: Regarding the top-level vs. nested navigation request we discussed briefly yesterday: would you prefer an approach that added a new property to requests? Or would you prefer something like splitting the `document` destination into `nested document` and `top-level document`? |
| 10:09 | <annevk> | mkwst: dunno, the latter might be tricky given that we already expose "document" I think |
| 10:09 | <mkwst> | Oh. Right. I forgot that `destination` is web-exposed. |
| 10:10 | <mkwst> | Ok. Scratch that. |
| 10:43 | <annevk> | Why would Object.getOwnPropertyDescriptor(location, "valueOf") return undefined? |
| 10:44 | <annevk> | Seems like that would be a bug |
| 10:44 | <annevk> | Good |
| 11:08 | <Ms2ger> | Where does that happen? |
| 11:20 | <annevk> | Ms2ger: in Safari TP |
| 11:20 | <annevk> | Ms2ger: see my most recent WPT PR |
| 11:25 | <Ms2ger> | Fun |
| 12:54 | <nox> | tobie: So, is heycam/webidl your new home now? |
| 12:55 | <tobie> | nox: mostly splitting my time between it and w3c/sensors (and friends). |
| 12:55 | <nox> | Nice. |
| 12:56 | <nox> | tobie: Are you changing any syntax? |
| 12:58 | <tobie> | nox: I think we have already (jyasskin introduced records, Domenic namespaces). Looking at mixins soonish and deprecating things. |
| 12:58 | <nox> | Ok. |
| 12:59 | <tobie> | nox: e.g. callback interface {}; -> legacycallback interface {}; or some such. |
| 12:59 | <nox> | Oh. |
| 12:59 | <nox> | tobie: I'll check whether Gecko's parser got these changes already. |
| 13:00 | <tobie> | nox: I'd love to find a simple system to better track those |
| 13:00 | <nox> | tobie: Yeah I didn't mean to update Gecko's parser, |
| 13:01 | <nox> | tobie: just that we rely on this one in Servo too, |
| 13:01 | <tobie> | on? |
| 13:01 | <nox> | on Gecko's parser |
| 13:01 | <nox> | so when I hear changes are coming I try to check whether Gecko's got updated, and updates it in Servo. |
| 13:01 | <tobie> | nox: I see. |
| 13:15 | <tobie> | suggestions on how to keep track of implementation status of features, bugs opened against rendering engines, other specs, parsers and test suites are welcome. |
| 13:35 | <Ms2ger> | tobie, I've talked for years about creating tooling for that |
| 13:36 | <ato> | Has anyone come close to a workable solution? |
| 13:36 | <Ms2ger> | No |
| 13:36 | <Ms2ger> | I don't know if anyone started |
| 13:36 | <ato> | Microsoft worked on a thing but when I looked at it, it didn’t really fit the bill. |
| 13:38 | <tobie> | I was thinking of something rather basic like create an issue with a special tag name which references the different issues. |
| 13:39 | <tobie> | Ideally, you'd have a small local script that would run it for you (file the issues with the different vendors or specs, collect their URLs, stick them in a GH issue in your repo) |
| 13:39 | <ato> | That’s not a bad idea. |
| 13:40 | <ato> | tobie: I wrote a small script to automatically file GitHub issues quoting which section for WebDriver: http://w3c.github.io/webdriver/webdriver-spec.html |
| 13:40 | <ato> | tobie: It would not be hard to look up the nearest command/definition/whatever and add a label to the issue. |
| 13:41 | <tobie> | yeah, I'm actually more concerned about the APIs of the browser vendors trackers |
| 13:41 | <tobie> | and old W3C one. |
| 13:43 | <ato> | The W3C tracker should be killed with fire. |
| 15:36 | <tobie> | What's the best practice for explainer content (outside explainer doc? informative sections? intro?) and why? |
| 15:37 | <jyasskin> | Informative sections, because once you have a spec, nobody goes back to look at or update the explainer. |
| 15:37 | <jyasskin> | slightlyoff may disagree with me on that. |
| 15:40 | <jyasskin> | Re the Hangouts plugin angst from yesterday: https://gsuiteupdates.googleblog.com/2016/09/new-early-adopter-programs-team-drives.html?m=1 |
| 15:41 | <jyasskin> | Googlers should be able to make meetings use the new thing. Googlers, ask me how. |
| 15:42 | <tobie> | jyasskin: it would be nice to have a blueprint for specs as to what questions need to be answered and why. |
| 15:44 | <tobie> | jyasskin: I've seen a lot of very good explainers lately, and I suspect that's because there's a good framework around what they're supposed to contain. |
| 15:46 | <jyasskin> | Oooh, you mean for the content of explainers, often before there's a spec. I'll look once I get to a computer. At one point it was just "imitate Service Workers." |
| 15:47 | <tobie> | jyasskin: well, no. I mean all non-normative content. |
| 15:48 | <tobie> | jyasskin: this could include high-level content, scope clarification, goal of the document, use cases, etc. |
| 17:28 | <tobie> | I rarely see diagrams in specs while it sometimes helps to better grasp their content. |
| 17:28 | <tobie> | For example, I'm still struggling with how the different parts of WebIDL end-up exposed to the Web through their bindings. |
| 17:28 | <tobie> | A diagram would really help. |
| 17:29 | <tobie> | s/would/could/ |
| 17:29 | <tobie> | Are we avoiding those because the tooling to make them is terrible? |
| 17:29 | <tobie> | s/make/make and update/ |
| 17:38 | <jyasskin> | TabAtkins: What are the chances of integrating dot into Bikeshed? |
| 17:39 | <TabAtkins> | If dot exists in Python, I'm amenable. |
| 17:39 | <jyasskin> | https://pypi.python.org/pypi/graphviz |
| 17:40 | <jyasskin> | Ah, no, that's just a library to create dot files. It'd be just as easy to subprocess out to dot, for dot written inline in the spec. |
| 17:44 | <TabAtkins> | Yeah, subprocessing out to an external library isn't great. It won't work on many systems. |
| 17:46 | <gsnedders> | TabAtkins: do you not rely on any extension modules currently, or is it specifically subprocess that's the worry? |
| 17:46 | <TabAtkins> | I rely on a few Python modules installable from pip. Otherwise nothing. |
| 17:47 | <gsnedders> | TabAtkins: pure-Python modules? |
| 17:47 | <gsnedders> | no, lxml is there |
| 17:47 | <gsnedders> | so there's already a depend on an external library |
| 17:47 | <TabAtkins> | (And I'm gradually moving toward the idea that I should just bake in all those modules; the pygments version differences are already annoying.) |
| 17:48 | <TabAtkins> | gsnedders: Sure, but that's unfortunately a *very core* dependency. |
| 17:49 | <TabAtkins> | Yeah, libxslt and libxml are the only external (non-Python) dependencies. |
| 17:49 | <TabAtkins> | Because they're dependencies of the lxml python module, which is my treebuilder, which I need because it's what the Selectors engine is built on top of. |
| 18:00 | <jochen__> | TabAtkins: any input on https://github.com/w3c/csswg-drafts/issues/904 ? |
| 18:01 | <TabAtkins> | jochen__: Official response is: yup, I need to start speccing that stuff. ^_^ |
| 18:02 | <jochen__> | TabAtkins: i'd also be happy with a PR for referrer policy that addresses https://github.com/w3c/webappsec-referrer-policy/issues/89 |
| 18:02 | <jochen__> | :D |
| 18:02 | <TabAtkins> | Sure, I'll get to this. |
| 18:03 | <jochen__> | cool, thx |
| 18:50 | <TabAtkins> | jyasskin: Oh wait it looks like graphviz is, itself, a python library https://github.com/ellson/graphviz/ |
| 18:50 | <TabAtkins> | wait nm it's c |
| 18:51 | <jyasskin> | Yeah. |
| 20:47 | <tobie> | jyasskin: wrt to permissions, have you 1) considered permission levels (foreground, background, always on), like e.g. iOS has |
| 20:48 | <jyasskin> | tobie: So far, we only have foreground permissions, and we'd been thinking of things like geofencing (background location) as just having a separate permission name. But since we haven't done any background permissions, it's not at all clear that that's what we'll settle on. |
| 20:49 | <tobie> | jyasskin: 2) timestamps of when permission was granted. I'll want to make sure cached values such as geo coordinates are only provided to the developer if the permission was granted before they were requested |
| 20:49 | <tobie> | jyasskin: geofencing is really an "always on" state |
| 20:50 | <tobie> | jyasskin: different from background / not top-level |
| 20:50 | <jyasskin> | We haven't considered timestamps at all. |
| 20:50 | <jyasskin> | tobie: Is "background" "in a tab but not the active one"? |
| 20:50 | <tobie> | jyasskin: for the sake of this conversation: not top-level browsing context. |
| 20:51 | <tobie> | jyasskin: I guess Feature Policy is the thing for that |
| 20:51 | <jyasskin> | Ok, so most permissions are "background" right now, but WebNFC is planning to be foreground-only. |
| 20:52 | <tobie> | jyasskin: right but there's no distinction at the permission level |
| 20:52 | <jyasskin> | Right. |
| 20:52 | <tobie> | jyasskin: it's a non user-flippable thing. |
| 20:52 | <jyasskin> | And it would probably make sense to expose that in the shared infrastructure. |
| 20:54 | <jyasskin> | Right now it's not user-flippable. It's plausible to let users toggle foreground vs background. Always-on tends to require the API to be designed to support it, but we could let users degrade that to fg or bg. |
| 20:56 | <tobie> | jyasskin: right-- this is not to say all of the features necessarily need to be available across all three "states" |
| 20:58 | <tobie> | jyasskin: just recognizing they're the same "feature" despite possible API differences and different levels of implied trust and privacy/security risks |
| 20:58 | <jyasskin> | Yeah, you've identified something we should figure out in the permissions spec. |
| 20:59 | <tobie> | jyasskin: e.g.: It would be dumb to prompt a user of geofencing for geolocation access |
| 20:59 | <tobie> | jyasskin: it's implied |
| 20:59 | <jyasskin> | At the moment, we'd handle that by saying geofencing is "stronger than" geolocation (https://w3c.github.io/permissions/#permissiondescriptor-stronger-than), but we can do it in a more systematic way. |
| 21:03 | <tobie> | jyasskin: wasn't aware of that. |
| 21:09 | <Domenic> | JakeA: annevk: a bit sad that this cancelation/observer design marks the end of fetch being platform-agnostic, but such is life. (Even if DOMException "AbortError" doesn't kill that dream, addEventListener definitely does.) |
| 21:10 | <tobie> | Domenic: events should be a language feature |
| 21:11 | <Domenic> | yeah, well, there are people in Chrome opposed to that too |
| 21:11 | <tobie> | Domenic: no idea how to pull it off, but it's the number one thing that breaks platform agnosticism |
| 21:12 | <Domenic> | I guess Node could just copy EventTarget |
| 21:12 | <tobie> | haha |
| 21:12 | <Domenic> | I don't see any other path. |
| 21:12 | <jyasskin> | "copy"? |
| 21:12 | <Domenic> | Copy the design of, i.e. implement |
| 21:13 | <jyasskin> | Oh, yeah. And then I'd be retroactively right to treat EventTarget as a mixin! ;-) |
| 21:19 | <JakeA> | Domenic: is it the same Chrome people/persons? |
| 21:20 | <Domenic> | An overlapping group |
| 21:21 | <tobie> | Node people tend to say: I guess browsers could just copy EventEmitter |
| 21:21 | <tobie> | 0.5 million modules vs. break the web |
| 21:59 | <Domenic> | tobie: yay for your deduplication into ConvertToInt(); it's making this SharedArrayBuffer/types-have-attributes thing I'm working on much easier. |
| 22:00 | <tobie> | Domenic: cool. Great to see stuff like that paying off! |