That Emil - Blog

CSS Specificity as semantic versioning

When thinking about CSS specificity, it can be tricky at first to understand how one selector beats another. It just occurred to me that semantic versioning could be a good way to explain it.

Semantic versioning is, of course, another slightly complex topic that someone beginning in the web dev world may or may not be familliar with, but bear with me here for a little bit.

The CSS spec for selector specificity states that each value is represented with an unspecified ”large base”, so for example 10 class name selectors will not make the number ”tick over” and equal 1 ID-selector, as it would in a base-10 system.

If we disregard the ”semantic” bit of semantic versioning, and stick to the major-minor-patch format, they work in the same way: version 1.9.9 does not tick over to 2.0.0 whenever a patch is released – the unspecified base means it would become 1.9.10 instead. In CSS specificity, higher version numbers simply beat lower ones.

I got the idea when reading Lea Verou’s post on Parsel – and the way the specificity is shown in the UI there (1,5,1), which was familliar to me from other places as well. Maybe the ”version-number-syntax” of 1.5.1 could be an alternative way of teaching – at least maybe better than the 151 format used in the spec.

Custom properties for breakpoint debugging

Yesterday, I stumbled across Eric Meyer’s post on displaying CSS breakpoint information with generated content. It reminded me of a solution to a related problem that Jeremy Keith blogged about way back in 2012 – how to conditionally load content (via JavaScript) when a certain breakpoint is active.

I was one of the people who came up with a potential solution to Jeremy’s problem, using pseudo-elements to stash a bit of text on (for example) the body element, and then reading that data via JS, using window.getComputedStyle(el, '::after') etc.

It was a hack, but it definitely worked.

Eric has discovered pretty much the exact same solution, but instead of hiding the stashed piece of text, he’s showing it to get a visual clue as to which media query (out of a few possible candidates) is currently active. Smart!

Now to the fun part: I remember having a discussion with Jeremy at some point about how the proper way to communicate in this manner between CSS & JS would be Custom Properties. I blogged about that back in 2013, using the Media Query naming technique as an example.

The solution I proposed there makes perfect sense as a small improvement to Eric’s debugging trick. Using a custom property allows for much cleaner code when setting the ”named breakpoint” text.

body::after {
   content: var(--bp, 'narrow');
}

@media (min-width: 25em) {
  :root {--bp: '>=25em'}
}

The first use of the var() uses a fallback value that you can pass in if the --bp custom property is undefined in the current scope. Then, at each increasingly wide breakpoint, you could update the --bp value to something new.

I’ve put a quick demo on JSBin – wrapped in one of my favorite CSS one-liners which I first saw from Lea Verou (although I can’t remember exactly where):

@supports (--css: variables) {}

Ah, blogging. Not dead yet.

Progressive Web Apps behind Basic Auth

When adding a service worker and Web App Manifest to a staging site recently, I ran into some small issues with HTTP Basic Auth. Here's how I solved them.

I know, I know. HTTP Basic Auth is soooo lame. Yet, I still use it for secret-but-not-super-secret stuff that I want to test out on a server reachable from the public web.

When combining it with a service worker and Web App Manifest, I ran into some issues. I've resolved most of them, but I thought I'd document my findings here mostly for myself, and update as I go along.

Caveat: I need to research if these are good to place there regardless of environment, or if they should be removed in production. Also, I'm still having issues with the authentication dialog not showing up unless I pop open devtools, so I probably need to be adding credentials in more places to have it working 100%.

Adding items to cache – add credentials

If you have calls that look like this:

cache.addAll([
        /* some files */
      ]);

...you’ll need to add credentials to those Request objects:

cache.addAll([
        /* some files */
      ].map(url => new Request(url, {credentials: 'same-origin'})));

Credentials for Web App Manifest

The same logic goes for your manifest.json file: it needs to pass on credentials, and it doesn't by default.

The fix here is simpler: you need to add the crossorigin attribute to the link-tag:

<link rel="manifest" href="/manifest.json" crossorigin="use-credentials">

