Question if innerText causes style calc/reflow like Node.innerText does, if so maybe better served by an async method?

We have quesitons abou how innerText maps to the range when adjustments are made, e.g. if an end point is in a hidden node, and the enpoint is moved, does it move to the start/end of the hidden text + offset?

reviewing last comment

Lea: Reasonable question.. prior art..

Dan: lets punt to plenary but also maybe for B.

Sangwhan [via chat]: I don't understand OP's comment.

Lea: will ask Sangwhan to comment on the issue.

Peter: My biggest concern - on the innertext and hidden stuff it's just that it was under-specified... my biggest concern was that sync ... they're pushing back on that...

... they have an answer on the other issue.

... sync forces a style computation.

... several times we've raised this... the prior art is broken. Not much if any lot of prior art doing it the wrong way. we'd like to fix this...

Tess: did Range.innerText not exist before? I understand the temptation.. but why propogate a [antipattern]?

Rossen: are you proposing to keep this from progressing until they figure out async?

... pushing for something - from expected behaviour and pattern - makes sense - but doesn't exist anywhere... we don't have good guidance.. we reviewed the event loop at the f2f - my expectation from the TAG pov - solid guidance - this is what causes flushes, this is what causes batches... this doesn't exist. Brings us.. we can continue to ask and be ignored or ... no alternative.

Tess: I think the alternative ... TAG vigilence... not suggesging we do the rigorous def.

Peter: we could guuide people to look at a better alternative...

Rossen: I think we can engage in a more meaningful way.

Peter: they can make it async.. they can turn it into an observer... there are paths forward... there's the issue of "leave it better than you found it" - just because someone else made the mistake before ...

Rossen: we're not steering them on how to move from the sync API...

Lea: we don't have a design principle don't trigger synchronous layout?

we look back through the design principles

Dan: open a design principle issue and get some debate going in the design principle?

Peter: What should our feedback be?

Rossen: i will open the issue

Peter: I will take a stab at writing the feedback...

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

Peter: waiting for response - async vs sync

Lea: still pending external feedback since august? This is another review pushing for synchronous layout stuff.

Peter: pushing off into Houdini land.. what do we do to help get to the state of this becoming async?

Lea: [drafts comment asking for updates]

Peter: I'd like to see evidence that they're discussing making this async in the WG