Contain scrolling inside the editor

[azaozz]

Improve the user experience when scrolling the Visual editor with mouse wheel or trackpad: don't scroll the main window when the end is reached.

[azaozz]

In 27095:

TinyMCE: don't scroll the main window when scrolling the editor content with a mouse wheel or trackpad and reaching the end. Fixes #27013.

[paulwilde]

I've tested this on the latest trunk and found a couple of regressions:

• With Safari 7.0.1 I'm unable to scroll the editor correctly. I can only scroll down (in the wrong direction, see next point) and not back up to the top.
• With Chrome 32, Firefox 26 and Opera 19 the scrolling is in the wrong direction and doesn't respect if the user has disabled the "natural" scroll direction in System Preferences. Changing the option seems to reverse the effect so the logic must be in reverse order.

This in on a Macbook Pro under 10.9.1.

[azaozz]

In 27110:

Fix scrolling inside the Visual editor on MacOS, add the same functionality to the Text editor, see #27013

[azaozz]

[27110] should fix the inconsistencies on MacOS. Tested in Safari 6 and 7, Firefox 26 and 27, IE 7-11 (IE11 Doc mode) and Chrome 32 on Mac and Windows.

This has the side effect of disabling scrolling on the main window when the editor doesn't have a scroll bar. What would be the better behavior: keep as-is or scroll the main window?

[nacin]

I've been playing with this for a few days and I think it's probably a bit too heavy-handed and could use some adjustments. I'm talking best-possible-UX here, not necessarily what is feasible.

• When scrolling down the page (when your mouse starts outside the visual editor), once it overlaps the editor you'll get "stuck". It should let a scroll continue if it started outside the editor.

• If you use a one-column view and a collapsed admin menu (like me, sometimes), it's basically impossible to find a place outside the editor to scroll down. Even when using two columns, it isn't as intuitive. Perhaps it would be better if we found a way to "throttle" this. If you're not at the bottom of the editor, then let them scroll to the bottom and "stop". But if you are already at the bottom of the editor, it should let you scroll down. Now, most scroll gestures stop-and-start as you take your fingers off the mouse or trackpad to continue scrolling some more. So perhaps it should debounce (not throttle) and only let you scroll outside the editor if you paused for more than X milliseconds.

• When scrolling to the top, it should let you scroll the window up just enough to place the toolbar entirely in view.

Just some initial thoughts. Any others?

[nacin]

Along the same lines as the last bullet point:

• If your editor is not fully within the viewport, it should scroll the window until it is. And then it should stop. And then probably throttle, per the second bullet point.

Really what I'd love is if the editor height "snaps" to the height of the page, automatically. There's no reason for the editor to ever be taller than your viewport. It should shrink in that case.

[helen]

Replying to nacin:

Just some initial thoughts. Any others?

I agree with all of the above, and also that I'd love a dynamically resizing editor that takes the viewport into account (the Quick Draft textarea does this to some effect).

This is, in short, making me a little crazy. It's very confusing to suddenly not be able to scroll just because my pointer isn't in the right place. I think it would go a long way to only restrict scrolling behavior when focus is actually inside the editor - that is, the cursor is in there, not just my pointer is hovering over it.

[azaozz]

In 27368:

Editor: throttle scrolling of the main window when the editor is active and is being scrolled with the mouse wheel or a trackpad, see #27013

[iseulde]

Could it be make so that this only works in the admin? Right now post.js becomes unusable on the front-end because themes usually have an element with an id content somewhere. It's probably more efficient to have a isAdmin global rather than checking the body class though.

[nacin]

avryl, I know you have a unique use case, but post.js isn't designed to be used on the frontend.

[27368] is a great improvement. I think I see a few more areas of improvement. *Potentially* —

• The editor's height should include #postdivrich (.edit-form-section), not just the iframe. As in, if the toolbars (top or bottom) are out of view, it should scroll to them. I can't imagine that's easy but I imagine an offset somewhere could do it?

• Can we prevent the bottom of the editor from ever being hidden? As in, can we dock the bottom of the editor to the bottom of the viewport, shrinking it up to say only 100px tall? If you have a stored preference of 1000 pixels, but only 200px to show the editor, that's all that should be shown, and it should grow automatically while you scroll down (fixed to the bottom) until you've crossed a height of 1000 pixels.

