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.
For all three methods, an 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 |
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 :( |
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. |
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. |
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!
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. 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 |