| 11:04 | <mohsen_> | Can whatwg provide off site notification support? |
| 11:07 | <annevk> | mohsen_: not sure what that means |
| 11:09 | <mohsen_> | Receiving notification when the browser is closed |
| 11:16 | <annevk> | mohsen_: the unload event provides that |
| 11:17 | <mohsen_> | Do you have an example for that? |
| 11:55 | <annevk> | mohsen_: window.onunload = ... |
| 12:00 | <mohsen_> | annevk: No I mean after that, when the browser is closed, the user still receive notifications from server. |
| 12:02 | <annevk> | mohsen_: oh, https://w3c.github.io/push-api/ |
| 12:36 | <annevk> | Anyone know how to suppress a bikeshed IDL LINK ERROR? |
| 12:38 | <annevk> | I'll ignore it for now |
| 13:20 | <smaug____> | oh, ShadowRoot is in dom spec now |
| 13:20 | <smaug____> | good good |
| 13:21 | <annevk> | It's quite a bit of work, but slowly getting there |
| 13:23 | <tobie> | mounir: wouldn't it make sens to have an abstract operation in Permissions-API to request permission if the request permission state returns "prompt"? I'm seeing everyone come up with roughly the same boilerplate for this. |
| 14:19 | <mounir> | tobie: wdym? |
| 14:34 | <tobie> | mounir: retrieving the permission state, returns one of "granted", "denied" or "prompt" |
| 14:35 | <tobie> | mounir: "granted" let's you go ahead with whatever it was you wanted to do. |
| 14:35 | <mounir> | tobie: sounds reasonable |
| 14:36 | <tobie> | mounir: "denied" pretty much forces you to throw/reject with a NotAllowedError |
| 14:37 | <mounir> | I would leave that to the implementation |
| 14:37 | <tobie> | mounir: arguably |
| 14:37 | <mounir> | I guess we could have two algorithms: one basic that checks the permission and return the result |
| 14:38 | <tobie> | mounir: and "prompt" pretty much asks you to do a little dance prompting the user (or some such) |
| 14:38 | <mounir> | one that "do X if allowed" and rejects otherwise |
| 14:38 | <mounir> | some specs wouldn't |
| 14:38 | <mounir> | background-sync so far is a UA permission for example |
| 14:38 | <mounir> | as in not in the user's face |
| 14:39 | <tilal6991> | Curious as to what is being discussed? :) |
| 14:40 | <tobie> | mounir: I'm not suggesting *all* specs should do the same, but a lot do something similar, eg midi: http://webaudio.github.io/web-midi-api/#dfn-algorithm-to-request-midi-access |
| 14:42 | <tobie> | tilal6991: a common abstract operation to ask for use permission in case the return value of the request permission state abstract operation is "prompt". |
| 14:42 | <mounir> | tobie: interested in writing it? :) |
| 14:43 | <tilal6991> | tobie: I see. If you do write it ^ have fun :P |
| 14:43 | <tobie> | mounir: well, I have to write it for the sensor API, so I might as well write it for the permissions API. :) |
| 14:44 | <mounir> | I take PR :) |
| 14:45 | <tilal6991> | mounir and I did a lot of that work on the permissions code last summer. Haven't looked at it for a while though so not sure what state it's in |
| 14:48 | <mounir> | tilal6991: I tihnk tobie is mostly interested about the spec :) |
| 14:50 | <tilal6991> | Oh I misunderstood. Still figuring out the interaction with requests would be interesting. |
| 14:50 | <tobie> | tilal6991, mounir: well, spec, sure; but I also want to make sure it can be easily implemented as one of the Intel guys working on this is about to send an intent to implement |
| 14:51 | <mounir> | tobie: in Chromium, it should be fine |
| 14:52 | <tobie> | mounir: awesome |
| 14:52 | <tobie> | tilal6991: can Riju ping you if he has issues/questions around this? |
| 14:52 | <smaug____> | annevk: have we considered exposing shadom dom only in secure contexts ? |
| 14:52 | <smaug____> | shadow dom and custom elments |
| 14:52 | <smaug____> | elements |
| 14:52 | <annevk> | smaug____: I don't think we have |
| 14:53 | <annevk> | smaug____: I would be okay with that, file an issue against w3c/webcomponents? |
| 14:53 | smaug____ | files a bug. Something to consider at least |
| 14:53 | <tilal6991> | Well sure but I've been out of chromium for a little while now. mounir would be the better person to ask since he owns the code but I can chip in sure |
| 14:54 | <mounir> | tobie: Riju should feel free to ping me |
| 14:54 | <tobie> | tilal6991: noted. thanks |
| 14:54 | <tobie> | mounir: noted. |
| 14:54 | <tobie> | mounir: where's "permission" precisely defined, btw? |
| 14:55 | <mounir> | tobie: hmm, that sounds like a tricky question :) |
| 14:55 | <tobie> | mounir: tricky or trick? |
| 14:56 | <mounir> | trick, sorry |
| 14:57 | <tobie> | mounir: well, maybe, I'm not sure. I can't find a dfn for it, and I'm unsure if it means the PermissionName, a PermissionDescriptor with name set to xxx, etc. |
| 14:58 | <tobie> | mounir: I refer to it like so in the Sensor spec: https://w3c.github.io/sensors/#retrieve-the-sensor-permission |
| 15:11 | <zcorpan> | why isn't <option> in the list of "Special" elements (in the parser)? |
| 15:14 | <annevk> | zcorpan: not sure, there's a couple of special category conditionals, are those affected? |
| 15:14 | annevk | is trying to figure out how to define <slot> parsing |
| 15:23 | <annevk> | gsnedders: so... html5lib doesn't support <template>? |
| 15:34 | <gsnedders> | annevk: no, it doesn't |
| 15:45 | <zcorpan> | annevk: hmm right, in particular "any other end tag". probably menuitem shouldn't be special but i'm not entirely sure yet |
| 15:46 | <zcorpan> | also AAA |
| 15:47 | <annevk> | zcorpan: if those are actually what makes option not special, that is worthy of a note |
| 15:47 | <annevk> | zcorpan: seems super confusing |
| 15:47 | <annevk> | zcorpan: file an issue, assign to Hixie_? |
| 15:55 | <zcorpan> | doneth |
| 15:55 | <annevk> | ta |
| 16:24 | <tobie> | jyasskin: hey--it seems you've written the core of the "request permission" abstract operation I also need in a branch of your fork of the Permissions API. |
| 16:24 | <tobie> | jyasskin: mounir and I were just discussing this above. |
| 16:25 | <jyasskin> | I'm on vacation today, so can't reply much. |
| 16:25 | <tobie> | jyasskin: oh--sorry. |
| 16:25 | <tobie> | jyasskin: when are you back? |
| 16:25 | <jyasskin> | But I'll scroll up and read your conversation tomorrow. Feel free to send comments on the PR, or take it over and merge it. :) |
| 16:26 | <tobie> | oh, I must have somehow missed the PR. |
| 16:27 | <tobie> | jyasskin: looking |
| 16:30 | <jyasskin> | https://github.com/w3c/permissions/pull/66 |
| 16:35 | <tobie> | jyasskin: ty |
| 16:36 | <tobie> | jyasskin: you'll be interested in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27048 for adding support for partial enums in WebIDL |
| 16:43 | <tobie> | Would be easier if WebIDL consolidated its issue trackers. |
| 16:46 | <Ms2ger> | Would be easier if it had an active editor |
| 16:46 | <tobie> | mounir: what I'm looking for is basically in: https://github.com/w3c/permissions/pull/66 |
| 17:13 | <smaug____> | is [Unscopeable] actually used in any spec? |
| 17:13 | <annevk> | smaug____: it's in DOM |
| 17:14 | <smaug____> | ah, there |
| 17:14 | <smaug____> | not in HTML |
| 17:19 | <smaug____> | hmm, different thing |
| 17:19 | <smaug____> | https://dom.spec.whatwg.org/#dom-childnode-before am I reading that right, or does the algorithm actually end up putting nodes before previous sibling |
| 17:20 | <smaug____> | s/right/wrong/ |
| 17:21 | <smaug____> | "Pre-insert node into parent before viablePreviousSibling. " |
| 17:22 | <smaug____> | oh, no, there is 5 |
| 17:22 | <smaug____> | nm |
| 17:23 | <smaug____> | odd reuse of viablePreviousSibling variable |
| 17:24 | <annevk> | smaug____: if it's confusing, I take PRs or issues |
| 19:06 | <rniwa> | annevk: yt? |
| 21:07 | <jyasskin> | annevk: Getting rid of Link Errors in bikeshed generally involves adding an item to the 'anchors' or 'link-defaults' blocks at the top of your spec. See https://github.com/WebBluetoothCG/web-bluetooth/blob/gh-pages/index.bs for a bunch of examples. |
| 21:09 | <jyasskin> | tobie: Yeah, I've seen that bug. I was waiting to push on it until I'd fixed the Permissions spec to handle other specs extending it. |
| 21:11 | <jyasskin> | To really fix it, it'd be nice to have a catalog of the "registries" in HTML specs, to see if they could all be handled in some uniform way other than partial enums. But failing that, partial enums look like they're probably enough for Permissions. |
| 21:16 | <tobie> | Yeah. Baby steps. Also, weren't you supposed to be on PTO? ;) |