Node form layout looks awkward on wide screens since #3158854

I raised the same problem in #3158854-33: Node form: address chasm between main form and meta but this was considered an improvement rather than a problem. I think more eyes are useful to discuss wether this intended improvement is an improvement.

I'm the one who created #3158854: Node form: address chasm between main form and meta, and I'll +1 @mstrelan. When I evaluated the solution that got committed I was on a very small display + it looked good to me in the screenshots. Now that I'm actually working with it day-to-day and on a wider display, I have similar concerns to those in the issue summary. I'd prefer a solution that addresses the chasm, but I think reverting #3158854 would also be acceptable provided there was a followup to find something that better addresses the chasm.

Check out #3181964: Horizontal field groups content too narrow and paragraphs break out of node edit form to see how limiting the width looks with nested paragraphs, it isn't too user friendly. TBH a little bit of chasm seems preferable to that.

I don't really get why the content has been limited to:
max-width: 52.5rem;

It sounds like a terrible idea to me. I just added a custom css library to remove that rule on my website.

This is a middle step towards the changes we want to introduce on the layout solution that should be able to accommodate more complex UIs: #3076820: [META] Layout redesign. There are several reasons behind limiting form elements width, but the most important is readability. Longer element widths end up having longer line length, which decreases legibility by making it difficult to gauge where the line starts and ends. A typical consequence of this is that it can be difficult to continue onto the correct line line as @lauriii pointed here: https://www.drupal.org/project/drupal/issues/3181964#comment-13924075.

Before introducing this change there was the discussion about letting the text area with WYSIWYG take more horizontal space when you want to compose more complex content, but it can be easily solved by adding the built-in button on CKEditor to expand to the full page. So I agree on the need to have wider space for some composing elements, but not to content-text creation elements. And to give that space we should plan and find good solutions, but giving all the space to all elements just in case there is something that might need more space instead of thinking why this space is needed doesn't feel correct.

As a last note, the reason behind centering the content instead of leaving it aligned on the left is that it ends up too far away from the right sidebar.

If someone is looking for an undo patch for clients, here's one

Crediting kvantstudio who filed a duplicate and added a patch

The fact that @kvantstudio created a separate issue for this: #3191427: Problem with node-add.css in Claro theme is additional evidence that users interpret the current implementation a problem/bug and not a readability improvement with minor tradeoffs. It's the third issue filed in the past 2 months, and multiple users within those issues are experiencing similar problems. The concerns that resulted in #3158854: Node form: address chasm between main form and meta are ones that can mitigated pretty easily by resizing the browser window or CKEditor. The problems created by that same issue can't be mitigated as easily, and I think rolling back is the best course of action.

I do think , but in the meantime I think the changes in #3158854: Node form: address chasm between main form and meta should be rolled back with the approach used in #8.

the concerns expressed in #7 should still be addressed, so I tagged this with "needs followup" to create an issue for those concerns. That issue summary should reference the prior attempts to fix it in #3158854: Node form: address chasm between main form and meta.

Someone create that followup and I'll review this a little more carefully and probably RTBC.

When using a 4K monitor, your restrictions and centering the text placement area do not lead to anything good. Therefore, I considered this a rather serious problem that prevents from fully using the editor.

A narrow area on the right for placing meta information is also a bad solution. It can accommodate various blocks with nested content and strictly limiting the width leads to the fact that it is also inconvenient to use the editor.

+1 for reverting using #8, yesterday was too late.

I see a good amount of interest in making this happen! I'm sure those interested would love to participate in pushing this forward, so this is what is needed next:

• Fix whatever is causing the custom commands failure in the patch in #8. This typically isn't too difficult once someone is familiar with running the tests locally and interpreting the results. If you're not familiar yet, ping me on Drupal slack and I'll assist.
• Create the followup issue I mentioned needed creating in #11. If you're not familiar yet, that is also something you can ping me on Drupal Slack to assist.

When those steps are completed (and assistance is available for anyone unsure how to proceed), I can review and potentially RTBC.

Adding working patch on 9.2.x.

And one more for 9.1.x

I would suggest that https://www.drupal.org/project/drupal/issues/3181964 is a follow-up because it describes the issue, laurii is already involved in the discussion there.

Applied patch #15 and it works fine. Adding screenshots bellow.

Hi @mirom,

You patch for drupal9.2 is applied but it's creating same view for all screen.

Can we do something witch is not changed normal view of Basic page.

for more detail please see the attachment below.

Thanks!

Copied a proposed resolution from the issue that was closed as a duplicate #3181964-13: Horizontal field groups content too narrow and paragraphs break out of node edit form.

