| 01:59 | <MikeSmith> | Web Share API shipped in Safari Technology Preview 66 |
| 01:59 | <MikeSmith> | https://developer.apple.com/safari/technology-preview/release-notes/ |
| 02:00 | <MikeSmith> | Mek: about bikeshed to auto-run on commits to a github repo, I would tell you how if I knew myself, but I have never set it up |
| 02:52 | <annevk> | Mek: you have to write scripts of sorts, WHATWG has some shared infrastructure for this, all shared (except for keys) |
| 03:00 | <Mek> | eventually I found very helpful step-by-step instructions at https://github.com/rtoy/auto-deploy-spec |
| 03:13 | <annevk> | 👍🏻 |
| 07:29 | <MikeSmith> | Mek: FWIW a link to that https://github.com/rtoy/auto-deploy-spec should be getting added to https://w3c.github.io/ soonish |
| 07:33 | <MikeSmith> | as far as W3C publishing goes, that https://w3c.github.io/ is meant to be the central place where editors and WGs can look to for info about related tooling |
| 07:35 | <MikeSmith> | (there’s already a Automatic Publication from GitHub section on the page, but the current info there applies only to aut-publishing to https://w3.org/TR/ space) |
| 11:13 | <ivaror> | Does anyone want to hear a joke? |
| 11:14 | <ivaror> | What is an abnormal HTMLSlotElement? |
| 11:16 | <ivaror> | anyone?? ) |
| 11:21 | <ivaror> | a normal HTML element |
| 17:06 | <TabAtkins> | ??? |
| 17:23 | <domfarolino> | RT^ |
| 17:31 | <TabAtkins> | Mek: And I've now linked to rtoy's steps in Bikeshed's docs. (Sorry, last time I learned of these steps, they weren't yet ready for public consumption.) |
| 20:39 | <domfarolino> | zcorpan: Is http://web-platform-tests.live/ basically the new http://w3c-test.org? |
| 20:55 | <TabAtkins> | domfarolino: I think so, yes. |
| 21:11 | <Domenic> | Oh cool |
| 21:11 | <Domenic> | Does it have submissions though |
| 21:30 | <TabAtkins> | I dunno. It's just the same code running on a different server. |
| 23:08 | <Domenic> | TabAtkins: dumb question, is there a reason why fieldset/legend couldn't be redone in terms of shadow DOM too? |
| 23:08 | <TabAtkins> | The obvious reason is that it has a bizarre rendering. |
| 23:09 | <TabAtkins> | But if we isolate that, I'm not sure - I *think* there's sufficient legacy issues to make it troublesome, but I'm not certain about that. It might be doable. |
| 23:09 | <TabAtkins> | Would have to consult with zcorpan. |
| 23:09 | <TabAtkins> | (Not a dumb question, btw.) |
| 23:12 | <Domenic> | Yeah, my impression of zcorpan's work was that interop was all over the place on edge cases, so I was wondering what the observable effects of shadow DOM vs. magic CSS boxes was. Apparently it affects ::before/::after, but unsure what else. |
| 23:12 | <Domenic> | (And maybe ::before/::after is enough of a reason, i.e. if that works interoperably currently in a way that's not compatible with shadow DOM, then maybe we couldn't change it.) |
| 23:13 | <TabAtkins> | Yeah, magic CSS boxes can do *whatever they want* re: ::before/::after. Shadow DOM has a single common way to do this. (Tho, uh, I think it's not actually specified...) |
| 23:14 | <TabAtkins> | The thing with fieldset::before is, I think, that it goes before all content *inside* the fieldset, but it's technically after the rendered legend (which got lifted up into the border). |
| 23:15 | <TabAtkins> | So whether that violates Shadow DOM's treatment or not depends on how much of the "rendered legend" behavior is CSS-layout magic, and how much is CSS-box-tree magic. |
| 23:16 | <TabAtkins> | I'd prefer to consider it a magical CSS `display` value that's not author-exposed, in which case the rendering *is* consistent with Shadow DOM, unless there's some weirder edge cases I'm not aware of. |
| 23:16 | <TabAtkins> | But to the best of my knowledge that's correct: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6238 |