search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.42k stars 647 forks source link

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

Open sanketj opened 4 years ago

sanketj commented 4 years ago

Moving this issue over from: https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

+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