WHATWG
2025-10-31
plaintext logs
prev next
source on github
09:49
<smaug>
oh, import is becoming fetch? https://github.com/tc39/proposal-import-bytes
09:50
<annevk>
smaug: kinda, dunno if you saw, but Mozilla is proposing "text" as well
09:51
<smaug>
didn't see
09:51
<smaug>
I just saw "bytes" in my review queue and pondered "what is this, never heard" šŸ™‚
09:51
<annevk>
https://github.com/whatwg/html/issues/9444#issuecomment-3462527442
10:47
<annevk>
jarhar: why does none of the selectedcontent impl logic check for the button element being there?
11:32
<Luke Warlow>
jarhar: why does none of the selectedcontent impl logic check for the button element being there?
I think because you can put it in your picker as well? Not just within the button.
12:46
<annevk>
Luke Warlow: not per its content model.
15:28
<jarhar>
sure we can make it check for the button if you want
15:29
<jarhar>
i also plan to make the selectedcontent element work outside of the select element in the future though for other cases where you can build your own popover with a select in it
15:50
<annevk>
I was mainly looking for motivation. It probably does not give much benefit to enforce it
17:22
<sb3nder>

Hi,
I have a question about focus. Iā€™m having a bit of a hard time following the spec.

With a page like this:

<body>
	<div id="target">#target</div>
	<a href="#target">go to #target</a>
</body>

Or like this:

<body>
	<button>before</button>
	<iframe>
		<div id="target">#target</div>
		<a href="#target">go to #target</a>
	</iframe>
	<button>after</button>
</body>

If I click the link go to #target and then press Shift+Tab, where should the focus go according to the spec?

17:27
<annevk>
sb3nder: based on https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-the-fragment-identifier the document's viewport gets focus, but I don't think it's strictly defined where that sits in the tab order (and to some extent that's all up to implementations as it's UI)
17:28
<annevk>
sb3nder: that is, the document's viewport gets focus when you follow the link as the div is not a focusable area (I'm assuming it's not scrollable here)
17:41
<sb3nder>

I get lost in this part:

  1. If new focus target is not a focusable area, then set new focus target to the result of getting the focusable area for new focus target, given focus trigger if it was passed.

Wouldn't get the focusable area set new focus target to null?

18:03
<sb3nder>
ah! not this part, my bad, I forgot which it was.
18:55
<sb3nder>

Maybe I get it now,
when I get to 6.6.5 Sequential focus navigation after pressing Shift+Tab

  1. If there is a sequential focus navigation starting point defined and it is inside starting point, then let starting point be the sequential focus navigation starting point instead.

for example:
In Firefox the focused element is <html> ,
while in Chrome is <body>,
because in Chrome calling focus() on <html> or <body> sets activeElement to <body>,
and in Firefox calling focus() on <html> sets activeElement to <html> and can't be called on <body>

19:27
<sb3nder>
nah, I don't get what is the document's viewport and if it's focusable...