Some of our recent UIEvent/beforeinput/editing discussions have revealed the need for an alternate to the Range object that is not as expensive for the user agent to maintain (i.e., one that doesn’t need to be updated when there are DOM mutations).
These discussions led to the proposal for a lightweight StaticRange that can be used instead of a Range when the complexity of a full Range is not necessary.
It is really important that this is being put into a spec ASAP, as these new types of ranges are essential for what we have been working on in the editing taskforce in terms of the Input events spec. We think our spec can solve many of the problems richtext editing on the web faces today, and both implementers and JavaScript editor developers are really excited, and these “static ranges” are the missing brick.
One comment though:
I can see that from the perspective of the browser, what you are describing is a “static” range, because you don’t need to use any extra computing power on updating the range information after it has been created.
From the perspective of a JavaScript developer, it may appear a bit strange though: The information given consists of two parts: A node and an offset. The offset is indeed static and doesn’t update. But the node is a live node, so it will change and possibly even be removed from the document. If I think of something “static”, I imagine something I can store away without it being affected of any further DOM changes, and with this I cannot really do that [1]. So for the benefit of JS developers, who may not always consider how these new types of ranges benefit browsers, I wonder if it would be possible to change the name? I don’t have much of a preference. I have seen the terms “shallow ranges” or “frozen ranges” mentioned, but I’m sure there are other alternatives as well.
[1] Although it must be noted that it is not that difficult to create an entirely “static” range description by exchanging the node with a static description of how to get to the node from a given ancestor node.
The name is certainly up for discussion, but I was unable to come up with a better name that captured the essence of what this class does.
If we could start over, I’d call this Range and use something like DynamicRange for the one that updates when the DOM is mutated. However, that’s not an option.
Some possible name options:
NonDynamicRange, PassiveRange, WeakRange, TorpidRange
Actually, I think the name is the smallest issue here. If StaticRange is what you guys thought made sense, let’s stick with that. I have now linked to this on http://w3c.github.io/editing/input-events.html which is what we need it for.
The Range object which can be serialized across Document boundaries;
The internal Range object which is bound to browser kernel’s Document live state
To let it be clear: theoretically, a Range object can be live if we only insert/remove/modify contents ‘’‘inside’’’ the range, not the 2 start/end boundary position points.
W3C’s Range may be not so expensive to maintain, if it is only created by User’s Drag-and-Select UI behavior, but if it is created by JS code programmatically, then it may be really expensive due to Range objects’ num increase…