| 01:31 | <spring2> | hi i need help about learning queueing for 2 different div id loading on document .ready |
| 01:31 | <spring2> | anyone want to help me plz thx |
| 02:04 | <karlcow> | Should we fix that? https://github.com/webcompat/web-bugs/issues/2344#issuecomment-195141744 |
| 02:04 | <karlcow> | window.location.replace(''); |
| 02:13 | <karlcow> | Blink (Opera), Firefox (Gecko) enters an infinite loop |
| 04:05 | <rniwa> | hayato: yt? |
| 04:05 | <rniwa> | Domenic: yt? |
| 04:05 | <hayato> | rniwa: yeah |
| 04:05 | <rniwa> | annevk: yt? |
| 04:05 | <rniwa> | hayato: what was your intention on https://github.com/w3c/webcomponents/issues/432 ? |
| 04:08 | <hayato> | rniwa: I guess the spec should clarify a case where event target is not a Node. |
| 04:08 | <rniwa> | hayato: indeed. |
| 04:10 | <hayato> | There was no intention. So deepPath() should return *eventPath*, a list of event targets, even if event target is a not Node. We should clarify it. |
| 04:13 | <rniwa> | hayato: okay, so you want to include it in the path? |
| 04:14 | <hayato> | Hmm. I have not considered it seriously so far... |
| 04:14 | <rniwa> | hayato: what if the path included a Node but the current target didn't? |
| 04:14 | <rniwa> | hayato: we can't quite determine whether a Node should be unclosed in that case |
| 04:15 | <rniwa> | hayato: so it seems that we may need to return an empty array in that case |
| 04:15 | <rniwa> | hayato: and most of non-Node targets don't have anything to bubble up (e.g. XHR) |
| 04:15 | <rniwa> | so I can't think of a use case in which deepPath() is needed |
| 04:16 | <hayato> | Yeah, for a world of non-node-tree, we can have a different answer. |
| 04:17 | <hayato> | Could you share a concrete example in the issue? |
| 04:17 | <hayato> | Let me think about it. |
| 04:17 | <rniwa> | hayato: I can't think of a concrete case in which this is possible |
| 04:17 | <rniwa> | so it could be a non-issue. |
| 04:17 | <rniwa> | I'm hoping that annevk can give us an insight into this |
| 04:18 | <hayato> | I see. |
| 04:22 | <rniwa> | hayato: writing a test for deepPath() is such a labor intensive work :( |
| 04:22 | <rniwa> | hayato: do you guys have a test for it somewhere? |
| 04:24 | <hayato> | Only in LayoutTests of Blink, I guess |
| 04:24 | <hayato> | https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/fast/dom/shadow/ |
| 04:25 | <hayato> | https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/shadow-dom/ |
| 04:25 | <rniwa> | hayato: cool! |
| 04:26 | <hayato> | However, I have not written any test for event.deepPath() for non-node-tree. |
| 04:26 | <rniwa> | hayato: I guess /dom/shadow is for v0? |
| 04:26 | <rniwa> | hayato: and shadow-dom is for v1? |
| 04:26 | <rniwa> | hayato: or are they mixed together? |
| 04:26 | <rniwa> | hayato: at some point, we should get gather and upstream these tests to W3C |
| 04:26 | <rniwa> | hayato: and make sure our behaviors are the same |
| 04:26 | <hayato> | Yeah, we separated it this week. |
| 04:27 | <rniwa> | hayato: nice! |
| 04:27 | <rniwa> | hayato: if we're going to have another in-person meeting, we can probably allocate a day before/after the meeting to do just that (upstream tests) |
| 04:27 | <rniwa> | because I suspect we'll have quite a bit of overlap between our tests |
| 04:27 | <rniwa> | (which is good though because we don't want one person writing all the tests) |
| 04:29 | <rniwa> | hayato: here's another weird case |
| 04:29 | <rniwa> | hayato: if you fired a scoped event inside a node that gets assigned to a slot |
| 04:29 | <rniwa> | hayato: then that event will propagate into the slot |
| 04:29 | <rniwa> | hayato: but never gets out of its shadow root |
| 04:30 | <rniwa> | that seems odd |
| 04:30 | <hayato> | It gets out of its shadow root. |
| 04:30 | <rniwa> | oh because of the check that Node is the root node of Target |
| 04:31 | <rniwa> | got it |
| 04:31 | <hayato> | Yeah, that's my intention. |
| 04:32 | <rniwa> | hayato: but that doesn't quite work |
| 04:32 | <rniwa> | hayato: if the target is in yet another shadow tree |
| 04:32 | <rniwa> | ugh... that's okay because we'd stop at the first shadow root |
| 06:06 | <annevk> | rniwa: non-node would mostly return just the target I think |
| 06:07 | <annevk> | rniwa: in IDB you might get multiple nodes |
| 06:07 | <annevk> | rniwa: hit regions also seem like they would be an exception |
| 06:13 | <rniwa> | annevk: can we have both non-Node and Node in a single event path? |
| 06:14 | <annevk> | rniwa: well, Window will be at the top for most paths |
| 06:14 | <rniwa> | annevk: is it supposed to be included in the path? |
| 06:14 | <annevk> | rniwa: for hit regions you might have a hit region object before the canvas element |
| 06:14 | <annevk> | rniwa: yes |
| 06:15 | <rniwa> | annevk: okay |
| 06:15 | <rniwa> | annevk: it appears after the document? |
| 06:15 | <rniwa> | annevk: or at the very beginning |
| 06:15 | <annevk> | rniwa: yeah, see document's get the parent |
| 06:15 | <rniwa> | annevk: cool |
| 06:16 | <rniwa> | annevk: so i guess when we're firing an event on non-Node object |
| 06:16 | <annevk> | rniwa: hit region would be at the start I think, but I have not sorted that yet |
| 06:16 | <rniwa> | annevk: oh no :( hit region case is convoluted |
| 06:16 | <rniwa> | annevk: in that one, the canvas can be inside a shadow DOM |
| 06:16 | <annevk> | Yes |
| 06:17 | <rniwa> | annevk: but we probably don't know about it :( |
| 06:17 | <rniwa> | because the target is not a node |
| 06:17 | <annevk> | But the way you calculate event paths you would |
| 06:17 | <rniwa> | annevk: how? |
| 06:17 | <annevk> | The target would be EventTarget though |
| 06:17 | <rniwa> | annevk: I'm talking about deepPath() here |
| 06:18 | <annevk> | Sure, but deepPath just returns the result of the path calculation, filtered |
| 06:19 | <rniwa> | annevk: by the current target |
| 06:19 | <rniwa> | annevk: but if the current target is not a node, how am I supposed to figure out which node is unclosed? |
| 06:19 | <annevk> | The path is calculated at the start of dispatch |
| 06:20 | <annevk> | So you should have all the info you need, I think, anyway, gotta go for a bit |
| 06:21 | <rniwa> | annevk: I think the problem here is that the we need to filter nodes at each current target separately |
| 06:22 | <rniwa> | annevk: I suppose we could find walk up the event path 'til the first target which is a node, and use that to filter the results |
| 06:22 | <annevk> | Yeah |
| 06:22 | <rniwa> | but some algorithm like that needs to be defined |
| 06:22 | <annevk> | Agreed |
| 06:22 | <annevk> | It's a shame the event stuff does not build more on DOM directly |
| 06:23 | rniwa | comments on the bug |
| 08:58 | <tobie> | I have errors I need to dispatch as error events. Where can I read more about how I'm supposed to do that? |
| 09:00 | <tobie> | Oh, in the HTML spec not the DOM spec. |
| 09:00 | <tobie> | Duh |
| 09:01 | <zcorpan> | it.... looks like github now has a mechanism for voting that is not adding a comment! |
| 09:09 | <tobie> | zcorpan: \o/ |
| 09:12 | <pard> | hello |
| 09:14 | <pard> | i've got to ask something about auto margins and their behaviour on inline elements, as it looks rathe incosistent to me |
| 09:14 | <pard> | not sure if anyone is on the channel though |
| 09:14 | <pard> | :\ |
| 09:18 | <pard> | my question is , why margin-right: auto is effectively 0 on inline elements? |
| 09:20 | <pard> | inline elements can have a deternmined width , which is what made me initially think UA's treat them (almost) like a div with a (max/min)-width |
| 09:21 | <pard> | turns out it was not the case :\ |
| 09:22 | <pard> | the spec states the setting the side margins will be effective on block elements only |
| 09:23 | <pard> | *on block elements meeting certain criteria |
| 09:23 | <pard> | any ideas? |
| 09:28 | pard | used to think all the www consortium are on this channel |
| 09:30 | <tobie> | Trying to subclass Event (so doing `Event.call(this, type, options);` in my FooEvent constructor). Chrome throws a TypeError (Failed to construct 'Event': Please use the 'new' operator, this DOM object constructor cannot be called as a function.) |
| 09:30 | <tobie> | Is this by design or an implementation issue? |
| 09:31 | <tobie> | In either case is there a known workaround or best practice? |
| 09:39 | <Ms2ger> | tobie, subclassing dom objects is not supported |
| 09:39 | <Ms2ger> | Maybe in a few years |
| 09:57 | <tobie> | Ms2ger: what's the workaround for polyfilling event subclasses, then? |
| 09:58 | <tobie> | Ms2ger: this: https://github.com/w3c/sensors/blob/a1a777/polyfills/geolocation.js#L40-L45 |
| 09:58 | <tobie> | ? |
| 10:04 | annevk | wonders if anyone has actually reviewed web manifests... I looked at it briefly yesterday to see how it deals with icons and it talks about a [[HasOwnPropery]] internal method... |
| 10:05 | <annevk> | tobie: not sure there's a workaround really |
| 10:05 | <annevk> | tobie: you could use CustomEvent and stuff it all in .data |
| 10:06 | <annevk> | tobie: properly subclassing platform objects seems hard anyway given platform object's need for internal slots |
| 10:06 | <tobie> | annevk: sure, but then it's not a 1:1 match of what the spec is specifying (which has a reading property instead of a data prop) |
| 10:06 | <annevk> | I'm not sure if anyone really thought that all the way through |
| 10:07 | <tobie> | annevk: that's a good point, actually |
| 10:21 | <annevk> | MikeSmith: I think due to the component rename you did in WebAppsWG some Bugzilla links are now broken, e.g., new bug / open bugs on WebIDL |
| 12:11 | <smaug____> | Seriously, shipping Intersection Observer o_O |
| 12:12 | <smaug____> | I guess time to review the spec before blink ships anything :/ |
| 13:17 | <annevk> | Domenic: how much nitpicking do you want on Custom Elements at this point? |
| 13:25 | <tobie> | On the sensor work, I have a start method that awakens the sensor and starts polling it. It returns a promise. |
| 13:27 | <tobie> | Should I explicitly prevent events from being emitted if the stop method is called before the start method's promise is resolved? |
| 13:28 | <annevk> | tobie: seems cleaner, yes |
| 13:28 | <annevk> | tobie: stop() should probably cause the promise to be rejected, too |
| 13:29 | <tobie> | oh. I hadn't thought of that. makes sense, yes. |
| 13:29 | <tobie> | annevk: seems the best way to handle that is to have a private state for the sensor, no? |
| 13:30 | <tobie> | idle / starting / polling or something |
| 13:31 | <annevk> | tobie: yeah, you might even want to expose that through sensor.state |
| 13:32 | <tobie> | annevk: ty |
| 13:36 | <annevk> | "It turns out there's not actually a spec for the XML parser. Awesome! (Not actually awesome.)" |
| 13:46 | <jgraham> | Not actually surprising? |
| 13:50 | <gsnedders> | I thought we all knew that? |
| 13:51 | <gsnedders> | (But I have no context for where that quote was from) |
| 13:51 | <annevk> | Yeah, I just liked the sentence |
| 13:51 | <annevk> | https://w3c.github.io/webcomponents/spec/custom/ |
| 13:55 | <Domenic> | annevk: consolidated nitpicking, or better yet PRs, would be welcome. And anything that would be better to catch now instead of during a merge. |
| 13:56 | <gsnedders> | So what we want to do is define infoset -> DOM and DOM -> infoset, right? So we have the whole platform well-defined. |
| 13:56 | gsnedders | hides |
| 13:58 | <annevk> | gsnedders: doesn't actually work given <script> and such executing synchronously |
| 14:00 | <annevk> | yoav: did you look into the perf benefits of disabling document.write(), not having sync scripts/stylesheets/scroll events, etc.? It seems letting a site disable those could allow a browser to make a number of optimizations that are hard or impossible now |
| 14:05 | <gsnedders> | annevk: I thought scripts didn't execute synchronously with XML, am I just forgetting, bah… |
| 14:05 | <gsnedders> | annevk: still, we need to address how XPath and XSLT interact with the DOM world. |
| 14:06 | <annevk> | gsnedders: you are, or maybe you didn't test |
| 14:27 | annevk | finds https://www.w3.org/blog/news/archives/5313 |
| 14:28 | annevk | loads https://lists.w3.org/Archives/Public/public-webapps/latest |
| 14:28 | <annevk> | I guess we stopped asking the WG about publications? |
| 14:30 | annevk | finds https://www.w3.org/blog/2016/03/html-whats-next/ |
| 14:30 | <annevk> | Seems to get particularly rambly in the end |
| 14:31 | <annevk> | "An important part of W3C work is getting commitments to provide Royalty-Free patent licenses from organisations, and for some large companies with many patents that approval takes time. At the same time, Art Barstow who was for many years co-chair of Web Apps, and an initial co-chair of this group, has had to step down due to other responsibilities." This |
| 14:31 | <annevk> | almost makes it seem like Art stepped down due to patent issues, which couldn't be further from the truth... |
| 14:37 | <gsnedders> | Why did Art step down? |
| 14:37 | gsnedders | has entirely missed his departure |
| 14:39 | <yoav> | annevk: we are looking into exactly that. I'd love to have you involved |
| 14:40 | <annevk> | His current employer does not fund this kind of activity, I think, best to just email him directly gsnedders |
| 14:40 | <gsnedders> | annevk: ah |
| 14:41 | <annevk> | yoav: if there's one thing I'd say about how CSP went down is that CSP didn't look carefully enough at the detailed picture of how features fit together |
| 14:41 | <annevk> | yoav: I'd try to avoid that by really exploring the architecture of the things you want to effect |
| 14:42 | <annevk> | (This advice really goes for any new standard, I suppose) |
| 14:44 | <yoav> | Yeah, I guess the practical takeaway would be to let the folks that got burned the last time review things at an early stage |
| 14:47 | <annevk> | yoav: also, if you can't "monkey patch" your change without doing some contorted, that's indicative of a problem |
| 14:48 | <annevk> | doing something* |
| 14:48 | <yoav> | I'll keep that in mind :) |
| 14:49 | <annevk> | yoav: and please do define everything as a monkey patch, makes it much easier to review the feasibility of something and will save you work down the line |
| 14:49 | <nox> | Wtf is HTML 5.1? |
| 14:50 | <Ms2ger> | Yet another fork |
| 14:50 | <nox> | How many of them are there? |
| 14:50 | <jgraham> | nox: s/?// and your setence makes sense still |
| 14:51 | <nox> | Hah. |
| 14:51 | <nox> | Also, |
| 14:52 | <nox> | how come an article named "HTML: WHAT’S NEXT?" not mention WHATWG at all? |
| 14:52 | <nox> | Are they always that tsun-tsun? |
| 14:54 | <gsnedders> | https://lists.w3.org/Archives/Member/chairs/2016JanMar/0106.html has dates/location for TPAC 2017 (Member-Only, sadly) |
| 14:54 | annevk | looks up tsun-tsun |
| 14:54 | <annevk> | Seems about right |
| 14:56 | <annevk> | W3C is sometimes very reminiscent of a British TV show I used to watch with my mom, Keeping Up Appearances |
| 14:56 | <nox> | annevk: So their fork doesn't even use the same tools nor sources? |
| 14:56 | <Ms2ger> | Indeed |
| 14:56 | <Ms2ger> | (Mind the pedestrians?) |
| 14:59 | <Domenic> | > How many of them are there? |
| 14:59 | <Domenic> | nox: I'm glad you asked!! https://wiki.whatwg.org/wiki/Fork_tracking |
| 15:00 | <annevk> | And that doesn't even contain an exhaustive list of the twenty-odd canvas forks Hixie_ collected at one point |
| 15:04 | <gsnedders> | twenty-odd?! |
| 15:05 | <nox> | Is that a French number I don't know about? :P |
| 15:13 | <annevk> | gsnedders: http://damowmow.com/temp/canvas-specs |
| 15:13 | <Ms2ger> | annevk, at least http://w3c.github.io/webmessaging/ is nice now |
| 15:20 | <gsnedders> | annevk: oh, ok, mostly just stuff in TR space |
| 15:21 | <annevk> | Mostly, but also nine elsewhere |
| 15:24 | <hallvors> | annevk: is this the right fix? Sorry if I'm doing a crappy job here.. :-p https://github.com/w3c/clipboard-apis/issues/10#issuecomment-195394397 |
| 15:25 | <annevk> | hallvors: for making it nullable that seems fine |
| 15:25 | <annevk> | hallvors: I think you do want to set a default though if you don't require the argument, per philipj_'s comment |
| 15:26 | <annevk> | hallvors: can't help you with ReSpec though |
| 15:26 | <hallvors> | did I come across a ReSpec bug, then? |
| 15:27 | hallvors | needs to understand WebIDL |
| 15:27 | hallvors | lacks time |
| 15:29 | <annevk> | hallvors: actually, where do you define the init dictionary? |
| 15:29 | <annevk> | hallvors: that is where you want to define the default |
| 15:29 | <annevk> | hallvors: in ClipboardEventInit, I think you're correct that it's wrong here |
| 15:31 | <hallvors> | I need to fix the example script just above too |
| 15:31 | <hallvors> | perhaps tests are wrong.. |
| 15:31 | <hallvors> | this wasn't a quick fix after all :-p |
| 15:33 | <hallvors> | Poorly worded issue that will make sure I follow up later: |
| 15:33 | <hallvors> | https://github.com/w3c/clipboard-apis/issues/10#issuecomment-195394397 |
| 15:34 | <hallvors> | wrong paste. https://github.com/w3c/clipboard-apis/issues/27 |
| 16:01 | <MikeSmith> | annevk: I can revert the names on any of the bugzilla components that need it |
| 16:02 | <annevk> | MikeSmith: I haven't done a thorough analysis, there's no way to just close the component to new bugs, but leave old links working? |
| 16:03 | <annevk> | MikeSmith: maybe it doesn't matter much if only I notice it |
| 16:39 | <MikeSmith> | annevk: they have/had some kind of convention of prepending HISTORICAL- to the components to indicate that they were closed. So I tried to follow that, mostly just so that it looked like somebody who was authorized to do it knew that convention had closed them |
| 16:40 | <MikeSmith> | but anyway I reverted the WebIDL component at least |
| 16:41 | <MikeSmith> | and I’ll go back and do the same for the others I changed recently (once I remember which those are) |
| 17:32 | <annevk> | Domenic: have you thought about merging environment settings objects into Realms btw? |
| 17:33 | <annevk> | Domenic: as in, by just creating Host-defined record fields on Realms |
| 17:33 | <Domenic> | annevk: I thought there were cases where they weren't 1:1? |
| 17:34 | <annevk> | Domenic: bz says he's pretty sure they're 1:1 |
| 17:34 | annevk | is not sure |
| 17:34 | <Domenic> | I think ES also prefers you stuff everything into a single HostDefined slot on their objects. At which point the thing you stuff in there basically is the settings object. |
| 17:35 | <annevk> | Domenic: right, might still be worth doing |
| 17:35 | <annevk> | Domenic: if only to make everything explicit |
| 17:35 | <nox> | Does any UA pass /css21_dev/html4/quotes-036.htm? |
| 17:35 | <annevk> | Domenic: oh, I raised https://github.com/whatwg/html/issues/167 for this at one point |
| 17:37 | <Domenic> | I guess the distinction between the three concepts has kind of grown on me |
| 17:37 | <Domenic> | Global object = thing JS uses, with internal slots to support its public APIs |
| 17:37 | <Domenic> | Realm = more general JS engine concept |
| 17:38 | <Domenic> | Settings object = more general web browser concept |
| 17:38 | <Domenic> | Making the link explicit and maybe adding an explanation like the above to the spec seems good. |
| 17:40 | <annevk> | It's a little uncomfortable that in impls they're typically just one thing, but I guess that'll change with new Realm() |
| 17:43 | <Domenic> | Hmm I don't think that's true |
| 17:43 | <Domenic> | V8 separates Realm and global object at least |
| 17:44 | <Domenic> | Realm <-> v8::Context, which has a v8::Object for the global object, roughly |
| 17:45 | <Domenic> | And then I believe there's some supertype in blink that contains a v8::Context, creates the appropriate v8::Object for window, and contains all the different behavior. That supertype is where the settings object stuff goes I imagine |
| 17:46 | <annevk> | So a settings object holds a Realm? |
| 17:47 | <annevk> | Oh well, doesn't matter |
| 17:47 | <annevk> | I think in Gecko they are the same |
| 17:47 | <Domenic> | I think settings object doesn't correspond to anything very exactly |
| 17:47 | <annevk> | But we should design with what we think the setup will be |
| 17:47 | <Domenic> | (in Blink) |
| 17:48 | <Domenic> | I guess I'd like to put everything inside Realm and define things in terms of that. I'll comment on the bug. |
| 17:49 | <Domenic> | http://krijnhoetmer.nl/irc-logs/ doesn't have last two months? |
| 17:49 | <annevk> | Yeah, not sure what's up with krijn's server |
| 17:49 | <annevk> | krijn: awake? |
| 17:50 | <annevk> | I solved it for myself with IRCCloud, so I kinda stopped caring about it, not the best, I realize |
| 17:53 | <krijn> | People stopped caring, like you said |
| 17:53 | <krijn> | Myself included |
| 17:53 | <annevk> | krijn: heh, it had a good run |
| 17:54 | <krijn> | Setup is too shitty, so it will break eventually |
| 17:54 | <annevk> | krijn: it's still useful at times I think to be able to point somewhere, but if it's too much trouble, understood |
| 17:54 | <krijn> | It'll stay up forever-ish, just not adding new stuff anymore |
| 17:54 | <krijn> | Hard disk is full as well :] |
| 17:55 | <krijn> | 1.2gb of text |
| 17:58 | <krijn> | (Also, I measured the amount of effort to put in on the number of donations, which I shouldn't have done ;) |
| 18:00 | <astearns> | krijn: just donated - not to bring it back, necessarily. Just in appreciation for the last few years |
| 18:15 | <TabAtkins> | krijn: Patreon for donations, yo. |
| 18:20 | <krijn> | astearns: thanks! |
| 18:22 | <krijn> | TabAtkins: that site that needs 1.3mb of JS to load? Grr! |
| 18:22 | <TabAtkins> | krijn: Hey, they have their sins, but they're *ridic* good for getting small regular donations from people. |
| 18:22 | <TabAtkins> | I'm currently in for ~$60/month to a bunch of folks. |
| 18:23 | <krijn> | (It's not really about the money, though, caring is an issue atm. Sorry HTML5 cabal!) |
| 18:29 | <jyasskin> | I'm working on adding an "interface" to https://w3c.github.io/permissions/#permission-registry, something like the environment settings object interface, except I expect it to be implemented more widely. Are there examples of similar things elsewhere? I'm especially looking for good ways to describe the argument and return types of the algorithms folks will |
| 18:29 | <jyasskin> | need to override. |
| 18:30 | <Domenic> | jyasskin: "interface" in this case is not "IDL interface"? |
| 18:30 | <jyasskin> | Right, it's a set of algorithms that vary by permission. |
| 18:31 | <Domenic> | Hmm hmm. I can think of a few examples, but IIRC they aren't terribly specific about argument and return types... let me see. |
| 18:31 | <jyasskin> | For example, https://html.spec.whatwg.org/multipage/webappapis.html#environment-settings-object is an interface that's implemented at https://html.spec.whatwg.org/multipage/browsers.html#script-settings-for-browsing-contexts. |
| 18:31 | <jyasskin> | I'm happy to make up a convention if none exists, but it's always nicer to be able to copy. |
| 18:31 | <Domenic> | jyasskin: https://html.spec.whatwg.org/#fetching-scripts-set-up-request might be close to what you're thinking |
| 18:34 | <Domenic> | oooh i think i have one |
| 18:34 | <Domenic> | jyasskin: https://dom.spec.whatwg.org/#get-the-parent |
| 18:35 | <jyasskin> | Yeah, that's a good example. |
| 19:45 | <jgraham> | annevk: You can point people to glob's logs I guess |
| 20:59 | <jyasskin> | Domenic: See https://rawgit.com/jyasskin/permissions/allow-choosers/index.html#permission-registry for how it turned out. Comments are welcome on https://github.com/w3c/permissions/pull/66. |
| 21:19 | <Domenic> | jyasskin: looks like a pretty sweet setup, very nice |
| 21:19 | <jyasskin> | Thanks! |