Early design review for Range API improvements

[dlibby-]

Braw mornin' TAG!

I'm requesting a TAG review of Range API improvements for rendered text content.

Ranges are somewhat limited in capabilities for advanced editing scenarios. While Ranges expose information about the rendering of the contained text via client rect(s), they only expose the text content (not the visible text — see differences) of the Range to script via toString(). Without this information, web developers resort to heuristics in JavaScript to map offsets of the visible text back to Node offsets in the DOM, which can be computationally expensive and error prone. This proposal aims to expose a flat text representation of the rendered text of a Range objects and allow developers to move a Range's endpoints over that representation, while keeping the Range rooted in DOM positions.

• Explainer¹ (minimally containing user needs and example code): https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/RangeInnerText/explainer.md
• User research: N/A
• Security and Privacy self-review²: [RangeInnerText] Security/Privacy questionnaire/self-review MicrosoftEdge/MSEdgeExplainers#566
• GitHub repo (if you prefer feedback filed there): N/A
• Primary contacts (and their relationship to the specification):
  • Daniel Libby (@dlibby-), Microsoft
• Organization/project driving the design: Microsoft
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5153662547525632

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): WHATWG HTML
• Existing major pieces of multi-stakeholder review or discussion of this design: N/A
• Major unresolved issues with or opposition to this design: N/A
• This work is being funded by: Microsoft

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify [dlibby-]

[cynthia]

We looked at this during a breakout today - here are some questions.

• innerText will trigger synchronous layout. This is not something we advocate new APIs doing; this should be made into an async API. (Probably not named innerText, since one being a property and this specific case being a method would be incredibly confusing.)
• Range.innerText and DOM do not directly map well; how would the mappings work when a hidden (e.g. via-CSS) node is involved?

[dlibby-]

Thanks for your response. I'm curious around prior art on APIs not triggering synchronous layout? In general, I think primitives such as ResizeObserver and IntersectionObserver make sense to have a specific observable spot during the 'update the rendering' steps to trigger observations - these are intrinsically tied to the state of the page that will (soon) be visible to the user.

For something like the innerText of a Range, it's unclear to me when authors could expect the callback to be invoked (i.e. what happens if there are subsequent DOM mutations, etc.). So I don't think this API is the best place to try to define those semantics, unless perhaps you're arguing something like a RangeObserver would be a better pattern? I could also see that being a bit confusing to authors (updates to the Range itself are synchronous) and add non-trivial overhead.

Also, I'd note that the adjust() method would be ergonomically difficult for authors to use if it also is async (it will rely on up-to-date layout data structures). One of the use cases, is to move ranges in conjunction with, e.g. Intl's word breaker, splitting multiple moves even across microtasks when other mutations may be interleaved seems like it would be difficult to reason about and achieve consistent results.

Please let me know if you had anything more specific in mind in terms of not having synchronous layout.

Range.innerText for hidden nodes would work the same as Element.innerText. Namely we'd run the steps from https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute but instead of an element and subtree, it would just span the range instead. So if the Range started in a part of the tree that was visibility:hidden, that text wouldn't be output (until walking through the range encountered an element that was visible).

[plinss]

@dlibby unfortunately there's not a lot of prior art of code not triggering synchronous layout and style computation. But this is something we're trying to fix. Existing cases tend to be bad for user experience and overall performance. We do have a general principle about not using the existence of less than ideal designs as license to repeat the mistake.

We understand that making the proposed adjust() method async raises further complications, but we would like to invite your group to discuss our concern and offer possible alternatives.

We've also opened a new issue about the general problem of synchronous layout and style and welcome your group's input there.

[LeaVerou]

Hi @dlibby-, we are considering closing this, should we leave it open? Are there any updates for us?

[plinss]

Since we haven't gotten any response in a while we're going to close this issue for now. We're also waiting for other work on the sync vs async style/layout flushing issue. Feel free to ping us to reopen this if there's any updates on your end.