Is it time to use CSS Grid Layout?

I am learning to fly light aircraft. It distracts me from computers. Recently, I could not manage to keep Cessna-150 at low altitude when we were approaching Bristol Airport. I was literally sucked into the cloud by an ascending stream. My flight instructor said: "It's not your fault, but your problem." He meant that I had to keep my height, even if something worked against me. I needed to find out what the situation was like and learn how to cope with it while piloting.

After landing, I thought that the phrase “this is not your fault, but your problem” is perfect for almost any situation. In this article, I reveal the theme of support for older browsers when using new technologies like CSS Grid Layout. We, the developers, are often shy of discussing browser support with customers and colleagues, as if we are to blame for the fact that sites do not look in IE9 exactly the same as in the latest Firefox or Chrome. It's time for us to accept that this is not our fault. But the duty to deal with it properly, for the benefit of everyone, is in many ways our problem.

Grids are completely new! Are they surely awful browser support?

CSS Grid Layout has been working in Chrome, Firefox, Opera and Safari since March of this year. Microsoft Edge recently released a pre-build with grids over the flag. At the time of publication of the article, Can I Use shows that global support for CSS Grid Layout is 65.64%, or 70.75%, if you add a version with a prefix from IE10-11 and the current Edge. Until now, we have not seen that such a grandiose novelty was introduced so quickly. It is not surprising that people do not realize how many visitors will have support.

It was not worth mentioning this, but I still say that your numbers may be more or less depending on the audience of your site. But if you are doing a new site right now, there is a good opportunity to take advantage of CSS Grid Layout.

Why should I use grids?

As I explained in a previous article , CSS Grid Layout makes it possible to make a two-dimensional layout without additional markup for wrapping rows. Since the layout is two-dimensional, the elements in it can span several rows in a reliable and predictable way.

You can achieve some nice design effects. For example, so that the elements in the design were at least a certain height, but stretched with a higher content - as in this example .

You can easily alternate fixed-width elements with flexible elements using the fr unit in the grid. This makes it easier to deal with layout elements that must maintain a fixed size.

You can redefine the layout at the container level , which makes responsive design an elementary task, and customize the design individually for different window sizes.

Elements can be superimposed on each other , they obey the z-index property, so that different elements can be placed in the same grid cells, which gives a lot of space for creativity.

What about non-supported browsers?

CSS has a solution for you. First, the specifications of grids and flexboxes already define exactly how these specifications override the old layout methods.

Thus, if you want to use floats, inline blocks, multi-column layout, flexboxes, or even display: table as a foldback for your layout on grids, everything is already provided in the specification. You can redefine these methods in a reliable and predictable way. I made a cheat sheet explaining the folbacks . Some of them are mentioned in my report, recorded at the Render conference earlier this year.

CSS also has a feature check . It has a truly wonderful browser support, and what is especially good about it is that you don’t need to worry about browsers without it. There are no browsers that support grids and do not support supports . Here is all you need in the CSS file:

1. Folback css
2. CSS for grids

All browsers will understand styles for folback. Those that do not support grids will stop there. And those that support will use styles for grids, and thanks to the rules that are described in the specification and explained in my cheat sheet , much of the folbechnom behavior will be reset.

As a rule, in the foldback styles, you will have something that “leaks” into the layout on the grids. Often this is the width of the elements, because in the old layouts you have to set the width to imitate something similar to the grid. Therefore, we use a simple supports directive, check for grid support, and in it, perhaps, return the auto value to the width. In general, there you can do anything for the grid version without fear that old browsers will see it.

We write CSS with CSS. No polifilov, no hacks. Everything is strictly according to the specification.

But folbacks mean I write the layout twice!

This is only true if you in your work proceed from the fact that sites should look the same in all browsers. And you know what? This is no good.

