"Oh no, Grid Garden doesn't work on this browser. It requires a browser that supports CSS grid, such as the latest version of Firefox, Chrome, or Safari. Use one of those to get gardening!" I am running Chrome 56 on MacOS
I don’t believe the downvotes are justified, but it the message you quoted specifies that you need to be on the _latest_ version of Chrome—which you weren't.
A lot of that is older version of Chrome (56) and iOS Safari (10.2), you can check the usage relative from the same website. Given their automatic update features, it would be changed pretty soon.
I'd guess a year or so before it's safe. A lot of smartphones (android browser, looking at you) are based on a build of chromium that's a few versions old. Edge support isn't here yet, but it's being worked on. IE11 will never support it, so if you're doing enterprise applications you might never get to use it.
You can use it with @supports and robust fallbacks now, but that does lead to writing the same layout styles twice basically. I don't know how desirable that is.
Is this like a built-in equivalent of Skeleton and similar frameworks? It's kinda cool the way it brings CSS closer to frameworks like iOS', which has built-in UI components like collection views and such that can be extended to build interfaces easily.
Kinda, but it is a lot, lot more powerful than Skeleton or any other previous CSS grid framework. The way I've heard it put is that if flexbox is what you use to do 1-dimensional layouts in CSS, then grid is its equivalent for 2-dimensional layouts.
You're halfway there. The indices are the grid lines, but they're also one-indexed. That's consistent with other parts of CSS, though it's inconsistent with the rest of the programming world.
So you have to put the rows (Y axis coordinates) first and columns (X axis coordinates) second, i.e. the opposite of how it's done in every other situation - i.e. draw_rect(start_x, start_y, end_x, end_y)
(1, 1, 3, 4) in every other language would draw a box 2 wide and 3 high, but in css grid it selects an area 3 wide and 2 high.
Also the fact it uses 'row' and 'column' to describe the gridlines rather than the actual rows and columns irked me.
Makes more sense, I always forget, which is why I looked it up, but apparently I either misread something or I can't remember it for longer than 2 or 3 seconds.
Indexing into 2D containers is often an exception to the "x, then y" rule; indexes are very often specified with "row, then column"[1]. It's true that this is different to Cartesian coordinates, but grid cells aren't points or locations on a Cartesian plane, they're members of a 2D container: the grid.
This is also consistent with how tables are typically laid out in HTML (cells/columns inside rows). Considering that grids are supposed to be the modern/responsive/semantic/etc. equivalent of table-based layout, the conventions here are not terribly surprising.
For example if you have 1fr 1fr 1fr that will give you three equally large columns that take up the rest of the space, but you can also use 0.33fr 1fr 1fr which gives you one column that's one third the size of the other two.
>Oh no, Grid Garden doesn't work on this browser. It requires a browser that supports CSS grid, such as the latest version of Firefox, Chrome, or Safari. Use one of those to get gardening!
Is Chrome 56 so outdates that this grid box doesn't work with it?
Or, perhaps, does the game only check if I'm running the "latest" version, regardless of which browsers do or do not actually work with Grid Garden?
Edit: Oh, wow, 56 is that outdated. Talk about cutting edge technology?
Grid shipped in Chrome, Firefox, and Safari in the last month: it really does mean the latest version, currently. Anything older doesn't have Grid support (okay, ignoring IE/Edge and their prefixed implementation of ~2010 draft which has little in common with what has now shipped elsewhere).
After everyone else has already shipped. Typical. Better late than never I guess.
At my work we have stopped testing on MS browsers. The higher ups have decided that it's not worth the time to support any version of IE and Edge. If it works on those browsers, great. But if it doesn't we won't do anything to address it. We started this about a year ago and so far nobody has said anything. Of course we are fortunate that we are not selling anything so we don't have to worry about things like lost sales.
This just made me realise how difficult it is to check my version.
1. Hamburger menu -> hunt for the 'about' -> version 54. Great!.. or..not? Is that old?
2. Google "google chrome current version" -> skip past a few 3rd party sites detailing how to find the 'about' page -> Choose what I assume is the product page: https://www.google.com/chrome/
3. No version number in this page. In fact, no mention of browsers at all! The page appears to be an advert for chromebooks. In the bottom left, in the site-navigation footer there is 'browser' under 'products'.
4. Ah, this is more like it. This looks like your typical marketing website/landing page - fancy feature list, big download button, but... no version number? -> Click "Download"
5. A terms of service and a download button? What version am I going to "Accept and Install"?? Filename it wants to download is "google-chrome-stable_current".. great! Is that the version I currently have?
Step 1 will attempt to update and tell you what the new version is. It will also tell you you are out of date. Recalling from memory, it looks like this:
Google Chrome is out of date.
Version 54.0.239.240 (Official Build) (##-bit)
Update available: Version 57.0.2987.133
56 is latest stable, though I think 57 is rolling out. From quick search, 57 seems to be the one that has added support for CSS Grid (which is very new). So it's not so much that your browser is outdated, but rather that this feature is fresh out of the oven.
I haven't stepped up my styling game in awhile. Would anyone like to explain to me how css grid is better than say flexbox, or how the two are different?
CSS Grid complements Flexbox by providing two-dimensional grid-based layout capabilities. Flexbox can only lay things out along one axis, and although you can do a lot of things that look a bit grid-like with it (usually involving multiple flex containers), it doesn't actually think in grid terms to do it.
So with CSS Grid and a few media queries it's pretty trivial to have a full-on, really robust grid layout on a desktop site and have it gracefully reflow itself into a column layout to render on a phone, with source element ordering being completely irrelevant.
Or at least, it will be when the mobile and desktop browser support picture for it is good enough.
Both Jen Simmons and Rachel Andrew have lots of good resources for understanding the new CSS layout techniques. This article of Rachel's is a year old, but will still give you a good understanding of the differences between the two: https://rachelandrew.co.uk/archives/2016/03/30/should-i-use-...
"Oh no, Grid Garden doesn't work on this browser. It requires a browser that supports CSS grid, such as the latest version of Firefox, Chrome, or Safari. Use one of those to get gardening!"
Oh well, maybe in 5 years time I can make use of this.
It's been supported (albeit prefixed) in IE since v11 (pre-11 versions are <<1% these days), which makes Android browser the only significant current version lagging.
In fact, one could observe that Chrome is the browser "holding this feature back", given the very high percentage of people on version 56 of Chrome (which will decline very rapidly given Google's aggressive browser updater).
TL;DR: if you start using CSS Grid today, it'll probably be widely supported by the time you commit your code.
I'm just going on StatCounter global stats, which is what caniuse reference. I'm sure usage within certain geographical areas or certain demographics may be higher or lower, but in those cases you're probably taking a more careful approach to a wide selection of modern browser features already anyway.
For the average case (or probably the more common case - not everyone works in b2b) CSS grids are going to be fine to use almost immediately.
Sadly it's really hard to convince corporate entities whose web products are used by other corporate entities that they don't still need to support IE8.
Even more sadly, sometimes they really do still need to support IE8...
Although actually I haven't had to do something for <IE10 for a while now. Woohoo!
> It's been supported (albeit prefixed) in IE since v11 (pre-11 versions are <<1% these days), which makes Android browser the only significant current version lagging.
The IE/Edge implementation is fairly different at this point as the spec has changed quite a lot. It probably isn't too worthwhile considering.
I love contrast rebellion (aside: tool to check your contrast game is http://leaverou.github.io/contrast-ratio/), but I believe the author of the website intended it to be so as to draw attention to make your code stand out. However, I agree the contrast isn't high enough
Yup that's the idea. Trying not to overload people focusing on a single new property, while still giving the full context of the ruleset. I will see about bumping up the contrast a bit.
Is there a library or babel like transform on server side which can enable this feature in older browsers? Most clients wont have this enabled for some time now.
I think in most cases the polyfills end up being pretty expensive to use. I know that's the reason why I'm not able to use a flexbox polyfill at work for IE9 support, though not sure if this particular feature set would be as bad to implement.
> I wouldn’t say this polyfill is slow by any measure, but your mileage may vary on mobile devices. My advice would be to use the polyfill only on tablets and desktops at the moment, after you have tested the compatibility and performance extensively on a representative number of devices.
Also, there are js layout libraries used with similar functionality, so one can expect that it is possible to implement this feature with the same efficiency.
Its author, François REMY, is now on the layout team working on Edge. I wouldn't at all be surprised if he was one of the people on the Edge team working on updating their implementation.
There are definitely cases for which the polyfill is likely going to be asymptotically worse than a native implementation, though there will also be plenty of simple cases where the efficiency loss is relatively small.
This is pretty cool. One thing I notice is that when you submit an answer, it shakes the editor box. This usually has a "you did something wrong" connotation (ie if you type a bad password when signing into a mac.)
That must just be a mac thing... cant recall seeing it in a native ui, only games. Although at least a few wm have it, most devs have the good sense not to use it, much like the blink flag of yore.
1. Grid columns and rows are 1 indexed instead of 0, ensuring a coming decade of mistakes due to the mismatch with Javascript (and, y'know, everything else) conventions for arrays.
2. Grid extents use the "one more than end" convention instead of "length", which is sorta confusing. But then they call it "end", which is even more so.
(edit) more:
3. grid-area's four arguments are, in order (using normal cartesian conventions to show how insane this is): y0 / x0 / y1 / x1. Has any API anywhere ever tried to specify a rectangle like this?
> Grid columns and rows are 1 indexed instead of 0, ensuring a coming decade of mistakes due to the mismatch with Javascript (and, y'know, everything else) conventions for arrays
but consistent with the rest of CSS IIRC, for example nth-child starts at one
True enough, but that causes much less damage because except in the rarest situations, you never write code to do random access to an array of children, you just iterate over them without using indices at all.
This is opening up a situation where you have a 2D Javascript array for a model and a bunch of components in the layout (a chessboard, imagine). And the coordinates won' t match!
None of that is like dealing with 0/1 arrays. Almost everything you encounter in real life starts with 1, not 0. If anything it's the 0 based array that should be consider "wrong" and the cause of so many errors. But we use 0 based arrays because of the C/assembly legacy where the 0 means the location of the array with a 0 offset.
`order` is a little bit different though as it doesn't set the position. Instead "Elements are laid out in the ascending order of the order value". So an element with order: 1 will move to the end in a group of elements with no order defined, similar to z-index I guess.
Lots of languages (c.f. python) do negative indexes with the first one starting from zero. The last element is indeed -1, because the element selected is simply the array-size-modulus of the index. It wraps exactly how you expect, and a few tricks use this.
CSS grid's negative indexes, hilarious, don't even get this right. If the first element is 1 then the last must be 0, right? No, it's not. Nor is it -1. It's negative two. Don't ask. I don't know.
You're not wrong on the first point, but I imagine consistency with the front and back of the index was on the spec designers minds.
I do have to point out that your second point is not correct. Remember it's not grid areas, it's grid dividers. So the final grid line <strong>is</strong> in fact -1.
Slashes are hidden all over the place in CSS shorthand properties (for example, you can use a slash to specify both font-size and line-height together in a "font:" declaration).
In my experience CSS is often written by non-programmers. So maybe they were assuming that CSS developers wouldn't be familiar with starting counting at 0? That the y/x instead of x/y thing is bizarre. Even elementary or middle school kids learn it as x/y.
138 comments
[ 3.0 ms ] story [ 49.7 ms ] threadOne more excuse not to use HTML tables in our toolbox
It said I wasn't on Chrome... it should have said, "You're on a version of Chrome that doesn't support this..."
Telling me I wasn't on Chrome was a bug... or at best really poor UX.
[0]: http://caniuse.com/#feat=css-grid
You can use it with @supports and robust fallbacks now, but that does lead to writing the same layout styles twice basically. I don't know how desirable that is.
It ain't perfect, but it works pretty decently.
| <- 0 1 -> | <- 1 2 -> | <- 2 3 -> |
That makes more sense.
It's just that C's heavy influence resulted in most languages with arrays being 0 indexed.
This made me uncomfortable though (about CSS grid, not about the game):
grid-area: row start / column start / row end / column end;
So you have to put the rows (Y axis coordinates) first and columns (X axis coordinates) second, i.e. the opposite of how it's done in every other situation - i.e. draw_rect(start_x, start_y, end_x, end_y)
(1, 1, 3, 4) in every other language would draw a box 2 wide and 3 high, but in css grid it selects an area 3 wide and 2 high.
Also the fact it uses 'row' and 'column' to describe the gridlines rather than the actual rows and columns irked me.
I'm sure I'll get over it!
Why isn't 0 the left most line as column and the top most line as row. That would make so much more sense, IMO.
What could be the reason they haven't done it this way? Or are 1 based arrays normal here?
There was another one for a different CSS thing (that I'm blanking on) that was based on the word "love" or something like that...
1: https://en.wikipedia.org/wiki/Index_notation#Two-dimensional...
That said, I don't tend to use the shorthands.
For example if you have 1fr 1fr 1fr that will give you three equally large columns that take up the rest of the space, but you can also use 0.33fr 1fr 1fr which gives you one column that's one third the size of the other two.
I'll work on improving the explanation of level 21 and fr units in general.
The gotcha is that actual value in fractional units is irrelevant as long as you defined the right number of columns.
Maybe showing more context in how the grid containers are defined?
my solution to level 21 was one 50px column, three columns taking equal share of remaining space, one 50px column.
Is Chrome 56 so outdates that this grid box doesn't work with it?
Or, perhaps, does the game only check if I'm running the "latest" version, regardless of which browsers do or do not actually work with Grid Garden?
Edit: Oh, wow, 56 is that outdated. Talk about cutting edge technology?
https://twitter.com/MSEdgeDev/status/848997331567497216
At my work we have stopped testing on MS browsers. The higher ups have decided that it's not worth the time to support any version of IE and Edge. If it works on those browsers, great. But if it doesn't we won't do anything to address it. We started this about a year ago and so far nobody has said anything. Of course we are fortunate that we are not selling anything so we don't have to worry about things like lost sales.
1. Hamburger menu -> hunt for the 'about' -> version 54. Great!.. or..not? Is that old?
2. Google "google chrome current version" -> skip past a few 3rd party sites detailing how to find the 'about' page -> Choose what I assume is the product page: https://www.google.com/chrome/
3. No version number in this page. In fact, no mention of browsers at all! The page appears to be an advert for chromebooks. In the bottom left, in the site-navigation footer there is 'browser' under 'products'.
4. Ah, this is more like it. This looks like your typical marketing website/landing page - fancy feature list, big download button, but... no version number? -> Click "Download"
5. A terms of service and a download button? What version am I going to "Accept and Install"?? Filename it wants to download is "google-chrome-stable_current".. great! Is that the version I currently have?
Unsurprisingly wikipedia has all the information I wanted: https://en.wikipedia.org/wiki/Google_Chrome_version_history
But my steps were:
1. Hamburger, Help, About. Says my Chrome is out of date.
2. Click update button.
3. Click restart.
So with CSS Grid and a few media queries it's pretty trivial to have a full-on, really robust grid layout on a desktop site and have it gracefully reflow itself into a column layout to render on a phone, with source element ordering being completely irrelevant.
Or at least, it will be when the mobile and desktop browser support picture for it is good enough.
Jen's got lots of great links here: http://jensimmons.com/post/feb-27-2017/learn-css-grid, including thoughts about how we're going to be able to use all these new layout techniques in ways both new and old.
It's an exciting time to be designing on the web :->
Oh well, maybe in 5 years time I can make use of this.
It's been supported (albeit prefixed) in IE since v11 (pre-11 versions are <<1% these days), which makes Android browser the only significant current version lagging.
In fact, one could observe that Chrome is the browser "holding this feature back", given the very high percentage of people on version 56 of Chrome (which will decline very rapidly given Google's aggressive browser updater).
TL;DR: if you start using CSS Grid today, it'll probably be widely supported by the time you commit your code.
I wish, I guess you don't do much enterprise intranets.
For the average case (or probably the more common case - not everyone works in b2b) CSS grids are going to be fine to use almost immediately.
Even more sadly, sometimes they really do still need to support IE8...
Although actually I haven't had to do something for <IE10 for a while now. Woohoo!
The IE/Edge implementation is fairly different at this point as the spec has changed quite a lot. It probably isn't too worthwhile considering.
There is an alpha polyfill effort here. https://github.com/FremyCompany/css-grid-polyfill
Regarding speed, here's the author's take.
> I wouldn’t say this polyfill is slow by any measure, but your mileage may vary on mobile devices. My advice would be to use the polyfill only on tablets and desktops at the moment, after you have tested the compatibility and performance extensively on a representative number of devices.
Also, there are js layout libraries used with similar functionality, so one can expect that it is possible to implement this feature with the same efficiency.
There are definitely cases for which the polyfill is likely going to be asymptotically worse than a native implementation, though there will also be plenty of simple cases where the efficiency loss is relatively small.
1. Grid columns and rows are 1 indexed instead of 0, ensuring a coming decade of mistakes due to the mismatch with Javascript (and, y'know, everything else) conventions for arrays.
2. Grid extents use the "one more than end" convention instead of "length", which is sorta confusing. But then they call it "end", which is even more so.
(edit) more:
3. grid-area's four arguments are, in order (using normal cartesian conventions to show how insane this is): y0 / x0 / y1 / x1. Has any API anywhere ever tried to specify a rectangle like this?
but consistent with the rest of CSS IIRC, for example nth-child starts at one
This is opening up a situation where you have a 2D Javascript array for a model and a bunch of components in the layout (a chessboard, imagine). And the coordinates won' t match!
What kind of programmer can't deal with properly escaping input under the control of the user?
What kind of programmer can't deal with keeping array indexes in bounds?
(tl;dr: you. And me.)
Example: https://jsfiddle.net/5uvpco6e/
CSS grid's negative indexes, hilarious, don't even get this right. If the first element is 1 then the last must be 0, right? No, it's not. Nor is it -1. It's negative two. Don't ask. I don't know.
I do have to point out that your second point is not correct. Remember it's not grid areas, it's grid dividers. So the final grid line <strong>is</strong> in fact -1.
See my very hasty little Codepen: https://codepen.io/jodi/pen/ZeNRJZ
* grid-column-index-start
* grid-column-index-end
* grid-column-length
PS: I have to say though that this grid thing is fucking awesome, and this game to learn this grid thing is fucking amazing as well.
I've being coding HTML since 2001, and have started using CSS in 2005. I can say that I've been dearly missing tables until now.
Not for rectangles, but the closest example of Y/X I can think of is GW-BASIC's "locate". It gets row number first and column number next. I.e Y/X