<\/p>\n\n\n\n
Grid garden (learn grid)<\/a><\/p>\n\n\n\n Grid in IE10\/11<\/a> Note CSS Grid is not used in Bootstrap. So you probably want to do this only if you are not<\/em> planning to use the BS4 grid solution.<\/p>\n\n\n\n Try this in To:<\/p>\n\n\n\n But make sure you\u2019re familiar how it works with IE11\u2013it\u2019s not necessarily going to be a plug and play solution. Start here 13<\/a> and here 6<\/a>.<\/p>\n\n\n\n <\/p>\n\n\n\n Even Superman can\u2019t always save everyone and Autoprefixer is no \ndifferent. While Autoprefixer is able to cut down on a lot of the \nworkload involved in making our grids IE-compatible, it can\u2019t fix \neverything. It can only translate things that IE can understand. These \nare the many critical things that you need to be aware of if you don\u2019t \nwant to open the site up in IE one day and have it blow up in your face.<\/p>\n\n\n\n As you may have seen in that last example, Update:<\/strong> The That isn\u2019t the only problem around using Autoprefixer adds If you try to use That explains Rows and columns in CSS grid default to a value of Well my inquisitive friend, I explained in Part 1<\/a> that So that explains why Autoprefixer doesn\u2019t support Not really. When you set Since the height of a typical grid is the same height as its content, in most cases, I really can\u2019t say this enough. The most important thing to remember when using CSS grid in IE is that everything<\/em> must be placed manually<\/em>.\n The instant you start thinking about using auto-placement is the \ninstant your site blows up in IE. I have a method for dealing with grids\n that have an unknown number of cells in them. I\u2019m covering that in Part\n 3 of this series. The main thing to know right now is that if you want \nto use CSS grid in an IE-friendly way, you should only ever use it if \nthere are a known number of cells for a known number of rows and \ncolumns.<\/p>\n\n\n\n It\u2019s this lack of auto-placement in IE that makes having access to \ngrid areas through Autoprefixer such a blessing. Instead of having to \ncalculate all of the coordinates manually, you can instead name each \ncell and then let Autoprefixer do the math for you. When using media \nqueries, you only need to redefine the grid template and autoprefixer \nwill recalculate all of the coordinates for you. You rarely have to do \nany column or row counting. It\u2019s great!<\/p>\n\n\n\n Update:<\/strong> This section is now out of date. Autoprefixer 9.3.1 supports duplicate area names. Read more about it in Part 4<\/a> of this series.<\/p>\n\n\n\n The ability to use Here is a small example. Early in the stylesheet, Grid Alpha has Modern browsers know exactly what column to place the grid cell in \nbecause they have access to the DOM. If the cell is placed inside Grid \nAlpha, it will go in the first column. If it is placed in Grid Beta it \nwill go in the second column. Autoprefixer can only read your CSS. It \nhas no idea if the grid cell is placed in Grid Alpha or Grid Beta. All \nit knows is that the grid cell needs to be placed in the “echo” area. \nAutoprefixer resolves this conundrum by going with whichever one came \nlast in the stylesheet. In this case, Autoprefixer will honor Grid \nBeta’s This also means that you can\u2019t really use the strategy of giving a \ncomponent a single designated area name that is repeatedly referenced. \nReferencing that area name in more than one The easiest way to ensure that each area name is unique is adopting a BEM<\/a> style approach to naming the areas.<\/p>\n\n\n\n This can be pretty verbose if there are lots of columns and rows. You\n might want to shorten it down to an abbreviation instead. Of course, \nthe less verbose your area names, the more chance there is of a \nconflict.<\/p>\n\n\n\n There is one major exception. Grid areas in media queries are allowed\n to be duplicates of other areas as long as the area names defined in \nthe media query are targeted at the same element<\/em>. Without this \nexception, it would be impossible to change the grid areas based on \nscreen size. The main thing to remember is that each grid has to have \nits own set of unique area names that must not be shared with any other \ngrids.<\/p>\n\n\n\n There are only two properties in IE\u2019s implementation of CSS grid that will help you span multiple columns. The main one being In modern browsers, you have access to far more options.<\/p>\n\n\n\n Out of the modern ways to span multiple cells, Autoprefixer fully \nsupports the following. Feel free to use any of these methods as much as\n you like:<\/p>\n\n\n\n Specify a starting line and the number of lines to span (similar to IE):<\/p>\n\n\n\n Specify an end line, then span backwards:<\/p>\n\n\n\n Specify a starting line and an end line directly:<\/p>\n\n\n\n Specify only a number of cells to span using Specify only a starting line:<\/p>\n\n\n\n Now this is where Autoprefixer reaches its limit. The following methods are supported in modern browsers but are not<\/em>\n supported by Autoprefixer. This is mainly due to Autoprefixer having no\n idea what grid the grid cell belongs to since it can only base its \ndecisions on what is in the stylesheet.<\/p>\n\n\n\n Specify a starting line and how many lines from the end of the explicit grid to span:<\/p>\n\n\n\n Specify both the start and end line from the end of the explicit grid:<\/p>\n\n\n\n Specify only how many lines to span using the shorthand syntax (issue in GitHub<\/a>):<\/p>\n\n\n\n Specify only a backwards span (IE can\u2019t span backwards):<\/p>\n\n\n\n Specify only an end line (IE doesn\u2019t understand So, basically avoid counting backwards from the end of the grid and you\u2019ll be fine. \ud83d\ude0a<\/p>\n\n\n\n One of the cool features of modern grids is giving grid templates \nline names. Instead of using numbers to reference a line, you can give \nthe line a name and reference that instead. Since Autoprefixer supports \ngrid areas, you would think that they would also support line names. \nUnfortunately, that isn’t the case. As of version 8.6.4, Autoprefixer \ndoes not support line names (at the time of writing). Don’t worry \nthough! It’s not that it is impossible to support (at least not \nentirely), it just hasn’t been a high priority for them. If you love \nusing line names in your grids then let them know about it in the GitHub issue for it<\/a>.\n Post your use cases and it will surely increase the priority of the \nfeature. In the meantime, see if you can use grid areas instead for now.<\/p>\n\n\n\n Keep in mind that, if it is going to be implemented, then every line \nname across your stylesheet would need to be unique. Like with grid \nareas, Autoprefixer wouldn\u2019t know what line name belongs to what grid. \nThe only way it can tell is if every line name in the stylesheet is \nunique (excluding media queries).<\/p>\n\n\n\n Update:<\/strong> Since duplicate area names are now supported, there is no reason why duplicate line names couldn’t be supported as well.<\/p>\n\n\n\n IE will behave itself most of the time as long as you follow all of \nthe rules we\u2019ve covered so far. That said, IE can still be a bit \nunpredictable. Just recently, I made a grid item a vertical flowing flex\n container and encountered an odd bug in IE11. The column width was set \nto
Shows which parts of Grid you can use or not with IE10\/11 when using the autoprefixer. Quite a lot<\/p>\n\n\n\n\n\n\n\nEnable in Sage:<\/h3>\n\n\n\n
postcss.config.js<\/code>. Change:<\/p>\n\n\n\nautoprefixer: true,<\/code><\/pre>\n\n\n\nautoprefixer: { grid: true },<\/code><\/pre>\n\n\n\nAutoprefixer still can\u2019t save you from everything<\/h3>\n\n\n\n
#<\/a>Grid Gap has limited support<\/h4>\n\n\n\n
grid-gap<\/code> isn\u2019t currently able to be inherited through media queries. If you want to use grid-gap<\/code>, you will need to duplicate the grid-gap<\/code> setting across all<\/em> of the media queries where you define a grid template for that grid.<\/p>\n\n\n\ngrid-gap<\/code> media query inheritance bug was fixed in Autoprefixer version 9.1.1. It is now safe to use grid-gap<\/code> in your default grid template and then let the gap setting trickle down into all of your media query grid templates.<\/p>\n\n\n\ngrid-gap<\/code> though. It is only supported by Autoprefixer when both<\/em> grid-template-areas<\/code> and grid-template-columns<\/code> have been defined.<\/p>\n\n\n\ngrid-gap<\/code> support by using grid-template-areas<\/code> to understand what your grid looks like. It then takes your grid-template-columns<\/code> and grid-template-rows<\/code> definitions and injects the grid-gap<\/code> value between each row and column, creating extra rows and columns in IE.<\/p>\n\n\n\ngrid-gap<\/code> on its own without grid-template-areas<\/code>,\n Autoprefixer has no way of knowing what cell belongs to what grid. \nWithout that critical knowledge, it cannot safely inject the extra \ncolumns and rows that IE needs.<\/p>\n\n\n\ngrid-template-areas<\/code> but why do we also need to define grid-template-columns<\/code>? Shouldn\u2019t something like this be just as easy for Autoprefixer to translate?<\/p>\n\n\n\n.grid {\n display: grid;\n grid-gap: 20px;\n grid-template-areas:\n \"a b c\"\n \"d e f\";\n}\n\n.cell-a {\n grid-area: a;\n}\n\n.cell-f {\n grid-area: f;\n}<\/code><\/pre>\n\n\n\nauto<\/code> so can\u2019t Autoprefixer just add something like -ms-grid-columns: auto 20px auto 20px auto;<\/code>? It does that for rows, so why can\u2019t it do the same thing for columns?<\/p>\n\n\n\nauto<\/code> in IE acts a bit differently to auto<\/code> in modern browsers. When columns are set to auto<\/code> in IE, they will always shrink down to the value of max-content<\/code>. Modern grid columns, on the other hand, will expand to 1fr<\/code> if there are no other fr<\/code>\n units being used in that grid template declaration. This discrepancy \ncan cause a massive difference in appearance between the modern and the \nIE version of a grid. The Autoprefixer team felt that it was too \ndangerous to make assumptions about this, so they made grid-template-columns<\/code> a mandatory setting in order for grid-gap<\/code> to take effect.<\/p>\n\n\n\ngrid-gap<\/code> when grid-template-columns<\/code> is missing. If auto<\/code> behaves so differently in IE, then why does Autoprefixer support grid-gap<\/code> without the user explicitly having to define grid-template-rows<\/code>? Isn\u2019t that just as bad?<\/p>\n\n\n\ndisplay: grid;<\/code> on something, \nit\u2019s width will grow to the full width of its container. Its height, on \nthe other hand, typically shrinks to the height of its content. Of \ncourse this isn\u2019t always the case. There are a number of reasons why a \ngrid might be taller than its content. If the grid is also a flex item \nand the flex container is taller than the grid, then that would be one \nreason why the grid might be taller than its content. In general though,\n if there are no other forces involved, then a grid container will \nalways be the same height as its content.<\/p>\n\n\n\nauto<\/code>\n in both IE and modern browsers will behave identically to one another. \nIt will only differ in functionality if the height of the grid exceeds \nthe height of the content inside of it. For the best balance between \nuser convenience and browser consistency, the Autoprefixer team made a \nchoice. They decided that supporting a missing grid-template-rows<\/code> property but not a missing grid-template-columns<\/code> property was the best way to handle grid-gap<\/code> support.<\/p>\n\n\n\n#<\/a>No auto-placement! No auto-placement! No auto-placement!<\/h4>\n\n\n\n
#<\/a>Area names must be unique<\/h4>\n\n\n\n
grid-template-areas<\/code> is one of Autoprefixer\u2019s greatest strengths, though it has its limits. Autoprefixer does not have any access to the DOM<\/abbr>.\n Due to this, Autoprefixer is entirely dependent on using the area name \nfor understanding where each cell needs to be placed in the grid. This \ncan cause clashes if you use the same area name twice in the same \nstylesheet.<\/p>\n\n\n\ngrid-template-areas: \"delta echo\"<\/code>. Later in the stylesheet, Grid Beta has grid-template-areas: \"echo delta\"<\/code>. We say that our grid cell belongs to area echo<\/code>… so does it go in column 1 or 2?<\/p>\n\n\n\n.grid-alpha {\n grid-template-areas: \"delta echo\";\n}\n\n.grid-beta {\n grid-template-areas: \"echo delta\";\n}\n\n.grid-cell {\n \/* What column does .grid-cell go in? *\/\n -ms-grid-column: ???;\n grid-area: echo;\n}<\/code><\/pre>\n\n\n\n\"echo delta\"<\/code> areas definition since it occurs last. \nIf you placed the grid cell inside Grid Alpha, it would look great in \nmodern browsers but it would be placed in the wrong column in IE.<\/p>\n\n\n\ngrid-template-areas<\/code>\n property will break IE for sure. Every single area name across every \nsingle grid in your style sheet needs to be unique or Autoprefixer will \nfreak the heck out.<\/p>\n\n\n\n.grid-alpha {\n grid-template-areas: \"grid-alpha__delta grid-alpha__echo\";\n}\n\n.grid-beta {\n grid-template-areas: \"grid-beta__echo grid-beta__delta\";\n}\n\n.grid-cell {\n \/* No more conflict :) *\/\n -ms-grid-column: 2;\n grid-area: grid-alpha__echo;\n}<\/code><\/pre>\n\n\n\n.grid-alpha {\n grid-template-areas: \"ga_delta ga_echo\";\n}\n\n.grid-beta {\n grid-template-areas: \"gb_echo gb_delta\";\n}\n\n.grid-cell {\n -ms-grid-column: 2;\n arid-area: ga_echo;\n}<\/code><\/pre>\n\n\n\n@media (min-width: 600px) {\n .grid-one {\n grid-template-areas:\n \"alpha bravo\"\n \"alpha charlie\";\n }\n}\n\n@media (min-width: 900px) {\n .grid-one {\n \/* This is fine *\/\n \/* It is targeting the same element *\/\n grid-template-areas:\n \"alpha bravo charlie\";\n }\n}\n\n@media (min-width: 900px) {\n \/* NOT FINE! *\/\n \/* The \"alpha\" area is being reused on a different element! *\/\n .grid-two {\n grid-template-areas:\n \"alpha delta\";\n }\n}<\/code><\/pre>\n\n\n\n#<\/a>Autoprefixer has limited column and row spanning support<\/h4>\n\n\n\n
-ms-grid-column\/row-span<\/code> which tells IE how many columns\/rows to span. The other being -ms-grid-column\/row<\/code> which tells IE where to start counting from.<\/p>\n\n\n\n.grid-cell {\n -ms-grid-column-span: 2; \/* number of cells to span *\/\n -ms-grid-column: 1; \/* starting cell *\/\n}<\/code><\/pre>\n\n\n\nAutoprefixer friendly<\/h5>\n\n\n\n
.grid-cell {\n grid-column: 1 \/ span 2;\n}<\/code><\/pre>\n\n\n\n.grid-cell {\n grid-column: span 2 \/ 3;\n}<\/code><\/pre>\n\n\n\n.grid-cell {\n grid-column: 1 \/ 3;\n}<\/code><\/pre>\n\n\n\ngrid-column\/row-end<\/code>. Remember that IE can\u2019t do auto-placement though. A starting line will still need to be specified elsewhere in the style sheet:<\/p>\n\n\n\n.grid-cell {\n \/* Make sure you specify a starting line elsewhere *\/\n grid-column-end: span 2;\n}<\/code><\/pre>\n\n\n\n.grid-cell {\n \/* The short way *\/\n grid-column: 1;\n\n \/* The more verbose way *\/\n grid-column-start: 1;\n}<\/code><\/pre>\n\n\n\nAutoprefixer unfriendly. Here be dragons!<\/h5>\n\n\n\n
.grid-cell {\n grid-column: 1 \/ -1;\n}<\/code><\/pre>\n\n\n\n.grid-cell {\n grid-column: -3 \/ -1;\n}<\/code><\/pre>\n\n\n\n.grid-cell {\n \/* Update: This is now supported as of Autoprefixer version 9.1.1 *\/\n grid-column: span 2;\n}<\/code><\/pre>\n\n\n\n.grid-cell {\n grid-column-start: span 2;\n}<\/code><\/pre>\n\n\n\nend<\/code> and Autoprefixer doesn\u2019t know where the start is):<\/p>\n\n\n\n.grid-cell {\n grid-column-end: 3;\n}<\/code><\/pre>\n\n\n\n#<\/a>Avoid using line names for now<\/h4>\n\n\n\n
#<\/a>You still need to test!<\/h4>\n\n\n\n
minmax(min-content, 350px)<\/code> but IE seemed to treat min-content<\/code> like max-content<\/code> in this circumstance. This completely broke the layout. Changing it to minmax(0, 350px)<\/code> fixed the issue. Just goes to show that IE\u2019s grid implementation isn\u2019t quite perfect.<\/p>\n\n\n\n