01:45
<Krinkle>
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 &#013; 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.
01:45
<Krinkle>
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.
08:08
<annevk>
MikeSmith: TabAtkins: looking at the output of https://github.com/whatwg/fetch/pull/1065 replacing aside with div doesn't really help
08:09
<annevk>
MikeSmith: TabAtkins: is the only way forward to disable MDN boxes?
11:04
<JakeA>
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
11:05
<annevk>
JakeA: create a popup
11:05
<annevk>
JakeA: "auxiliary"
11:06
<annevk>
JakeA: i.e., <a target=x> or window.open()
11:09
<JakeA>
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"
11:09
<annevk>
JakeA: I guess that is a little weird
11:10
<annevk>
JakeA: I suspect we'll rename create a new top-level browsing context to create a new browsing session eventually
11:10
<annevk>
although... that would also need to happen for auxiliary, so no
11:11
<JakeA>
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.
11:12
<annevk>
JakeA: so what we want is that session history is 1:1 with a top-level bc
11:12
<annevk>
including auxiliary
11:13
<annevk>
so a browsing session holds a (auxiliary) top-level bc and survives COOP and such
11:15
<JakeA>
annevk: doesn't session history need to sit above tlbc, since a browsing session's history can contain many tlbcs?
11:15
<annevk>
JakeA: yeah, 1:1 was wrong, it's 1:M
11:17
<JakeA>
annevk: Yeah, I'm going to try moving browsing contexts to session history items, and move session history to some concept of a "navigable"
11:17
<JakeA>
Where frames have a "navigable", and the top level navigable is a browsing session
11:18
<annevk>
JakeA: do frames need a thing of their own at all? Or can the session entry contain some kind of tree?
11:18
<annevk>
I think in impls session entries are across the entire top-level bc (and therefore a tree to capture navigations in frames)
11:19
<JakeA>
annevk: I think it's better if frames have their own thing, then removal of the frame can also remove those session history items
11:19
<annevk>
Yeah, that is needed
11:19
<JakeA>
Session history seems like more of a timeline to me
11:20
<annevk>
JakeA: it might be worth doing a writeup somewhere and get smaug____ to take a look
11:20
<JakeA>
annevk: smaug____: ta-da https://github.com/whatwg/html/issues/5767
11:33
<JakeA>
Here's a PR for the bit that confused me https://github.com/whatwg/html/pull/5780
11:41
<annevk>
I'll have a look in a bit
13:01
<annevk>
JakeA: thanks; I'll ping some folks internally
13:12
<JakeA>
ta!
13:16
<MikeSmith>
annevk: I will take a look at the validation errors right now
13:17
<annevk>
MikeSmith: that's great, thanks!
13:45
<MikeSmith>
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
13:45
<MikeSmith>
specs
14:10
<annevk>
MikeSmith: it does seem not all WHATWG specs are affected
14:21
<MikeSmith>
annevk: yeah it only affects specs that have dfn inside dt element
14:22
<MikeSmith>
anyway, I found the bug
14:22
<MikeSmith>
will raise a PR witha patch
15:50
<smaug____>
the biggest thing to fix in session history is the whole joint session history concept
15:51
<smaug____>
(I don't understand what this DOMContentLoaded thingie is about)
15:51
<JakeA>
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
15:54
<smaug____>
I don't see 'steps' in https://github.com/whatwg/html/issues/5767
15:54
<JakeA>
smaug____: See the "details" in "Specifying the history as a 'timeline'"
15:55
<smaug____>
last time I checked all the implementations had list of trees as the implementation.
15:55
<smaug____>
Perhaps that has changed since
15:56
<smaug____>
but if that is still the case, might be worth to use that in the spec too
15:56
<smaug____>
perhaps "the single history timeline has to be enforced through algorithms." means that?
15:59
<JakeA>
Implementations are bad here tho
15:59
<JakeA>
so I don't find matching implementations compelling 😀
15:59
<smaug____>
Edge had the most reasonable behavior
15:59
<smaug____>
or perhaps it was IE
16:00
<JakeA>
Interesting, I didn't test that. What did it do different to Firefox?
16:02
<smaug____>
trying to recall... it had something to do with DOM mutations
16:04
<JakeA>
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)
16:11
<smaug____>
Can't find now the testcase for IE
16:11
<smaug____>
I did notice that at some point Chrome has changed behavior
16:11
<smaug____>
http://mozilla.pettay.fi/moztests/history2/Start.html behaves rather oddly now at the last step
16:11
<JakeA>
Yeah, it's much more sensible now, but still not as good as Firefox when it comes to removed contexts
16:12
<smaug____>
I guess Chrome behaves now like Presto used to
16:16
<JakeA>
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
18:13
<Domenic>
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?
18:38
<annevk>
Domenic: yeah, dveditz said he was gonna look, I can ping one more time tomorrow
21:43
<Krinkle>
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.