Active match timing (until-found and <details>) #12019
Description
What is the issue with the HTML Standard?
Creating complex DOM structures can be expensive for frameworks, and if they're not going to be visible then it seems like a waste, but with <details> and hidden="until-found", this enables things to be searchable in the page.
A nice compromise could be to dump simple text into these elements (presumably cheap) and enhance it into full components once these elements open.
However, that depends on the browser's active-matching coping with the content changing.
I created a quick test where the contents of the elements is changed when they open, but the text content remains the same - search the page for 'w', as that only appears in the hidden sections.
Here are the results:
✅ = Opens the hidden area and highlights the match
❌ = Opens the hidden area but does not highlight the match
| Change delay | Firefox | Chrome | Safari | |
|---|---|---|---|---|
<details> |
No change | ✅ | ✅ | ✅ |
| Sync | ❌ | ❌ | ❌ | |
queueMicrotask |
❌ | ❌ | ❌ | |
requestAnimationFrame |
❌ | ❌ | ❌ | |
setTimeout(cb, 0) |
❌ | ❌ | ❌ | |
<div hidden="until-found"> |
No change | ✅ | ✅ | ✅ |
| Sync | ❌ | ✅ | ❌ | |
queueMicrotask |
❌ | ✅ | ❌ | |
requestAnimationFrame |
❌ | ❌ | ❌ | |
setTimeout(cb, 0) |
❌ | ❌ | ❌ |
My gut feeling is that the sync & queueMicrotask cases should be ✅. Maybe requestAnimationFrame too. It feels ok for the setTimeout case to be unreliable.
Frameworks don't perform their updates synchronously. Most are roughly microtask timing. Some delay further.
There's some similarity here with how #target URLs are resolved, where there's some leniency in the timing.