[whatwg/dom] Make it possible to wrap [parts of] the contents of a <textarea> or <input> in a Range (Issue #1375)

DavidJCobb created an issue (whatwg/dom#1375)

### What problem are you trying to solve?

It's currently impossible to apply the CSS Custom Highlight API to a `<textarea>` or text-based `<input>` element. The API is designed around `Range` objects, which define start and end points within the contents of text nodes. However, the current values of textareas and inputs are represented via the `value` property, not as text nodes. You cannot meaningfully apply a `Range` to the internal content of these elements.

### What solutions exist today?

The workaround I currently use in my personal projects is to overlay a second HTML element on top of the textarea, with its text color set to `transparent`, and with JavaScript used to copy computed styles from the textarea to the overlay and ensure that text in both will line up perfectly. (You would of course disable pointer events, text selection, and so on for the overlay.) JavaScript events can be used to watch for changes to the textarea, duplicating its value into the overlay element's `textContent`. Custom highlights can then be set on the overlay, changing the text `color` and painting overtop the textarea's content.

This has a few flaws:

* You have to set `scrollbar-gutter: stable` on the textarea and overlay, set the overlay to `overflow: hidden`, and use JavaScript to forward changes in the textarea's scroll position to the overlay.

* If you apply a `background-color` to a custom highlight range, it may cover the text input cursor within the textarea, since you're applying it to an element on top of the textarea rather than to the textarea itself. This depends on how the browser decides to position the cursor, which in Chromium can vary depending on what column of the textarea the cursor is placed at.

* Similarly, the native text selection highlight no longer overrides custom highlights, since the two exist within different elements. To ensure that you don't interfere with the native text selection colors (background and text), you have to manually detect changes to the user's selection, update additional custom highlights that exactly mimic the user's text selection bounds, and then have styles which clear text colors, etc., off of the "mimic" highlight.

* Even if you exactly mirror the sizing, positioning, and font from the textarea to the overlay, the overlay may not perfectly cover the textarea's content. Text may appear to anti-alias oddly because it's being painted twice in one spot, not simply recolored.

### How would you solve it?

I'm not strongly committed to any option. You could extend the Range API to be able to deal with textareas and text-based input elements, or extend the Custom Highlight API to offer special-cases that make it possible to deal with those elements. The CSSWG seems to prefer the former (see next section).

### Anything else?

The CSS Custom Highlight API is built around `Range` objects, which define start and end points within the `textContent` of one or more DOM nodes. However, the text currently entered into an HTMLInputElement or HTMLTextareaElement isn't represented as a text node, but rather via the `value` property. This means that there's no node that you can wrap in a `Range`, making it impossible to apply the Custom Highlight API directly to a textarea or other native text-editing element.

The CSS WG apparently decided [about five years ago](https://github.com/w3c/csswg-drafts/issues/4603) that this use case would be best handled by extending the DOM to allow `Range` (or some comparable object) to wrap [parts of] the contents of textareas and inputs, and they stated that the WHATWG issue tracker would be the best place to request that. However, no one ever actually opened an issue here.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1375
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1375@github.com>