I think if we had the toolbar fixed to the bottom like Flow this would be much less of an issue, as most of the time your cursor is at the end of the document.

That said I think comments longer than a page are relatively rare.

Updated the task description to:

• Include additional feedback @Demian shared here: https://w.wiki/SEh
• Expand the task's scope to include the range of feedback people are sharing.

Thank you, @ppelberg!

I'd like to share ideas... stolen from Gmail, actually. I find that message composing interface very user-friendly.

1. The editing toolbar is on the left side. Though there's no "Visual" / "Source" tab in gmail, I think the toolbar would fit well on the right side of the "Source" tab with some margin between the two.
2. Gmail keeps both the top and the bottom of the editor on-screen. This approach would result in both the toolbar (top) and the edit actions (bottom) to stay on-screen all time. I think this is the best UX:
   1. The toolbar (top) and editactions (bottom) are position: sticky. Note that the new Vector's header will be sticky as well (DEMO), therefore the toolbar's top has to be adjusted for that skin when that gets implemented in a few months (T246170: 69px as of 2020-06-01).
   2. As a visual hint the top and bottom toolbars drop a shadow on the editing area whenever there is text off-screen.

Implementation:

The .dt-ui-replyWidget-modeTabs element is moved into .oo-ui-toolbar-bar (necessary for both points).
Positioning with flexbox and float fallback for some old browsers.

.dt-ui-replyWidget .oo-ui-toolbar-bar {
    display: flex; // Not strictly necessary.
}
.dt-ui-replyWidget .dt-ui-replyWidget-modeTabs {
    position: unset;
    float: left;
}
.dt-ui-replyWidget .oo-ui-toolbar-tools {
    float: left;
    margin-left: 2em;
}

CSS draft for the sticky toolbars:

@background-color-base: #fff; // skin's default BG
@size-toolbar-shadow: 4px;

.dt-ui-replyWidget .oo-ui-toolbar {
    position: sticky;
    top: 0;
    background-color: @background-color-base;
    z-index: 1;
    &.oo-ui-dropshadow {
        box-shadow: 0px @size-toolbar-shadow @size-toolbar-shadow -@size-toolbar-shadow;
    }
}

.dt-ui-replyWidget-actionsWrapper {
    position: sticky;
    bottom: 0;
    background-color: @background-color-base;
    &.oo-ui-dropshadow {
        box-shadow: 0 -@size-toolbar-shadow @size-toolbar-shadow -@size-toolbar-shadow;
    }
}

In T252445#6180738, @Demian wrote:

2. Gmail keeps both the top and the bottom of the editor on-screen. This approach would result in both the toolbar (top) and the edit actions (bottom) to stay on-screen all time. I think this is the best UX:

This is mostly resolved by T254208: Revise position and behavior of Reply tool's text input

In T252445#6180738, @Demian wrote:

Thank you, @ppelberg!

I'd like to share ideas...

@Demian we appreciate you advancing the thinking on this and going so far to draft an implementation!

Here is what we're thinking as it relates to resolving these two issues [ii]: Initially, we are going to focus on the first issue: people can find the tools hard to reach when writing comments on a wide screens.

To address this issue, we are going to try the approach you proposed [i], moving the tools to the side of the screen where writing starts (read: on the left side of the screen in left-to-right languages and on the right side of the screen for right-to-left languages).

This implementation will happen in: T257280.

Now, as to why we are going to address Issue 1 – "tools can be hard to reach" – first:

1. People finding the tools hard to reach is an issue we assume some people will experience quite often
2. Addressing the above issue fits nicely with the plan we have to experiment with making the visual and source mode switcher less prominent in the UI (T256166) so as to minimize the likelihood people new to using talk pages will be confused by the tool's two modes (T246190#6201892 + T246190#6186156)
3. We are assuming fewer people will encounter Issue 2 less frequently than they will Issue 1.

All of the above is now represented in the task description.

i. Issue 1: People can find the tools hard to reach when writing comments on a wide screens; Issue 2: People can have difficulty locating the tool when writing a long comment [b/c the tools are out of view].

ii.

In T252445#6180738, @Demian wrote:

The editing toolbar is on the left side. Though there's no "Visual" / "Source" tab in gmail, I think the toolbar would fit well on the right side of the "Source" tab with some margin between the two.

It astounds me when I look around my workplace and see people running web browsers or word processors or similar applications in full screen on a 1920-px or wider monitor. And yet they do. (Usually with the actual text only 1/3 of the screen and huge gutters on the sides.)

I use everything from a 6" phone to a 2560-px monitor, and for anything over 1024x768 I would make text-heavy applications less than full width. Am I just special?

Unfortunately "you're using the 'puter wrong" isn't the most friendly answer for feedback that right-aligned buttons are too far away. And I wouldn't want to cap the column width like so many sites do.

Because of my habits I don't feel the right-side buttons are too far, but no objections about moving the tools to the left (in LTR languages): it would be consistent with most other web toolbars and even OS-provided menubars.

Re. keeping the top and bottom on-screen: fine for most environments, but floating toolbars (like VE) are horrible on iOS. I'm always having to scroll the page to make the toolbar reappear. I understand it's Apple's fault not ours, but it's one of the things that encourages me away from NWE back to the classic editor on iPad.

This context is helpful, @Pelagic – a comment and question for you as a result...

In T252445#6303517, @Pelagic wrote:

Unfortunately "you're using the 'puter wrong" isn't the most friendly answer for feedback that right-aligned buttons are too far away. And I wouldn't want to cap the column width like so many sites do.

Can you share a bit more here? I think we're on the same page about thinking the right-aligned buttons are an issue that needs to be addressed. In fact, you can experiment with the prototype we put together in this Patch demo (click any reply link on the page). For context, the work on this issue has been happening in T257280.

Also, if there is something I said that gave you the impression that we are not addressing the, "...right-aligned buttons are too far away." issue, please let me know! ...I wonder if others might've been confused by it as well.

Because of my habits I don't feel the right-side buttons are too far, but no objections about moving the tools to the left (in LTR languages): it would be consistent with most other web toolbars and even OS-provided menubars.

Re. keeping the top and bottom on-screen: fine for most environments, but floating toolbars (like VE) are horrible on iOS. I'm always having to scroll the page to make the toolbar reappear. I understand it's Apple's fault not ours, but it's one of the things that encourages me away from NWE back to the classic editor on iPad.

You're spot on about the toolbar behaving as it does as a consequence of how Safari behaves. With this said, it's helpful to know how this behavior impacts what editing interface(s) you use.