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.
I’ve written up an explainer for this proposal: https://github.com/garykac/staticrange/blob/master/staticrange.md
Note: It is intended that all current uses of
Range would remain unchanged, but new APIs or objects would make use of
Previous discussions that touched on this topic:
@garykac: This looks great!!!
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.
 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:
Note, there is an IDL discussion related to this proposal going on in one the github issues: https://github.com/garykac/staticrange/issues/2
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.
I think there are 2
- 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…