Perch, Patterns and Old Browsers

We chose Fractal because: ▸ It didn’t assume the shape of our project - no assumption of a ‘homepage’ for example ▸ It left the organisation of components and naming up to us ▸ It didn’t dictate which build tools were used for the end CSS ▸ Allowed documentation to be stored alongside patterns
▸ Could export to HTML in order that we could make it available online Fractal was in a reasonably early stage itself when we selected it, however we were comfortable working with something that might change and it seemed to ﬁt our needs far more neatly than anything else we had looked at, so I made a start by adding all my existing bits and pieces of HTML to the system.

I’m going to talk a bit about some of the things we learned as we did so.

Perch supports right back to IE9.

supports doesn’t mean ‘looks the same’ The Perch UI needs to work in the terrible old browsers that our customer’s clients use. We could dictate “latest browser only” which would be fair enough for the people building sites with Perch. However a big selling point of Perch is that it reduces friction between end client and web designer. Preventing clients from editing in an older browser is going to result in calls to their web designer asking why things don’t work.

That said as a small team, and one that wants to take advantage of newer CSS, we also don’t want to ﬁnd our development held back by trying to make everything work in exactly the same way on older browsers.

So we take an approach of “has to work on the hotel computer” for IE9 and 10. Meaning that you should be able to edit your site without a problem from a terrible computer in your hotel etc. However the full experience will be available in more modern browsers and from IE11 up. As we rely heavily on ﬂexbox in the Perch UI (we shipped before Grid was available), we need to deal with versions of IE that use old ﬂexbox and also IE9 with no ﬂexbox.

.wrapper { display: flex; flex-wrap: wrap; } .wrapper { display: grid; grid-gap: 10px; margin: 0 auto; grid-template-columns:
repeat(auto-fill, minmax(200px, 1fr)); grid-auto-rows:
minmax(150px, auto); } .panel { margin-left: 5px; margin-right: 5px; flex: 1 1 200px; } .tall-panel { grid-row-end: span 2; } @supports (display: grid) { .wrapper > * { margin: 0; } } No Grid? Use Flexbox as a fallback So I’m pretty much able to rely on the fact that if a ﬂex item becomes a grid item it loses its ﬂex properties, so as long as I declare display ﬂex before display grid, if our browser doesn’t support grid it will ignore the grid value of display and make the child items of wrapper ﬂex items. So the ﬂex properties on panel will apply to set a width on the panel.

If the browser supports grid then the items will become grid items. The ﬂex property is ignored as the sizing is now deﬁned by the grid container.

In my feature queries all I need to do is remove the margin if the browser supports grid, as in grid layout we can use grid gap.