| 02:39 | <MikeSmith> | TabAtkins: https://github.com/tabatkins/bikeshed/pull/1742 has the fix for the problem that’s breaking the WHATWG spec builds |
| 07:02 | <annevk> | MikeSmith: TabAtkins: I went ahead and merged that |
| 07:02 | <MikeSmith> | annevk: makes sense, thanks |
| 07:02 | <MikeSmith> | can still be reviewed post-merge |
| 07:03 | <MikeSmith> | but it a was pretty simple fix, for a silly-oversight kind of thing |
| 07:03 | <annevk> | It also has resolved the build issues |
| 07:03 | <MikeSmith> | yay 🎉 |
| 07:03 | <MikeSmith> | sorry for having broken the build |
| 07:04 | <MikeSmith> | I really should have anticipated the problems, and tested more myself |
| 07:06 | <annevk> | This wasn't too bad, I guess part of the problem is that while Bikeshed does have WHATWG regression tests, they are not going through the same build process |
| 07:12 | <MikeSmith> | right |
| 07:15 | <MikeSmith> | and also in general, Bikeshed's own test automation doesn't include running the HTML checker |
| 07:18 | <MikeSmith> | and it probably shouldn't in general, because I'm guessing it might run into a lot of errors with with other specs |
| 07:19 | <MikeSmith> | but, I dunno, maybe we could make it run the checker for WHATWG specs at least |
| 07:20 | <MikeSmith> | ...since we know those are otherwise valid, that would help catch any Bikeshed changes that introduced validity regressions |
| 10:46 | <annevk> | That would be a pretty cool enhancement |
| 12:06 | <MikeSmith> | question about math parsing test: |
| 12:07 | <MikeSmith> | <math><tr><td><mo><tr> |
| 12:07 | <MikeSmith> | Expected: |
| 12:07 | <MikeSmith> | | <math math> |
| 12:07 | <MikeSmith> | | <math tr> |
| 12:07 | <MikeSmith> | | <math td> |
| 12:07 | <MikeSmith> | | <math mo> |
| 12:07 | <MikeSmith> | Got: |
| 12:07 | <MikeSmith> | | <math math> |
| 12:07 | <MikeSmith> | | <math tr> |
| 12:07 | <MikeSmith> | | <math td> |
| 12:07 | <MikeSmith> | | <math mo> |
| 12:07 | <MikeSmith> | | <math tr> |
| 12:07 | <MikeSmith> | ... |
| 12:07 | <MikeSmith> | Does that look familiar to anybody? |
| 12:07 | <MikeSmith> | gsnedders maybe? |
| 12:08 | <MikeSmith> | the validator.nu Java parser seems to be failing that test |
| 12:08 | <gsnedders> | MikeSmith: no idea, scarcely touched parsing in years |
| 12:09 | <MikeSmith> | gsnedders: ok yeah I reckon others who worked on html5lib tests probably also haven’t touched it in years |
| 12:10 | <gsnedders> | hsivonen just wrote a PR! |
| 12:10 | <MikeSmith> | for html5lib? |
| 12:10 | <gsnedders> | html5lib-tests, yeah |
| 12:10 | <MikeSmith> | aha |
| 12:11 | <MikeSmith> | well I guess I should look at that |
| 12:11 | <gsnedders> | sorry I can't be much help! |
| 12:12 | <MikeSmith> | no worries |
| 12:14 | <MikeSmith> | hmm all browsers also fail that math-parsing test |
| 12:14 | <MikeSmith> | https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cmath%3E%3Ctr%3E%3Ctd%3E%3Cmo%3E%3Ctr%3E |
| 12:15 | <MikeSmith> | ...if I am looking at the Live DOM Viewer results correctly |
| 12:18 | <gsnedders> | Firefox Nightly is giving the expected above? |
| 12:19 | <MikeSmith> | gsnedders: oh, yes — I was just misreading it (looking at actual instead of expected) |
| 12:19 | <annevk> | So does Chrome Canary afaict |
| 12:20 | <annevk> | (Safari TP does too) |
| 12:20 | <MikeSmith> | yeah, sorry I had just flipped the actual/expected |
| 12:20 | <annevk> | Curious that validator.nu does it wrong as I believe Firefox's code is still generated from that |
| 12:31 | <MikeSmith> | annevk: yeah that is also I what I don’t understand either |
| 12:32 | <MikeSmith> | I think there are some differences that are introduced when the Java code is translated to the C++ code for Firefox |
| 12:32 | <MikeSmith> | but this case would be a pretty big surprising difference |
| 12:39 | <MikeSmith> | hmm isn’t https://github.com/whatwg/html/commit/8cf34ad2ac651329f2c682f16e11faa5cbad839c “Handle foster-parenting of <math> and <svg> elements” the relevant change? |
| 12:40 | <MikeSmith> | and if so I can’t find that was ever implemented in the Java code |
| 12:41 | <annevk> | MikeSmith: maybe the code bases did diverge then, hsivonen would know best |
| 12:41 | <MikeSmith> | ok |
| 15:03 | <annevk> | JakeA: so I looked a bit at your thing and I think it works, but it seems to me that you need to store the navigables as a tree on the (top-level) session entry |
| 15:04 | <annevk> | JakeA: in particular the previous document can be gone at which point all you have is a session history entry to try to rebuild it, including the history positions of its frames |
| 15:06 | <JakeA> | annevk: doesn't the DOM already make them a tree? The navigable is owned by the iframe |
| 15:06 | <annevk> | JakeA: well but if you reparse it from the network, how do you know what to restore it too? |
| 15:09 | <JakeA> | annevk: ahh yes, in that case the "restorable session history" forms a tree |
| 15:12 | <annevk> | JakeA: okay, so I think you and smaug____ might be on the same page then |
| 15:12 | <annevk> | JakeA: for the bfcache case you could indeed have a "simpler" session entry, with more logic in the document itself |
| 15:13 | <JakeA> | annevk: yeah, right now "restorable state" is either a Document or a serialisable "restorable session history" |
| 15:13 | <JakeA> | So that enforces that the history item doesn't need a Document and serialisable state at the same time |
| 15:15 | <JakeA> | I'll keep noodling on the spec then. I might so a first pass that doesn't do the restorable state stuff, so that's a 'smaller' thing to review and land. But I'll try to prove that the restorable state stuff can be layered on top of that. |
| 15:15 | <annevk> | JakeA: maybe the document should have a weak ref to the BC |
| 15:16 | <annevk> | JakeA: well, it already has a ref so maybe that's enough |
| 15:16 | <JakeA> | annevk: yeah, I was thinking there needs to be a weakmap where the document is the key and the BC is the value |
| 15:17 | <annevk> | Yeah maybe, I guess I'm not entirely sure what happens to the document's ref when it's navigated away |
| 15:17 | <JakeA> | annevk: I want the reference the history entry has to the BC to be weak, so the BC can be destroyed when documents are no longer using it. |
| 15:17 | <JakeA> | annevk: it stays in the history entry if it's bfcache restorable |
| 15:18 | <annevk> | JakeA: well but if the document has it the history entry wouldn't have to worry about it |
| 15:18 | <annevk> | JakeA: and it could be unset when the document is collected |
| 15:19 | <JakeA> | annevk: yeah, I could manually unset it. Maybe I'm over complicating it by trying to make it weak |
| 15:19 | <JakeA> | I was trying to avoid having to manually unset it, but the weak ref thing might be more complex than it's worth |
| 15:20 | <annevk> | We already have some amount of destructer-type things |
| 15:23 | <annevk> | I'm pretty positive on this now; hoping folks internally will share their feedback, if any, soonish |
| 15:25 | <JakeA> | I'll push the 'right' Chrome folks to do the same. There's been general positivity so far, but just need to get higher up navigation folks to give it the thumbs up |
| 15:29 | <annevk> | JakeA: I do think we'll probably want to experiment more with our options for the API itself; in terms of less cross-origin leakage and such |
| 15:29 | <annevk> | JakeA: but having a solid foundation will only help with that |
| 15:30 | <annevk> | (mostly saying that, e.g., history.length === nr of steps might not be the final answer here) |
| 15:31 | <JakeA> | annevk: yeah, I think Chrome does some stuff here like "history.back does nothing if called from a sandboxed iframe and the navigation would be external to the iframe", which seems sensible at a very minimum. But yes, might want to lock this and .length down further |
| 15:43 | <Domenic> | annevk: any further bikeshedding on the various cross-origin isolation booleans welcome. https://github.com/whatwg/html/pull/5752#issuecomment-669264642 |
| 16:06 | <annevk> | Domenic: I suggested cross-origin isolated capability in the original issue |
| 16:06 | <Domenic> | Not bad |
| 19:02 | <innovati> | Honest question: Is there any use case for <embed> today that's not served better by other tags like <svg>, <video>, <audio>, <iframe>, etc? When is <embed> advantageous? |
| 20:38 | <TabAtkins> | I have never once used <embed> or seen it used in any tutorial more recent than the last decade. |
| 23:25 | <innovati> | I remember <embed> from the Flash days, and understand that theoretically that's how support for different types of data can be plugged into the browser…are there still people doing that these days with other plugins/formats? It seems like a lot of stuff like that gets supported in DOM, <svg> or <canvas> these days |