In PR #19, we introduced a way to highlight Turbo Frames using additional elements in the DOM instead of manipulating the Turbo Frame itself.
This solves some of the problems mentioned in #18 but introduces others. It just isn't a good solution. It’s not precise, especially when the Frame loads asynchronously. It also adds quite a lot of extra DOM manipulation, which results in poor performance, for example, when visiting the Hey calendar with hundreds of Turbo Frames.
I suggest we keep the overlay functionality until we find a better solution but make the previous approach of manipulating the frame itself the default. Most pages seem to work well with this approach. Anyone who experiences layout shifts due to this naive approach can switch to the "overlay approach".
In PR #19, we introduced a way to highlight Turbo Frames using additional elements in the DOM instead of manipulating the Turbo Frame itself.
This solves some of the problems mentioned in #18 but introduces others. It just isn't a good solution. It’s not precise, especially when the Frame loads asynchronously. It also adds quite a lot of extra DOM manipulation, which results in poor performance, for example, when visiting the Hey calendar with hundreds of Turbo Frames.
I suggest we keep the overlay functionality until we find a better solution but make the previous approach of manipulating the frame itself the default. Most pages seem to work well with this approach. Anyone who experiences layout shifts due to this naive approach can switch to the "overlay approach".