- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Wed, 23 Feb 2005 17:18:11 -0500
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