the browser support is the most important thing when you need to adopt new features! Maybe that 15% of non supported browsers can represent 50% of your users. Besides that, why should I write a fallback? Do we really need to write twice the amount of code only for displaying some boxes?

This is a concern that a lot of people have about CSS Grid and my answer to that is to look at the data. If the majority of your users are coming from old browsers that does not allow you to use any new CSS feature, then by all means, stick to the tools that are suitable for you.

But for a lot of us with businesses where the majority of users come from modern browsers, then CSS Grid is a tool worth working with. Writing a fallback is important for the minority of users who still comes from old browsers. But overtime, these old browsers will be phased out and will not be maintained anymore. Writing a fallback and also using new CSS features is a way of future proofing your code. When the number of users using old browsers is so small that it just doesn't make sense to support it anymore, you can just toss the fallback code out; easier to maintain that way.

agree, but writing a fallback doesn't imply two times the amount of code? then my questions is: if you can create the same layout with some fallback techniques, why would I wrote another modern version of the layout using css grid or whatever?

Using CSS Grid is not about coding the same layout design as another fallback solution. You would want to use CSS Grid as progressive enhancement. What does that mean? It means going with a minimalistic layout design for older browsers using floats/inline blocks/etc. and go for a more sophisticated design on modern browsers using CSS grid. Layouts can get complicated based on product requirements and you cannot expect layouts to look the same on ALL browsers. This is where you wanna look up progressive enhancement techniques.

And if you have actually explored CSS Grid, you notice that the code is much simpler than any fallback layout methods such as floats or inline blocks that are not originally design to work with layouts.

And no, you do not have twice the amount of code UNLESS you are expecting your layout to look the same on all browsers. This is true if you can’t stand the idea of having a minimalist layout on older browsers or if you have some complicated product requirements that does not allow you to progressively enhance. If you want to know more about supporting older browsers and enhancing layout for modern browsers, look up “Cutting the Mustard” by Tom Maslen.

CSS Grid is just one of the tools for building layouts and no one is going to force you to use it at the end of the day and its effectiveness depends on your layout strategy.

I'm pretty sure that's very easy to build a layout with grids, although I din't played with yet. It is indeed a powerful solution my only concern was about the browser support, but as you said, the project/business requirements can have a huge impact on this. I'll take a look also at Tom's presentation. Thanks for the tip!

Interesting use of mixins there.
I had a similar approach but then realised that most of the time I would be declaring the container in the actual css without using those.
If you go deeper and start laying out boxes from the 3rd to the 8th column for example, then you'd need to create classes that say something like col--3to8 or similar, that makes the css longer as you need to take care of several screen sizes as well.

I opted for a css only declaration with a clean and tidy html in the end.

This approach is fantastic though, as it makes transitioning to css grid a breeze for bootstrap and col12 users.