I think I’ve found a scenario in which, while the use of Mixins aren’t vital, they’re certainly very useful, and it’s because of one of the core principles of coding: DRY (Don’t Repeat Yourself).

Just in case you’re not familiar with Mixins, they are reusable blocks of code. In Sass they’re defined with the @mixin at-rule and a unique identifier, like so:

@mixin foobar {
  color: red;
  font-size: 1.5em;
}

And wherever you want those rules to apply, you call them with @include:

h1 {
  @include foobar;
  font-weight: bold;
}
h2 { @include foobar; }

So you can see, it prevents repetition. The W3C’s case is that you can code around this using CSS as it is:

h1, h2 {
  color: red;
  font-size: 1.5em;
}
h1 { font-weight: bold; }

Which is fair enough in the example I’ve provided, and in simple stylesheets. But what about in more complex stylesheets? Depending on how they’re ordered, you either have to use some selectors very far away from where the other rules are applied to it, or you repeat the rules. And what happens when you bring Media Queries into the equation?

Imagine you have two elements and you want to have them styled differently, but if a media query is in play for them both to be the same, like this:

h1 { color: red; }
h2 { color: blue; }
@media screen and (max-width: 640px) {
  h2 { color: red; }
}

NB: I’ve used only a single property here for the sake of clarity, but it’s more likely I would be using multiple properties so the situation would be even more complicated.

To avoid repeating myself I could add a class to the h1 using JavaScript and matchMedia, but that of course relies on the user having JS enabled and so isn’t a real solution. Or I could pre-process the CSS with a server-side language, but again that’s reliant on another technology which I can’t say for certain is available (in an offline appplication, for example).

With the example I’ve given, I could actually approach the problem from the opposite direction:

h1, h2 { color: red; }
@media screen and (min-width: 640px) {
  h2 { color: blue; }
}

But that means the queries I use are being forced on me by the limitations of CSS; I may want to use my original query for different reasons, but if I want to avoid repetition I have no choice.

That’s where Mixins would come in handy, allowing me both the flexibility to choose the queries that better suit the way I’m working, and avoiding repetition:

@mixin primarycolor { color: red; }
h1 { @include primarycolor; }
h2 { color: blue; }
@media screen and (max-width: 640px) {
  h2 { @include primarycolor; }
}

So, there’s my use case. It’s not bulletproof, there are ways around it, but they all impose limitations on me which I don’t feel should be imposed. I’d be interested to hear your thoughts on this, so please leave a comment if you have something to add.

Firefox 10, which is due for release in a few weeks, will see an implementation of the updated linear-gradient and repeating-linear-gradient functions, so in this article I’ll take a look at those, and write a follow-up when the radial gradient updates are available for use.

The simplest linear gradient function remains this, which creates a top to bottom gradient (you can see it in Example 1):

