FormControlRange Interface

[t-andresre]

What problem are you trying to solve?

The current Range interface methods do not support retrieving or creating Range objects that represent the value (rather than the element itself) of <textarea> and <input> elements.

What solutions exist today?

Currently, if web authors wish to use range-based operations with <textarea> or <input> elements, they must find workarounds, which often involve cloning these elements and their styles into <div>s, which is both difficult to maintain and may impact the web application's performance.

How would you solve it?

The proposed interface provides a way of creating a FormControlRange—a specialized type of Range object—that represents part or all of the value of <textarea> and <input> elements, enabling range-based operations such as getting bounding rects and setting custom highlights, while limiting access to the standard Range API to enforce encapsulation.

Anything else?

This proposal is only scoped to textarea/input element. For other elements, the regular Range interface can already be used for range-based operations.

Link to the explainer for this proposal: FormControlRange

[keithamus]

You may want to take a look at https://open-ui.org/components/richer-text-fields.explainer/ which overlaps a lot with this. It might be worth combining the proposals in some capacity or at least making sure nothing is missed from the relevant sections of the open ui proposal.

[annevk]

It seems a bit weird to me to support these instance methods on non-live ranges. Because this API makes it seem like you can treat these ranges the same as live ranges, but you really can't.

[leotlee]

You may want to take a look at https://open-ui.org/components/richer-text-fields.explainer/ which overlaps a lot with this. It might be worth combining the proposals in some capacity or at least making sure nothing is missed from the relevant sections of the open ui proposal.

Thanks @keithamus for pointing us to the Open-UI explainer. I agree that both explainers are aligned in direction, and we’ll make sure the relevant sections from each are appropriately covered. We're open to combining the proposals.

Our next step is to do some exploratory prototyping and circle back with you. We’ll then bring it to WHATWG and Open-UI, and open it up for broader discussion and feedback.

[leotlee]

It seems a bit weird to me to support these instance methods on non-live ranges. Because this API makes it seem like you can treat these ranges the same as live ranges, but you really can't.

Thanks @annevk for your feedback. We’ll update the explainer to clarify that the new range type is intended to be live. We’ll also add examples to illustrate how it should behave when the underlying control values change.

Regarding your first comment—could you clarify which instance method you found odd?

[annevk]

Apologies, I didn't realize these are meant to be live.

A colleague brought up the idea that the name might be too limiting if in the future we want to use this class to allow custom elements to expose encapsulated ranges to the outside world as well. (That would require quite a bit more API surface of course at that point to be able to control the ranges.) Perhaps ElementRange could work?

And yeah, introducing LiveRange as abstract class might be worthwhile.

cc @smaug----

[stephanieyzhang]

Thanks @keithamus and @annevk for the thoughtful feedback.

Given the overlap with InputRange in the Richer Text Fields explainer, we suggest treating FormControlRange as a concrete proposal within that broader effort. We’ll update our explainer to clarify that the range type is live, add examples for value changes, and reference the Richer Text Fields explainer directly to avoid duplication.

We’re also considering a rename (e.g. ElementRange, as @annevk suggested) to better reflect extensibility and avoid confusion with InputRange (since the name may imply it only applies to <input> elements).

Please let us know if this direction sounds good to you, as we’d like to align before bringing this to wider review. Thanks!

[stephanieyzhang]

We synced with @keithamus offline, and he’s aligned with the current direction. We're proceeding with the name FormControlRange for now to match the work done so far (explainer and initial Chromium implementation), but if there are objections or a strong preference for a broader name (e.g., ElementRange), please let us know and we can update it. Thanks!