Return Text Fragments for linking to highlights? about highlight-words

[tricinel]

Probably not at this time. What would be the use case? Could you give me an example?

[karlhorky]

It would be a UX feature of search:

• Backend searches through content of multiple pages using highlight-words
• The highlighted text of each SearchResult is shown to a user, wrapped in a link
• The link has a hash including the textFragment from the SearchResult - clicking on the link scrolls to the unique location of the highlight in one of those pages

[tricinel]

So on the back end, you're searching some content and getting back a list of matches/non-matches, wrapped in a link with the hash and the text fragment.

So why can't you use it as is now? You're already getting back a list of matches/non-matches. So you could forEach match and wrap it however you want. What am I missing?

[karlhorky]

getting back a list of matches/non-matches, wrapped in a link with the hash and the text fragment

Yes, to be clear, it's not the list itself that is wrapped in the link, it's each item in the list.

What am I missing?

Not entirely sure where the gaps are but I'll try to re-explain in more detail.

The Text Fragment (the thing after the #:~:text=, as mentioned in the issue description above) is not yet generated - it needs to be generated somewhere. Generating a Text Fragment which is unique across the whole document can be done with code like this, but this code deals with selections on the page, which are not relevant in the backend.

Given that highlight-words has the whole document already in memory and is already splitting it into chunks, it is potentially in a good position to create a unique Text Fragment so that a link can be created to this specific highlight.

As of now, the highlight-words data passed back in the chunks offers a rudimentary way of creating a link (${previousChunk}-,${currentChunk},-${nextChunk}), but this naive approach is not robust - one first case where they fail is when a phrase is repeated in the document.

[tricinel]

Understood. I don't think personally this helps others in many ways to be honest. The argument could be made, if you already have the document, why not return some JSX, or a vue component, or a lit element. But that's not the purpose of this. We just split the content into chunks that are either a match or not a match. And the consumer can manipulate it afterwards as they please.

In my own use cases, I either count the matches (so I don't need extra work happening inside of the matcher for some transformation I won't use) or I apply some CSS on chunks conditionally (again, that work should not happen in the matcher).

I understand your use case. The uniqueness of the fragment will be problematic either in the library or outside of it, so I don't think that's an argument either - if the phrase is repeated in the document, it will be the same problem in the matching function as it will in your app.

Bottom line, I don't see a point for this right now. We can revisit later if need be.