[WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)

Olav Junker Kjær olav at olav.dk
Thu Feb 24 03:47:01 PST 2005

Matthew Raymond wrote:
>    The Mozilla getSelection method doesn't actually return a DOM Range, 
> though, so I'm inclined to pass on it, even though we're introducing 
> window in WA1. It just strikes me as too complicated; it introduces a 
> completely new selection object, multiple ranges, et cetera...

This is like the IE model: a selection is is separate object, which may 
contain one ore more ranges. At least in IE this indirection is 
necessary since a the selection can be discontinuous e.g. several 
pictures different places in the same document (selected while holding 
the ctrl key down).

IE distinguishes between "text selection" and "control selection". 
Images, input controls, tables and absolutely positioned elements may be 
individually control-selected, which enables you to move end resize 
them. Continuous ranges of text (including objects) may be 
text-selected, but as far as I know, only one continuous text range can 
be selected at a time.
I don't know if Mozilla has a similar distinction?

Anyway, I agree this seem like overkill if you just want to manipulate 
the selection in a text-box. It might be useful to have some convenience 
methods to get the start and end points of a the current selection in a 
input field without having to walk through the selection and range objects.

>    Well, the question, though, is whether or not DOM Range provides 
> enough of an interface. In theory, you could do everything you need to, 
> but in reality the scripting could get so complex that you're rather 
> just use a built-in method like execCommand.

True. The execCommand encapsulates quite a bit of complexity. The 
problem with the IE version is that it is a black box. You cannot modify 
how a command works, you cannot create your own commands, and if you 
work outside of the box (and directly through the DOM), the undo history 
(which is the killer feature) is cleared. If WA1 should include 
execCommand, it should be a more general framework, which should allow 
you to create your own undoable commands. In the end this gets rather 

It does make sense though, to standardize the execCommand interface, 
since lots of CMS frontends rely on contentEditable+execCommand, and 
this is an area where IE have a stronghold, since its still the only 
browser (as far as I know) that support contentEditable.

Olav Junker Kjær

More information about the whatwg mailing list