Posted on by Lee Moody.
TL;DR: Users of Google Chrome may recently have seen a broken layout for many of our internal tools and products which use the o-layout component. Users of Firefox, Safari, and other browsers were not affected. In this post we'll discuss what changed in Chrome 80.
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.
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.)
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.
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.
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.
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. 🎉