| 10:22 | <annevk> | tobie: so I read "I think we need a community group for that." and for a moment there I thought you were serious, then read the rest |
| 10:24 | <tobie> | annevk: yeah. This work mode is an important cause of the current situation. |
| 10:25 | <tobie> | annevk: it puts the burden of initiating change on those that are victims of the status quo. |
| 10:27 | <tobie> | annevk: but then lets those benefiting from the status quo keep the situation as is by refusing to enact change (absence of consensus for change at the AC level). |
| 10:28 | <tobie> | annevk: this is how Swirtzerland works, btw. |
| 10:28 | <annevk> | Yeah, hence WHATWG, but WHATWG isn't exactly diverse either |
| 10:29 | <tobie> | annevk: yes on both counts. |
| 10:49 | <smaug____> | Hmm, what is the best way to search through wpt to see if some behavior is being tested |
| 10:50 | <smaug____> | perhaps I should just run them all |
| 10:50 | <smaug____> | and change implementation to see if anything breaks |
| 10:50 | <smaug____> | (or get unexpected pass) |
| 10:55 | <jgraham_> | smaug____: We might have useful coverage data these days? |
| 10:56 | <smaug____> | jgraham_: hmm |
| 10:56 | <smaug____> | this particular case is about form element stuff inside shadow DOM |
| 10:57 | <jgraham_> | smaug____: https://github.com/marco-c/code-coverage-reports/blob/master/web-platform-tests.tar.xz has wpt coverage data |
| 10:57 | <jgraham_> | From Firefox CI |
| 13:18 | <annevk> | smaug____: I tend to resort to grep and digging around in the couple places that might make sense |
| 14:38 | <annevk> | frivoal: fyi tobie was sarcastic |
| 14:48 | <frivoal> | hehe. That went way over my head. Also, I had heard the same comment made non sarcastically by a couple of people right before, so... |
| 14:49 | <frivoal> | either way, this is a real problem, and priviledged people alone are unlikely to be in the best position to get to the bottom of it. |
| 14:49 | <frivoal> | (which doesn't mean committees are the best way of out this) |
| 14:53 | <annevk> | yeah |
| 14:53 | <tobie> | frivoal: oops. see my comments above. The problem with that is we’re basically asking minorities to do the work for free. And then it’ll die at the AC. |
| 15:23 | <jyasskin> | tobie: What was the context? |
| 15:23 | <jyasskin> | +1 for that being a problem. |
| 15:24 | <tobie> | jyasskin: essentially me being a sarcastic jerk on twitter. :-/ |
| 15:28 | <tobie> | jyasskin: https://twitter.com/annevk/status/994876132422975489?s=21 |
| 15:29 | <jyasskin> | Your joke was good. |
| 15:37 | <jyasskin> | WHATWG has something of the opposite problem: browser implementers are in a position of power, and folks who don't work for a browser have an uphill battle even if they're right. |
| 15:43 | <tobie> | It’s the same problem, really. Creating diversity grants would be a good first step imho. |
| 16:15 | <annevk> | Domenic: I'm gonna uppercase those variable names now |
| 16:15 | <annevk> | Domenic: for https://github.com/whatwg/whatwg.org/pull/201 that is |
| 16:15 | <Domenic> | annevk: ah OK sounds good |
| 16:16 | <annevk> | Domenic: shall I also add my review.sh thingie? |
| 16:16 | <Domenic> | Yeah please go ahead :). I was prepared to take over since it's getting late for you but if you're still working go for it |
| 16:31 | <annevk> | Domenic: should be all in order now |
| 16:32 | <annevk> | Domenic: I haven't quite tested the full setup though, only the individual pieces |
| 16:32 | <annevk> | Domenic: if I do more work later on I'll ping you here first, but it seems unlikely |
| 16:32 | <Domenic> | Yeah, I'll try to give it a try today. It's a bit hard since using curlbikeshed doesn't work until the Bikeshed PR is merged |
| 16:33 | <Domenic> | Maybe landing the Bikeshed changes + CSS refactoring + rebuilding all the living standards would be a good first step |
| 16:33 | <Domenic> | I'll make gray icons of everything |
| 16:33 | <TabAtkins> | Happy to land whenever. |
| 16:35 | <Domenic> | Probably Monday |
| 16:38 | <annevk> | Domenic: I guess the other thing I might work on later is updating Makefile / .gitignore / README.md for standards |
| 17:04 | <annevk> | Did for URL now, as a demo |
| 17:05 | <annevk> | I haven't looked at what we need to do for HTML, hopefully it's not too bad |
| 18:57 | <TabAtkins> | Domenic, annevk, anyone else with an opinion: Putting together the code for cross-spec backrefs now, so uses of a definition in other specs will show up in the dfn's dfn-panel. Should I just put a single reference to the *spec* that's referencing the term, or should I, when possible, put in all the links to the actual references, like you get with the spec-internal references? |
| 18:58 | <TabAtkins> | Possible problem with the latter is that very common types will have *lots* of references - TypeError is referenced by WebIDL alone 70 times, for instance. |
| 19:00 | <Domenic> | Oh wow, interesting/awesome... |
| 19:00 | <TabAtkins> | Maybe just something like `<a href='link-to-spec'>webidl</a> (70 refs)` |
| 19:01 | <TabAtkins> | (Specs that aren't Bikeshedded probably won't have IDs on their refs anyway, so I *can't* link straight to them. But this first run is only going over Bikeshedded specs, so the question still arises.) |
| 19:01 | <Domenic> | I'm a bit confused by that example, where would that show up for TypeError? Since TypeError is defined in JS. |
| 19:02 | <TabAtkins> | Yeah, it's just the particular thing I'm looking at. Imagine anothe rspec that's actually bikeshedded. ^_^ |
| 19:03 | <TabAtkins> | Like, Infra's set/append definition is referenced 8 times in WebIDL. |
| 19:04 | <TabAtkins> | list-iterate has 12 refs in WebIDL. |
| 19:04 | <TabAtkins> | etc. |
| 19:04 | <Domenic> | Got it, yeah. I think that would work well, maybe with [WebIDL] as the text |
| 19:05 | <Domenic> | You could do the whole thing with <details>, but with a big increase in output file size in many cases, I imagine. |
| 19:05 | <TabAtkins> | Yeah, if I go this way I'd just use the same naming code that generates the spec names in the indexes. |
| 19:05 | <TabAtkins> | Yeah, exactly. |
| 19:06 | <Domenic> | I have a related idea to make that work even better... |
| 19:06 | <TabAtkins> | The fact that you can't iterate down the list of refs, like you can internal ones, suggests to me that having the full list wouldn't be that helpful. |
| 19:06 | <TabAtkins> | Yeah? |
| 19:06 | <Domenic> | If you made the "Terms defined by other specifications" behave like https://html.spec.whatwg.org/multipage/infrastructure.html#dependencies |
| 19:06 | <Domenic> | where clicking on the term opens a dfn panel |
| 19:07 | <Domenic> | Then you could have "70 refs" link to the entry in "Terms defined by other specifications" |
| 19:07 | <Domenic> | So you could jump directly to the usage of the term in the other spec's appendix and see all uses |
| 19:07 | <TabAtkins> | Ooooh. |
| 19:08 | <TabAtkins> | Hm, I'd have to do some verification that said newly-generated section actually exists, in case you're looking at a spec that hasn't been regenerated recently, or isn't Bikeshed at all... |
| 19:09 | <TabAtkins> | But I wanted to do that anyway, to verify that the URL your .bs file claims is where you're published actually contains a document on the other end... (WebVR, for example, is now lying.) |
| 19:10 | <TabAtkins> | (Claims to live at https://immersive-web.github.io/webvr/, was moved to https://immersive-web.github.io/webvr/spec/1.1/, first URL is now a "this spec is abandoned, here's a link to it for legacy purposes" landing page.) |
| 19:13 | <annevk> | This sounds quite exciting |
| 19:13 | <TabAtkins> | I think my current attempt is probably not great anyway, and I should just be parsing HTML directly and inferring the spec it's referencing via URL. That'll automatically extend to non-Bikeshed things, and won't depend on possibly-legacy linking data. |
| 19:17 | <TabAtkins> | I'll do that "dfn-panel for Terms Defined By Reference" thing first, that's more straightforward. |
| 19:46 | <jyasskin> | TabAtkins: This sounds great, and I like Domenic's https://html.spec.whatwg.org/multipage/infrastructure.html#dependencies suggestion. Note, though, that it wasn't obvious to me that clicking would open the dfn panel instead of jumping to the definition in the other spec. |
| 19:46 | <TabAtkins> | Yeah, it looks like a link there. I won't be styling it like a link. |
| 19:46 | <Domenic> | Ah that makes sense |
| 19:59 | <Domenic> | Can the Bikeshed web service parse multiple Text-Macro values? |
| 19:59 | <Domenic> | And more trickily, how would I pass them with curl? |
| 20:35 | <TabAtkins> | https://api.csswg.org/bikeshed/ explains how to pass metadata to bikeshed via the curl api. It *should* handle multiple Text-Macro values, but you'd have to check. |
| 22:59 | <TabAtkins> | All right, Terms Defined By Reference is now dfn-panel'd. Let me know if there's anything you want fixed in https://github.com/tabatkins/bikeshed/issues/1249. I'll give more thought to backreferences next week. |