Discussed this at length with @ckrina and @saschaeggi to come up with a short term solution to the bugs documented here because #3076820: [META] Layout redesign could take a while.

What we thought would be the right steps for solving the problems here:

On this issue:

1. Increase the max width of the layout region
   • This will increase the chasm between the sidebar and the main column but this will be solved in future with a background color
2. Add separate max width to form elements to improve readability

Open follow-ups for:

1. Improving the alignment of the tabs to make the design look more consistent visually
2. Improving vertical tabs to be adapted to work in a smaller space
   1. Iterate designs to consume less horizonal space
   2. Implementation needs some improvements too to allow it to be used in a node form
3. Investigating table overflow issues impacting Paragraphs

I am working on this issue.

#23 I have provided the patch please verify if it is working or not

#23 Patch Custom Commands Failed,

Re created patch #24

#24 Patch Custom Commands Failed,

Re created patch #25

#25 Patch Custom Commands Failed,

Re created patch #26

I have added before and after patch screenshots for reference. The width is now covering full-screen size.

Moving to RTBC.

+++ b/core/themes/claro/css/layout/node-add.css
@@ -22,40 +45,35 @@
-  .layout-region--node-main,
-  .layout-region--node-footer {
+  .layout-region-node-main,
+  .layout-region-node-footer {

I notice the -- is changed to a single - in several places. This isn't needed to address the issue, and breaks Drupal Core's use of BEM CSS standards http://getbem.com/introduction/.

This should be refactored so the classnames are unchanged.

Used patch #26 as base in the MR.

I can confirm this is working with 9.2.2

Patch file from the latest MR changes.

Neither the MR or patches reflect what lauriii suggested in #20...

Whilst I accept is was quite a drastic change, I'm not sure simply reverting it is helpful, there are legitimate reasons for it.

The comment in #20 seems like a fair middle ground. I also think adding a new breakpoint for those of us with really wide screens, where it's most obvious, will help this issue in particular.

This patch (which is mostly for discussion, I didn't want to go changing the MR just yet) does the following:

• Max width 48rem only for long text fields where the original issue of line length is most relevant
• Increases the breakpoint at which the centering applies (61rem/976px is far too soon, IMO)
• Increases the column max width in general to 66rem, which is opinionated but looked ok to me
• Adds a new breakpoint for 112rem/1792px for mega screens, which utilises viewport width units instead of rem. This allows the columns (including sidebar which feels very constrained at it's original 22.5rem) to widen and keeps the chasm between them to a more comfortable amount.

Screenshots of the effected breakpoints attached.

Keen to see what everyone thinks!

At least in my tests it seems that the patch from #38 works quite nicely. Only issue I seem to have with it, is that it sets the left and right margin to auto for the content main and footer area. This makes the node edit area area not aligned with the page title on the left side. Changing the margins to be initial aligns the page correctly to my eyes.

I changed the following styles:

.layout-region--node-main .layout-region__content,
.layout-region--node-footer .layout-region__content {
  margin-left: initial;
  margin-right: initial;
}

I didn't find any side effects from making that change for mobile, tablet or large table screen.

Attached are two screenshots which shows how the margin auto and initial change the edit page top part where the node title and edit form are not aligned. This was tested with core 9.2.5.

The auto margin was the proposed solution for https://www.drupal.org/project/drupal/issues/3158854#comment-13793472, to address the "chasm" between the sidebar. My understanding is this is just a short term solution, until a more complete design is done, and the mis-alignment with title is an acceptable compromise.

I found that the new narrow form doesn't work with the field_layout module.
I think that the gin admin theme did a better job for this and it would be nice to take it as an example 😅

example with actual version of claro :

same example with Gin :
(work perfectly even with the left sidebar)

#38 Worked Great, thx

I ran into this and reported it as #3256817; given that a lot of people use wider screens than were in use ten years ago, I think the 48rem limitation is too restrictive and wasteful of screen space.

One question about the patch/MR - should the class renaming be doing in a separate issue so this one can be focused on the width issues?

Fixed CS errors.

Thanks @rikki_iki for all the work done implementing changes based on what was suggested in #20.

Increases the breakpoint at which the centering applies (61rem/976px is far too soon, IMO).

You changed 976px for a 86rem/1.376px. While I totally understand the reason behind it, most of the content editors using laptops (a huge part of them use the laptop as main screen) would end up working with the mobile version. As a reference, a13 inches lapatop without high definition screen is 1280px wide. That is not a desired experience, specially if at 976 you can still have a reasonable usable experience with 2 columns:

Another option would be to do that change at 1024px, but that would mean that at 1023px you could end up with really long lines on descriptions (see screenshot below). Long story short, I wouldn’t change that breakpoint for now. Maybe in the future with an improved design :)

Adds a new breakpoint for 112rem/1792px for mega screens, which utilises viewport width units instead of rem. This allows the columns (including sidebar which feels very constrained at it's original 22.5rem) to widen and keeps the chasm between them to a more comfortable amount.

I really like this change, but only for the sidebar. The problem with the main region ends up being the same: really long lines of text without a limit. See descriptions for example:

Increases the column max width in general to 66rem, which is opinionated but looked ok to me

Agreed on increasing the column max width as the way forward (specially to ease the situations the current max-width is causing), but maybe 66rem is a little bit too much. We’ve discussed it on the #admin-ui-design channel and a good value would be 52rem.

Max width 48rem only for long text fields where the original issue of line length is most relevant

If we’re already keeping 52 as the max-width for the whole column, we can keep it for the text areas too. It’s not too wide and we can avoid having to define it individually to other elements (like the ..filter-wrapper) below the text area taking more width than the text area itself if the column wrapper is wider)

As a summary, I’ve just left the change of the value from 48rem to 52rem and the improvement to increase the sidebar width in larger screens. The margin: auto; is also needed to get to the future steps to improve this page (see Gin implementation in #42 as a reference to where Claro is slowly going).

With all that said, I understand this max-width is causing issues in some specific UIs that need wider space. But we can’t define all forms experience based on some specific node configurations. Ideally, the experience should be customized for those with wider width and better designs (improve the components Paragraphs & co use). The reason behind this is the plan to change the layout in future iterations: #3076820: [META] Layout redesign. This max-width is a first and needed step to modernize the overall layout for the administration UI.

There seems to be a whole lotta backstory to this issue that I tried to digest.

The fix in #47 looks good except at very wide widths (above 1790 viewport width). Screenshots attached. I'm going to try to dig in a bit and see if its an easy fix.

Was a pretty straightforward fix. Patch and interdiff attached.

Woot! I'm happy with those changes @ckrina. The patch in #49 applies and resolves the issue in #48. Before/after screenshots attached. Marking RTBC

Missing the 'after' screenshot @rikki_iki?

Oops, forgot to press upload on the after screenshot :)

Can we also have a Drupal 10 patch for this issue?

Apply patch #49

1. Browser Chrome
2. System Resolution 1920 X 1080 (16:9)

Here's a version of #49 for D10.

Thanks for the patch @DamienMcKenna! Looks perfect. Drupal 10 version is also RTBC IMHO.

Committed e2d3a3e and pushed to 10.0.x. Also committed the 9.x patch to 9.4.x. Thanks!

Yay! 👏

Cant get any patches to work on 9.4.5 and php 8.0. #38 works fine in 9.3.21.

For now I cannot upgrade to 9.4.5 unless I remove this patch.

@ainsofs. It looks like this patch was committed to 9.4.x, so that makes sense.

@ainsofs We fix this with a custom module FYI

In the custom module we have 4 files
my_module.module
my_module.info
css/claro-node-form-overrides.css
my_module.libraries.yml

In my_module.module

/**
 * Implements hook_form_BASE_FORM_ID_alter() for \Drupal\node\NodeForm.
 *
 * Adds style overrides for claro/node-form.
 */
function my_module_form_node_form_alter(&$form, FormStateInterface $form_state) {
  $form['#attached']['library'][] = 'my_module/claro-node-form-overrides';
}

In my_module.info

name: 'My module name'
type: module
description: 'Description.'
core_version_requirement: ^9 || ^10
package: 'My package'

In css/claro-node-form-overrides.css

/*
  Overrides Claro layout for node form.
  @see https://www.drupal.org/project/drupal/issues/3184667
*/

@media screen and (min-width: 61rem) {
  .layout-region--node-main,
  .layout-region--node-footer {
    width: 65% !important;
  }

  .layout-region--node-main .layout-region__content,
  .layout-region--node-footer .layout-region__content {
    max-width: 100% !important;
  }

  .layout-region--node-secondary {
    width: 35% !important;
  }
}

In my_module.libraries.yml

claro-node-form-overrides:
  css:
    layout:
      css/claro-node-form-overrides.css: {}
  dependencies:
    - claro/node-form

Since there is no factual basis for this:

There are several reasons behind limiting form elements width, but the most important is readability. Longer element widths end up having longer line length, which decreases legibility by making it difficult to gauge where the line starts and ends. A typical consequence of this is that it can be difficult to continue onto the correct line line as @lauriii pointed here:

In order for any admin theme to succeed it must at least honor the screen real estate of the user.

For websites with advanced elements, vertical tabs are a must.

Often the fancy side bar on the right hand must even be moved down as a horizontal element, because horizontal real estate is extremely important for certain elements.

Since Drupal is so much more than just a Title-Image-Body CMS, any serious admin theme must make use of the horizontal space for larger screen.

We know that responsive design and editing via mobile is also important, but this must not interfere with the correct and ergonomic editing via larger screens.

The important difficult case to have in mind for advanced websites are nested entities. The whole reason to use Drupal instead of lightweight alternatives, is the excellent way of handling nested, translatable, revisionable entities.

For example for an admin theme to excel, it must for large screens display Nested Inline Entities (https://www.drupal.org/project/inline_entity_form) and also Inline Entity Form Table View Mode(https://www.drupal.org/project/ief_table_view_mode) in a reasonable way.

This entails that vertical tabs must work and 100% of the remaining width must be available for any kind of advanced element requiring horizontal space.

For sure, regular text fields and text areas can be limited in width, in order to preserve readability. But this must be a per-field type width limit.

From a pure design point of view, "centering" the whole admin area below the left-aligned full width top admin tool bar and a right aligned side box -is just incorrect. That layout is objectively invalid.

Kudos however to the rest of the theme. It is a pleasurable improvement over Seven indeed:)

@martinb14 you might be interested in using the Gin Admin Theme which will offer a lot of customization options depending on your usecase.

@saschaeggi, Gin does look promising.

It seems however that also for this theme we may need to inherit and remove the max width from

.gin--edit-form .page-wrapper__node-edit-form .block-system-main-block {
  max-width: 1280px;
}

In general I guess this should just be in the theme settings, even though in my personal opinion, one should never have this max width in the first place:)

If the node form contains veritcal tabs (e.g. using https://www.drupal.org/project/field_group) then the form is pretty much unusable.
Also there is no obvious way to disable the right sidebar (or move it bellow the form) if not needed and reclaim the extra space. Even if "Authored by" and "Authored on" are disabled in "Manage form display" they still appear in the sidebar. #64 was a helpful temporary workaround.

Wit its width limit it is more or less unusable for content creation - especially when using paragraphs. With paragraphs and especially layout paragraphs it becomes a content creation nightmare.

ok, I have to look into howto create patches. The only viable solution is to remove the max-width entirely. Everything else doesn't work.

Have to chime in here and say this max width makes this theme totally unusable. We setup all our node edit pages with vertical tabs to make the editing process simpler for users, keeping things in sensible groups. This destroys all that, along with using Paragraphs. Will be going back to Seven until this issue is resolved.

It seems like maybe the solution here is to make this configurable? I can understand the desire to have this feature for new sites and better OOTB experience, but it is certainly not workable for a lot of setups using vertical tabs and/or Paragraphs.

Seems like there are many legitimate objections to the changes here! However, there's unfortunately zero chance of getting it addressed by commenting on an issue that was closed almost a year ago. Fortunately, if this same info is included in a new issue this moves from "zero chance" to "quite likely" that someone will work on addressing the problems reported.

The open one is marked as duplicate and there is a link chain to here after upgrading to D10 with Claro. Using vertical tabs. For D9 we overrode max-width in css. Now the thin column is back without max-width but width: min().

We use a custom block for inline css overrides for claro admin theme for ease of adjustments.

Used this in D9

<style type="text/css">

.layout-region--node-main .layout-region__content,
.layout-region--node-footer .layout-region__content {
max-width: 100%;
}

</style>

It changed for D10

We can't make it 100% of the area without pushing the admin tabs off canvas. 75rem seems to be okay.

<style type="text/css">

.layout-region--node-main,
.layout-region--node-footer {
width: min(75rem, 100%);
}

</style>

Before in D9 it flexed well with the admin tabs at max-width 100%;

---

This seems to work similarly as before for our users.

<style type="text/css">

.layout-region--node-main,
.layout-region--node-footer {
width: calc(100% - 2rem);
}

.layout-region--node-main .layout-region__content,
.layout-region--node-footer .layout-region__content {
max-width: 100%;
margin-right: auto;
margin-left: auto;
}

</style>

Crutch check out this module : https://www.drupal.org/project/asset_injector to do CSS better then a custom block, the way you're doing it.

Thanks alphex! Installed and using.

Note that classes changed for 10.3.1 and had to add additional classes

.layout-region--main:has(.vertical-tabs),
.layout-region--main,
.layout-region--footer {
width: calc(100% - 2rem);
}

.layout-region--main .layout-region__content,
.layout-region--main .layout__region-content,
.layout-region--footer .layout-region__content {
max-width: 100%;
margin-right: auto;
margin-left: auto;
}