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

[WordPress Trac]

#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 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.

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