[ITS] Live preview context matching

[auniverseaway]

We take a, "crawl, walk run" approach in everything we do. We also constantly make choices around lesser of evils. When we built live preview in 2023, we had a couple basic goals:

1. Allow previewing at specific screen sizes.
2. Do not put / require scrollbars in the preview.
3. Don't build anything too complicated.

This was a great start, but there are currently two problems:

1. Mis-matched editing / preview context

One of my big annoyances with live preview is that it's constantly mismatched to the context of the content you're editing. It's a nice feature, and certainly helpful, but if you're doing a lot of authoring, it can be tedious to constantly scroll up and down because the doc is a different context than when the page is fully decorated.

2. Infinite viewport height

One common design pattern is to set a hero to have a height that matches the viewport using the vh CSS unit. When your page renders, DA's live preview will continually check for changes in height of your page and set the iframe height accordingly. This is to prevent iframe scrolling. These two decisions collide:

1. CSS sets the hero to 100VH.
2. We see it as a change in height.
3. CSS sets the hero to 100VH to match new height.
4. We see it as a change in height.
5. Repeat.

The solve (I think)

I think we have a path to solve the above to challenges, but it will come at the expense of having a scrollbar for live preview.

First, we are going to clamp the iframe down to common device sizes: 375x812 (iPhone X - yes, old), etc.

This will solve the ever changing viewport height issue. However, this alone would be problematic: when you make a change in your document, we re-render the entire page. This would mean that the page will constantly snap back to the top and you would be forced to constantly scroll down to the content you're trying to preview.

We also plan to push your caret position into the preview and this would mean your preview will always be exactly where your caret is. The preview will then auto-scroll to where your caret is. The hope is that you can still move up and down the preview and interact with elements, but if the page re-renders, it will snap back to match the context of the document.

We still have open questions: what if your caret is inside a hidden element (think a carousel slide) and we cannot get the coordinates? My hope is that we can fall back to the preview scroll position at the very least. We'll see...

Let me know your thoughts on this topic.