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.
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.
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.
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.
>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?
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
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.
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.
First off - I liked the game. It was fun. No arguments there.
But (and nothing against the author of the game)...
I'm going to jump on the bandwagon here of others wondering just what the person or committee who thought up the API was smoking when they came up with it?
At first, it made kinda sense. Nothing too troubling.
But the deeper it went, the less it made sense. I don't have a problem with 1 vs 0 indexing (because I started coding in old-school BASIC back in the dinosaur days of microcomputing - so that doesn't bother me much).
It's just that the rest of the API seems arbitrary, or random, or maybe ad-hoc. Like there were 10 developers working on the task of implementing this, but with no overall design document to guide them on how the thing worked.
I'm really not sure why there's two (or three? or four?) different ways to express the same idea of a "span" of row or column cells, based on left or right indexing, or a span argument, or...???
Seriously - the whole thing feels so arbitrary, so inconsistent. This API has to be among the worst we have seen in the CSS world (not sure - I am not a CSS expert by any means). I can easily see this API leading to mistakes in the future by developers and designers.
We'll also probably see a bazillion different shims, libraries, pre-compilers, template systems, whatever - all working on the same goal of trying to fix or normalize it in some manner to make it consistent. Unfortunately, all of these will be at odds with one another.
I'm sure JQuery will have something to fix it (if not already). Bootstrap too.
The dumb thing is that had this been designed in a more sane fashion, such hacks wouldn't be needed.
From my understanding a lot of it has to do with needing to take localization into account. The developers aren't stupid, they are just working under more considerations than you are taking into account in your narrow worldview.
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.
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.
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.
I think these CSS learning games would work better if the game you were trying to complete was something you would actually use the technology for. For example, a game that involves building a website. (e.g. Instruct me to make the page for UX friendly by moving an element from one column to another, or adjust columns, etc.)
I would never use CSS grid to do what this game is asking me to, so even though it helps me learn the syntax and properties, it's not helping me learn how it's going to be applied to an actual website.
This is a neat game, but I have to say that the explanation of order didn't feel particularly enlightening, and I was hoping it would become clearer but it never got used again.
For all elements not explicitly positioned, sort by `order` value. If two elements have the same `order` value, sort by the order they appear in the source.
So in the game, setting the `order` of the `#poison` to any value greater than 0 (the default) will move it to the end.
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.
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.
`grid-row: -2` targets the bottom-most row, whereas I would have expected `grid-row: -1` to do so. I've never seen `-2` used to refer to the last element in a sequence. Python [1,2,3][-1] yields 3, for example.
Anybody have an explanation for this surprising behavior?
The logic goes like this: everything is 1-indexed, including the negative numbers (zero is just illegal).
1 means "the first grid line" aka the top edge of the grid , and -1 means "the last grid line" aka the bottom edge of the grid.
grid-row is a shorthand property, and giving just one number is equivalent to specifying it as grid-row-start, so your declaration is the equivalent of grid-row-start: -2
Specifying a negative counts from "the other side," but it doesn't change how the automatic span/end is calculated. It's still 1 grid-line "further" by default. This is why you need to use -2: with -1 you're saying: occupy one row starting from the far bottom edgeline of the grid, going down (meaning the first row outside the grid).
To get the last row, you want to say "start at one grid line from the bottom and go one line down," meaning you want grid-row-start: -2, or in shorthand grid-row: -2.
"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.
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.
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.
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?
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-...
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.
Not really. Flexbox is good for laying elements out along a single axis, either horizontally or vertically. Grid is good for doing true 2-dimensional layout.
You'll probably end up using both of them - grid for larger layouts and flexbox for smaller components. They work together fairly harmoniously.
awesome.
Few of the levels like level 23, 24 found them a bit difficult ,Can't find a solution. would have been great if there was a solution where i can compare my results with it.
"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.
> 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'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!
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?