This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently there's exactly one Selection in existence per Document. It would be useful to allow authors to create additional selections that don't correspond to the user-visible one. They could then use methods like modify() on it, we could let them use execCommand() on it, etc. We could also let them save and restore the selection this way, together with all its associated info (at least direction). Specifically, we might want Selection.cloneSelection(), document.newSelection(), and document.replaceSelection() or something like that.
We need to decide whether cloned selection should be updated upon DOM mutations like the one attached to the document/window.
Per spec, a Selection is just a collection of Ranges, so the constituent Ranges will be updated and therefore the Selection will be too. WebKit doesn't behave this way, but I think this is just a WebKit bug and it needs to be fixed sooner or later. IE and Gecko treat Selections this way, and WebKit's behavior is far more complicated, so we want to stick to the IE/Gecko way. We discussed the possibility of wanting to save a Selection without the Ranges changing, though, for undo/redo. I think if you don't want the Ranges to change, you should just save the boundary points, you don't need an actual Selection object.
Maybe turn it into a constructor as we are doing elsewhere?
(In reply to comment #3) > Maybe turn it into a constructor as we are doing elsewhere? But a selection needs to be owned by some document though.
Each global object has an associated Document object so that should be easy enough to do. XMLHttpRequest has the same.
Moving Selection-related bugs to editing: see bug 14248, bug 14252.
Moving to Selection API component.