My idealistic view is that the web should work for everyone, regardless of their method of access. Idealism always takes second place to pragmatism, however; I know that we have to work within our limits, we can’t provide a first-class experience for everyone all of the time. So where do we draw the line for browser support?

The answer is the same as always: it depends.

When making the decision, you should use a Cost-Benefit Analysis (CBA). The cost includes your resources: how much time you have, how much money, the staff you have available. All of these are finite. The benefit (or lack of) is mostly to your users: not only the ones who may be excluded, but also the others who could get a reduced service if you have to divert resources to legacy support.

In 37Signals case they know their users well, they’ve done this before and obviously feel the benefits are greatly in favour of their current user base. If someone can’t get access to their website it’s not the end of the world, there are alternatives available.

But your market may be different. You may not even know your market. Telling people that they must update their browser is making a lot of presumptions about them:

• That they are aware of what a browser is. A lot of people aren’t. It’s why Google are spending millions on a global campaign (not entirely selflessly, of course).
• That they have the ability to update it — and I don’t just mean technical ability, but cognitive and physical ability too.
• That the technology they use supports updating or using alternative browsers. Many (most?) of the devices I know do, but I’m not aware of the technology markets across Africa and Asia, for example.

Most importantly, you must assess the benefit of the content — or the lack of access thereof — to the user. You could be building a site about healthcare which contains content that could save lives — literally vital information. Christian Heilmann recently posted browser stats from a healthcare site which showed that ~50% of visitors were using a browser which wouldn’t meet 37Signals’ criteria.

With all that in mind, after we’ve done the CBA I would say that the very least consideration of ours should be how easy it is to do something. I said in the discussion that “we play the cards we’re dealt” — that wasn’t intended to be a statement of passivity, but rather one of acceptance that we don’t control our users. If they use IE6, we build for them. We can educate and encourage, but only up to a point. Beyond that point we start to become arrogant.

So that’s my opinion, I look forward to hearing yours.

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.

I think it’s been a really exciting year for our industry; the explosion of web browsing away from the desktop, HTML5 beginning to prove itself as the best option for cross-platform development, the newly-resurgent Microsoft making good browsers again… if you make your living from building the web you can’t fail to be heartened by this flourish of new life. There’s been a great appetite for discovery of new browser features, with lots of demos being made using cutting-edge and experimental CSS, HTML and JavaScript, so the curious amongst us have had plenty to satisfy us.

Part of my contribution to tutsplus.com’s experts(!) review of 2011.

I’ve put together my list of the 20 Best CSS Sites of 2011 for .net Magazine. Choosing only 20 turned out to be really difficult, as I wanted to get a broad range of approaches. I’m sure there are plenty I missed out, including any that aren’t in the English language.

For The Sass Way I wrote about How Sass Can Shape The Future of CSS, showing how many of the features contained in the pre-processed CSS extension are under discussion for inclusion in future versions of CSS.

Webdesigntuts+ interviewed me about my book and my opinions on CSS3, including what I’m excited about for the future, and things to beware of when using cutting-edge properties.

And again for .net Magazine I discussed The Future of CSS Layouts, a subject I’m really excited about at the moment, which led to an article that was very popular with .net’s readership.

I currently have two more articles waiting for technical review and proofreading, which I hope will see the light of day shortly, and have promised to write another two as soon as I get time (as well as one for a dead tree publication). I’m very happy to be writing about my craft, and appreciate feedback or further requests for articles from other sources — although, I won’t be able to write quite as much next year as I’m planning to start my second book.

I enjoyed giving this talk, and the whole event is worth a watch. You can see all the other videos on Vimeo. Bonus: See if you can spot the point where I completely forgot what to say next. It’s quite early on…

• Demos that work in one browser/engine only and aren’t updated even when other browsers implement the new features, are harmful.
• Using prefixed features as a way of actively excluding other browsers is lazy and anti-competitive.
• Including an unprefixed property in anticipation of eventual standardisation works against the principle of using prefixes
• When browsers have working, largely compatible, implementations of properties (like transform) they should remove the prefix even if the spec hasn’t reached the stage required by the W3C.

However, I still think using prefixed properties is the right approach. If we do as Henri suggests and leave experimental features in experimental builds (an eminently sensible suggestion, I might add), the pace of progress will be much slower. I believe that having these features out there and getting people using them encourages competition (and collaboration) between browser makers, and the benefits of that competition are given to us, the developers, and passed on to the audiences of the sites we build.

That doesn’t mean that the current situation is ideal; far from it. But improving things will involve more effort from us, the developers and writers, the community in general. Chief responsibilities will be:

• Commit to supporting old demos that we have made.
• Always make sure we plan our designs and builds in a way that they are not reliant on prefixed features, but degrade gracefully.
• Don’t use an unprefixed property before standardisation has happened unless we can have reasonable confidence that it is safe.
• Make sure we stress that the things we use and teach are experimental and subject to change.

As an author and writer I’m guilty of some of the faults that are pointed out in his article, and I promise to do better in the future.

In closing, I want to congratulate Henri on writing this thought-provoking post. I was ready to dismiss it as one of the lazy articles criticising prefixes that occur regularly, but the argument was very well thought and well made, and made me change my mind a few times while I was writing this post.

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.