Interactions between inert and hidden="until-found" and beforematch events

[romainmenke]

What is the issue with the HTML Standard?

Chrome is the only browser supporting all three features (as far as I know).

And up until Chrome 123 it was possible to set an element to inert, visually hide it with hidden="until-found".
We could then reveal it and make it non-inert through a beforematch event listener.

This was really handy to make accordions as the closed panels should be inert but we still want users to be able to search for text in a page and that the panel is opened and scrolled to when there is a match.

In Chrome 124 this stopped working.

When reading through the spec text for inert it doesn't specifically say that an element should not be findable through search in a page.

So I am not sure if this is a browser bug, or something that never should have worked in the first place and was actually fixed in Chrome 124.

Happy to file browser bugs if this is an issue in Chrome, but wanted to know the actual expected behavior first.

[josepharhar]

Are you revealing it with find in page? Because we recently made find in page stop finding results in inert subtrees.

[romainmenke]

Indeed, this used to work perfectly and inert is what we want.
So we shipped this in dozens of sites :/

As I said, I am unsure if this was ever supposed to work.
Specs don't seem te explicitly say anything about this and both behaviors could be argued for.

[annevk]

Do other browsers find text in (non-hidden) inert subtrees? This should probably be clarified in the standard if nothing is said about it today, though we can at most make this a "should" I suppose.

[romainmenke]

• Safari (latest) ✅
• Chrome worked in 102 - 123, no longer works
• Firefox worked in 112 - 123, no longer works

(weirdly coincidental that this stopped working both in 123)
(lower bound is when those browsers shipped inert)

---

Are there cases where you want an element to be visible, yet inert and not have it appear through "find in page"?

[annevk]

I'm not sure, but it seems a bit suspect and might be an issue for keyboard-only users? cc @whatwg/a11y

[romainmenke]

I agree that it is be bad for keyboard-only users when they find content that remains inert even after discovery.

[romainmenke]

I've investigated a bit further on how we ended up having both inert and hidden on the same elements as this also seemed weird to me.

We started out with panels that were hidden without using the hidden attribute or display: none; so that panel contents could be revealed with animations/transitions.

We used inert to ensure that panel contents were hidden from tab order, accessibility tree, ...

When hidden=until-found and beforematch were added to Chrome we added support, but we didn't revisit our whole implementation.

I think that for our specific case it makes more sense to remove inert altogether. hidden serves the same purpose for our use case.
Animating from hidden can now be done with @starting-style.

---

I think that the spec should clarify that inert elements are not discoverable through find in page and that Safari should be updated to match Chrome and Firefox.

[josepharhar]

Relevant links:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1868316
• https://phabricator.services.mozilla.com/D201906
• [Gecko Bug 1868316] Remove user-find, make inert not findable. web-platform-tests/wpt#44633
• https://issues.chromium.org/issues/327017912
• https://chromium-review.googlesource.com/c/chromium/src/+/5319168

Looks like firefox did it so we followed in chrome

[romainmenke]

the spec should clarify that inert elements are not discoverable through find in page

https://html.spec.whatwg.org/#inert-subtrees

The user agent should ignore the node for the purposes of find-in-page.

Already in the spec :)

---

So to circle back to my original question which was specifically about beforematch event.

Removing inert through beforematch only worked because browsers weren't following the spec for inert and find in page.

So maybe this can be closed as "no change"?

[josepharhar]

So maybe this can be closed as "no change"?

Sounds good to me