Re: [Editing] [DOM] Adding static range API
On Sat, Jan 9, 2016 at 6:55 PM, Ryosuke Niwa wrote: > >> On Jan 9, 2016, at 6:25 PM, Olli Pettay wrote: >> >> Hard to judge this proposal before seeing an API using StaticRange objects. >> >> One thing though, if apps were to create an undo stack of their own, they >> could easily have their own Range-like API implemented in JS. So if that is >> the only use case, probably not worth to add anything to make the platform >> more complicated. Especially since StaticRange API might be good for some >> script library, but not for some other. > > The idea is to return this new StaticRange object in `InputEvent` interface's > `targetRanges` IDL attribute, and let Web apps hold onto them without > incurring the cost of constant updates. Could you simply return a dictionary with the parent nodes and parent indexes? / Jonas
Re: [Editing] [DOM] Adding static range API
> On Jan 9, 2016, at 6:25 PM, Olli Pettay wrote: > > Hard to judge this proposal before seeing an API using StaticRange objects. > > One thing though, if apps were to create an undo stack of their own, they > could easily have their own Range-like API implemented in JS. So if that is > the only use case, probably not worth to add anything to make the platform > more complicated. Especially since StaticRange API might be good for some > script library, but not for some other. The idea is to return this new StaticRange object in `InputEvent` interface's `targetRanges` IDL attribute, and let Web apps hold onto them without incurring the cost of constant updates. - R. Niwa
Re: [Editing] [DOM] Adding static range API
Hard to judge this proposal before seeing an API using StaticRange objects.
One thing though, if apps were to create an undo stack of their own, they could easily have their own Range-like API implemented in JS. So if that is
the only use case, probably not worth to add anything to make the platform more complicated. Especially since StaticRange API might be good for some
script library, but not for some other.
-Olli
On 01/10/2016 01:42 AM, Ryosuke Niwa wrote:
Hi,
This is yet another feedback from multiple browser vendors (Apple, Google,
Microsoft) that got together in Redmond last Thursday to discuss editing API
and related events.
For editing APIs, it's desirable to have a variant of Range that is immutable.
For example, if apps were to create an undo stack of its own, then storing the
selection state using Range would be problematic because those Ranges would get
updated whenever DOM is mutated. Furthermore, live ranges are expensive if
browsers had to keep updating them as DOM is mutated. This is analogous to how
we're moving away form LiveNodeList/HTMLCollection to use StaticNodeList in
various new DOM APIs.
So we came up with a proposal to add StaticRange: a static, immutable variant
of Range defined as follows:
[Constructor,
Exposed=Window]
interface StaticRange {
readonly attribute Node startContainer;
readonly attribute unsigned long startOffset;
readonly attribute Node endContainer;
readonly attribute unsigned long endOffset;
readonly attribute boolean collapsed;
readonly attribute Node commonAncestorContainer;
const unsigned short START_TO_START = 0;
const unsigned short START_TO_END = 1;
const unsigned short END_TO_END = 2;
const unsigned short END_TO_START = 3;
short compareBoundaryPoints(unsigned short how, Range sourceRange);
[NewObject]
Range cloneRange();
boolean isPointInRange(Node node, unsigned long offset);
short comparePoint(Node node, unsigned long offset);
boolean intersectsNode(Node node);
};
Along with range extensions from CSS OM view also added as follows:
https://drafts.csswg.org/cssom-view/#extensions-to-the-range-interface
partial interface StaticRange
{
[NewObject] sequence getClientRects();
[NewObject] DOMRect getBoundingClientRect();
};
with one difference, which is to throw an exception (perhaps
InvalidStateError?) when StaticRange's boundary points don't share a common
ancestor, not in a document, or offsets are out of bounds.
- R. Niwa
[Editing] [DOM] Adding static range API
Hi,
This is yet another feedback from multiple browser vendors (Apple, Google,
Microsoft) that got together in Redmond last Thursday to discuss editing API
and related events.
For editing APIs, it's desirable to have a variant of Range that is immutable.
For example, if apps were to create an undo stack of its own, then storing the
selection state using Range would be problematic because those Ranges would get
updated whenever DOM is mutated. Furthermore, live ranges are expensive if
browsers had to keep updating them as DOM is mutated. This is analogous to how
we're moving away form LiveNodeList/HTMLCollection to use StaticNodeList in
various new DOM APIs.
So we came up with a proposal to add StaticRange: a static, immutable variant
of Range defined as follows:
[Constructor,
Exposed=Window]
interface StaticRange {
readonly attribute Node startContainer;
readonly attribute unsigned long startOffset;
readonly attribute Node endContainer;
readonly attribute unsigned long endOffset;
readonly attribute boolean collapsed;
readonly attribute Node commonAncestorContainer;
const unsigned short START_TO_START = 0;
const unsigned short START_TO_END = 1;
const unsigned short END_TO_END = 2;
const unsigned short END_TO_START = 3;
short compareBoundaryPoints(unsigned short how, Range sourceRange);
[NewObject]
Range cloneRange();
boolean isPointInRange(Node node, unsigned long offset);
short comparePoint(Node node, unsigned long offset);
boolean intersectsNode(Node node);
};
Along with range extensions from CSS OM view also added as follows:
https://drafts.csswg.org/cssom-view/#extensions-to-the-range-interface
partial interface StaticRange
{
[NewObject] sequence getClientRects();
[NewObject] DOMRect getBoundingClientRect();
};
with one difference, which is to throw an exception (perhaps
InvalidStateError?) when StaticRange's boundary points don't share a common
ancestor, not in a document, or offsets are out of bounds.
- R. Niwa
