Allowing Browser find-in-page to find non-DOM text


#21

Yes @marcosc I thikn it is stalled :frowning: And I think it would be a useful spec, although it is not in the current WebPlat charter.

But for now it might be most sensible to move it to WICG, assuming the annotations WG agrees - it’s in their charter.

As well as handling endless scrolling search, it would probably be helpful of e.g. editing systems could generate an in-page search rather than reimplementing it, in the case where the text actually is all in the DOM but you want to find e.g. /\<h.\>/ as a way to search for the headings when you’re editing…


#22

I opened this issue: https://github.com/whatwg/html/issues/2858


#23

I’m not convinced this kind of hack-around band-aid is required at this stage. While developers have wrung enormous speed ups from virtualized-list components, I have not seen anyone trying other speed-up approaches, like using drastically reduced rendering formats for off-screen content and swapping into a fully-rendered view on demand.

If the web really needs a feature like this, so be it, but I’d much prefer not diving off the classical contract of a web page being a set of content declared via HTML if we don’t have to. The performance wins of virtualzied components need to be compared versus alternatives we haven’t dived into yet.


#24

That would be an interesting UI, where the browser’s find would scroll to some unstyled text, and then the page would render it while trying to keep the user’s search target on screen.


#25

Modern HTML5 text editors do this, and they have to implement their own search functionality for it.

Also, what about custom-rendering cases?


#26

In case you read email mostly, I mean to link to the following in my last comment:

Custom-rendering cases


#27

Hi there, we (@domenic and I) are working on possible Find-in-page APIs that might help with the concerns addressed here. We’ve put together an explainer here.

We are separating the explainer into two parts, with the main part focusing more on the simpler API that allows webpages to completely replace the UI with their own. The other explainer contains proposal for APIs like allowing the webpage to redo the browser’s find-in-page, make the browser wait for something before finding, etc. Please take a look at the explainer and share any thoughts you have on it! :slight_smile: