latest prototype: https://vector-2022.web.app/Moth

In T298198#8486041, @alexhollender_WMF wrote:

latest prototype: https://vector-2022.web.app/Moth

@alexhollender_WMF the use of the grid in that prototype is wrong. You are using the column gutters (separation between columns) to place the content but you should use the columns instead. This is what you should do:

In this way, the separation between ToC - Content - Tools wouldn't be 32px but would be 24px instead.

In T298198#8486978, @bmartinezcalvo wrote:

@alexhollender_WMF the use of the grid in that prototype is wrong. You are using the column gutters (separation between columns) to place the content but you should use the columns instead. This is what you should do:

I can't see the image you posted. To clarify: the dark red is the gutters, and the light red is the columns. As we discussed, in this version of the prototype the gutters are generally wider than the columns.

In T298198#8499531, @alexhollender_WMF wrote:

In T298198#8486978, @bmartinezcalvo wrote:

@alexhollender_WMF the use of the grid in that prototype is wrong. You are using the column gutters (separation between columns) to place the content but you should use the columns instead. This is what you should do:

I can't see the image you posted.

@alexhollender_WMF sorry, my image was not public. Now you should view it. What I was explaining in the image is that, as documented in the Grid design proposal, you should use the following sizes in the desktop grid (from 1120px to 1679px screens):

• Margins 32px
• Gutters 24px
• Max content width 1514px

In T298198#8499531, @alexhollender_WMF wrote:

To clarify: the dark red is the gutters, and the light red is the columns. As we discussed, in this version of the prototype the gutters are generally wider than the columns.

Ah ok, I misunderstood. Then the content is starting in the first grid column, well. In some cases the gutters could be bigger than the columns (e.g. in 1120px screens) but in all cases gutters should be 24px.

Static grid-areas

@bmartinezcalvo the current grid-area definitions are static, so the content area remains the same (15 columns) regardless of whether or not the tools menu is pinned or hidden:

tools menu hidden	tools menu pinned

On larger screens this doesn't present an issue, however on smaller screens it means that the content gets squished more than it needs to, for example:

tools menu hidden (smaller screen)

Dynamic grid-areas

One way to improve the layout for smaller screens would be for the grid-area definitions to be dynamic, so that the content area can take up more columns when the tools menu is hidden:

tools menu hidden	tools menu pinned

One possible downside with this approach is that on larger screens, when the tools menu is hidden, the content will be wider than what we previously considered ideal (960px).

tools menu hidden

This width of course depends both on the number of columns we allow the content to take up when the tools menu is hidden (16, 17, 18, or 19), as well as the max-width of the entire grid (which is currently set to 1650px in the prototype). This table is not comprehensive, just a start to help frame how we think about this:

In addition to the number of columns the content takes up, and the max-width of the grid, other things could affect this:

• media query so that the content takes up less columns again above a certain width
• add a max-width on content area
• increased font-size (which means the ideal width is then larger)

Prototype with 1650px max-width, and content area taking up 17 columns when tools menu is hidden: https://vector-2022.web.app/Moss

In T298198#8632291, @alexhollender_WMF wrote:

Dynamic grid-areas

One way to improve the layout for smaller screens would be for the grid-area definitions to be dynamic, so that the content area can take up more columns when the tools menu is hidden:

tools menu hidden	tools menu pinned

@alexhollender_WMF I agree with using a dynamic layout to expand the content when the Tools panel is hidden. Also I agree with using 4 columns for the Tools panel since in the previous proposal we were using 3 col. instead, which causes the Tools panel to be too narrow on small desktop screens. So I agree with using a dynamic layout with 4col. Tools panel and expandable content area.

One possible downside with this approach is that on larger screens, when the tools menu is hidden, the content will be wider than what we previously considered ideal (960px).

tools menu hidden

This width of course depends both on the number of columns we allow the content to take up when the tools menu is hidden (16, 17, 18, or 19), as well as the max-width of the entire grid (which is currently set to 1650px in the prototype). This table is not comprehensive, just a start to help frame how we think about this:

	content at 16 columns	content at 17 columns
grid max-width: 1514px	content max-width: 1001px	content max-width: 1065px
grid max-width: 1650px	content max-width: 1092px	content max-width: 1161px

