[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