I don't think this is really necessary. Edit summaries aren't supposed to be very long. If the edit summary length issues are fixed, there will still probably be a fairly low maximum size for edit summaries, although we might have saner rules than measuring by byte counts, which wouldn't affect the actual visual size. (IMO, all unicode characters should count as 1 letter, and link targets shouldn't be counted at all, so "[[Page target|Word]]" should only count as four letters.)

https://en.wikipedia.org/w/index.php?diff=828381447&oldid=828377910&type=revision&diffmode=source has some possibly relevant JavaScript codes. It seems like the consensus has not been established at enwiki, there are many solutions being discussed in a chaotic fashion.

You also have to consider the fact that by this you will completely hide big parts of edit summaries to readers and, potentially, other editors, which can cause disruption and harassment happening in the parts of edit summary that not every one of editors would be interested in opening each time one by one. If Wikimedia developers decide for us to go through with this change and we in turn decide to hide some parts of edit summaries under the rug, there also has to be an option to ‘Show all’ so to speak.

@stjn I think the optimal would be a show/hide javascript (or whatever) link for long edit summaries with the default being selectable in your preferences. I don't know how much work would be, but I guess it is not astoundingly trivial.

We should probably avoid introducing another preference -- too many of those as it is. But with the proposed implementation, it's just a CSS class. So you could add a single line of code to your personal CSS to always show the full summary. For convenience we could make this a gadget.

I'm interested in taking a stab at the MediaWiki implementation, but I'd like to hear from more that this is a good idea.

Note that the "original" discussion was about keeping things better aligned in all conditions within the recentchanges-related special pages, action=history and so on. Compacting or hiding stuff via JavaScript is what the CleanChanges extension does; previously discussed solutions included a switch to a table format as we see in the various Special:ListFiles, LQT history etc. Was the table format in another feature request?

Community Tech's current proposal (being discussed at ENWP's Village Pump) is to set the edit summary input on all desktop and mobile web editing interfaces to 500 characters. We also offered to help build/review/participate in creating a gadget or user script to visually truncate long edit summaries on recent changes, histories, logs, etc.

Making the summaries 500 characters should solve most of the visual problems, but for folks who really want to go back to the days of 255 can opt-in to a visual change.