Re: [w3ctag/design-reviews] Early design review for Range API improvements (Issue #725)

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).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/725#issuecomment-1138032023
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/725/1138032023@github.com>