| 10:11 | <DarwinElf> | i've always liked to download the HTML specification for offline usage (since the 1990s) and after W3C replied on Github and finally made an html52.tar.gz file, they said they'd do one for future versions... but I don't see an html53.tar.gz anywhere, or is that not the latest normally-numbered version? |
| 10:26 | <DarwinElf> | hmm... it's a living document now? Anytime I edit HTML and might have to learn/review something, is it best to just read/download the latest version? It used to sometimes be years until I was aware of a new version from W3C but it seems you're working on it much more than they were in the past... |
| 10:28 | <DarwinElf> | though it'd be nice to read from a tarball as well as single-page or PDF... is it acceptable/doable to copy the developer version with wget or something? |
| 11:32 | <annevk> | DarwinElf: that should be fine, there’s also a PDF |
| 11:34 | <annevk> | DarwinElf: there’s a half-yearly snapshot for lawyers, but for most people the latest version is the one to read, which is updated somewhat frequently indeed |
| 15:10 | <domfarolino> | annevk: What would an async/defer equivalent for images buy us? They are already not render-blocking. It could unblock the load event but is that a big win? |
| 15:38 | <annevk> | domfarolino: it might be as lots of execution blocks on that; pages coded that way might not adopt this though |
| 16:47 | <annevk> | domfarolino: I think it also frees up some space for browsers to innovate versus only fetching when it is about to intersect the viewport |
| 16:52 | Ms2ger | waves |
| 16:52 | <Ms2ger> | See y'all in '20 |
| 17:00 | <domfarolino> | annevk: Sounds like that would result in a looser spec than we have now right? We'd specify the image can be deferred from parse-time until basically any time the browser wants to fetch...that seems vague |
| 17:08 | <annevk> | domfarolino: yeah |
| 17:12 | <domfarolino> | annevk: seems a little tricky to test, but haven’t thought about it much |
| 20:49 | <bathos> | Got a question re: https://gist.github.com/alice/174ae481dacdae9c934e3ecb2f752ccb |
| 20:49 | <bathos> | I was under the (maybe mistaken) impression that one of the motivations for the AOM reflection API was that it could solve currently intractable accessibility issues when using shadow DOM. One of the options listed in this gist says that it ‘does not allow authors to refer to elements across any shadow boundaries.’ Am I understanding correctly that this means this API might not end up addressing those issues? |
| 21:01 | <Domenic> | bathos: yes, my understanding is that due to Apple and Mozilla preferences it is no longer clear whether we will be able to have accessible shadow DOM structures in this way. |
| 21:03 | <bathos> | ouch ... well, crossing my fingers that they’ll reconsider its importance. thanks for confirming |