- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Wed, 23 Feb 2005 23:10:40 -0500
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.
Received on Wednesday, 23 February 2005 20:10:40 UTC