[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