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

[Olav Junker Kjær]

Matthew Raymond wrote:
 > So you see, if we want to establish a GUI selection interface for
 > DOM/Javascript, we can use DOM Range as PART of the interface, but we
 > 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:
http://www.mozilla.org/docs/dom/domref/dom_window_ref24.html#1000044
While I like your proposal, I think we should choose one of the 
currently implemented methods (IE's or Mozillas) unless they have 
serious shortcomings.

 > Yeah, but from the little bit I've read of the IE method, I hear it
 > sucks.

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 
content.

 > 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.

regards
Olav Junker Kjær