In T354463#9674654, @Tacsipacsi wrote:

• The summary box is huge. In one design, it’s a two-line textbox, in the other one, it’s a one-line input; in the implementation, it’s eight lines tall. This gives the impression that the edit summary can be however long I want it to be (and indeed, nothing on the frontend prevents me from writing an over 1000 characters long summary, even though the backend (MW core) caps the summary at 500 characters).

In T354463#9681704, @Tacsipacsi wrote:

Both the first design and VisualEditor present the edit summary as a textbox with two lines by default (VE uses an autosized box, the design shows a grabber). I think that’s convenient (and consistent with VE).

Also, in VisualEditor, the frontend caps the summary at 500 characters, not the backend, and it shows the number of characters left when the user exceeded 400 characters; this should be implemented here as well, because this gives the user a chance to rephrase the summary to stay within the limit, rather than cutting off potentially in the middle of a word. (I couldn’t find an option in Codex to do this, so maybe Codex should be enhanced to support at least the maxlength attribute, but potentially also the “characters left” thing.)

One part is that the frontend should warn/prevent the user if they want to input a too long summary, but there is the other part, which seems to have been forgotten: how the input should look like. Currently, it’s eight lines tall. The design in this task shows a one-line input field, but it doesn’t make it clear whether changing the input field to one-line (or anything else) is intentional.

@JFernandez-WMF Thanks for updating the design! However, it’s still not clear whether the change in the edit summary field is within the scope of this task (and if not, which other task’s scope it’s within).