Claro content editing area is too narrow

HI @deiviic

I have fixed the issue & added commit in MR, please review here.
https://git.drupalcode.org/project/drupal/-/merge_requests/5217/diffs?co...

MR has some errors

Before/after screenshot should be added to the issue summary.

May not be needed but tagging for sub maintainer input also.

This is one of those recursive issues

1. Too much space when editing in Claro: #3158854: Node form: address chasm between main form and meta →
2. The node edit form is now too wide in Claro: 📌 Node form layout looks awkward on wide screens since #3158854 Fixed
3. Today: The node edit area is too thin in Claro: 🐛 Claro content editing area is too narrow Needs review

We've found it, solved it, found it, solved it ...

I'm not sure what the actual answer is. I know in Annertech we just created a clone of Claro to add the CSS to fix this specific issue for our desires because it seems whatever we choose it will be too wide for some and too narrow for others.

I don't see how taking up the whole available space would be too wide.. For now we also just cloned the Claro theme and made the necessary changes.

First, thanks all for raising this issue and working on this. I am totally aware that this is a problem to be fixed, but as @markconroy mentioned there's been several attempts to fix that with a general layout changes changing the max-with. The truth is that this width should change depending on the needs of the content it's printing. If you have a really small form so much width is bad on a usability perspective.

We are working towards solving this problem in a more holistic way on a design perspective in 📌 [META] Layout redesign Active .

But this problem would likely be solved if specific form elements that need extra horizontal space (like vertical tabs) could add a class to either the main content region or a parent that would modify the max width.

If you want to work to solve that it would be great: feel free to reflect it on the issue summary. But if the proposed solution only tries to change the max-with for all situations I'm afraid I'll have to close this as work as designed.

saschaeggi → changed the visibility of the branch 3398277-claro-content-editing to hidden.

@ckrina & I discussed this at length today.

While we're working on 📌 [META] Layout redesign Active to tackle this more holistically we want to provide some improvements right now.

We looked at different possible sizes and settled at 60rem (960px, up from 832px) as the default for now.
To take advantage of CSS3 new :has() feature which should land in Firefox pretty soon (2023-12-19 as of writing) as last browser not supporting it, we included a check if vertical tabs are used in the layout and extend the layout to 68rem (1088px).

While this might still not be wide enough for your specific use case we expose both widths as CSS3 variable:

--layout-region-edit-width // New default width of 60rem, for basic layouts
--layout-region-edit-extended-width //New width for layouts which require more space (e.g. vertical tabs)

so changes can be made easily without having the need to subtheme Claro.

We hope to at least address the pain point of the possible shortcomings of this layout until we can implement 📌 [META] Layout redesign Active 🙇

I tested the MR manually both with and without vertical tabs. I personally find reading something like the body content easier with the 832px width. This is pushing the CKEditor content to be quite a lot wider from that of native text editors. I don't want to hold this change on that but just wanted to bring that to attention. I do like the vertical tabs fix because it at least allows improving that a little but. I think we need a follow-up because vertical tabs are currently not usable on screens below ~1300px on the node form.

@lauriii I agree with you 200%. But I’ve tested it with 55, 58 and 60rre. 60rem is way too wide on a line length perspective, but without having a solution easy to apply and adapt by contribs it’s worst the pain we are causing to a lot of people that need to use a wider form (because it's the solution implemented by widely used contribs) than the pain we’re causing with this longer line length (at 60rem/960px) to the rest of users.

@lauriii @ckrina +1

but without having a solution easy to apply and adapt by contribs it’s worst the pain we are causing to a lot of people that wants need to use a wider form (because it's the solution implemented by widely used contribs) than the pain we’re causing with this longer line length (at 60rem/960px) to the rest of users.

This is why we opted for the giving solution

Looks like generally all of the maintainers are +1 on this. I think we still need 10.2.x backport but the 11.x MR is ready.

@lauriii 10.2.x backport is ready -> https://git.drupalcode.org/project/drupal/-/merge_requests/5832

Committed 3df04e7 to 11.x and 1050de8 to 10.2.x. Thanks!

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2023-12-15 Needs work . That issue has a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @AaronMcHale, @Emma Horrell, @benjifisher, @rkoller, @simohell, and @worldlinemine.

We agreed with the point made in #19: even before this issue, the content area is often too wide, and this change can make it worse. On the other hand, users have the option of narrowing their browser windows if the content area gets too wide. Perhaps it is better to make it too wide in some situations than to make it too narrow in other situations.

We were frustrated by the "Steps to reproduce" in the issue summary:

Setup vertical tabs in form display

That is not enough information, and we wasted some time trying to reproduce the screenshot in the issue summary.

Automatically closed - issue fixed for 2 weeks with no activity.

Re #11, #19, #20, #29.
It seems established that, and I confirm it, opinion and needs on this subject vary depending on the user.
Why is this forced on users then? Is this a CMS or a dictatorship?
A "do not limit editing form width" checkbox in the theme parameters would be nice.
To me white space around the form looks as much silly as inside it.
And it's worse from an ergonomic point of view when you use the Bricks module for example.