W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2005

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

From: (unknown charset) Olav Junker Kjær <olav@olav.dk>
Date: Thu, 24 Feb 2005 12:47:01 +0100
Message-ID: <421DBEB5.7080800@olav.dk>
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 
complicated.

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.

regards
Olav Junker Kj?r
Received on Thursday, 24 February 2005 03:47:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:21 UTC