You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: FormControlRange/explainer.md
+27Lines changed: 27 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -580,6 +580,33 @@ The resulting `AbstractRange` inheritance structure would look like this:
580
580
It has been [discussed](https://github.com/whatwg/html/issues/11478#issuecomment-3113360213) that custom elements could also use this API to expose encapsulated ranges, enabling richer editing or selection behaviors while maintaining internal structure.
581
581
Such use cases might also prompt revisiting the current `FormControlRange` name in favor of something broader, such as `ElementRange`, to better reflect its applicability beyond form controls.
582
582
583
+
## Open Questions
584
+
How should `FormControlRange` behave when callers provide reversed offsets (i.e. `startOffset > endOffset`)?
585
+
586
+
Consider the following ideas:
587
+
- Throw `IndexSizeError`.
588
+
- Convert to a collapsed range (by clipping or reordering endpoints).
589
+
- Which direction should the collapse target?
590
+
- Collapse to `max(startOffset, endOffset)` (matches DOM `Range`).
591
+
- Collapse to `min(startOffset, endOffset)`.
592
+
- Preserve a backwards range (allow `startOffset > endOffset` and define direction-aware behavior for text, `toString()`, and layout methods).
Note: With reversed endpoints, DOM `Range` setters collapse them to a single point, whereas `Selection` preserves directionality (anchor/focus). Collapsing is the current interoperable behavior, but alternatives remain open for discussion.
609
+
583
610
## References & acknowledgements
584
611
585
612
Many thanks for valuable feedback and advice from:
0 commit comments