04:24
<Smudge>

Hi! I want to know if there's any likelihood of footnotes becoming an element of HTML. They're mentioned in the HTML spec in section 4.14.4 as a feature without "a dedicated mechanism." The spec then suggests alternatives. Of the alternatives: using <title> is inaccessible, using <a> causes me to easily lose my place in the text with how I prefer to have it positioned on the screen, and the other suggestions don't apply to the type of footnotes I'm interested in. Altogether, I feel pretty dissatisfied with the state of footnotes on the web. :(

I genuinely love reading footnotes in fiction (for jokes and translation notes!) but the UX for footnotes on the web makes it so that the inconvenience of them outweighs the joy I'd get from reading those extra bits when they'd be most appropriate. I was happy enough to overlook the inconvenience but after so many encounters I feel like there has to be a better way.

04:37
<jschoi>

I’m not part of WHATWG, but this is a topic I am interested in.
However, note that there are many ways to do footnotes:

  1. As is most popular on the web, you can put footnote content at the very end of a page or section and link references to them in the main text.
  2. Using CSS Grid, you can make footnote content appear in a sidebar, Edward Tufte style (https://www.edwardtufte.com/wp-content/uploads/2024/03/VE-Spread-Detail-2.jpg). This is my personal preferred way to do footnotes.
  3. Using HTML Popovers, you can put footnote content declaratively in a popover element, then add references to them in the main text using buttons. The buttons can declaratively make their respective popovers appear.

For all three methods, an <aside> element could contain the footnote content. But all of these are quite different semantically.

That’s the problem with trying to standardize “footnotes”. The semantics of what we call “footnotes” are diverse and may be quite specific to the document context that they appear in. Some people will want content at the very end; some people will want them in a sidebar near their references; some people will want popovers.

(With that said, I’m a bit surprised nobody else has asked this question in the whatwg/html GitHub repository. But I know that this has been discussed many times in the past.)

04:53
<Smudge>
Yeah! Language is funky and weird. I'm using "footnotes" to mean notes that appear in a page's footer, which is more relevant for print than web. I think print might have more specific words for these that haven't reached web people. 🤔 Something in my brain is telling me that "endnotes" is for the ones that appear at the very end of a work. I haven't played with HTML Popovers yet. I'll look into that some more! Thanks for the tip, jschoi!
05:05
<jschoi>

Smudge: If you’re most interested in laying out footnotes in printed pages, you’re looking for the CSS Generated Content for Paged Media Module.

You might also be interested in the generated cross-references in the (confusingly similarly named) CSS Generated Content Module.

Please note that both of these are still under development and therefore have little browser support.

05:08
<Smudge>
Those are good to know about! I'd like to make my footnotes work in both print and web if possible. Thank you, again!
05:29
<annevk>
There's a section on footnotes: https://html.spec.whatwg.org/multipage/semantics-other.html#footnotes
06:54
<Smudge>
There's a section on footnotes: https://html.spec.whatwg.org/multipage/semantics-other.html#footnotes
Yes, I mentioned as much before, but the suggested alternatives to implement the type of footnotes I'm looking for each have undesirable limitations—of them, only the first two are relevant and of those, the first is inaccessible and the second I find disorienting. 😔
09:20
<Andreu Botella>
There aren't any ways to detect whether a cross-origin iframe or parent is in the same agent, right?
09:21
<Andreu Botella>
I'm assuming we don't want a new API to make that information potentially exposable, right?
09:44
<annevk>
keithamus: https://github.com/whatwg/html/issues/10802 has gotten a bit messy since the "good first issue" label was added. Are you willing to untangle it and give the people that showed up some more feedback?
09:45
<annevk>
And maybe we should consider this the final nail in the coffin for that label. Unfortunate, but it doesn't seem to work well. Or maybe too well?
09:46
<annevk>
Andreu Botella: that's right.
09:47
<annevk>
Andreu Botella: although, what we really don't want to expose are the actual process boundaries. Maybe exposing agents can be okay, but we're in the midst of changing the agent boundary through the document.domain removal so hmm.
09:48
<Andreu Botella>
implementation-wise, would that map to e.g. having different V8 isolates, even if it's in the same process?
09:51
<annevk>
I'm not sure. Browsers don't really have a good handle on agents which is another reason to avoid exposing them I suppose.
09:56
<Andreu Botella>
For AsyncContext, I don't think cross-origin events would be too much of an issue, but Scott Haseley pointed out that at least in Chrome, the focus and blur events can be fired synchronously across agents (related to https://github.com/whatwg/html/issues/3506), so that might have to be special cased
09:57
<Andreu Botella>
since for events fired sycnhronously, AsyncContext would always propagate the context, which would be able to be used to detect whether the iframes are in the same agent/process
11:22
<annevk>
Noam Rosenthal: just to confirm, appending Math.random() to an image URL's query is sufficient to cache bust it right?
11:24
<Noam Rosenthal>
annevk: yea unless someone is fiddling with the random seed
11:38
<Noam Rosenthal>
(I've used performance.now() for this a few times and that caused flakes on some platforms)
11:38
<Noam Rosenthal>
If I'm doing this in a test I usually prefer to have an incrementing index
11:58
<Luca Casonato>
Is there currently a way to have an element be persistently at the top of the top layer? Imagine a side-drawer that is implemented as a <dialog>, but then you also want a global toast that can show ontop of the dialog backdrop (and dialog). Because top layer ordering is controlled by opening order, this means that one would have to make the toast a popover and then close and re-open it everytime something else gets added to the top-layer, so that the toast is always at the top of the top layer. Is there a better way?
11:59
<annevk>
Noam Rosenthal: should be fine here, they're all reftests
12:00
<annevk>
Luca Casonato: I don't think so. Might be worth filing an issue on.
12:00
<Luca Casonato>
@anne
12:01
<Luca Casonato>
@annevk Will do. The more I get exposed to the top layer, the more I feel like it is not a good abstraction :(
12:05
<Luca Casonato>
@annevk Will do. The more I get exposed to the top layer, the more I feel like it is not a good abstraction :(
https://github.com/whatwg/html/issues/11193
12:09
<annevk>
Luca Casonato: yeah maybe. What's at least clear is that developers would like more control over it. Though how to give that and not run into other issues doesn't seem straightforward to solve.
12:30
<annevk>
krosylight: thanks for closing that PR, please don't forget the "invalid" label next time
12:32
<annevk>
(The "invalid" label is what helps GitHub determine whether certain people are spammy.)
13:18
<Luke Warlow>
Luca Casonato: yeah maybe. What's at least clear is that developers would like more control over it. Though how to give that and not run into other issues doesn't seem straightforward to solve.
Yeah I hear this a lot from people. They want control via CSS or at least a way to have more control. But I struggle to see how this doesn't end up being z-index wars all over again.
13:19
<Luca Casonato>
Yeah I hear this a lot from people. They want control via CSS or at least a way to have more control. But I struggle to see how this doesn't end up being z-index wars all over again.
I mean I can deal with z-index. I can not deal with not having any control at all 😆
13:21
<Luke Warlow>
I suspect we'd maybe be better trying to directly solve the specific use cases rather than ripping open the layer for all to access. Like perhaps we need a toast primitive that is always on top.
13:23
<Luca Casonato>
That’s an option too for sure.
13:43
<Simon Wülker>

Hi!
When trying to build the DOM standard locally with make local I get the following error:

LINE 6103:64: Multiple possible 'head' element refs.
Arbitrarily chose https://html.spec.whatwg.org/multipage/semantics.html#the-head-element
To auto-select one of the following refs, insert one of these lines into a <pre class=link-defaults> block:
spec:html; type:element; text:head
spec:epub-34; type:element; text:head
<{head}>
 ✘  Did not generate, due to errors exceeding the allowed error level.
make: *** [Makefile:19: local] Error 2

Is there something I'm doing wrong or is this a known issue?

13:55
<smaug>
oh, fun, session history rewrite changed the definition of script-closeable. I wonder why
14:02
<annevk>
Simon Wülker: it's known insofar I just encountered it myself. You can add text: head as a final line to the link-defaults block as a workaround for now (including the leading space).
14:14
<Luca Casonato>
How does hit detection work for the top layer (where is it specified)? In my tests the first layer of the top layer always sits ontop of any newer layers for hit detection (but newer layers do render on top of the first layer). Both Chrome and Firefox behave this way seemingly.
14:49
<annevk>
Luca Casonato: hit testing is famously not defined
15:48
<Luca Casonato>
How does hit detection work for the top layer (where is it specified)? In my tests the first layer of the top layer always sits ontop of any newer layers (which do render on top of the first layer). Both Chrome and Firefox behave this way seemingly.
Oh it seems like this happens because when the dialog is opened through showModal(), it makes the rest of the page inert, including the other things in the top layer above it.
15:50
<Luca Casonato>
I think https://html.spec.whatwg.org/multipage/interaction.html#blocked-by-a-modal-dialog should get an exception for elements in the top layer above the subject dialog. I'll open an issue.
16:04
<Luca Casonato>
https://github.com/whatwg/html/issues/11195
17:14
<Luke Warlow>
There's actually been some discussion about this recently related to the interactivity property. Essentially you need to do more than just "uninert" the top layer items. AT won't let you navigate to the higher items otherwise