Smart borders between flex items – the dumb way

Caution, stupid code ahead.

When creating a component that adapts to available space without using Media Queries, I found myself in a situation where I had two items and wanted a border between them, regardless if they were side by side or on top of one another. The border would be left (or right) when items lined up horizontally, but top (or bottom) when the items lined up vertically.

In essence, I wanted border-between or somesuch property to exist.

With a little fiddling and some brain ping-pong with Robin, I came up with the following solution:

CodePen example

.container {
  display: flex;
  flex-wrap: wrap;
  overflow: hidden;
}

.item {
  flex: 1 1 20em;
  background-color: hotpink;
  border-top: 1px solid purple;
  border-left: 1px solid purple;
  margin-top: -1px;
  margin-left: -1px;
}

...where the border is always present on top/left, but hidden with negative margins. Ouch. Caveats: lots, probably. Not least that this only works (nicely) in a pretty limited set of circumstances.

Then, I thought, ”wait, I could just use the logical direction keywords (border-block-start vs border-inline-start etc) in modern browsers”, quickly followed by, ”no, I can’t – the logical direction isn’t actually changing.” Oh well.

Current status: feeling clever/feeling dirty.

Fixing fieldsets

The fieldset element is a really useful one. It creates a grouping of related form fields, giving them a label in the shape of a legend element.

Sadly, people have been avoiding the fieldset element. Purely for lack of styling options (or reluctance to add a mess of hacky CSS), this semantically clear and accessibility-enhancing element has been ignored since forever.

The appearance of a fieldset and its associated legend is more or less hardcoded into the browser, and it acts more like replaced content than the simple container and text pairing that it is. The HTML spec has formalized these wierdnesses, and dictates some rather odd behaviors of how the fieldset and legend combo is to be rendered:

A fieldset element's rendered legend, if any, is expected to be rendered over the block-start border edge of the fieldset element as a block box (overriding any explicit 'display' value).

I think it's about time that we fix this. I also think that browser makers and spec writers have a unique opportunity to implement that fix at this moment in history.

Enter display: contents. This declaration basically tells the browser to not generate a rendered box for the element to which it is applied. Currently, it does not work on <code>fieldset</code> elements where supported - but I think it should. When chatting to Jeremy about this, he said it sounded like "a DOCTYPE switch for fieldset rendering", which I think is spot on.

The legacy appearance of fieldsets probably needs to be preserved for compatibility reasons. But display: contents is not supported in any old browsers, and is most likely used on exactly zero sites using the legacy look of fieldsets. If it is applied, the legend should probably just become an inline element, and it would be up to authors to style it any way they see fit.

So: browser makers should allow authors to set display: contents on fieldset elements, thus removing all of the associated weird handling of backgrounds and borders, and weird positioning of legend elements inside them. Should a wrapper element for the fieldset be needed, authors can add a div or other element. The spec should allow for this exception - I've opened issues against the WHATWG spec as well as the W3C HTML spec, and I hope that's at least a start to get the ball rolling.

Come on, people – let's fix this.

Update: it seems that the CSS Display spec actually has an appendix describing this very situation, and that display: contents should remove magic display behavior from legend elements specifically when it is applied. In which case, the spec authors deserve a break, and bugs will have to be opened agains browser implementations instead. Specifically, Chrome (Canary, with experimental web features flag enabled) gets it right on fieldset but not legend, and Firefox disregards it completetly. I've put up a quick test on Codepen.

Enquire Within Upon @media

When dealing with advanced layout features, it makes sense to place all of your CSS inside of a feature query, including media queries for the advanced layout. However, Chrome (currently) drops the ball on that last bit. The Chrome bug has since been fixed, so it should hopefully work better in coming versions.

Grid Layout will soon be available in browsers. With it comes a classic conundrum – when can we use it?

As Grid very much defines what is possible in terms of CSS layout, it's likely that adoption will initially be a little slow, at least for existing sites. For newly created web properties, I'd advocate an ”aggresive enhancement” approach as soon as support is reasonably wide. What I mean by that is make your layout as simple as possible for simpler browsers (a single column, maybe some small flexbox, inline-block or float enhancements here and there), but bring out the Big Grid Guns when supported.

