[css-highlight-api] Need to support a mechanism for creating ranges inside textarea and input elements

[sanketj]

Moving this issue over from: MicrosoftEdge/MSEdgeExplainers#78.

Textarea and input elements can't be highlighted with this proposal. We need a mechanism to express the position of a range inside these elements so that spellchecking/grammar extensions can add squiggles to these elements too.

[frivoal]

I suspect this might be best handled by an extension to range objects that can reach into these elements, and that this should be discussed over in https://github.com/whatwg/dom/issues

[sanketj]

Closing this issue out for now as it is not relevant for css-highlight-api-1. This will likely require a new proposal, and yes, it most likely live over in WHATWG DOM.

[frivoal]

I suspect we should check with the WHATWG / the TAG that they agree this is likely to be solved the way we think before closing, because if not, we've got some harder thinking to do.

[sanketj]

@frivoal I think this is beyond scope for css-highlight-api-1. This is also just a tracking issue for future work in WHATWG DOM. What's the best way to keep this issue around, but not let it block css-highlight-api-1?

cc: @dandclark

[frivoal]

I think we should either conclude that this is indeed going to be solved by some future addition and close this issue (most likely), or that the fact that we haven't solved this shows the whole approach is wrong and we need to start from scratch (I very sincerely hope not). @atanassov @LeaVerou @plinss can the TAG have a look at this issue?

[iNalgiev]

Any updates on this thread?
I noticed the same issue also applies to contenteditable elements. It does not seem to highlight the text inside these areas.

[schenney-chromium]

I just tested Chrome 121 and succeeded in setting highlights inside a contenteditable="true" div, and editing the content while maintaining the highlight.

Do you have an example of it not working?

Otherwise no update on the status of textarea.

[iNalgiev]

Here's an example with contenteditable="true" element.
This using the Ngx Tiptap editor example. The highlighting code should mark "Hello" but nothing is happening.
stackblitz demo

[schenney-chromium]

There's a lot going on in your example, but one thing I do notice is that DevTools says the CSS highlight is named 'search-result-highlight' but the js says HIGHLIGHT_NAME='match' If I edit the CSS to name the highlight 'match' I get a yellow "Hello".

[bramus]

+1 on adding support for custom highlights textarea/input. Got numerous requests from authors about this.

As for [contenteditable]: I could get it to work but it was a lot of jumping through hoops mainly because of [contenteditable] itself doing Weird Things™. Demo + Write-up: https://www.bram.us/2024/02/18/custom-highlight-api-for-syntax-highlighting/#highlighting-contenteditable