[wp-trac] [WordPress Trac] #27013: Contain scrolling inside the editor

WordPress Trac noreply at wordpress.org
Sat Mar 8 19:52:51 UTC 2014


#27013: Contain scrolling inside the editor
----------------------------+-----------------------
 Reporter:  azaozz          |       Owner:  azaozz
     Type:  task (blessed)  |      Status:  reopened
 Priority:  normal          |   Milestone:  3.9
Component:  TinyMCE         |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  needs-testing   |     Focuses:  ui
----------------------------+-----------------------

Comment (by 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 (maybe just with some mouses), but it switches to
 scrolling by moving the mouse.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/27013#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list