Using this strategy, you'd probably want to make sure that the code for the Grid-based layout is properly isolated. Something like this would be a good starting point:

@supports (display: grid) {
  /* KABOOM! */
}

Given this approach, you probably want your @media rules for the fancy responsive goodness inside the @supports rule. And this is all fine, according to the spec.

However, at the time of writing, Chrome does not respond dynamically to @media rules inside @supports rules – it reacts at page load, but not on window resize. Other browsers I’ve tested (Firefox, Safari) handle this just fine. Not a show stopper, but it got me scratching my head for a while. I’ve filed a bug and this has since been fixed – should be out in a version or two (52+?).

In conclusion, this will currently not be triggered correctly on window resize in Chrome:

@supports (display: grid) {
  @media (min-width: 65em) {
     /* ...sad trombone */
  }
}

...but this will:

@media (min-width: 65em) {
  @supports (display: grid) {
     /* ...mildly amused trombone */
  }
}

(If you're wondering about the title, it is a reference to the precursor to the World Wide Web, which Sir Tim called ENQUIRE, after a book called Enquire Within Upon Everything.)

Revisiting the Float Label pattern with CSS

The float label pattern is a slick pattern that designers seem to love. I’m not sure that I’m 100% in love with it, but I couldn't resist cooking up a quick demo implementation. This version uses a few nice form-styling tricks using modern CSS that I've seen recently, particularly the :placeholder-shown selector.

First things first: this is not a ”Best practice” implementation in any way, shape or form. It works in recent versions of some browsers — most notably Chrome/Opera and Safari/WebKit. It fails miserably in Firefox. I have barely tested it. Be warned.

I'm relying on quite a few moving parts here:

Flexbox—using Hugo Giraudel’s pattern for putting the label after the input in the markup, then reversing the order.
A transform to shift the label down over the input. When this state is active, the placeholder text get's an opacity: 0 so the two pieces of text don’t overlap.
Shifting the label up only when the placeholder is not shown, i.e. when the field is filled in, or when it’s focused, inspired by Jeremy’s ”Pseudon’t” post.

That last part is what separates this implementation from for example Chris Coyier’s and Jonathan Snook’s versions, in that they use the :valid pseudo-class. I think this demo steps around that particular limitation, but as I said at the start, there are limitations in the form of browser support.

This version instead uses the :placeholder-shown pseudo-class, but negated to only move the label out of the way when the placeholder text is not showing—which plays nicely with how the pattern is supposed to work.

Here's the relevant HTML:

<div class="field">
    <input type="text" name="fullname" id="fullname" placeholder="Jane Appleseed">
    <label for="fullname">Name</label>
</div>

...and the CSS:

/**
* Make the field a flex-container, reverse the order so label is on top.
*/
.field {
  display: flex;
  flex-flow: column-reverse;
}
/**
* Add a transition to the label and input.
*/
label, input {
  transition: all 0.2s;
}

input {
  font-size: 1.5em;
  border: 0;
  border-bottom: 1px solid #ccc;
}
/**
* Change input border on focus.
*/
input:focus {
  outline: 0;
  border-bottom: 1px solid #666;
}
/**
* When the label follows an input matching :placeholder-shown...
* 1. Make sure the label is only on one row, at max 2/3rds of the
*     field—to make sure it scales properly and doesn't wrap.
* 2. Fix the cursor.
* 3. Translate down and scale the label up to cover the placeholder.
*/
input:placeholder-shown label {
  /* [1] */
  max-width: 66.66%;
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
  /* |2] */
  cursor: text;
  /* [3 */
  transform-origin: left bottom; 
  transform: translate(0, 2.125rem) scale(1.5);
}
/**
* By default, the placeholder should be transparent. Also, it should 
* inherit the transition.
*/
::-webkit-input-placeholder {
  transition: inherit;
  opacity: 0;
}
/**
* Show the placeholder when the input is focused.
*/
input:focus::-webkit-input-placeholder {
  opacity: 1;
}
/**
* 1. When the element is focused, remove the label transform.
*     Also, do this when the placeholder is _not_ shown, i.e. when 
*     there's something in the input at all.
* 2. ...and set the cursor to pointer.
*/
input:not(:placeholder-shown) + label,
input:focus + label {
  transform: translate(0, 0) scale(1); /* [1] */
  cursor: pointer; /* [2] */
}

Update 2016-01-26: I updated the selector for the label so that the transformed label is only used when it's following an input matching :placeholder-shown. That way, non-supporting browsers fall back to the ”normal” label-above-the-input pattern. Thanks to Matteo Capucci for pointing out that simple enhancement to me—in my haste to whip up the demo, I completely missed that simple improvement. Also thanks to Patch for pointing out the cursor:pointer-improvement.

Here's the full JSBin demo.

Grid Tidbits part 3: grid track sizing

This post will examine some of the finer points of sizing grid tracks (a.k.a. rows and columns) in CSS Grid Layout. Flexible sizing, the repeater function, the minmax function – oh my!

To play along with the examples in this post, I recommend that you download and fire up Chrome Canary, since that browser has the most up-to-date implementation.

Recap

In the previous tidbit, we used some very simple markup to represent a grid container and three child items.

<div class="grid-container">
  <div class="grid-item-a">A</div>
  <div class="grid-item-b">B</div>
  <div class="grid-item-c">C</div>
</div>

We're going to keep this markup, but play with the sizing. The grid track definitions we started with looked like this:

.grid-container {
  display: grid;
  grid-template-columns: 50% 50%;
  grid-template-rows: auto auto;
}

The above means we created a 2 ✕ 2 grid template, where the two columns each take up 50% of the width, and the two rows automatically adjust their height to fit the tallest content inside. If we just let the items position themselves with the automatic placement algorithm, A and B end up in the first row, and C ends up in the bottom left corner.

The 2 ✕ 2 grid from part 2 (JSBin link for figure 1)

The mental shift to understand grid layout is that the sizing mechanics of the grid resides mostly in the grid track definitions, rather than in the items themselves. We can use loads of types of measurements to size tracks – percentages, ems, pixels, viewport units etc. But there are more exciting possibilities in the grid layout spec – let’s jump straight in!

Getting flexible – the `fr`-unit

The Grid Layout spec introduces a new unit for flexible sizing. The fr unit stands for fraction of remaining space. It distributes the space left when any tracks sized with auto, percentages, ems, pixels etc have been calculated. If you know your flexbox, it's basically the same thing as a flex-grow factor, with a 0 flex-basis.

If we change the first column to be 5em and the second column to be 1fr, the second column will receive any space left above 5em.

.grid-container {
  display: grid;
  grid-template-columns: 5em 1fr;
  grid-template-rows: auto auto;
}

The updated grid, where the right column takes up any space left above the 5em width of the left column. (JSBin link for figure 2)

You may be wondering what the 1 in 1fr actually stands for. If you’re comfortable with flexbox already, you may have a reasonably clear picture, but it doesn’t hurt to actually get into the details.

For example, what happens if the right column would be sized to 2fr? Would it then be two times as wide as the remaining space, and cause overflow? No. Mathematically, “fraction of available space” means that the second column will receive(flex number * available space) / combined number of flex units. This means that if there’s 100 pixels of available space, the right column will be (2 * 100) / 2 pixels wide, so still 100 pixels. It’s like mixing drinks: no specific measurements, but rather “2 parts tequila, 1 part whisky, 1 part bitter tears” (That would probably be a horrible cocktail. Then again, I’m not a licensed mixologist).

If we were to add another column also sized to 1fr, the middle and right columns would be equally wide – each is 1 fraction of the available space, i.e. 1/2.

.grid-container {
  display: grid;
  grid-template-columns: 5em 1fr 1fr;
  grid-template-rows: auto auto;
}

The B and C columns are now equally wide. Note that the second row in the grid is now empty, and collapses down to 0 height. (JSBin link for figure 3)

If we use different flexible lengths for the two tracks, we can see more clearly how the units relate to each other.

.grid-container {
  display: grid;
  grid-template-columns: 5em 2fr 1fr;
  grid-template-rows: auto auto;
}

The B column is now twice as wide as C. (JSBin link for figure 4)

There’s three units competing for space in total (2fr + 1fr), so two thirds of the remaining space (after the first column is sized) gets allocated to the second column, and one third to the second column.

Repeating grid tracks

If you’re dealing with a more complex grid than just a handful of columns, it get’s tedious to write out repeating columns of the same size. Luckily, the grid spec has this sorted: you can use the repeat() functional notation. If we have a grid of 24 equal width columns (for example), you can just repeat a 1fr track 24 times.

<div class="grid-container">
  <div class="grid-item-a">A</div>
  <div class="grid-item-b">B</div>
  <div class="grid-item-c">C</div>
  <div class="grid-item-a">A</div>
  <div class="grid-item-b">B</div>
  <div class="grid-item-c">C</div>
  <!-- ...and so on, 24 items -->
</div>

.grid-container {
  display: grid;
  grid-template-columns: repeat(24, 1fr);
  grid-template-rows: auto auto;
}

24 items in 24 equal width columns. (JSBin link for figure 5)

You can mix and match repeated tracks with regularly declared tracks, in case some of them are different. If the first and last columns are of a different measurement, the track list for columns could look like this.

.grid-container {
  display: grid;
  grid-template-columns: 5em repeat(22, 1fr) 5em;
  grid-template-rows: auto auto;
}

Minimum and maximum sizes

Since we're sizing grid tracks rather than elements in the DOM, we can't use the min-width, max-width, min-height and max-height properties to size them. Instead, the Grid Layout spec introduces a functional notation for this purpose, appropriately called minmax().

For instance, we might want the leftmost column to take up 20% of the width, but with a minimum width of 5em.

.grid-container {
  display: grid;
  grid-template-columns: minmax(5em, 20%) 1fr 1fr;
  grid-template-rows: auto auto;
}

Intrinsic sizing keywords and auto sizing

So far, we have declared that the row tracks have an auto height. What does that mean? Well, we’ve already concluded that it means that the track collapses down to 0 height if the row is empty. If there are items placed in the row, it will expand to fit them. In simplified terms, this expand-to-fit behavior means that it will be as tall as the tallest grid item, depending on how the items themselves are sized.

We can also use the keywords from the Intrinsic & Extrinsic Sizing module to gain even more fine-grained control over how we size the tracks. If we’re dealing with a column containing some short text, we may want to size it so that it has a maximum size corresponding to the max-content width.

<div class=";grid-container";>
  <div class="grid-item-a">Hello world</div>
  <div class="grid-item-b">B</div>
  <div class="grid-item-c">C</div>
</div>

.grid-container {
  background-color: #E6CAD6;
  display: grid;
  grid-template-columns: minmax(5em, max-content) 1fr 1fr;
  grid-template-rows: auto auto;
}

As long as there’s any space left, the first column will now expand to fit the words “Hello world. (JSBin link for figure 6)

If we add a fourth item to the grid, it will end up on row two (via the rules of auto placement – don’t worry, we’ll get back to that in later tidbits). If the content inside that item is even wider, then the whole track will have a larger min-content size. So: max-content means “the largest max-content item inside the track”.

<div class="grid-container">
  <div class="grid-item-a">Hello world!</div>
  <div class="grid-item-b">B</div>
  <div class="grid-item-c">C</div>
  <div class="grid-item-d">Hello big world!</div>
</div>

.grid-item-d {
  background-color: #274461;
}

The “D” item pushes on the max-content size of the first column (JSBin link for figure 7)

To me personally, track sizing in the grid layout module is one of the places where I’ve actually seen immediate use for the intrinsic sizing keywords in CSS. (On the other hand, I suspect that they're highly useful elsewhere, but I haven’t worked them into my thinking yet.) These keywords have been around for a while, but support is still spotty, with mostly prefixed implementations.

Wrap-up

That’s it for the first pass of sizing grid tracks! There’s more to come – we haven’t even gotten started on gutters, named lines or template areas yet… These first posts have been slightly longer than anticipated, but as we get to grips with the basics, we can discuss other concepts in shorter form ahead. So stay tuned for more tidbitty tidbits!

The tidbits so far:

Grid Tidbits part 2: terminology and basics

This post goes through the terminology of CSS Grid Layout, the basics of defining grid templates, and placing items on the grid.

For this ”tidbit”, we're going to do the following:

Take an element and convert it to a grid.
Watch items place themselves onto the grid
Start playing with how to control the placement.

To play along with the examples in this post, I recommend that you download and fire up Google Chrome Canary, since that browser has the most up-to-date implementation.

Grid terminology

Grid layout works by ”slicing” an element – called a grid container – into rows and columns. The direct child elements of the container element – the grid items – can then be placed on that grid. Grid items can occupy a single grid cell, or span several rows or columns. Collectively, any rectangular part of the grid is known as a grid area. As you are creating rows and columns – known collectively as grid tracks – you are also creating grid lines, made up by the edges of the tracks.

We'll start by creating a simple grid and then identify these pieces as we go along. The markup for now is just a container div and three child elements.

<div class="grid-container">
  <div class="grid-item-a">A</div>
  <div class="grid-item-b">B</div>
  <div class="grid-item-c">C</div>
</div>

Some basic styling to give some dimensions and identify the different pieces with colors:

.grid-container {
  background-color: #E6CAD6;
}
[class^="grid-item"] {
  border: 1px solid #fff;
  font-size: 4em;
  min-height: 2.5em;
  line-height: 2.5em;
  text-align: center;
  color: #fff;
}
.grid-item-a {
  background-color: #3D74C7;
}
.grid-item-b {
  background-color: #85CAAA;
}
.grid-item-c {
  background-color: #DAB97D;
}

Now, what happens if we tell the .grid-container element to display as a grid, and just leave it at that?

.grid-container {
  display: grid;
}

The bare grid container. (JSBin link for figure 1)

The only thing that seems to happen from a visual point of view is that the width of the four items shrinks down to the content-size of the items themselves. But we have actually created a grid, where there's one column and three rows, all of them sized according to content. This is because of something called the implicit grid – we'll talk more about that in later posts.

The grid template

To get further, we need to define how the grid works. Say we wanted two columns of 50% percent each, and two rows that have an auto height, meaning they are only as tall as the tallest content. For this next trick, we need need the assistance of a grid template. The grid template defines the tracks (columns and rows), and in their simplest form we supply them as space separated lists of sizes, in order of appearance.

.grid-container {
  display: grid;
  grid-template-columns: 50% 50%;
  grid-template-rows: auto auto;
}

Hey look, it’s properly grid-shaped!. (JSbin link for figure 2)

Well, hey now. That is an honest to goodness grid-shaped thingamajig. Our grid items fit neatly into three of the four cells we have defined, and the grid takes up the whole width. Nice. But – we didn't actually place anything yet, and still the items line up column by column, row by row – what's up with that? Well, the grid layout has something called automatic placement and by default it will place each item, going by source order, in the first empty cell of the first row which has an empty cell. So our three child elements will automatically go into three of the empty cells, all by themselves. Neat.

Numbered grid lines

As we created two grid tracks in each dimension, we also created three grid lines in each dimension. For two columns, there's the leftmost line, the middle line and the rightmost line. Similarly, there's top, middle and bottom for rows. These can now be referenced by a number. Grid lines are numbered starting at 1 . (No, not 0. You've been reading too much JavaScript, friend.)

For our left-to-right grid, line 1 is the leftmost column line, and line 3 is the last.

The numbers of grid lines. I see them as almost like the ruler lines in Illustrator, Photoshop or Sketch etc.

Placing items

Now for some real meaty stuff: telling items to take up a specific part of the grid. We could, for example, have the .grid-item-a element take up both of the columns in the first row. To do this, we need to supply the lines where it starts and ends.

.grid-item-a {
  grid-row-start: 1;
  grid-row-end: 2;
  grid-column-start: 1;
  grid-column-end: 3;
}

Item A now spans the whole first row. (JSbin link for figure 3)

Now, this is a bit verbose. We can use a shorter version by smashing the -start and -end properties together into the grid-row and grid-column properties, separating the start and end indexes by a slash:

.grid-item-a {
  grid-row: 1/2;
  grid-column: 1/3;
}

Well, screw it, let's go for it and smash them into something even shorter. Since what we're actually doing is defining the grid area where the item sits, there is a full shorthand property conveniently named grid-area.

.grid-item-a {
  grid-area: 1/1/2/3;
}

I don't know about you, but I find that kind of hard to read. The order is row-start /column-start / row-end / column-end – so compared to margin or padding shorthands, it's going the opposite way. (As a sidenote, the reason is that it allows you to omit end positions for items that only span one cell).

Negative line numbers and spans

By default, items span one row and one column. As we've already seen, items are automatically placed into the first empty area where they fit, via the automatic placement algorithm. As the .grid-item-a element is first in the source order, we don't really have to specify either of these facts:

That it sits in the first row
That it spans one row

Hold that thought for a second.

If we want to reference the grid lines in the opposite direction, we can use negative numbers: the rightmost column line is -1, and the leftmost is -3. We might have a situation where we are not sure how many columns the final grid will have, but we are sure that .grid-item-a should span all the columns. In that case, the negative line numbering is really handy.

Combining the default placement with the negative indexing gives us a really short way to define the item spanning the whole of the first row.

.grid-item-a {
  grid-column: 1/-1;
}

If we're not interested in spanning the whole row, but more interested in the fact that the element spans a specific number of columns, we can be explicit about that fact instead. Since the starting position is already set by auto placement (first element in source order, starts in column 1, row 1) , we can fall back to only specifying that <code>.grid-item-a</code> spans two columns.

.grid-item-a {
  grid-column: span 2;
}

All of these ways of specifying placement of this particular grid item gives us the same result, but with different levels of readability, and different levels of explicitly placing and sizing the item.

Spanning rows & column height

If we switch the “a”-item to span two rows instead of two columns, we can place it as a sidebar of sorts, and the other two items will fill the other two empty slots.

.grid-item-a {
  grid-row: 1/-1;
}

Item A now spans the whole first column instead. (JSBin link for figure 4)

Now, if the “C”-item were to be much taller, the “A”-item would still stretch to take up all of the height of the grid. No more “equal height columns” problems.

.grid-item-c {
  height: 6em;
}

Item C pushes the height of the entire second row. (JSBin link for figure 5)

That's all you need to create a basic grid container and placing things inside the grid tracks – rows and columns – you create. In the next installment, we are going to dive into some more advanced parts of defining grids. See you in part three, where we get deep into sizing grid tracks!

Grid tidbits, part 1: the Why and Where

CSS Grid Layout is a new way of handling layout in browsers. It differs from other methods (like flexbox) in perspective and capabilities, but it also overlaps somewhat. Oh, and it's going to be in a lot of browsers real soon. This post gives you an overview of what it is, and what it's for.

So. You might be going ”oh great, yet another new layout mechanism in CSS, and I was just starting to get to grips with Flexbox”. In that case, this post (and the rest of the series) is for you.

This post is not about code. Just to give you a taste of both some basics and some more advanced features, here's what (a small part) of the Grid syntax looks like:

/**
* Assume this markup:
* <div class="grid-container">
*   <div class="grid-item"></div>
* </div>
*/

/**
* A grid container element with one row
* of automatic content height
* and five columns, where the first
* is at least 12em wide and otherwise
* 25%, and the remaining four are of
* equal width in the space that's left.
*/
.grid-container {
  display: grid;
  grid-template-rows: auto;
  grid-template-columns: minmax(12em, 25%) repeat(4, 1fr);
}

/**
* A child element inside the container
* placed in row 1, starting at column 2
* and spanning 2 columns.
*/
.grid-item {
  grid-row: 1;
  grid-column: 2/span 2;
}

At first glance, this might look sort-of-kinda like Flexbox. You set a display mode and some general layout rules on the parent, and some details on a child element. There's even some flexible units dealing with remaining space. Let's stay in flexbox-land for a second.

Flexbox is great. It gives us the possibility to size stuff in a number of different ways, and have it line up neatly in one or more rows, or columns. Yay for non-hacky horizontal layout! It also offers freedom from markup source order, and lets you align and distribute content more easily. From one perspective, the core strength of flexbox is to let content size itself based on things like available space, or the content dimensions. This is the first big conceptual difference between Flexbox and Grid.

Grid is top-down

Looking at the code example above, there is at least one major difference from how flexbox works. There is nothing in the rule-set for the item saying how it is to be sized. All the sizing takes place in the grid container. You make an element into a grid container, slice it into rows and columns at specific points along the two axes, and then place the child elements into the slots that are created.

Where Flexbox has a lot of focus on how to size the item itself, grid is more about creating a bunch of virtual receptacles and pouring your content into them. This doesn't mean that Grid is inflexible – as you can see from the code example, there's plenty of flexibility. You are free to size the columns and rows (known collectively as grid tracks) based on content size, remaining space, percentages etc etc.

This means that Grid is great for more high-level layout. You can use it to define the overall layout system of whole pages, but more likely, you'll use Grid to define the layout of larger sections of a page. We'll get more into the use-cases in later installments.

Grid is two-dimensional

When you're creating layouts with floats, table display modes, inline-blocks or Flexbox you can create horizontal rows – columns lining up from left-to-right or right-to-left. Some of these allow you to create wrapping rows. But as soon as you want to have one item spanning multiple rows, you'll need to further divide things with wrapper elements. For complex layouts, that can mean a lot of wrapper elements.

All of these methods are in a sense one-dimesional: you can create rows or columns, but not in any sense that make the two aware of each other. Grids are two-dimensional: you can create layouts as complex as you like. If you want a great illustration of the differences, check out this talk by Tab Atkins from CSSDay 2014. Meanwhile, check figure 1 – how many wrappers would you need to recreate that with floats or Flexbox? Grids make this easy-peasy.

A complex 2D-grid.

Grid is coming soon

So, at this point, you may be going ”OK, maybe there is good reason for this new Grid thing. But it's not supported anywhere, almost!”. Well, yes, and no. Here’s the lowdown.

All the major browser makers are on board with this spec.
It is expected that the spec will be finalized this summer.
Grid Layout is already supported in IE10+, but it's a slightly older version of the spec. It can still do the basics, but it's missing a lot of the new shiny. It's -ms--prefixed though, so you have to tweak the syntax slightly.
Blink and WebKit are both very far along with their implementation, you can try it out in Chrome Canary or WebKit Nightly. The same people are implementing it in both engines, so they're pretty in-sync.
Firefox is not far behind, and things are happening if you look in Bugzilla. Note: I think that the later stuff is not yet merged with the trunk codebase, so the nightlies only have a very buggy version hidden behind a flag inside about:config.

It seems very likely that Grid will land in all of the major browsers within a year, if I'm being conservative. IE is in a slight pickle, as they already have the old version with prefixes, so they'll probably hold off shipping the unprefixed modern spec in Edge a little while. I’d say it's a pretty safe bet that they are working to get it out ASAP. Safari is stuck in the stone age with their once-a-year release cycles, but hey, at least it' being worked on very actively in WebKit. If there isn't a change in policy and a point release contains Grid, it'll probably be in Safari iOS/Mac next year.

To sum up, there's a massive new layout technology that will be in a large percentage of browsers within a year. If you want to be ready, read on in part two!.

This article has been translated to Russian at css-live.ru.