| 01:22 | <nox> | heycam: Great, thanks. |
| 01:40 | <TabAtkins> | Domenic: I accidentally fixed the "using [[DOM]] puts [WHATWG-DOM] in the biblio index" problem, while fixing another bug. |
| 01:41 | <TabAtkins> | (Whatever form you use in an explicit biblio ref is now used automatically by anything else that grabs the same biblio ref, whether through an aliased term or what-have-you.) |
| 06:42 | <annevk> | Is GitHub super slow today? |
| 08:38 | <annevk> | terinjokes: is https://github.com/whatwg/fetch/issues/259 something that's worth standardizing language for in the Console Standard? |
| 09:08 | <Ms2ger> | zcorpan, can I bug you about https://github.com/w3c/csswg-test/pull/1066 ? |
| 09:42 | <zcorpan> | Ms2ger: looking |
| 09:42 | <zcorpan> | what does this construct do again? https://github.com/w3c/csswg-test/pull/1066/files#diff-c8670d7412c9acf48f69da4f9aa995c0R39 |
| 09:43 | <Ms2ger> | I suspect it returns matrix after calling f() on it, but do complain about it :) |
| 10:15 | <zcorpan> | ok reviewed |
| 10:21 | <Ms2ger> | Thanks |
| 12:50 | <annevk> | zcorpan: philipj: https://www.w3.org/Bugs/Public/show_bug.cgi?id=29018 |
| 13:56 | <annevk> | Woohoo, less than 200 open legacy bugs |
| 14:13 | <philipj> | annevk: uh, yes, not sure what to do about that one, would need to redo testing to refresh my memory |
| 14:36 | <zcorpan> | gsnedders: jgraham: some of my <menuitem> tests fail in html5lib even though the Expected: and Received: are the same. Is that due to #errors being different, or something else? |
| 14:38 | <Ms2ger> | I think we might check the number of errors still? |
| 14:52 | <zcorpan> | https://github.com/html5lib/html5lib-tests/pull/72 |
| 14:53 | <zcorpan> | happy eastern everyone! see y'all on wednesday |
| 14:54 | <wanderview> | annevk: if you get a sec, can you confirm that step 8 here should not copy the destination or type from the original request? https://fetch.spec.whatwg.org/#dom-request |
| 14:56 | <wanderview> | annevk: or maybe it should copy them... the fetch() method invokes the constructor immediately... is it intentional to lose those values if a service worker does fetch(evt.request)? |
| 14:58 | <wanderview> | I'll write an issue... you can close if I'm just confused |
| 15:01 | <wanderview> | https://github.com/whatwg/fetch/issues/262 |
| 15:10 | <annevk> | wanderview: that was intentional |
| 15:10 | <annevk> | wanderview: since destination affects the CSP policy |
| 15:11 | <wanderview> | annevk: right, but doesn't that break CSP for passthrough service worker requests? |
| 15:11 | <annevk> | wanderview: I can add a note about the things we don't copy intentionally I guess |
| 15:11 | <annevk> | wanderview: I don't think so |
| 15:12 | <annevk> | wanderview: the document that initiates the fetch will get the CSP policy applied it asked for, and then in the worker you'll get the CSP policy corresponding to destination "" |
| 15:12 | <wanderview> | annevk: so this assumes the worker has a different CSP policy? |
| 15:13 | <annevk> | wanderview: a service worker will always have its own policy afaik |
| 15:13 | <annevk> | wanderview: I think all workers do |
| 15:16 | <wanderview> | annevk: hmm, ok... not sure why marcos wanted the destination/type to propagate... might need you to comment on the gecko bug at some point |
| 15:20 | <annevk> | wanderview: left a comment |
| 15:21 | <wanderview> | where? |
| 15:22 | <Ms2ger> | Under the mat before your back door |
| 15:22 | <annevk> | wanderview: I got a collision with your comment, so I think I'll leave it now since you said effectively the same |
| 15:22 | <annevk> | wanderview: I'll add the extra bit I added to GitHub instead |
| 15:22 | <wanderview> | thanks |
| 15:34 | <Domenic> | annevk: https://github.com/whatwg/html/issues/929 seems bogus to me; can you take a look? The client is the worker, right? Which is a fine place to inherit HTTPS state from. |
| 15:44 | <annevk> | Domenic: the problem is that it does not have state yet, I discussed that case earlier with jwatt |
| 15:46 | <annevk> | Domenic: gotta go for a bit, one last thing |
| 15:46 | <annevk> | Domenic: it'd be ideal for Mozilla if custom elements was all done and sorted within the next couple of weeks |
| 15:47 | <Domenic> | annevk: hmm ok, good to know. can do, but why? |
| 15:47 | <annevk> | Domenic: if there's anything I can do let me know, I'll let it take precedence over the Shadow DOM work I've been doing |
| 15:47 | <Domenic> | annevk: it'll probably just be agressive reviews as I move things to HTML. |
| 15:48 | <Domenic> | annevk: next week has some TC39 meetings that might slow things down but rest of this week and the week after next I can make it my top focus |
| 15:49 | <annevk> | Domenic: there's a large number of Mozillians in Taipei that'll be doing more Gecko work and in a couple of weeks I believe wchen will be there to help them get started with this |
| 15:49 | <annevk> | Domenic: some of them, anyway |
| 15:49 | <annevk> | Domenic: so if the spec is mostly done, that's ideal |
| 15:49 | <annevk> | Domenic: I'll do another review tomorrow then |
| 15:50 | <Domenic> | annevk: biggest missing piece is still the custom element callbacks :-/. I'll hopefully at least get a start on that today/tomorrow |
| 16:37 | <annevk> | Domenic: what timezone is TC39 in? |
| 16:37 | <Domenic> | annevk: San Francisco |
| 17:39 | <tobie> | Is there a best practice for when you should be putting the dfn within WebIDL, compared to out of it? |
| 17:42 | <TabAtkins> | If you're specifically defining something, put the dfn near it, so the IDL will link to it. You want anyone visiting the anchor to land on the definition. |
| 17:42 | <TabAtkins> | If it's more trivial, feel free to leave it in the IDL. |
| 17:44 | <tobie> | TabAtkins: ty |
| 17:45 | <tobie> | TabAtkins: asking because now my WebIDL in another spec references the dfn rather than the IDL, which is weird. |
| 17:45 | <TabAtkins> | Why weird? |
| 17:47 | <tobie> | TabAtkins: well, in interface AmbientLightSensor : Sensor {}; Sensor links to the dfn and not the IDL, which seems weird, no? |
| 17:48 | <TabAtkins> | Again, why weird? |
| 17:50 | <TabAtkins> | (Also, Sensor isn't in Bikeshed's db - you using local refs? Should I add something to Bikeshed's d? |
| 17:51 | <TabAtkins> | *db |
| 17:51 | <annevk> | tobie: that would be weird, yes |
| 17:52 | <tobie> | TabAtkins: Oh, so that might explain it. |
| 17:52 | <tobie> | annevk: OK, I thought so too. |
| 17:52 | <annevk> | tobie: class names should reference IDL |
| 17:52 | <TabAtkins> | I agree that an interface name isn't something that should be separated from its definition. |
| 17:53 | <tobie> | TabAtkins, annevk: sorry this is a combination of me not being super familiar with Bikeshed + me not being super familiar with spec editing. :) |
| 17:53 | <TabAtkins> | The most pertinent definition of "what this interface is" is the interface itself. It's just a name given an object shape, unlike methods and attributes. |
| 17:53 | <annevk> | tobie: no need to apologize, we're all here to learn |
| 17:54 | <TabAtkins> | tobie: You're talking about this dfn, right? https://w3c.github.io/sensors/#sensor |
| 17:55 | <tobie> | TabAtkins: yes. |
| 17:56 | <tobie> | TabAtkins: it's extra confusing because I have a "sensor concept" which doesn't map the Sensor interface 1:1. |
| 17:56 | <TabAtkins> | Alright, so (a) Imma go pop that into Shepherd, and (b) feel free to file a bug asking for them to change that <dfn> to an <a>. |
| 17:56 | <TabAtkins> | You can ref me and Anne saying that interface dfns should be in the IDL, as the most useful "definition" of the term. ^_^ |
| 17:58 | <tobie> | well, I wrote both, so I can go fix it myself. :) |
| 17:58 | <TabAtkins> | Ah, kk. ^_^ |
| 17:58 | <TabAtkins> | In that case, is the desired shortname "sensor" or "generic-sensor"? |
| 17:59 | <tobie> | the latter. |
| 18:00 | <tobie> | you might want to wait before I pushed changes to fix this, then. |
| 18:00 | <tobie> | TabAtkins: ^ |
| 18:01 | <TabAtkins> | Nah, it'll pick up the differences after you push them, it's fine. |
| 18:01 | <TabAtkins> | Specs that aren't in its CI notification structure get reparsed like once a day or something. |
| 18:02 | TabAtkins | is still sincerely wondering if he should take this part of Bikeshed on his own, rather than relying on Shepherd. |
| 18:02 | <tobie> | TabAtkins: cool, so how does it work, though. Will the IDL in the AmbientLightSensor spec, automatically link to the Generic Sensor one? |
| 18:03 | <TabAtkins> | Oh, you'll need to rebuild at some point to make that work. |
| 18:03 | <TabAtkins> | But right now you're probably relying on a local <pre class=anchors> block anyway, so wtv. |
| 18:04 | <tobie> | Mmm. I'm not sure I understand all of those subtleties. |
| 18:05 | <TabAtkins> | Okay. So. |
| 18:05 | <TabAtkins> | I just added the Generic Sensor spec to Shepherd a few minutes ago. Shepherd will parse the spec and extract all its definitions, and repeat this about once a day or so iirc in case things change. |
| 18:06 | <tobie> | OK, I figured that part. :) |
| 18:06 | <TabAtkins> | Your Ambient Light Sensor spec was already linking to Generic Sensor. Since it wasn't in Shepherd yet, it wasn't relying on Bikeshed's built-in autolinking database. It was either doing a manual link (ewwwwww) or was using a <pre class=anchors> block to tell Bikeshed about some additional cross-spec refs it should know about, for the purpose of processing |
| 18:06 | <TabAtkins> | this spec. |
| 18:07 | <tobie> | OK, now I get it. |
| 18:07 | <tobie> | I guess what makes it weird is that I don't know upfront what spec is in shepherd in which isn't. |
| 18:08 | <tobie> | s/in/and/ |
| 18:08 | <tobie> | So sometimes the magic works and sometimes it doesn't. |
| 18:09 | <TabAtkins> | Yeah, that's a bit of a problem. |
| 18:09 | <tobie> | For example, the permissions-API isn't in Shepherd, right? |
| 18:09 | <TabAtkins> | The interface isn't publicly available. |
| 18:09 | <TabAtkins> | Yeah, it's not. |
| 18:09 | <tobie> | TabAtkins: got it. |
| 18:10 | <TabAtkins> | You can always ask Bikeshed if it knows about a particular reference or not. Just run: `bikeshed refs` (-h to see the arguments) and it'll list everything it knows matching that ref request. |
| 18:10 | <tobie> | OK, I see. |
| 19:01 | <smaug____> | annevk: rootNode can be consider stable, right? |
| 19:01 | Domenic | is suddenly tempted to bikeshed the name |
| 19:02 | <smaug____> | ha |
| 19:03 | <smaug____> | Domenic: don't even think about or I'll start complaining about Custom Element's callback names and functionality ;) |
| 19:03 | <Domenic> | smaug____: hahaha you got me |
| 19:07 | <smaug____> | s/consider/considered |
| 19:23 | <annevk> | smaug____: yes |
| 20:12 | <jyasskin> | TabAtkins: Can Shepherd handle ReSpec editors' drafts at all? It'd be nice to get the permissions API in there even if we have to use link-defaults a lot. |
| 20:13 | <jyasskin> | TabAtkins: Also, where's Shepherd's list of specs? I'd be happy to send pull requests instead of bugging you for each new spec. |
| 20:18 | <TabAtkins> | jyasskin: Only if the ReSpec spec has explicitly added decent metadata that Bikeshed understands. The format is well-documented now, but it's rather annoying to add by hand, so ~0 specs have done so. |
| 20:18 | <TabAtkins> | jyasskin: (Or if they happen to be using patterns similar to what Shepherd is using to extract definitions from CSS/SVG/HTML/a few others.) |
| 20:19 | <TabAtkins> | (It works better than I'd expect, but not "well".) |
| 20:19 | <TabAtkins> | The list of specs is stored in Shepherd's DB, only accessible via the admin interface which is obviously not public. :/ |
| 20:19 | <TabAtkins> | You can also see it in processed form in Bikeshed's data files, the bikeshed/spec-data/specs.json file. |
| 20:20 | <TabAtkins> | But there's no PR bridge to it; I have to add things manually. |
| 20:20 | <TabAtkins> | (I'm wondering how to fix it, and will bug plinss about it today.) |
| 20:21 | <TabAtkins> | Well actually, that's not true, there's a public API to read the spec data from Shepherd. |
| 20:22 | <jyasskin> | Yeah. IIUC, from ReSpec specs we'd get a lot of non-exported 'dfn' references, but they wouldn't be marked as IDL. |
| 20:22 | <TabAtkins> | https://api.csswg.org/shepherd/ is the human-readable endpoint that describes the REST api. |
| 20:22 | <TabAtkins> | jyasskin: Exactly. |
| 20:23 | <TabAtkins> | If people did what they were *supposed* to and actually published the *processed* ReSpec documents, instead of their source files and a JS converter, this would be easy. ReSpec could use the same sorts of shorthands and such that Bikeshed does, and mark things up well. |
| 20:23 | <jyasskin> | Yeah, I'm looking more for a place to send PRs. |
| 20:23 | <TabAtkins> | But nah, people lazy. |
| 20:24 | <jyasskin> | Presumably Shepherd could run the JS for a page and then process the result. |
| 20:26 | <TabAtkins> | Theoretically, sure. |
| 20:26 | <TabAtkins> | Would require running things in Node and hoping that jsdom is up to the task, tho. Shepherd is written in Python, so it'd need a language bridge, too. |
| 20:27 | <TabAtkins> | I'm bugging plinss now to see if we can have a GH repo be the "canonical" storage for the spec list. |
| 21:02 | <tobie> | TabAtkins: think you could take a quick look at https://github.com/w3c/ambient-light/pull/7/commits/fd7548a |
| 21:03 | <tobie> | TabAtkins: and tell me whether I should be getting auto links to SensorReading SensorOptions and the like? I'm clearly doing something wring and I have no idea what. |
| 21:03 | <tobie> | *wrong |
| 21:04 | <TabAtkins> | Will check in a few, currently walking to Starbucks to avoid the cleaners |
| 21:04 | <tobie> | TabAtkins: ty |
| 21:07 | <Domenic> | jsdom is always up to the task! <3 |
| 21:07 | <Sebmaster> | ^ |
| 21:14 | <tobie> | TabAtkins: src file has now been merged here: https://github.com/w3c/ambient-light/blob/gh-pages/index.bs |
| 21:14 | <tobie> | TabAtkins: note the index.html is the old Respec doc, so don't be surprised if the two are disconnected for now. |
| 21:16 | <wanderview> | jsbell: can you remind me where in the chromium tree your wpt service worker tests are? |
| 21:17 | <wanderview> | I can't seem to find the right path and the source viewer doesn't seem to have a search box any more |
| 21:17 | <jsbell> | wanderview: third_party/WebKit/LayoutTests/http/tests/serviceworkers and cachestorage |
| 21:17 | <wanderview> | thanks! |
| 21:17 | <jsbell> | wanderview: https://cs.chromium.org (cs=codesearch) |
| 21:18 | <wanderview> | jsbell: ah, that helps... I followed the "browse source" link by accident |
| 21:18 | <wanderview> | instead of the search source |
| 21:18 | <jsbell> | np! |
| 21:19 | <wanderview> | jsbell: btw, I am close to upstreaming our tests... are you ok if I just do that and then we can hash out any differences in PRs? |
| 21:19 | <wanderview> | I've probably asked you this before... sorry for the repeat |
| 21:19 | <jsbell> | wanderview: yep, sounds good |
| 21:19 | <wanderview> | thanks again! |
| 21:21 | <TabAtkins> | tobie: How do you want comments, now that it's been merged? |
| 21:21 | <tobie> | TabAtkins: can't you still comment on the PR? |
| 21:21 | <TabAtkins> | I can, yeah. Just asking you whether that was good. Sounds like it is. ^_^ |
| 21:22 | <tobie> | yeah, whatever's more convenient for you. |
| 21:23 | <tobie> | here's fine too, depending on what it is you need to say |
| 21:27 | <tobie> | oh!! dfn |
| 21:27 | <tobie> | TabAtkins: dfns aren't exported by default |
| 21:27 | <tobie> | Now I get it. |
| 21:28 | <TabAtkins> | dfn-type dfns. |
| 21:28 | <TabAtkins> | (Which <dfn>s are if you dont' specify a different type.) |
| 21:28 | <TabAtkins> | When fully expanded, <dfn data-dfn-type=dfn>. ^_^ |
| 21:29 | <tobie> | I-- |
| 21:30 | <tobie> | Maybe I should re-read the doc another 3 times. |
| 21:30 | <TabAtkins> | Yeah, I know. Badly named. Can't fix it now. |
| 21:30 | <TabAtkins> | Really annoying to talk about and I hate it. |
| 21:31 | <TabAtkins> | Something like <dfn interface> (or when expanded, <dfn data-dfn-type=interface>) *are* exported by default. It's just the "dfn"-type ones that are treated different for exporting. |
| 21:31 | <tobie> | BTW, I wasn't really asking for a review of this src file, more of an explanation as to why there wasn't auto-links to the stuff defined in the generic sensor spec. |
| 21:32 | <tobie> | And it seems that's because I've using DFN's for interfaces, and those aren't exported by default |
| 21:32 | <TabAtkins> | They're the wrong type, and *also* as a result of that they aren't exported, yeah. |
| 21:32 | <TabAtkins> | The fact that they're not exported isn't why your autolinks are failing, tho, it's that they're not the right type. |
| 21:33 | <tobie> | https://github.com/w3c/sensors/blob/gh-pages/index.bs#L648 |
| 21:33 | <TabAtkins> | But it looks ok in the source - Sensor is defined with an "interface" type, as it should be. |
| 21:34 | <TabAtkins> | Are you generating your spec with a local copy of Bikeshed, or the remote version? |
| 21:34 | <tobie> | local |
| 21:35 | <TabAtkins> | Have you run `bikeshed update` some time after I put Sensors in the db? |
| 21:35 | <tobie> | mmm |
| 21:35 | <tobie> | yeah-ish |
| 21:36 | <TabAtkins> | May have been too early. I just did it, and SensorReading is definitely in the db now. Update again and it should get picked up. |
| 21:36 | <tobie> | Amazing if it is. |
| 21:36 | <TabAtkins> | Why amazing? |
| 21:37 | <tobie> | Because it's 10:30pm and I'm tired. :) |
| 21:37 | <TabAtkins> | Oh, amazing as in "I'll be happy if so", not "that would be surprising" |
| 21:38 | <tobie> | yeah--sorry. |
| 21:38 | <tobie> | It works. |
| 21:38 | <tobie> | Also it's amazing because it's actually pretty cool tech. |
| 21:38 | <tobie> | :) |
| 21:39 | <TabAtkins> | Cross-spec autolinking is literally the reason I wrote Bikeshed. It is pretty cool. ^_^ |
| 21:39 | <tobie> | indeed. |
| 21:40 | <tobie> | OK, so I'll need to export dfns I want to reference in the AmbientLight spec |
| 21:40 | <tobie> | And should leave the dfn with the WebIDL for the interfaces |
| 21:40 | <TabAtkins> | Yeah. If you don't you can still link them, but you need to declare that you really do mean to link that spec, usually through a link-defaults block. |
| 21:40 | <tobie> | And then it'll be all good. |
| 21:41 | <TabAtkins> | Which is annoying if the term is *meant* to be generally useful for other specs. |
| 21:41 | <tobie> | OK. Got it. |
| 21:41 | <tobie> | Thanks so much for your help. |
| 21:42 | <TabAtkins> | np |
| 21:43 | <TabAtkins> | Glad to help the ecosystem grow. |
| 22:24 | <Krinkle> | Woo. https://w3c.github.io/webstorage/#dom-localstorage points to https://html.spec.whatwg.org/multipage/webstorage.html |
| 22:34 | <tobie> | TabAtkins: curious as to why https://w3c.github.io/sensors/#high-vs-low-level [GEOLOCATION-API] ends up as [geolocation-API] in the ref section. |
| 22:34 | <tobie> | TabAtkins: https://w3c.github.io/sensors/#biblio-geolocation-api |
| 22:36 | <tobie> | TabAtkins: sure, the shortname is mixed-cased, but my local ref isn't. |
| 23:29 | <TabAtkins> | tobie: Because the ref index uses the casing from SpecRef if it's mixed-case, in case that's important. |
| 23:29 | <TabAtkins> | (It uppercases things that are all-lowercase.) |
| 23:30 | <tobie> | TabAtkins: oh, right, because you're not using the specref service |
| 23:30 | <TabAtkins> | Well, I'm calling SpecRef for its data. |
| 23:30 | <tobie> | TabAtkins: the service is case-insensitive and generates an alias on the fly |
| 23:31 | <TabAtkins> | duuuuude, store the casing you want *in the db*. |
| 23:32 | <tobie> | TabAtkins: well... depending on the use case, having the actual shortname casing is important |
| 23:32 | <TabAtkins> | Then don't complain when I preserve it. ^_^ |
| 23:32 | <TabAtkins> | (Bikeshed is also case-insensitive for *looking up* refs. It just preserves the casing for display if it surmises that it's important, such as when the casing is mixed.) |
| 23:33 | <tobie> | Well, sticking references in a spec isn't one of those use cases. :P |
| 23:33 | <TabAtkins> | Mang I can't tell that. |
| 23:35 | <tobie> | It's not that important tbh, but I do think the casing displayed in the ref section should match that used in the body of the spec |
| 23:35 | <tobie> | i.e. those references are internal |
| 23:36 | <TabAtkins> | I can probably do that, given the way I'm handling "preferred" names now. |