• Can we prevent the editor from ever being taller than the viewport? Similar to the last point, if the window is only 674px pixels tall (as mine often is on an 11" MacBook Air), then that's the very tallest that #postdivrich should become. Once you scroll down past that point, the editor shouldn't grow any more, that way the toolbar is visible on top.

I'm gonna ask MarkJaquith to weigh in as well, as this is a white whale we've been chasing for years.

[markjaquith]

• If the content fits entirely within the editor, it shouldn't be intercepting scrolling.

• The delay feels wrong to me. I can't figure it out. If I scroll, hit the "wall", stop my scroll, then start again, sometimes I'm still blocked. Why? I've clearly stated my intention. I think the wall should be based on acceleration. If I'm accelerating, I want to break through. If I'm decelerating, then maybe I just wanted to the bottom of the editor and over-scrolled or let inertial scrolling (mouse or trackpad) go until it hit the bottom.

• This might be crazy, and I'm not entirely convinced myself, but what if the editor always autofit the content and never had any internal scroll? Scroll within scroll is super confusing, and we're to find some sort of nuanced clever behavior to disguise that central fact. Long posts would be long, but we could offer a "jump" to bottom button. We could pin the bottom bar to the bottom of the screen in a semi-transparent fashion, so you could still see your word, focused element, word count. We could do the same with the top formatting bar (never let it go above the top). I can try to sketch out what I mean tomorrow.

[markjaquith]

I chatted more with Nacin last night about my last bullet point. Here's the idea, in more detail:

1. Editor height auto-expands/contracts to fit content.
2. Editor toolbar stops moving up when it hits the admin toolbar (pins to top, content scrolls under it). You always have access to the editor toolbar.
3. Editor footer is pinned at the bottom of the screen if there is more content below. So you always have access to the editor footer.
4. If you reach the bottom and keep scrolling and the footer is in danger of touching the header, the header should unpin and scroll off the screen (for the case where you're scrolling past content to get to meta boxes below it).
5. For long posts, there are contextual "jump to top" and "jump to bottom" buttons (maybe they just show if you are scrolling in that direction, and there are more than 800 pixels to go in that direction).
6. The publish box (when in the sidebar) pins to the top as it is about to scroll off the page, and then accordions to just display the top and bottom of it (the main action items) as the page scrolls further.
7. Bonus idea: If all of your sidebar meta boxes fit in the browser height, they should be pinned.

WHY:

1. Nested scroll areas are a terrible interaction paradigm.
2. Anything we do to fix that isn't going to quite feel right (a pause or a stickiness makes it seem like something is broken or CPU-constrained somehow).
3. Content is king. That we hide your content so we can display a "Custom Fields" metabox is, frankly, embarrassing.

[MattyRob]

Test 3.9-alpha-27368-src on OSX with FF 27.0.1 and Safari 7.0.2. My feedback is:

FF it feels reasonably intuitive that the editing are scroll when that's active and the entire window scrolls when outside of that area.

In Safari, it feels more forced and clunky. It gives the impression more the the page is hanging or javascript is looping making the page unresponsive.

[markjaquith]

Here's a mockup of the editor portion of my idea:

​http://codepen.io/markjaquith/full/uCtGJ

[iseulde]

+1 for that.

[azaozz]

To summarize:

The editor's height should include #postdivrich (.edit-form-section), not just the iframe.

Agreed, it would be better to save the total height including toolbar(s) and footer. But the elements that "control" the height are the textarea and iframe. There were some problems with using the total height when we first attempted it (remember the 56,000px heights?) because of trying to get height of elements that were being resized at that moment. Can look at this again.

...I think the wall should be based on acceleration.

Looked at that but seems very hard or even impossible to have a common threshold. Acceleration happens on Macs (more on laptops/touchpad, less on desktops/mouse) and to lesser extend in IE when "smooth scrolling" is enabled. It is very much browser and device specific, and the speed of firing the JS events can vary a lot.

If the content fits entirely within the editor, it shouldn't be intercepting scrolling.

Sure, can add that if we keep the current behavior.

Can we prevent the bottom of the editor from ever being hidden?
Can we prevent the editor from ever being taller than the viewport?

1. Editor height auto-expands/contracts to fit content.
2. Editor toolbar stops moving up when it hits the admin toolbar (pins to top, content scrolls under it). You always have access to the editor toolbar.
3. Editor footer is pinned at the bottom of the screen if there is more content below. So you always have access to the editor footer.

To implement this:

• The editor height should be equal to the content height but not less than viewport height. To do that we need to remove the editor resizing (cannot be used).
• If the editor height is larger than viewport height, the toolbars and footer are pinned to top and bottom. There is no scrolling inside the editor, scrolling the main window scrolls the editor under the pinned toolbars and footer.
• If the Publish postbox is on the side and all side postboxes fit in the viewport, they are pinned to the top, same behavior as editor toolbars. Have to experiment with this a bit. Could keep the Publish postbox pinned and close the rest of the side postboxes.
• The toolbars and footer get "unpinned" when the top or bottom of the editor reaches about half-way through the viewport while scrolling the main window.
• There is some "stickiness" when the editor toolbar gets near the top of the viewport: if it is whitin 100-200px, we auto-scroll the main window until the editor toolbar is pinned at the top. Then we can cancel further mousewheel/trackpad scrolling for 500-600px to keep the top of the content visible. That will work well with "smooth scrolling" and acceleration, needs testing.

To consider:

• This would be non-intuitive for accessibility/screenreaders, would need a screen option to turn it off.
• Behavior on touch devices.

Can experiment with Jump to top/Jump to bottom buttons that appear on scrolling under the cursor. There is something similar that appears on middle-click on Windows, but it switches to scrolling by moving the mouse.

[gcorne]

I wonder if we should do something similar to what @markjaquith proposes at the very least for small screens where the post boxes always are stacked. As it is now, the user on a smart phone probably already is scrolling both the editor and the window to reach the publish box or any other the other metaboxes. In this case, it may also make sense to add a simplified publish box that just has the action buttons that sits above the editor and sticks like the other editor buttons.

[azaozz]

Been testing different things on and off for the last two weeks. Implementing all of the above points is a big UX/UI change at the most used screen in WordPress. Thinking best would be to move this to 4.0 when some UX testing can be done and functionality changed depending on the results.

For 3.9 perhaps we should significantly reduce the threshold for throttling of wheel/touchpad scrolling when the editor is focused. Or remove it completely.

[kovshenin]

I agree with Ozz, but if we're gonna keep this in 3.9, we should add a class to the TinyMCE wheel events like we do with .text-editor-scroll.

[azaozz]

In 27770:

Remove containment of scrolling inside the editor for now. See #27013

[azaozz]

Lets try making this awesome in 4.0.

[nacin]

In 27783:

Remove unused JS variables after [27770]. see #27013.

[iseulde]

Related: #28328.

[iseulde]

Follow-up ticket: #28328.