W3C home > Mailing lists > Public > www-dom@w3.org > April to June 1999

Comments on Range spec

From: Terry Crowley <tcrowley@microsoft.com>
Date: Tue, 1 Jun 1999 15:43:14 -0700
Message-ID: <7CD674FF54FBD21181D800805F57CD546BA5E7@RED-MSG-44>
To: www-dom@w3.org

Had some comments on the DOM Range spec.  Most of this input is based on
experience with writing the FrontPage editor internals that deals with
similar issues.

1. Overall, it seems like the notion of an insertion point should be a core
object independent of the range.  A range then has a start and end insertion
point, as does a node.  This is so obvious that I assume there was lots of
discussion about it, but I think the wrong call was made here.  Although
this seems like a large change to the spec, it really doesn't change any of
the complex behaviors that have been described.  In general, I'm in complete
agreement with what is specified (they almost exactly match FP's current
internal behavior, with one exception noted below).

2. FrontPage (as well as emacs, other editors I've built, IE, etc) has found
it extremely valuable to have two different kinds of insertion point with
respect to what happens to the IP when insertions occur at the IP (whether
the IP ends up before or after the content).  The DOM should really make
this directly available (so you can explicitly specify it when creating an
IP object).  Additionally, the internal FP range object has the behavior
that the start IP has right-gravity and the end IP has left-gravity.  The
effect is that ranges tend to stay "tight", not including new content at
their edges (so you don't have the unintuitive behavior called out in the
second insertion example of the range spec).

3. I believe that the spec should clarify that although for exposition
purposes they have described the position of an IP in terms of a parent node
and an offset, this does not imply that this is the way it will be
implemented.  In fact, there is no guarantee that this will be a constant
time lookup in any implementation (so for example, some implementation might
trade off the cost of computing this information against the cost of keeping
it up to date and decide to compute it when requested on the fly (since none
of the actual operations that use the IP need this information directly).

4. The discussion of behavior under mutation does not include a discussion
of behavior after surroundContents is called.  This is important, since if
you actually implemented surroundContents using the primitive operations
that the spec says it corresponds to, all range objects pointing into the
surrounded contents would collapse.  This is not appropriate.  The spec
should specify that for purposes of behavior under mutation,
surroundContents corresponds to an insertion of the start tag at the start
IP and the insertion of the end tag at the end IP.

5. I believe the behavior described in example 3 for behavior under deletion
is wrong.  The <EM> start tag should still be in the range.  Since the range
previously included it and it wasn't removed by the deletion operation, it
makes semantic sense that it is still in the range.

Terry Crowley
Received on Tuesday, 1 June 1999 18:43:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:05 UTC