#1142: Incubation: FormControlRange - Live ranges for <input> and <textarea>

Visit on Github.

Opened Aug 22, 2025

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/FormControlRange/explainer.md

The explainer

Where and by whom is the work is being done?

  • GitHub repo:

  • Primary contacts:

    • Stephanie Zhang (@stephanieyzhang), Microsoft
    • Ana Sollano Kim (@anaskim), Microsoft
    • Dan Clark (@dandclark), Microsoft, tech lead
    • Leo Lee (@leolee), Microsoft, team lead
    • Taylore Givens (@tayloregivens, Microsoft, PM

  • Organization/project driving the design: Microsoft Edge

  • This work is being funded by: Microsoft

  • Incubation and standards groups that have discussed the design:

  • Standards group(s) that you expect to discuss and/or adopt this work when it's ready: WHATWG HTML

Feedback so far

You should also know that...

Currently, web developers can’t perform range-based operations (e.g., getting bounding rects, setting custom highlights) inside native text controls (<input>, <textarea>). As a result, they often resort to workarounds such as replicating the control and its styles in a contenteditable container and reimplementing input behavior -- an approach that’s tedious and error-prone to keep in sync with native behavior.

FormControlRange is a specialized, live AbstractRange subclass scoped to input/textarea value space. It enables those operations directly in native controls while restricting standard Range mutations to preserve encapsulation. It integrates cleanly with existing selection/editing behavior and closes a long-standing gap for form controls.

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1142

Discussions

Log in to see TAG-private discussions.

Discussed Sep 1, 2025 (See Github)

Aside: I updated the title of the issue above because Cryptpad's markdown parser messed up the rendering of the remaining text - Sarven

Sarven: Review https://github.com/w3ctag/design-reviews-private-brainstorming/issues/197#issuecomment-3248284375 ... I'm satisfied with this. The important parts, that they should cover, are OK. They are shuffling how things work, adding an abstraction in order to add the new stuff. All fine. They cover what will be unavailable or do not apply to form control range. You might get the sense of the length of a password field. <input type=text|password|url|tel> won't be covered. Understand the password thing, but the text didn't make sense to me. The idea is that the value space should be able to find the location of terms and whatnot. Good that passwords are not included; I don't understand "text" being excluded that way. Seems like a mistake. Solves a real need. Improves on workarounds that people use.

Lola: Comments reads.

Matthew: Like Sarven's comment. I noticed the image in the explainer is broken. Maybe there is a mockup, because it's not there. Couple of things: assistive tech potential benefits. They don't mention a11y in the explainer. Because this is so tied to user input, they should be encouraged to put that in the explainer even if there are no impacts (or only positive ones). They should make it clearer. If there are no privacy concerns, is there some fingerprinting surface here? Not sure. It would be nice if it would be more explicit about why those concerns aren't there. One thing that we've been encouraged to ask for. Maybe we can also ask them how their API might be abused. (Two images are broken in fact, not just one.)

Lola: Maybe ask them to fix the images and address abuse cases.

Matthew: and a11y use cases. Are we okay saying there are no privacy concerns. The live one makes me think it needs more thought.

Sarven: I think there are concerns, but it looks like their design is trying to work around them by disallowing methods or disabling for passwords, that was my impression. ... A function like getBoundingClientRectangle is available, but the context is about the value space, which is disabled for passwords. If that is the case (and I understood correctly), I can't see how this would be abused. It won't be available.

Matthew: The privacy concerns sections says "nope". Maybe they can reassure people there.

Sarven: They should acknowledge these concerns and point to the mitigations. ... Another example was including the textarea could include script strings. If that is somehow exposed to the API, that could be an issue. Whether the form is working in a way that filters all that, how the script might be exposed, but that is another example that could be mentioned.

Matthew: We've designed the platform to make it hard to detect assistive technologies. But it is still detectable through patterns of mouse movement, key press timing, and things like that. This might open up something. Could you infer typing speed, determine what is pasted.

Martin: Sorry to say, we already lost the ability to hide that stuff.