div { background: linear-gradient(#000, #FFF); }

If you want the gradient to go in a different direction (and you probably will), you should now use the keyword ‘to’ plus the side (top, bottom, left, right) you want the gradient to end at; for example, a gradient from left to right would go like this:

div { background: linear-gradient(to right, #000, #FFF); }

Example 2 shows that in action, as long as you have Firefox version 10 or greater.

You can make simple diagonals by using two direction keywords; this one will go from top-left to bottom-right:

div { background: linear-gradient(to right bottom, #000, #FFF); }

The previous syntax allowed you to use direction keywords without to, and this would be the origin of the gradient; that is, the previous example (top-left to bottom-right) would be written like this:

div { background: linear-gradient(left top, #000, #FFF); }

Example 3 illustrates this; if you have Firefox 9 or below you’ll see the old syntax in use, but if you have 10 or above you’ll see the new one. The new Firefox implementation allows you to still use the old syntax for the sake of backwards compatibility, but it will be dropped when the unprefixed functions are implemented.

The rest of the syntax remains consistent. For more complex diagonals you can still use angles:

div { background: linear-gradient(70deg, #000, #FFF); }

That’s shown in Example 4. NB: although the spec states that 0deg is bottom to top, all current implementations (including this updated one in Firefox 10) measure 0deg as left to right. I’m not sure whether all of the browsers will have to change, or the spec will.

Each color-stop can also have a length or percentage value to further customise the gradient:

div { background: linear-gradient(#000 20px, #FFF 90%, #000); }

Example 5 shows this.

There have been a lot of changes to the syntax since it was first proposed, but I think they’ve all been for the better. The linear gradient functions are quite straightforward, understandable, and flexible enough for the majority of use cases, which is what we want from CSS.

To know more, I recommend you read the relevant section of the CSS3 Image Values and Replaced Content module.

Another pair of articles by me got published today; they’re both introduction-level:

Adventures In The Third Dimension, on Smashing Magazine, is a beginners guide to CSS 3D Transforms, explaining the syntax with a few demos; and for Ubelly I wrote The Five-Minute Guide to CSS Animations, which does the same job for CSS Animations.

I’ve an article coming up for .net Magazine soon; it’s called 10 CSS Techniques for 2012, it’ll be the cover article, and I’m very excited about as I wrote it in collaboration with Andreas Johansson, Harry Roberts, Lea Verou, Nicolas Gallagher, and Paul Adam Davis, all of whom do great work.

After that I have two more articles to write, should be tech editing a book on CSS3, then probably starting work on my own second book. 2012 is going to be a very busy year.

This is still a very experimental feature but it’s worth beginning to investigate, so in this article I’m going to very quickly walk through the syntax and discuss the current level of implementation. Update, Nov 15: I realised that I overlooked Microsoft’s implementation of CSS Regions, so I’ve updated this post to correct that.

CSS Regions in Chrome

If you’re using at least version 15 of Chrome, the example below should show you a paragraph of content split between three boxes; if you’re using another browser, you should see a paragraph of text followed by three empty boxes (see this example on JSFiddle if the iframe’s not working, and resize the browser to see the flow in action).

The syntax itself is quite straightforward. We’ll start with the source element — this must be included in your markup, but won’t show up in the document. CSS is used to set the source, but the property is currently in a state of flux: in Chrome 15 you must use the –webkit-flow property, and in Chrome 16, the newly revised –webkit-flow-into property. In both cases the value is a unique identifier of your own choice — note, however, that in the first property I’ve quoted the identifier as it’s actually a string:

#source {
  -webkit-flow: 'foo';
  -webkit-flow-into: foo;
}

You can then distribute that content across as many target elements as you like. The content will flow through those elements in DOM order, with overflow from the first element appearing in the second, overflow from there appearing in the third, and so on. Once again, how you do this has changed: in Chrome 15 you use the content property with the –webkit-from-flow() function as a value, and in Chrome 16 you use the –webkit-flow-from property — in both cases, referring to the identifier you created (formatted as a string for Chrome 15):

.target1, .target2 {
  content: -webkit-from-flow('foo');
  -webkit-flow-from: foo;
}

Just to muddy the waters even further, the build of Chrome I’m currently using (16.0.912.21) is halfway through the transition between the old and new syntaxes, and so although I expect this to change before 16 becomes stable, currently only works with this syntax:

#source { -webkit-flow-into: foo; }
.target1, .target2 { content: -webkit-from-flow('foo'); }

Anyway, the flowed content is effectively invisible to the target elements, so by default they will have neither height nor width; that being the case, you need to assign some dimensions to them. NB: Not being aware of the flowed content also means min-height and min-width will behave identically to height and width (respectively).

.target1, .target2 { height: 100px; width: 100%; }

Having to set explicit dimensions does somewhat limit the possibilities of CSS Regions; they were created to support print-influenced semi-fixed layouts aimed at tablets or ebook readers, so their usefulness on the web at large is perhaps restricted (certainly when viewed against some of the more flexible layout methods that are being planned).

A quick note about styling the flowed content: long term there will be a new rule, @region, which will allow you to style the content for each target, for example:

@region .target1 { color: #F00; }

At the current level of implementation, however, you have to apply the rules to the source, not to the targets; that is to say, you can only style the box of the target elements, not the content within them.

CSS Regions in IE10

The preview release of IE10 also has support for CSS Regions, although their implementation has one important difference, in that the source must be contained in an iframe:

<iframe id="source" content="source.html"></iframe>

This is then used in the same way as the standard dictates:

#source { -ms-flow-into: foo; }
.target1, .target2 { -ms-flow-from: foo; }

You can read more in the IE10 Developer Guide. I’d imagine this implementation will be updated to fully meet the spec before IE10 is officially released. I don’t have access to a copy of the preview browser at the moment so I can’t test if this works, but will update this post when I get the opportunity.

@media -o-paged {}

Then use new values for the overflow property on the scrollable element to control whether the pagination moves horizontally or vertically, and whether or not on-screen controls are shown, like so:

@media -o-paged {
  html {
    height: 100%;
    overflow: -o-paged-x-controls;
  }
}

This paginates the whole document horizontally, and adds controls. To see this working, you’ll need to download a copy of the Labs build (available for Mac, Windows, Linux and Android), then you can visit this example page from Dive Into HTML5 I quickly set up. Navigate by dragging/swiping, cursor keys, or the native controls.

I really like this; it’s still early days, but the syntax seems clear and logical and works well in the demos I’ve seen, and I think it’s going to be really useful as the web migrates away from the desktop and onto other connected devices. More information and examples are in the ‘Paging the Web’ article on Håkon Wium Lie’s website, and I’ll definitely be delving further into this.

I actually don’t think it’s perfectly suited for complex page layouts, but it does some simple things very well, so that’s what I’ll concentrate on. There are three use cases in this article, none of which are impossible using CSS2.1, but all of which are made easier with FlexBox.

You can see all of the examples in action on this page: Demo: Three Practical Uses for FlexBox — it should go without saying that you’ll need to be using a decent browser.

Equally-distributed Navigation Items

For the first example I’m going to make a horizontal tabbed navigation, where all of the tabs have equal widths and spacing. In my example I have four tabs inside a parent which is 600px wide, each tab has a 1px border, and between each of the tabs I have a 4px gap. I can set the tab widths by using absolute numbers or percentages* but both of these mean making calculations, and having to recalculate when new items are added — not practical if you create a website for a client with no knowledge of CSS.

Using FlexBox makes this much easier; you just need to give the list parent a display value of box, and each item a box-flex value of 1:

ul.nav { display: box; }
.nav li { box-flex: 1; }

Of course, you will have to use all of the prefixed properties (–moz–, –ms– and –webkit–), but these are the core rules. What this does is distribute all of the li elements equally into the parent, after margins have been accounted for; no calculations required, and no modification of the CSS needed if an extra nav item’s added.

Update: As pointed out in the comments, if you have very varied text in the list items this actually doesn’t work the way you think it should (especially in Firefox), as the widths of the tab will vary to fit the content. To work around this in WebKit browsers you just need to add a width value other than auto; even 0 is acceptable. In Firefox you need to add a greater width value (in my example I’ve used 150px which, as there are four children, is 25% of the parent) just to get the layout working in the first place, and there is no way to stop the tabs from resizing.

Vertical Centring

Horizontal centring is easily achieved by using an auto value for margin-left and margin-right, but vertical centring is not so easy; there are a handful of different methods, but they involve either extra markup, or a fixed height on the centred element, or both. FlexBox does away with those drawbacks.

In this example I’m going to centre an element horizontally and vertically inside it’s parent, using these rules:

.parent {
  box-align: center;
  box-pack: center;
  display: box;
}
.child { box-flex: 0; }

The box-align and box-pack properties control the distribution of unused space on the horizontal and vertical axes (respectively), so giving them a value of center means all space will be distributed equally on all sides, positioning its child in the dead centre. The box-flex value of 0 on the child element just means it will retain its set dimensions and not be resized.

Start and End Alignment

In my third example I’m going to use a fairly common design pattern, which is two elements positioned at opposite ends of their parent, on the same axis. This is quite often seen in headers and footers, and the way to do this currently is using either absolute positioning or floats; both involve setting dimensions, so aren’t very flexible.

With FlexBox this can be done with the box-align property we saw in the previous example, but with a value of justify:

.footer {
  box-align: justify;
  display: box;
}
.footer p { box-flex: 0; }

The two p elements in the footer have the box-flex value of 0 so retain their dimensions, and are displayed justified in their parent — that is, one at each end of the .footer element. Note that this value doesn’t work in Firefox’s implementation of FlexBox; hopefully that will be resolved in the near future.

Wrapping Up

So can you use FlexBox on your sites today? I think so, if you take care; you can detect support using Modernizr, and provide fallbacks for incompatible browsers. A couple of things to bear in mind, however: first, Firefox’s implementation is quite old and not quite in sync with the spec, as well as having some bugs (I intend to write more about that in a future post); second, the syntax is going to change in the future, and perhaps behaviour will change slightly too.

You can read about the new syntax in the latest version of the spec; I know the WebKit team are implementing this right now, so it may appear in the very near future. But these prefixed properties should be supported for a while to come, so it’s reasonably safe to use them, in my opinion; although perhaps not if you’re going to hand the site over to a client and never touch it again.

While I think the alternative syntax is pretty robust, I did detect a couple of flaws in it which I promised Mark I would write about, and that’s what I’ll do in this article. Before I get to that, I just want to quickly address one of the key points from his proposal.

Defining a Grid

grids have been around for quite a while and there is established words for things like Columns, Fields, Modules and Gutters. It’s my feeling that the CSS grid module should speak the same language as designers, not that of developers.

I’m not certain that I wholeheartedly agree with this; not that the Grid Layout syntax uses terms that are more familiar from tables or spreadsheets rather than typographic grids, as this is certainly true; but the contention in the second sentence, that the Grid module should be aimed at designers rather than developers.

The language of grids may be obvious to those that are trained in using them, but I wonder just how many people that includes. For the non-typographically savvy I think it’s not as literal; speaking for myself I find Rows and Cells more logical than Fields and Modules.

And while Mark’s proposed syntax works well for typographic grids, it does mean that making an irregular grid becomes extremely hard. Using the Grid Layout syntax you can make regular and irregular grids very easily, whereas this new proposal is really intended only to make one very strict type of grid.

Anyway, that’s kind of besides the point; I’m not strongly convinced of my own argument, just thought it was worth raising. But I’ll take Mark’s premise at face value and go along with the syntax that he proposes. If that’s a more logical way to think about grids, then the syntax seems pretty solid. There are, however, a few potential problems I can see with it.

Fractions

The first problem is that basing the grid on modules eliminates the effectiveness of the fr (fraction) unit. In the example in section 4 of the article a three column grid is created using this code (NB: I’ve changed some of the values a little to bring them into line with existing properties):

div {
grid-columns: 3md 1fr 2md;
grid-x-count: 10;
}

As this is on a grid made of 10 horizontal modules, the central column is five modules wide. But what if we used four columns, with two fraction units?

div { grid-columns: 3md 1fr 1fr 2md; }

That would make the second and third columns 2.5 modules wide. I’m presuming that we can’t have fractions of modules, so if the fraction unit can’t be used to create fractions then it becomes useless (or, at least, very hard to work with). In this case we should just go back to using the md unit for everything:

div { grid-columns: 3md 5md 2md; }

And if we’re doing it this way, then we don’t need the proposed grid-x-count property any more; that count can be obtained by the sum of the md units in grid-columns. This brings it a little closer to the existing Grid Layout syntax.

Breaking the Grid

The second problem is that the grid is now very hard to break out of. What if, after we’ve laid out our grid, we wanted to put an item that broke into the gutters:

How do I position that? Unlike in the Grid Layout syntax, gutters aren’t available as slots to position elements in. I could use relative positioning to move it into the gutter, but how do I also expand the element so that it’s larger than the modules it covers? Maybe with padding:

div {
left: -21px;
padding: 21px;
position: relative;
top: -21px;
}

But if, in this box model, padding is added to make the element bigger, then how would I put put internal padding on an element which I didn’t want to get bigger? A possible alternative solution to this would be to add a new property, something like:

grid-gutter-span: all;

This could also have the keywords top, right, bottom, left, or none, to provide flexibility to the elements that are placed in the grid.

Conclusion

For defining a typographic grid I think this syntax is pretty well thought out, certainly for a first draft, and the problems I’ve pointed out here are not insurmountable, but just require some more consideration. I hope that the feedback I’ve given is constructive — well, most of all I hope that I’ve understood the proposed syntax correctly and not made any stupid mistakes! If you’ve anything you’d like to add, feel free to leave a comment.

One quick learning from making this: it would be really useful to have CSS Mixins when using a lot of repetitive keyframes, as I do in this animation. The W3C seem to be quite against them, however.

I’ll discuss quickly the result of that submission, but first I should mention that I’ve since found out that the Google Chrome developers have already implemented their own syntax, and it’s not too far removed from what I proposed. Before I get to that, however, allow me to gripe.

What the feedback on my proposal would be, I have no idea — and may never know. As I mentioned, I submitted it via the www-style list, but my emails were never published. I was told that as a new user my mail would be held for approval, but that was six weeks ago. I emailed the list administrator and tried to submit it again, but never got a reply.

I have to say that, as a developer trying to get involved in the standards process — which is what the W3C claim they want — this was not a good experience for me. I had a serious proposal which I wanted to open up for discussion, but was completely unable to do so and met with a wall of silence. I’m not against there being a moderation and approval process, but only if there’s an eventual result and some kind of communication throughout.

OK, with the moan out of the way, I’ll talk about the Chrome validation error styling syntax. The error message, known as the ‘bubble’, is made of four div elements which are accessible via four pseudo-classes, each of which applies to a different div in the bubble:

::-webkit-validation-bubble {}
::-webkit-validation-bubble-arrow-clipper {}
::-webkit-validation-bubble-arrow {}
::-webkit-validation-bubble-message {}

The parent element is ::-webkit-validation-bubble, which sets the size and position of the bubble, and has two child elements. The first child is ::-webkit-validation-bubble-arrow-clipper, which has its own child, ::-webkit-validation-bubble-arrow; these two set the styles of the tail of the bubble. The body of the bubble is the second child, ::-webkit-validation-bubble-message, which contains the text node with the error itself.

I’ve made a quick example which you can see in action on the HTML5 Forms demo — you’ll need to use Chrome to see it, and you can view the source to see the styles I’ve used. Below is an image comparison of the default message (top) and my styled version. Note: I took a little criticism for calling the default styles ‘ugly’ in my original post, and I don’t want to claim that mine is any better, because it’s really not; it’s just different, to act as an example.

You can read a little more about this syntax on the WebKit wiki, and also see the default styles the error message uses. I’ve no idea if Firefox or Opera implement their error messages in the same way so don’t know if this is likely to become standard, or will always remain a WebKit-only syntax. I have to say it’s not really an elegant solution, but it works.

The book doesn’t aim to teach CSS from scratch; it presumes that you’re a working developer with a good knowledge of web technologies, especially CSS, and you want to take your knowledge to the next level. It aims to translate the sometimes complex specification into something that’s easier to understand, and has plenty of code examples and illustrations to aid in achieving that aim.

It’s not a book of step-by-step techniques, it’s for keeping at hand to use as a resource; and as such, I believe it’s the first book of it’s kind on this topic. There are plenty of books available which teach you about the exciting visual elements of CSS3 like animations, border radius, and so on, and while my book certainly covers those areas it also goes deeper into looking at new layout methods and what we can expect to see in the future.

If you’re a regular reader of my blog you should find plenty in the book that you’ll enjoy; many of the more popular posts I’ve written, such as Using Media Queries in the Real World or CSS gradient syntax: comparison of Mozilla and WebKit, have been adapted for the book in one way or another.

If you’d like to read a sample the publisher has made available a PDF of Chapter 6: Text Effects and Typographic Styles.

You can buy The Book of CSS3 direct from the publisher, No Starch Press, as either a print copy with free eBook (PDF, ePub or Mobi), or eBook alone. You can also order the print book from many online retailers including Amazon UK and Amazon USA.

There’s a companion website with examples and resources from the book, which I aim to keep updated so that it becomes a constant online reference guide; with browser implementation of CSS3 changing so quickly it’s inevitable that some references in the print book will become outdated in the long term, so the website should go some way to combating that.

I’m anxiously awaiting the first reviews, although initial feedback has been promising. I hope it’s popular not only because I put a lot of time and effort into it — the sense of achievement I have from writing it has been worth all of that effort on it’s own — but also because I believe it’s a book that will be of great use to many people. (I know, I would say that!)