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

[Matthew Raymond]

Olav Junker Kjær wrote:
> 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.

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

    Then again, if you have a really good argument for it, I'm willing 
to  hear it.

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

    Matthew Thomas was worried that allowing webmasters to alter 
selections with setSelection or removeSelection would create situations 
where webmasters would intentionally prevent users from selecting stuff. 
As a result, I think he'd oppose a model that supports setting the 
selection outside a control, which makes the IE selection model not 
terribly useful.

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

    /me shrugs.

    Okay. I just skimmed the spec, so maybe it does. Doesn't really 
matter, though, because the .value property is still not the same as the 
|value| attribute or the contents of a <textarea> element, and changing 
that would break the specification of the reset button. (In theory, you 
may actually want to change the initial value of a control in the DOM so 
that when someone hits a reset button, the new initial value is put into 
the control instead of the old one, so saving the initial value outside 
the DOM may not be an option.)

    Then again, there's a .defaultValue property. Form reset could be 
defined in such a way as to use that property as the initial value 
instead of the contents of the DOM. However, the DOM content is defined 
as the initial value in the HTML 4.01 spec, so does changing the DOM in 
some browsers change the corresponding value of .defaultValue???

    What's certain is that linking the .value property with the markup 
for the initial value would directly contradict portions of the DOM2 spec.

 From http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-49531485:

    "Changing this attribute changes the contents of the form control, 
but does not change the value of the HTML value attribute of the element."

 From http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-70715579:

    "Changing this attribute changes the contents of the form control, 
but does not change the contents of the element."

    So would this be considered breaking backwards compatibility, since 
the opposite of the proposed behavior is defined in the spec?

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

    Perhaps we should change getSelection to getSelections and have it 
return a collection of ranges... Hmm...

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

    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.

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

    The real problem is that DOM Range is largely useless for selections 
that consist entirely of a string of text obtained through the .value 
property. All I need to know is the start and end points within the 
string and I can make any changes I want using simple string 
manipulation. So there's really never a situation where you NEED 
something as complicated as DOM Range for a simple text control. Never 
mind the fact that the value you're talking about doesn't exist in the 
DOM in the first place. There's also the problem of DOM Ranges requiring 
Nodes to define their start and end points. If .value isn't in the DOM, 
what would the parent node be?

    No, better to have two systems, since we're essentially dealing with 
two kinds of content. DOM Range is a lot harder to learn anyways, so 
after that the Mozilla method should be as easy as cake.