I've explored this dynamic layout proposal testing both 16col. and 17col. for the expandable content area.

I lean towards using the expandable content from 15col (tools displayed) to 16col (tools hidden) since the content area will be more aligned with the 960px ideal width. Since the grid max-width is 1514px, the max-content width will be 1002px which is just 42px more than the ideal content width.

@alexhollender_WMF could you update the prototype with both 17col and 16col to compare both options?

Hi @bmartinezcalvo, is this something pending response from Web team folks? If so, would it make sense for @KieranMcCann to work with you on resolving?

In T298198#8722457, @RHo wrote:

Hi @bmartinezcalvo, is this something pending response from Web team folks? If so, would it make sense for @KieranMcCann to work with you on resolving?

@RHo I need to know if @KieranMcCann agrees with the new proposal of having a dynamic grid where central content will expand if the right panel (tools) is hidden. Please review my last comment above and the one from Alex. If you both agree with this, I will update the grid and layout proposal in this task and the layout documentation in the library.

@RHo @bmartinezcalvo I do agree with having a dynamic grid which allows for the article to expand to the right when the tools panel is hidden. There are, however, a couple things in the way of us moving forward with this at the moment. These being:

• One of the outcomes of the recent Vector 2022 rfc is that there are community members who support a move towards full-width article content. Meaning that the article would just continue grow in width as the browser extends. This approach would have a big impact on how we approach the grid.
• Also, as part of the next set of iterations to Vector 2022 the application of the grid has been descoped due to the technical complexity. That doesn’t block it in the future but something you should be aware of.

Happy to continue working on this but until the first point above is resolved then it we wouldn’t be able to come to a resolution.

Hey @KieranMcCann thank you for sharing this. I've updated the layout proposal applying your feedback related with the content full-width. We could use 4col for the tools panel and then expand the article content when the tools panel is hidden. With this new layout, we would solve the user's full-width request for the article content.

This layout proposal uses the same grid solution we proposed some time ago (24col grid on desktop) so there is no problem with implementing one or another layout using this grid. In any case, I think it's worth implementing a grid so we can unify the margins and visual structure in all our projects.

In T298198#8728592, @bmartinezcalvo wrote:

Hey @KieranMcCann thank you for sharing this. I've updated the layout proposal applying your feedback related with the content full-width. We could use 4col for the tools panel and then expand the article content when the tools panel is hidden. With this new layout, we would solve the user's full-width request for the article content.

This layout proposal uses the same grid solution we proposed some time ago (24col grid on desktop) so there is no problem with implementing one or another layout using this grid. In any case, I think it's worth implementing a grid so we can unify the margins and visual structure in all our projects.

Hi @bmartinezcalvo. Just to clarify that this updated proposal still appears to have a max-width on the content of 1514px. If we end up going with the current suggestion, from some community members, not to have any width limitation, then the grid approach would need to change. Myself and @RHo were discussing this earlier and there may be a few options:

• have a breakpoint at a large width where we switch from the grid to a % based flexible layout that follows the column ratios on the max width
• as above but we have a mix-width on the menus and allow the width of the article content to flex

Either way I think it might be useful to hold off on making any final grid decision this until we have a clearer direction on this. Will keep you posted!

In T298198#8735855, @KieranMcCann wrote:

Hi @bmartinezcalvo. Just to clarify that this updated proposal still appears to have a max-width on the content of 1514px. If we end up going with the current suggestion, from some community members, not to have any width limitation, then the grid approach would need to change.

@KieranMcCann oh yes, sorry, I misunderstood your previous comment. So the right new proposal would be this one instead, with no max-width limitation on big screens:

I would avoid using a no max-width limitation since the reading experience will not be the best and the content would be too wide on some big screens, specially when the tools panel is hidden.

Myself and @RHo were discussing this earlier and there may be a few options:

• have a breakpoint at a large width where we switch from the grid to a % based flexible layout that follows the column ratios on the max width
• as above but we have a mix-width on the menus and allow the width of the article content to flex

Either way I think it might be useful to hold off on making any final grid decision this until we have a clearer direction on this. Will keep you posted!

I agree, let's discuss this when we have a clearer direction.

In T298198#8737660, @bmartinezcalvo wrote:

In T298198#8735855, @KieranMcCann wrote:

