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

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

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Wed, 23 Feb 2005 17:18:11 -0500
Message-ID: <421D0123.8050202@earthlink.net>
Olav Junker Kj?r wrote:
> Matthew Raymond wrote:
> 
>>   Another problem, though, is the fact that user agents would have to 
>>support Document Object Model Range. That may be assumed as a result of 
>>the DOM2 requirement for WF2, but I'm not aware of anything else in WF2 
>>that requires DOM Range.
> 
> I thought that selectionStart, selectionEnd and setSelectionRange() were 
> part of the DOM Range, but they seem to be Mozilla-specific?

     Looks like it. I'd prefer the Mozilla method for form controls, though.

> That means we have three different models for working with selections in 
> input fields: the IE way, the Mozilla way, and DOM Range.

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

> Since DOM Range is already a standard there seems to be no point in 
> defining yet another standard in WHAT (except perhaps if the point was 
> to standardize on the IE way for backwards compatibility?)

    DOM Range doesn't appear to have anything to do with actual GUI 
selection. It merely states that you can use a Range DOM object to 
represent the selection. From 
http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ranges.html:

    "The term 'selecting' does not mean that every Range corresponds to 
a selection made by a GUI user; however, such a selection can be 
returned to a DOM user as a Range."

    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. I'm thinking something like this:

| var myRange = document.getSelection();

    The above gets the current selection within the document. If the 
document doesn't have a selection, it returns document.createRange(). 
Similarly, there will be a setSelection method:

| document.setSelection(myRange);

    If you wish to deselect everything in the document, you could do the 
following:

| document.removeSelection();

    If you want to select a specific element, you'd do something like this:

| var myRange = document.createRange();
| var myElement = document.getElementById('myID');
|
| myRange.selectNode(myElement);
| document.setSelection(myRange);

    Do we need a way of maintaining multiple user selections? I don't 
think IE supports this. Also, do we need execCommand if we're using DOM 
Range? It would seem to me that you could just use surroundContents, 
etc. for something for some of this stuff, but that might get 
complicated. If anyone wants to chime in on these issues, feel free.

     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. It doesn't really 
matter, though. With the Mozilla method, you need only find the <input> 
node and set two values to set the selection. In DOM Range, you have to 
create a Range object, feed the element node to .selectNodeContents, 
then change the start and end offsets, so you have two extra steps. 
Therefore, the Mozilla method would win even if the text was in the DOM.

> Anyway, I dont think selections should be part of WF2, but rather WA1 
> where editing is defined,

     Agreed.

 > and I certainly think that the same interface
> should be used for handling editing in form controls and in elements 
> with contentEditable.

    No. The whole idea behind |contentEditable| is that you're changing 
the DOM. The values of <input> and <textarea> may be copies of values 
set in markup, but the actual value in a control is never truly in the 
DOM. For controls like <input> and <textarea>, 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.

    Question: Should any element with |contentEditable| be submitted if 
it's within a <form> and has a |name| attribute?
Received on Wednesday, 23 February 2005 14:18:11 UTC

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