[WA1] GUI Selections (was Re: [whatwg] Web Forms 2.0)
Olav Junker Kjær
olav at olav.dk
Wed Feb 23 16:33:15 PST 2005
Matthew Raymond wrote:
> So you see, if we want to establish a GUI selection interface for
> still have to define some way of getting the current selection and
> setting the user selection.
Okay. I get it. Mozilla seem to support something similar (also
non-standard) to get from a selection to a DOM range:
While I like your proposal, I think we should choose one of the
currently implemented methods (IE's or Mozillas) unless they have
> Yeah, but from the little bit I've read of the IE method, I hear it
Well, it doesn't provide a way to get the start or end points of a
selection, which is what the original poster wanted.
It works like this: the document has a "selection" property which
represents the current selection. On the selection object you can call
createRange() to create a TextRange object which is more or less similar
to a DOM Range object (although more limited). Also, you can turn a
TextRange into the current selected by calling the select() method on it.
It works the same way for input values, textarea values, and ordinary
> Near as I can determine, though, DOM Range can't change attributes,
> so it would be useless for use with <input>, even if the |value|
> attribute was always equal to the .value property.
The DOM Range spec claims that it works on Attr-nodes also.
> Do we need a way of maintaining multiple user selections? I don't
> think IE supports this.
The API suggest that it does (there is a createRangeCollection()
method), but I'm not sure this actually works.
> Also, do we need execCommand if we're using DOM Range?
The important thing is to have contentEditable and an interface to
manipulate the current selection. Then execCommand can be built on top
of that in script. (The execCommand interface in IE is cool though,
because it supports undo. Except that the undo history is cleared when
any DOM manipulation is done using any other method than execCommand,
which limits its usefulness).
> I prefer the Mozilla
> method anyways. It's much simpler and people don't have to understand
> DOM Range to use it, which is good in situations like this since
> dealing with selections within controls is more common.
But one interface is simpler that two interfaces, and we need DOM Range
(or something similar) anyway to do rich editing, which is arguably just
as common an use case.
Olav Junker Kjær
More information about the whatwg