Hi @bmartinezcalvo. Just to clarify that this updated proposal still appears to have a max-width on the content of 1514px. If we end up going with the current suggestion, from some community members, not to have any width limitation, then the grid approach would need to change.

@KieranMcCann oh yes, sorry, I misunderstood your previous comment. So the right new proposal would be this one instead, with no max-width limitation on big screens:

Once direction/decision has been made on the full-width issue, I recommend updating this diagram to show how it would work on very wide screens beyond the grid max breakpoint.

I would avoid using a no max-width limitation since the reading experience will not be the best and the content would be too wide on some big screens, specially when the tools panel is hidden.

Agree, this has been the design recommendation throughout, but conversation is ongoing.

Myself and @RHo were discussing this earlier and there may be a few options:

• have a breakpoint at a large width where we switch from the grid to a % based flexible layout that follows the column ratios on the max width
• as above but we have a mix-width on the menus and allow the width of the article content to flex

Either way I think it might be useful to hold off on making any final grid decision this until we have a clearer direction on this. Will keep you posted!

I agree, let's discuss this when we have a clearer direction.

Here is the latest proposal for the grid with particular reference to how it behaves with Vector 2022. This proposal takes into account:

• community feedback requesting a full width option that can be toggled to allow no width restriction
• the likely introduction of the ‘Zebra 9’ design changes which has introduced larger padding on the article and menus and therefore reduced content column widths.

The key changes from the previous proposal include:

• ToC and Tools columns are now the same width to create a symmetrical layout when both menus are pinned. The column distribution is 4/16/4
• In ‘restricted width mode’ the article does not change size or position when menus are hidden.
• In ‘restricted width mode’ the maximum width has been increased to 1618px to compensate for the increased padding introduced by the Zebra design which reduced the article text column width.
• Addition of ‘full width mode’ where the grid has no max-width.
  • In ‘full-width mode’, when menus are hidden the article expands to fill the empty columns. This behaviour is different from ‘restricted width mode’.

{F36992048}
{F36992049}

Figma file

In T298198#8844041, @KieranMcCann wrote:

Here is the latest proposal for the grid with particular reference to how it behaves with Vector 2022. This proposal takes into account:

• community feedback requesting a full width option that can be toggled to allow no width restriction
• the likely introduction of the ‘Zebra 9’ design changes which has introduced larger padding on the article and menus and therefore reduced content column widths.

The key changes from the previous proposal include:

• ToC and Tools columns are now the same width to create a symmetrical layout when both menus are pinned. The column distribution is 4/16/4
• In ‘restricted width mode’ the article does not change size or position when menus are hidden.
• In ‘restricted width mode’ the maximum width has been increased to 1618px to compensate for the increased padding introduced by the Zebra design which reduced the article text column width.
• Addition of ‘full width mode’ where the grid has no max-width.
  • In ‘full-width mode’, when menus are hidden the article expands to fill the empty columns. This behaviour is different from ‘restricted width mode’.

{F36992048}
{F36992049}

Figma file

Adding in non-restricted versions of above images (since KieranMcCann is no longer active)

Sharing here the updated proposal for the Grid being implemented in T337282.

Based on the existing page's layouts across projects, the grid could be used to cover the following layouts. At breakpoints desktop-wide and desktop there will be max-width of 1514px, and side panels might be visible; while the content will be full-width at breakpoints tablet and mobile, with the side panels collapsed as default and displayed as overlays when needed.

• 2-panel layout: The main content area spans 16 columns, with a collapsible 4-column panel on each side.
• 1-panel layout: The main content spans 20 columns, with a collapsible 4-column side panel. This layout is typically used when only one of the two panels from the 2-panel layout is visible.
• No-panel layout: The content spans 16 columns, leaving 4 columns of margin on each side. This ensures visual consistency in case side panels are expanded.
• Full-width layout: The content spans 100% of the grid at any screen size. This layout is typically used when both side panels from the 1-panel or 2-panel layout are collapsed.

Currently, side panels in Vector 2022 have a fixed width that only changes at specific breakpoints. With the new grid system, this behavior will change: side panels will span 4 columns of the grid, meaning their width will adjust fluidly as the screen is resized, rather than only at predefined breakpoints.

Current side panels in Vector22	Grid columns resizing