My biggest problem with CSS Grid is compatibility. We're still not in a state where most devices can view it properly, not only talking about old browsers but mini-browsers like opera mini on phones still don't support it and if I'm making a second structure just for those then I'd rather build only one for all or most.
Some statistics on user browser usage would change my mind though, since I love it, I even made an atomic responsive CSS Grid library I'd like to share.
That's a super valid point, It was part of part 4 on the video series, but maybe I can delve in a bit here!
Based on caniuse.com stats, we are at 93.83% covered in term of availability, with the notable exceptions of some mobile browser.
The easiest way to look at it is in the cost/benefit trade off:
to me CSS grid help me maintain designs over the years and reduce complexity in my front end pretty greatly for over 90% of my users. On the same side it might harm 10ish% (even though, in actual stat it's way less because my audience is skewed toward earlier adopters).
My trade off is to test for Grid support in CSS media queries, and if it is not present, I provide a mobile friendly layout (most of non-gridable browser are mobile browsers anyway). That mobile layout is actually the one that drives the pure HTML markup, even if I would like to keep it as semantic as possible.
The grid-able browser gets the "more interesting" layout. So far, I haven't had any client complain about this approach
I don't know, in that case I'd just rather do a single template using Flexbox so I don't have to support two different templates for achieving the same... and I mean exactly the same thing.
Maybe for very complex template structures it would be much better to go with Grid right now, but I think I'll stay with flexbox for, at least, the end of the year, but only for websites.
For hybrid apps, as popular frameworks use chromium based webview (at least electron and ionic, which I use), I'm currently working with Grid. It's way too convenient when I don't have to think about compatibility.
I'd still would take it into account in sites that are mainly informative at least for the rest of the year.
For web apps, most if not all users will see it from a mid and high end phone or a computer, so I'd still use it since those browsers are only downloaded on very low end phones for memory space saving.
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
While it's true that a not-insignificant portion of users (~7-10%, it seems) still don't support CSS Grid, it's also very doable to write fallback CSS targeting those older browsers. This doesn't mean porting your CSS Grid design exactly back to older standards; instead, it means giving users in older browsers a clean, readable, functional layout that will get the job done without getting in their way, but that's about it.
In fact, I can't recall who, but I heard a talk or a podcast episode where someone recommended falling back to the mobile layout. You're probably writing one anyway, and it's often much simpler than the large-screen layout while still maintaining full functionality (or it should be, and if it's not, fix that first), so why not use it here?
One very handy tool for allowing Grid and fallback CSS to peacefully coexist is to wrap all CSS Grid code in @supports (display: grid) { ... }. This rule will only be recognized and run by browsers with Grid support, and this lets you write whatever non-grid-specific CSS you need in support of the Grid layout (margins and padding and whatever else) without worrying that you'll break the fallback layout.
I haven't use "support" but I may start looking at it, since I'd rather just work on the lesser common denominator I'll be targeting so I just work once.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My biggest problem with CSS Grid is compatibility. We're still not in a state where most devices can view it properly, not only talking about old browsers but mini-browsers like opera mini on phones still don't support it and if I'm making a second structure just for those then I'd rather build only one for all or most.
Some statistics on user browser usage would change my mind though, since I love it, I even made an atomic responsive CSS Grid library I'd like to share.
That's a super valid point, It was part of part 4 on the video series, but maybe I can delve in a bit here!
Based on caniuse.com stats, we are at 93.83% covered in term of availability, with the notable exceptions of some mobile browser.
The easiest way to look at it is in the cost/benefit trade off:
to me CSS grid help me maintain designs over the years and reduce complexity in my front end pretty greatly for over 90% of my users. On the same side it might harm 10ish% (even though, in actual stat it's way less because my audience is skewed toward earlier adopters).
My trade off is to test for Grid support in CSS media queries, and if it is not present, I provide a mobile friendly layout (most of non-gridable browser are mobile browsers anyway). That mobile layout is actually the one that drives the pure HTML markup, even if I would like to keep it as semantic as possible.
The grid-able browser gets the "more interesting" layout. So far, I haven't had any client complain about this approach
I don't know, in that case I'd just rather do a single template using Flexbox so I don't have to support two different templates for achieving the same... and I mean exactly the same thing.
Maybe for very complex template structures it would be much better to go with Grid right now, but I think I'll stay with flexbox for, at least, the end of the year, but only for websites.
For hybrid apps, as popular frameworks use chromium based webview (at least electron and ionic, which I use), I'm currently working with Grid. It's way too convenient when I don't have to think about compatibility.
There you go, shows mobile browsers only. Opera Mini/Mobile currently has a market share of 2.1% (slightly falling too).
Well, that's it, you're right.
I'd still would take it into account in sites that are mainly informative at least for the rest of the year.
For web apps, most if not all users will see it from a mid and high end phone or a computer, so I'd still use it since those browsers are only downloaded on very low end phones for memory space saving.
There is a growing mantra in the CSS world: Websites don't need to look the same in every browser! (e.g.: dowebsitesneedtolookexactlythesame...)
While it's true that a not-insignificant portion of users (~7-10%, it seems) still don't support CSS Grid, it's also very doable to write fallback CSS targeting those older browsers. This doesn't mean porting your CSS Grid design exactly back to older standards; instead, it means giving users in older browsers a clean, readable, functional layout that will get the job done without getting in their way, but that's about it.
In fact, I can't recall who, but I heard a talk or a podcast episode where someone recommended falling back to the mobile layout. You're probably writing one anyway, and it's often much simpler than the large-screen layout while still maintaining full functionality (or it should be, and if it's not, fix that first), so why not use it here?
One very handy tool for allowing Grid and fallback CSS to peacefully coexist is to wrap all CSS Grid code in
@supports (display: grid) { ... }. This rule will only be recognized and run by browsers with Grid support, and this lets you write whatever non-grid-specific CSS you need in support of the Grid layout (margins and padding and whatever else) without worrying that you'll break the fallback layout.I haven't use "support" but I may start looking at it, since I'd rather just work on the lesser common denominator I'll be targeting so I just work once.