Here is an article that I wrote in 2002. In 2002, people were afraid to learn the layout on CSS, because it would mean that their sites would not be “equally displayed” in all browsers. But I made websites with CSS, trying to figure out how to do this in the best way possible, and taught other people what I learned myself. From the very opening of his own company, making websites for customers who demand that everything work in Netscape 4. I have been doing this throughout my career. I understand compatibility issues for 20 years. Now I am making a product with an interface that should work right up to IE9 . It was not my fault that these old browsers existed, but my problem and my work over the years has been to cope with them.

If your site really needs to look the same in all browsers (whatever that means to you), you cannot use anything that can be done only by grids. In this case, do not use grids! Use the Grid Layout if you want to achieve something that cannot be done normally with old technologies. Then make a folback, which can be used in less advanced browsers, and don't worry about doing exactly the same. The power of grids is that you can do things with them that were previously impossible. Use them for this , not for recreating your old designs.

I want a magical polyfil!

If you globally back up the entire layout with a polyfill, it will be a nightmare for users. If you implement what grids do, using JS tools, it will all be terribly slow. Loading the page in the end will look awful "jerky." It is much better to give these old browsers a simpler version, adapted to their capabilities, than trying to force Grid-layouts into them with scripts.

Attempts to make polifil can significantly delay your development and testing, and for a smaller group of users. Again, if the same look is for everyone - ideal for your site, I would not advise using grids right now. You will have to accept that all those users who could enjoy the grid layout will be deprived of it because of the presence of old browsers in the world.

That's what it means to develop for the web.

Work on the web is unthinkable without things that do not yet have full support. Such is the nature of the industry in which we operate. Your job is to grope the inevitable technological compromise for each project.

Your job is to learn new things and advise your client or management on the best way to achieve their business goals using all available technologies. And for this you must first study these new items yourself. Then you can advise them on exactly which compromises to make. To guarantee a uniform design at the price of additional markup, extra development time, or a forced restriction of convenience for all browsers? Or a simplified layout for IE9, which will reduce development time, and a faster site with new technologies in the end? If you understand the pros and cons of each option, you can defend your arguments.

If the use of new technology does not provide absolutely no benefits, then do not use it. But if your client wants something that only makes sense on new technologies like grids, or what can be done quickly on grids, and without them you have to suffer for a long time, you have a lot of ways to explain possible compromises, their benefits and price.

Explain them to how much development time, now and in the future, can be saved due to less complexity.

Explain them to the fact that the designers have created a stunning design that is simply impossible to reliably impose without grids.

Explain their speed, in many cases, this argument will work, because you can get rid of the cumbersome framework, without which it would not do otherwise.

All this we get in exchange for the requirement to give a simplified layout to old browsers. But this does not mean "no layout." Be prepared to explain that the introduction of grids into browsers is not like the introduction of anything in CSS that we have seen before. Implementations are already compatible more than ever. Edge has already updated grids for the flag in the pre-assembly. Browsers without support disappear much faster than one would expect from past experience.

When you are armed with all the necessary information about the price of the issue, the discussion becomes very simple. That old browsers exist is not your fault. Do not start these discussions as if you failed the task to ensure that the site looked the same in all browsers released over the past 10 years, using technology that does not even have a year. This is not your fault, but your problem. Your problem, your duty as a web professional, is to put yourself in an environment in which you can choose the right course of action for each project.

That's what we're going to

The transition from tabular layout to CSS has changed the look of the web. He led us from pixel-by-pixel-cut images to something more flexible, with text at the base, less like print design. For the past 15 years, the look of the web has been dictated by the technical limitations of CSS. I think that our new layout methods - grids, flexboxes and stuff like web shapes - will change its look again. But we must let this happen, we must allow ourselves to experiment, learn and create new things.

We can do this only if we are ready to show the benefits of these methods to the people for whom we make websites and applications. We can do this only if we discard our prejudices about the web, browsers, and the pace of implementation, at least until we learn all these things. Only then can we make the right decision for each project. There will never be a clear "or - or", there will always be compromises. Our job is to cope with this, as always.