Block theme: Add drag handles to resize pattern preview

[ryelle]

See #642. This updates the wporg/pattern-view-control block to include drag handles for resizing the preview. Since the new version of the block uses the Interactivity API, not React components, we can't "just port over" the old functionality, and we can't use the gesture library. I've made it work fairly well with vanilla JS + interactivity directives, but it still seems janky to me.

• When the drag handle is clicked (mousedown), it triggers the "dragging" state, and tracks the current x-position & which handle was clicked
• On any mousemove, if we're in dragging state, check the difference in x-position to see which way we should resize and update the previewWidth accordingly
  • On large screens, the iframe width doesn't update correctly, so the preview is pushed to the side
  • There's a throttle timeout, but it's just 10ms — any higher and the resizing was jumpy
• On any mouseup, it resets the dragging state back to the initial values

For keyboard users, they can focus on the drag handles, and use the left/right arrow keys to change the preview width. This matches the current behavior.

I did not use the HTML draggable API because it created a ghost-button while dragging, and it seemed to not work on the button element.

In the design, the toggles are only 4px wide. When testing, I had a lot of trouble targeting that size, so I've changed them to 8px.

⚠️ Known issues, would appreciate opinions:

• I had to give the whole preview a fixed height, otherwise the middle-aligned drag buttons jump around, so now the patterns are cut off on the wide/medium sizes (or have extra whitespace, if the pattern is short).
• The mousemove event over iframe only works when pointer-events: none or there's an overlay, but then we can't scroll inside the window.
• The aforementioned width issue on large screens (shown in the video below)

Screenshots

On a large screen, resize up and then back down.

large-screen.mp4

On small screen, resize from the "mobile toggle" up to large screen, which scales down the preview (but not the frame height).

small-screen.mp4

How to test the changes in this Pull Request:

1. Check out the branch and built the project
2. View any pattern
3. You should see drag handles, and be able to drag them to change the preview size
4. Clicking the set buttons should still work
5. Try again with a pattern you own

[StevenDufresne]

I checked out this PR and it is working pretty well.

I had to give the whole preview a fixed height, otherwise the middle-aligned drag buttons jump around, so now the patterns are cut off on the wide/medium sizes (or have extra whitespace, if the pattern is short).

I like the fixed height and feel like this should probably be the default behavior.

The mousemove event over iframe only works when pointer-events: none or there's an overlay, but then we can't scroll inside the window.

I don't understand.

On large screens, the iframe width doesn't update correctly, so the preview is pushed to the side

Does this depend on how the pattern was made? Seems to be working for me.

On this front, I think we can have an outer bound for the width. I don't see a use case for extending the width indefinitely.

A couple of small points:

• The handle target area is pretty small
• An active and inactive state for the handle would improve UX.
  • We should update the cursor appropriately.
  • We could change the color and make the handle larger.

---

I appreciate the effort on this PR. 🙇

I do however question the value of this feature and wonder if provides enough extra context for users to find it valuable and use it. What if we shipped without it and added it if requested?

[jasmussen]

Nice work. Is there an easy way to test this? Visually this looks close. Charcoal 5, pill shaped, 4x52px:

I would keep that optical handle size, though naturally we want the hit area to be big enough to be comfortable. So if you can make it bigger in practice, that would be fine. E.g. something like:

That's 14x52 just as an example. Can be even bigger if you can find the space for it.

Here's how big the hit area is in the block editor, which is one of the patterns we're following for this:

[ryelle]

To @StevenDufresne's comment:

I like the fixed height and feel like this should probably be the default behavior.

Yeah, I think I'm outvoted 🤷🏻 I like being able to see the whole pattern at once.

The mousemove event over iframe only works when pointer-events: none or there's an overlay, but then we can't scroll inside the window.

I don't understand.

For example, this pattern is taller than 600px, so it's cut off. But I can't scroll, it only scrolls the full page. If I disable pointer-events: none, then I can scroll to see the full pattern. But now trying to scale the pattern, it stops when I'm over the pattern preview (in fact, I released the click while on the pattern, but that did not trigger the drag state to end).

pointerevents.mp4

However, this might just be a FF issue, since scrolling seems to work fine with pointer-events: none on Chrome.

Does this depend on how the pattern was made? Seems to be working for me.

Ah, I accidentally missed rebasing the PR on the layout updates. In your version the preview is constrained by the wideSize (1160), as you see by the container not actually expanding. If you try on the rebased PR (pushed now), you'll see it like the screen recording.

On this front, I think we can have an outer bound for the width. I don't see a use case for extending the width indefinitely.

We do, it's 2400px. Happy to change that though, I just went with an arbitrary large size. Anything over 1200 will cause the issue, though.

I do however question the value of this feature and wonder if provides enough extra context for users to find it valuable and use it. What if we shipped without it and added it if requested?

I agree that it's not very valuable, and I was trying to simplify the preview by leaving it out. IMO the 3 size toggles provide enough preview capability.

To @jasmussen's comment

Is there an easy way to test this?

You can use wp-env like all the other redesign repos, the instructions are in the project readme.

I would keep that optical handle size, though naturally we want the hit area to be big enough to be comfortable.

I can try this, but it's strange to me that the click target will be larger— it's still going to feel like you need to hit a tiny line.

[ryelle]

So I made a fuss on the call about how hard fixing this up would be, but I think coming back to this with fresh eyes and no pressure was the solution 😅

I spent some time noodling on it and I think I've fixed all the previous weird edge cases.

On desktop sizes, this works well — grabbing the drag handles can expand up to 1400, down to 320, and the switching between drag and toggles works.

drag-handles.mp4

Even with keyboard, the toggles work and left/right arrow keys when the handles are focused will resize the view (same as production).

drag-handle-keyboard.mp4

It does get awkward on small screens/mobile, since you can "drag" wider than the screen, and shrinking down from a big preview only changes the preview's scale. So the handle & cursor no longer match. The production site gets around this by not allowing a larger preview than the current screen size, but I think that's a silly restriction— a user on a phone should be able to preview desktop size. And with the toggles this works fine. Maybe we should hide the handles at some screen size?

Also, I haven't tested this with an actual phone or tablet, so I'm not totally sure how the touch interface will work (trying production on my phone though, it doesn't work well, another point to hiding it at small sizes).

drag-handles-small.mp4

So I'd actually be comfortable merging this before launch after all, provided it passes others' QA checks, and then thinking through the small screen behavior once it's on the preview site — should be enough time before the proposed launch next week.

[StevenDufresne]

Maybe we should hide the handles at some screen size?

I think this would be fine. We can cycle back if/when this feature is requested.

[jasmussen]

Nice work! I'd be happy to launch with this, and even hide those handles at small screen sizes.

[fcoveram]

It looks very nice ✨ And agree with Joen, we could hide the handlers.