- From: Terry Crowley <tcrowley@microsoft.com>
- Date: Tue, 1 Jun 1999 15:43:14 -0700
- To: www-dom@w3.org
Folks, 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