| 14:42 | <keithamus> | Sorry I missed this before. Do you have a reproduction of a perf issue for this? Is the concern around style invalidation? |
| 14:46 | <annevk> | keithamus: yeah it's about invalidation |
| 14:48 | <annevk> | (You also have to ensure :heading is as optimized as a type selector is.) |
| 14:50 | <keithamus> | So a headingoffset changes and you walk the tree and invalidate prior offsets? Why do you need to walk up and down? |
| 14:58 | <annevk> | keithamus: if an element gets replotted, that might impact an arbitrary descendant heading element, but in order to compute the offset for that heading element you have to go up |
| 15:00 | <keithamus> | oh yeah. To the first headingreset or root, I guess. Does this actually cause perf issues though? |
| 15:00 | <annevk> | keithamus: I suspect it will cause issues on websites as large as GitHub that are already prone to perf issues |
| 15:01 | <keithamus> | I suppose one could keep a flag on trees as to whether or not they have a reset, to avoid a walk for nothing |
| 15:02 | <annevk> | There's quite a few optimizations possible of course, but the question I'm having is whether this is too much complexity for the amount of benefit we're getting. |
| 15:05 | <annevk> | My implementation is close to done, but sunk cost fallacy and all that. |
| 16:31 | <smaug> | Luke Warlow: hmm, I guess we don't have good tests for Trusted Types + moveBefore |
| 16:33 | <Luke Warlow> | Luke Warlow: hmm, I guess we don't have good tests for Trusted Types + moveBefore |