| 01:37 | <sideshowbarker> | looking at https://github.com/mdn/browser-compat-data/pull/12376 |
| 01:38 | <sideshowbarker> | can somebody remind me what is the WebIDL keyword that replaced the Transferable API? |
| 02:08 | <sideshowbarker> | nevermind, I found https://html.spec.whatwg.org/multipage/structured-data.html#transferable and https://html.spec.whatwg.org/multipage/structured-data.html#detached |
| 02:08 | <sideshowbarker> | …I had just expected to find the definitions of those in the WebIDL spec itself, rather than in the HTML spec |
| 04:32 | <Dominic Farolino> | How can a worklet have multiple realms? https://html.spec.whatwg.org/multipage/webappapis.html#worklet-agent |
| 07:41 | <annevk> | Dominic Farolino: iirc each script that you add through addModule or equivalent runs in its own realm |
| 07:42 | <annevk> | Dominic Farolino: it's a bit different from <iframe> in that the realms cannot access each other directly (though they can prolly observe each other) |
| 08:23 | <foolip> | https://webidl.spec.whatwg.org/ is up! |
| 08:24 | <foolip> | annevk: did you deliberate not replace WebIDL with Web IDL in https://webidl.spec.whatwg.org/#legacy-constructs? |
| 08:24 | <Ms2ger 💉💉> | Webi DL |
| 08:27 | <annevk> | foolip: I might have forgotten to grep for WebIDL, I can review a follow-up PR 🙂 |
| 09:47 | <annevk> | Dominic Farolino: can you have a look at https://github.com/whatwg/spec-factory/pull/32 btw? |
| 10:12 | <annevk> | Two for one special today: https://testutils.spec.whatwg.org/ by jgraham |
| 12:00 | <sideshowbarker> | foolip: annevk About spec frontmatter, to trim down some of the vertical space, I think we should consider:
|
| 12:01 | <sideshowbarker> | the rationale for the single GitHub icon is that since GitHub repos all have exactly the same structure, users already know how to get from the base repo URL to the issues list, commit history, etc. |
| 12:02 | <sideshowbarker> | so or https://webidl.spec.whatwg.org/ we’d have, at the end of title or subtitle, one GitHub icon and one Twitter icon |
| 12:03 | <sideshowbarker> | but tests are a different thing — I think ideally what we should have at the top if each spec is a copy of the corresponding row of test results from wpt.fyi |
| 12:04 | <annevk> | Heh, my biases are different! I like the individual links we have toward GitHub. 🙂 |
| 12:05 | <annevk> | I wouldn't mind entertaining some alternatives to what we have now though, but I'm not entirely convinced a couple of logos is clear enough for everyone. |
| 12:07 | <sideshowbarker> | well for W3C specs, we are moving to putting all the frontmatter in a details element |
| 12:08 | <sideshowbarker> | …and Marcos and I are working on showing some other more-useful spec-specific data at the top |
| 12:08 | <sideshowbarker> | …including the test results |
| 12:09 | <sideshowbarker> | so for example at the top of the WebIDL spec, we’d have a table showing that ⬆ |
| 12:09 | <sideshowbarker> | …except it would also show colors — shades of green and red |
| 12:10 | <annevk> | That seems reasonable, but isn't number of open GitHub issues also indicative of quality? |
| 12:11 | <annevk> | (Not sure I like details. Pretty much the only thing I need when looking at a spec is a way to find filing an issue, but that's my bias I suppose.) |
| 12:11 | <sideshowbarker> | That seems reasonable, but isn't number of open GitHub issues also indicative of quality? |
| 12:11 | <sideshowbarker> | (to show what I mean about the colors) |
| 12:12 | <sideshowbarker> | (Not sure I like |
| 12:14 | <sideshowbarker> | I assert that we should be optimizing for the readers who benefit the most from us having the spec frontmatter give them some clear indicators to help them get oriented with the spec |
| 12:14 | <annevk> | Yeah, has W3C done surveys with spec readers? It'd be pretty interesting to know what people are looking for primarily |
| 12:14 | <sideshowbarker> | …and I think the readers we should be trying to most to help are typical-developer readers |
| 12:14 | <Ms2ger 💉💉> | Weighted by number of hours per week looking at specs |
| 12:15 | <sideshowbarker> | Yeah, has W3C done surveys with spec readers? It'd be pretty interesting to know what people are looking for primarily |
| 12:17 | <sideshowbarker> | other thing I we should add to all our specs is a Can I Use table like the ones that Respec specs now have |
| 12:17 | <sideshowbarker> | example https://w3c.github.io/geolocation-api/ |
| 12:19 | <sideshowbarker> | …of course those tables are lot more interesting in the case of specs that aren’t implemented in all engines — so you get some red and orange and yellow in there too |
| 12:20 | <sideshowbarker> | …and it’s dynamic — you can hover to get more browser-version info |
| 12:21 | <sideshowbarker> | anyway, I plan to get that Can I Use table generation added to Bikeshed as a feature |
| 12:21 | <sideshowbarker> | and Marcos and I will be working on getting the wpt.fyi table generation added to both Respec and Bikeshed |
| 12:22 | <sideshowbarker> | …and soon all W3C specs by default will have all the other frontmatter collapsed by default |
| 12:22 | <sideshowbarker> | example https://w3c.github.io/webappsec-mixed-content/ |
| 12:23 | <sideshowbarker> | collapsing all that other frontmatter into details gives room for the Can I Use and wpt.fyi tables to actually show up above the fold — in the initial viewport, without readers needing to have to know to scroll down to see those |
| 12:24 | <sideshowbarker> | anyway, that’s just an idea dump that I mention here after taking a first look at the WebIDL and Test Utils specs |
| 12:55 | <foolip> | no surveys have been done of this kind, as far as I know — I think foolip might be the a good person to put together such a survey in the right way |
| 13:03 | <annevk> | foolip: if we could get them + browser developers (e.g., email webkit-dev, dev-platform, and blink-dev to please also fill it out), we'd have a pretty good start I think |
| 14:38 | <TabAtkins> | Okay I was excited about WebIDL moving to whatwg, but I'm much less excited about the CSS regressions. No more persistent ToC really sucks for a spec that you often bounce around semi-randomly in. |
| 14:42 | <Luca Casonato> | Okay I was excited about WebIDL moving to whatwg, but I'm much less excited about the CSS regressions. No more persistent ToC really sucks for a spec that you often bounce around semi-randomly in. |
| 14:42 | <Luca Casonato> | Also dark mode being gone is unfortunate. |
| 14:44 | <Luca Casonato> | Also felt the "old" design was more readable because the center container was less wide. Now I have to resize the browser window to make it somewhat readable (like I already do with fetch and HTML specs) |
| 14:46 | <annevk> | This was mentioned before in https://github.com/whatwg/meta/issues/117 though it didn't really get traction. I'd be open to changing this, but not really sure I have the bandwidth to drive it at the moment. |
| 14:47 | <annevk> | I guess the trick would be to sufficiently scope it and try not to address all the styling issues 🙂 |
| 14:48 | <Luca Casonato> | Yup |
| 14:48 | <Luca Casonato> | I'd personally vote for side-ToC being more important, as the max-width can easially be "resolved" by just making the entire viewport less wide. |
| 14:49 | <TabAtkins> | I filed an issue with the three styling issues that seem most unfortunate to me from the change |
| 15:26 | <TabAtkins> | gonna just file a PR that's the Bikesheed stylesheet but with the colors changed to green |