2020-08-01 [17:46:38.0000] (eg by using a single-match or last-match on replacing to insert both your data script and the execution script that consumes it) [17:47:02.0000] I believe the browser stack middleware for unit test capture works that way as well. 2020-08-03 [15:13:46.0000] TabAtkins: thanks much for raising https://github.com/whatwg/html/issues/5778 [15:13:55.0000] thanks for inspiring it ^_^ [16:13:44.0000] TabAtkins: added a comment https://github.com/whatwg/html/issues/5778#issuecomment-668284945 2020-08-04 [18:45:05.0000] I'm trying to determine whether it is expected that there appears to be no way for a line break in a data attribute to also become a line break in CSS generated content. e.g. using ::after { display:block; content: attr(title);}. I'm using which Firefox/Safari/Chrome agree to render as line break in the native tooltip, but Chrome/Safari collapse it to a space and Firefox eats it away. [18:45:36.0000] I tried white-space: pre; as well as it seems fair to collapse whitespace by default the same as it would if it were a real element, but no dice. [01:08:44.0000] MikeSmith: TabAtkins: looking at the output of https://github.com/whatwg/fetch/pull/1065 replacing aside with div doesn't really help [01:09:25.0000] MikeSmith: TabAtkins: is the only way forward to disable MDN boxes? [04:04:09.0000] annevk: Any idea how a browsing context set (https://html.spec.whatwg.org/multipage/browsers.html#browsing-context-set) can contain more than one tlbc? Creating a new tlbc creates a new group (https://html.spec.whatwg.org/multipage/browsers.html#creating-a-new-top-level-browsing-context), so it feels like the set can only ever contain one item [04:05:50.0000] JakeA: create a popup [04:05:59.0000] JakeA: "auxiliary" [04:06:22.0000] JakeA: i.e., or window.open() [04:09:18.0000] ah, cheers, it always catches me out that auxiliary browsing contexts are also top-level browsing contexts, but aren't created via "create a new top-level browsing context" [04:09:52.0000] JakeA: I guess that is a little weird [04:10:19.0000] JakeA: I suspect we'll rename create a new top-level browsing context to create a new browsing session eventually [04:10:33.0000] although... that would also need to happen for auxiliary, so no [04:11:48.0000] annevk: I'm seeing if I can decouple session history from browsing contexts right now. I'll add notes for things that trip me up along the way. [04:12:19.0000] JakeA: so what we want is that session history is 1:1 with a top-level bc [04:12:25.0000] including auxiliary [04:13:03.0000] so a browsing session holds a (auxiliary) top-level bc and survives COOP and such [04:15:06.0000] annevk: doesn't session history need to sit above tlbc, since a browsing session's history can contain many tlbcs? [04:15:51.0000] JakeA: yeah, 1:1 was wrong, it's 1:M [04:17:07.0000] annevk: Yeah, I'm going to try moving browsing contexts to session history items, and move session history to some concept of a "navigable" [04:17:30.0000] Where frames have a "navigable", and the top level navigable is a browsing session [04:18:11.0000] JakeA: do frames need a thing of their own at all? Or can the session entry contain some kind of tree? [04:18:40.0000] I think in impls session entries are across the entire top-level bc (and therefore a tree to capture navigations in frames) [04:19:12.0000] annevk: I think it's better if frames have their own thing, then removal of the frame can also remove those session history items [04:19:44.0000] Yeah, that is needed [04:19:48.0000] Session history seems like more of a timeline to me [04:20:02.0000] JakeA: it might be worth doing a writeup somewhere and get smaug____ to take a look [04:20:16.0000] annevk: smaug____: ta-da https://github.com/whatwg/html/issues/5767 [04:33:49.0000] Here's a PR for the bit that confused me https://github.com/whatwg/html/pull/5780 [04:41:49.0000] I'll have a look in a bit [06:01:43.0000] JakeA: thanks; I'll ping some folks internally [06:12:33.0000] ta! [06:16:31.0000] annevk: I will take a look at the validation errors right now [06:17:31.0000] MikeSmith: that's great, thanks! [06:45:31.0000] annevk: so the cause is a bug in my Bikeshed code for placing the annos; the code is meant to detect whether the target it’s annotating has an dt ancestor, but I can see that code is not actually detecting the dt ancestor as expected. So I’ll step through it now it see why. But if I can can’t get it figured out soon, I’ll make a patch/PR for turning of the MDN panels for now, for WHATWG bikeshed [06:45:36.0000] specs [07:10:38.0000] MikeSmith: it does seem not all WHATWG specs are affected [07:21:49.0000] annevk: yeah it only affects specs that have dfn inside dt element [07:22:12.0000] anyway, I found the bug [07:22:44.0000] will raise a PR witha patch [08:50:39.0000] the biggest thing to fix in session history is the whole joint session history concept [08:51:56.0000] (I don't understand what this DOMContentLoaded thingie is about) [08:51:57.0000] smaug____: My suggestion is to replace it with 'steps'. Where the top-level thing dictates which step the history should be at, and from that each navigable can determine which of their session history entries that corresponds to [08:54:21.0000] I don't see 'steps' in https://github.com/whatwg/html/issues/5767 [08:54:50.0000] smaug____: See the "details" in "Specifying the history as a 'timeline'" [08:55:53.0000] last time I checked all the implementations had list of trees as the implementation. [08:55:58.0000] Perhaps that has changed since [08:56:12.0000] but if that is still the case, might be worth to use that in the spec too [08:56:44.0000] perhaps "the single history timeline has to be enforced through algorithms." means that? [08:59:06.0000] Implementations are bad here tho [08:59:21.0000] so I don't find matching implementations compelling 😀 [08:59:34.0000] Edge had the most reasonable behavior [08:59:43.0000] or perhaps it was IE [09:00:08.0000] Interesting, I didn't test that. What did it do different to Firefox? [09:02:03.0000] trying to recall... it had something to do with DOM mutations [09:04:20.0000] With the timeline/steps model, I focused on enforcing the single history timeline across contexts, while still making things tidy up nicely when contexts are removed (which was one nice thing about the joint session history) [09:11:11.0000] Can't find now the testcase for IE [09:11:26.0000] I did notice that at some point Chrome has changed behavior [09:11:50.0000] http://mozilla.pettay.fi/moztests/history2/Start.html behaves rather oddly now at the last step [09:11:52.0000] Yeah, it's much more sensible now, but still not as good as Firefox when it comes to removed contexts [09:12:15.0000] I guess Chrome behaves now like Presto used to [09:16:50.0000] Fwiw I created https://iframe-session-history.glitch.me/ to test the browsers, but it's pretty manual since I was exploring the various behaviours [11:13:46.0000] annevk: any ideas on next steps for X-Frame-Options? I'd love to get something merged... maybe if implementers aren't being too responsive, we could just merge the spec and tests as-is and then file bugs, and see if that drives further refinements? [11:38:33.0000] Domenic: yeah, dveditz said he was gonna look, I can ping one more time tomorrow [14:43:24.0000] about those line breaks in pseudo elements, I have a repro at https://codepen.io/Krinkle/pen/bGpbjBa?editors=1000 which also shows the difference between Chrome/Safari and Firefox, where Firefox eats the line break. 2020-08-05 [19:39:52.0000] TabAtkins: https://github.com/tabatkins/bikeshed/pull/1742 has the fix for the problem that’s breaking the WHATWG spec builds [00:02:04.0000] MikeSmith: TabAtkins: I went ahead and merged that [00:02:41.0000] annevk: makes sense, thanks [00:02:51.0000] can still be reviewed post-merge [00:03:14.0000] but it a was pretty simple fix, for a silly-oversight kind of thing [00:03:23.0000] It also has resolved the build issues [00:03:45.0000] yay 🎉 [00:03:51.0000] sorry for having broken the build [00:04:13.0000] I really should have anticipated the problems, and tested more myself [00:06:14.0000] 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 [00:12:28.0000] right [00:15:47.0000] and also in general, Bikeshed's own test automation doesn't include running the HTML checker [00:18:06.0000] and it probably shouldn't in general, because I'm guessing it might run into a lot of errors with with other specs [00:19:26.0000] but, I dunno, maybe we could make it run the checker for WHATWG specs at least [00:20:51.0000] ...since we know those are otherwise valid, that would help catch any Bikeshed changes that introduced validity regressions [03:46:23.0000] That would be a pretty cool enhancement [05:06:59.0000] question about math parsing test: [05:07:22.0000]
[05:07:23.0000] Expected: [05:07:23.0000] | [05:07:23.0000] | [05:07:23.0000] | [05:07:25.0000] | [05:07:27.0000] Got: [05:07:30.0000] | [05:07:32.0000] | [05:07:35.0000] | [05:07:37.0000] | [05:07:40.0000] | [05:07:42.0000] ... [05:07:45.0000] Does that look familiar to anybody? [05:07:47.0000] gsnedders maybe? [05:08:14.0000] the validator.nu Java parser seems to be failing that test [05:08:45.0000] MikeSmith: no idea, scarcely touched parsing in years [05:09:47.0000] gsnedders: ok yeah I reckon others who worked on html5lib tests probably also haven’t touched it in years [05:10:25.0000] hsivonen just wrote a PR! [05:10:36.0000] for html5lib? [05:10:43.0000] html5lib-tests, yeah [05:10:58.0000] aha [05:11:05.0000] well I guess I should look at that [05:11:18.0000] sorry I can't be much help! [05:12:07.0000] no worries [05:14:04.0000] hmm all browsers also fail that math-parsing test [05:14:32.0000] https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cmath%3E%3Ctr%3E%3Ctd%3E%3Cmo%3E%3Ctr%3E [05:15:10.0000] ...if I am looking at the Live DOM Viewer results correctly [05:18:50.0000] Firefox Nightly is giving the expected above? [05:19:52.0000] gsnedders: oh, yes — I was just misreading it (looking at actual instead of expected) [05:19:53.0000] So does Chrome Canary afaict [05:20:13.0000] (Safari TP does too) [05:20:20.0000] yeah, sorry I had just flipped the actual/expected [05:20:49.0000] Curious that validator.nu does it wrong as I believe Firefox's code is still generated from that [05:31:36.0000] annevk: yeah that is also I what I don’t understand either [05:32:20.0000] I think there are some differences that are introduced when the Java code is translated to the C++ code for Firefox [05:32:40.0000] but this case would be a pretty big surprising difference [05:39:35.0000] hmm isn’t https://github.com/whatwg/html/commit/8cf34ad2ac651329f2c682f16e11faa5cbad839c “Handle foster-parenting of and elements” the relevant change? [05:40:16.0000] and if so I can’t find that was ever implemented in the Java code [05:41:09.0000] MikeSmith: maybe the code bases did diverge then, hsivonen would know best [05:41:19.0000] ok [08:03:50.0000] 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 [08:04:37.0000] 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 [08:06:02.0000] annevk: doesn't the DOM already make them a tree? The navigable is owned by the iframe [08:06:51.0000] JakeA: well but if you reparse it from the network, how do you know what to restore it too? [08:09:55.0000] annevk: ahh yes, in that case the "restorable session history" forms a tree [08:12:03.0000] JakeA: okay, so I think you and smaug____ might be on the same page then [08:12:47.0000] JakeA: for the bfcache case you could indeed have a "simpler" session entry, with more logic in the document itself [08:13:26.0000] annevk: yeah, right now "restorable state" is either a Document or a serialisable "restorable session history" [08:13:59.0000] So that enforces that the history item doesn't need a Document and serialisable state at the same time [08:15:31.0000] 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. [08:15:46.0000] JakeA: maybe the document should have a weak ref to the BC [08:16:20.0000] JakeA: well, it already has a ref so maybe that's enough [08:16:30.0000] annevk: yeah, I was thinking there needs to be a weakmap where the document is the key and the BC is the value [08:17:05.0000] Yeah maybe, I guess I'm not entirely sure what happens to the document's ref when it's navigated away [08:17:27.0000] 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. [08:17:59.0000] annevk: it stays in the history entry if it's bfcache restorable [08:18:33.0000] JakeA: well but if the document has it the history entry wouldn't have to worry about it [08:18:56.0000] JakeA: and it could be unset when the document is collected [08:19:18.0000] annevk: yeah, I could manually unset it. Maybe I'm over complicating it by trying to make it weak [08:19:42.0000] I was trying to avoid having to manually unset it, but the weak ref thing might be more complex than it's worth [08:20:06.0000] We already have some amount of destructer-type things [08:23:38.0000] I'm pretty positive on this now; hoping folks internally will share their feedback, if any, soonish [08:25:26.0000] 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 [08:29:29.0000] 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 [08:29:58.0000] JakeA: but having a solid foundation will only help with that [08:30:30.0000] (mostly saying that, e.g., history.length === nr of steps might not be the final answer here) [08:31:08.0000] 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 [08:43:01.0000] annevk: any further bikeshedding on the various cross-origin isolation booleans welcome. https://github.com/whatwg/html/pull/5752#issuecomment-669264642 [09:06:08.0000] Domenic: I suggested cross-origin isolated capability in the original issue [09:06:21.0000] Not bad [12:02:09.0000] Honest question: Is there any use case for today that's not served better by other tags like , advantageous? [13:38:28.0000] I have never once used or seen it used in any tutorial more recent than the last decade. [16:25:21.0000] I remember 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, or these days 2020-08-06 [23:52:18.0000] littledan: if you do something like realmGlobal.document = new FakeDocument();, wouldn't that FakeDocument have the wrong global associated with it? [00:08:46.0000] /me filed https://github.com/tc39/proposal-realms/issues/268 [03:17:52.0000] Thanks for the ping annevk , following up on the issue. I am not sure if I understand the concern. [10:27:44.0000] Domenic: so does HTML dispatch a load event for network errors for I looked it up and it already does for