Origami Frontend Components & Services

CSS Grid In Chrome 80

Posted on by Lee Moody.

Users of Google Chrome may recently have seen a broken layout for many of our internal tools and products. Users who did not upgrade Chrome, users of Firefox, Safari, and other browsers were not affected.

In this blog post we’ll take a brief look at what changed in Chrome 80 and how it affected us.

What Happened?

Many of our internal tools such as bizops, sos, people finder, the Origami registry, and even this blog displayed with a visually broken layout for Google Chrome users who upgraded to Chrome 80. Although content was still visible, it made using these sites pretty difficult. Users who did not upgrade Chrome, users of Firefox, Safari, and other browsers were not affected.

All these sites are built with our o-layout component. o-layout uses CSS Grid to position headers, footers, sidebars, and other key areas of the page at different screen sizes. CSS Grid is great at this. It enables a developer to flexibly position content in columns and rows, a little like a fancy table.

The World Wide Web Consortium (W3C), who help define the web standards which browsers implement, proposed a change to how CSS grid layouts are calculated in a draft CSS Grid specification.

The draft updates how the length of flexible rows or columns, which grow or shrink according to available space, are calculated in certain circumstances. (More context including why the change was proposed can be found in the CSS Working Group drafts issue.)

How Did That Break o-layout?

The content of our layouts need to keep within the contained width of our header component o-header-services. To achieve this o-layout uses a horizontally centred CSS Grid with a max width to match our header.

A basic CSS Grid with a max width. There is a header on one row, a fixed width sidebar on the second row, and also a main content area with flexible size on the second row.

Using a grid with a max width like this means we can create new layouts with different columns and rows, and have them all contained within the width of our header content more easily.

But o-header-services has a background which bleeds to the edge of the screen. To achieve this we set the header width to 100% the browser width. So the header went beyond the width of our grid. We then positioned the header to the left.

The grid container with its max width is still centred the same but the header now goes off the edge of the screen.
Now the header is positioned to the left and takes up the full screen width. The grid container is still centred in the same way, with the sidebar and main content area contained in its max width.

Our sidebar has a fixed width and the main content area is flexible to fill the remaining space in our grid container. In the current Candidate Recommendation of the CSS Grid specification our header overflow does not increase the width of the main area. In the draft version of the CSS Grid specification, the main area grows to match the width of our spanning header element and overflows the grid container also. For o-layout this caused a wide, misaligned grid with horizontal page scroll.

In Chrome 80 the main content area also expands beyond the edge of the screen. The page is now horizontally scrollable.
When the header is positioned to the left, and the page scrolled left, things are looking even worse in Chrome 80.

What Was The Solution?

We weren’t the only ones who experienced layout issues and it looks like Google Chrome plan to revert this change for now. In the meantime we avoided the issue by calculating our CSS Grid Column widths with a calc function rather than relying on an overall grid container (see the PR).

o-layout now renders correctly for Chrome 80 users and for both versions of the specification, should the new draft be adopted. Plus, as an added benefit, this change also prevents some annoying horizontal scroll for users who have scrollbars visible at all times. 🎉