Bite-sized CSS & HTML nuggets

Unprefix express in full swing

The big vendor prefix discussion comes and goes in waves, but one conclusion that always pops up is that these prefixes should have a shorter lifespan. Of course browser makers may shift the responsability to specification writers, arguing that specs take too long to reach Candidate Recommendation (CR) status. Well, it seems the unprefix express is finally picking up steam.

A few weeks ago we heard about unprefixed transitions, transforms, animations, gradients, IndexedDB (and more) in the next Internet Explorer, and this week the Firefox team anounced exactly the same.

This is all great news. Even better, as Lea Verou noticed:

Keep in mind that this means you don’t have to use the -ms- prefix at all for transitions, animations and gradients, since no stable build of IE was ever released that requires it.

box-decoration-break finally coming to more browsers

One of the lesser known CSS properties I’m really excited about is box-decoration-break. From the official spec:

When a box is broken at a page break, column break, or, for inline elements, at a line break, the ‘box-decoration-break’ property specifies whether box fragments are treated as broken fragments of one continuous box, or whether each fragment is individually wrapped with the border and padding.

This will finally give us a simple solution for this problem for example, and for cut off box-shadows and the like. It would have been great to fully control which properties should be sliced and which ones not, but currently the poperty only has two possible values, slice (the default) and clone. This image – also from the spec – says it all:

So far, only Opera supports box-decoration-break, since 2009 (Opera 10.60). Firefox does have the -moz-background-inline-policy property that specifies how the background image of an inline element is determined when the content of the inline element wraps onto multiple lines, but that’s just a part of what box-decoration-break does. Here’s the corresponding Bugzilla bug.

Last week support for parsing the property landed in WebKit, with the rendering part still to be implemented. Let’s hope box-decoration-break will be available in all browsers soon!

Small but important (and final?) change to linear gradient syntax

After redefining angles in gradients, another small but important revision was made to the linear gradient syntax last week. It’s outlined in full detail on Peter Gasston’s blog, but the gist is this: If you need a direction keyword, you’ll have to specify the destination keyword and prepend the word to. Previously you had to specify the origin of the gradient.

background: linear-gradient(left top, red, gold); /* old syntax */
background: linear-gradient(to right bottom, red, gold); /* new syntax */

Makes it a bit more readable and logical, so it’s a good adjustment. But how about the transition from old to new syntax then? Well, this will probably be the last edit to the syntax, as the CSS Image Values and Replaced Content Module Level 3 specification moved to the Last Call status. Browser vendors will likely only start using this new syntax when moving to unprefixed gradients, or keep supporting the old syntax for prefixed gradients (as Firefox 10 will do).

Therefore, if you already used unprefixed gradients with direction keywords – for future compatibility – you’d better edit these stylesheets.

On filters, -ms-filters and filters

In CSS, there have been filters for a long time. Microsoft first introduced them for Internet Explorer 4, producing a range of visual effects and transitions. Also called DirectX filters, we still occasionally use them today, for things like fallbacks for CSS gradients. They are proprietary though, and were never picked up by other browser vendors.

As a result, the Internet Explorer team decided to add the -ms- prefix in 2009. But soon after these filters were deprecated, and in IE10 they won’t even be supported no more. So you really never need to bother with the -ms-filter syntax, just use filter in those rare cases.

In the meantime, the filter property has been reborn however, this time for SVG filter effects applied in CSS. Partially supported in Firefox since version 3.5, they’re currently being formally specified, and also being implemented in Internet Explorer 10 and WebKit. These CSS filter effects will allow some very exciting Photoshop-like filters, like grayscale, sepia, blur, saturate, brightness, and much more. Coming soon!

Native CSS nesting with new Hierarchies spec

Googlers Shane Stephens and Tab Atkins Jr. recently posted the first editor’s draft of a new specification on CSS hierarchies. The CSS Working Group has been paying close attention to what’s happening in the world of CSS preprocessors (like LESS and SASS), and this is another illustration of that. Take this code:

.error, .warning {
    padding: 10px;
.error p, .warning p {
    font-size: 12px;
.error a, .warning a {
    color: #f00;
.error a:hover, .warning a:hover {
    border-bottom: 1px solid #f00;

When the spec is implemented, you will simply be able to write it like so:

.error, .warning {
    padding: 10px;
    & p { font-size: 12px; }
    & a {
        color: #f00;
        &:hover {
            border-bottom: 1px solid #f00;

The advantages are pretty clear: better readability and maintainability, and smaller file sizes!

If you’re wondering about compatibility, the spec says the following about this:

if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored

So a browser that doesn’t understand nested selectors will read the above example as:

.error, .warning {
    padding: 10px;

While we wait for browser implementations, it would be great if all CSS preprocessors added support for this syntax so we can start getting used to it today you can actually start using this syntax today – it’s compatible with both LESS and SASS. (Thanks @dariocravero!)

Complete Compass API in iOS 5

One new feature of iOS 5’s Mobile Safari that was not known back when I wrote this post, is an extension to the DeviceOrientation Event API. There was already an implementation of the official yet limited spec in iOS, but the Apple team didn’t have the time to wait for a resolution and implemented two new properties that allow developers to get full access to the real world orientation in Mobile Safari now!

James Pearce from Sencha took the new API for a spin and created a complete web-based compass. If you’re running iOS 5 and you’re on an iPhone 4 or 4S, iPad or latest generation iPod Touch, just tap the image below. Now go ahead and make your web app orientation-aware!

Some notes on bouncy CSS transitions

Know your lingo: pseudo-class vs pseudo-element

Looking at other people’s stylesheets, you may have asked yourself the question why you sometimes see :after and sometimes ::after? And what’s the deal with these pseudo-classes and pseudo-elements?

Well, it’s pretty simple actually. Pseudo-classes are selectors that let you target elements themselves, or a special state of the element – like :hover, :first-child, :nth-of-type(n), :empty, :root, :lang, etc. Pseudo-elements on the other hand allow you to target a sub-part of an existing element, something which is not part of the document element tree.

In the CSS3 spec the authors wanted a clearer distinction between the two, so they decided that pseudo-elements should start with a double colon. But for the sake of compatibility browsers should also parse the single colon versions of the four pseudo-elements that existed before CSS3 – ::first-line, ::first-letter, ::before and ::after. Internet Explorer 8 and lower don’t understand the double colon notation however, so most people just keep using a single “:”. New pseudo-elements introduced in CSS3 – like ::selectiondo need a double colon.

Angles in gradients subject to change

Vendor prefixes have always been the subject of heated debates among web developers and designers. And although it’s easy to forget, a prefix basically means: this stuff is not finished, and might change in the future – use at you own peril.

A prime example of this recently cropped up concerning angles in CSS gradients. A few months back Fantasai posed a simple question to the web community: do you prefer the current way of defining angles (0 is east, continue counter-clockwise) or should we adapt a system of bearing angles, where 0 is north and we move clockwise? The response largely pointed in the direction of the latter option, and recent versions of the spec now read like this:

0deg points upwards, 90deg points toward the right, and positive angles go clockwise

It’s great to see that the people writing the specs actively listen to feedback from the community, but this means that browsers will have to implement this backwards-incompatible change sooner or later. So yes, CSS gradients defined with angles will more or less break when this happens. Let’s hope this shift will happen swiftly and well coordinated.

Shorter media queries

As tweeted by Mathias Bynens a few months ago:

Most of the time, there’s no need to limit your media queries to screen media only.

Indeed, usually your media queries should apply to all media types, so instead of this:

@media screen and (min-width: 500px) { ... }

You can do this:

@media all and (min-width: 500px) { ... }

Even better, the spec says the all keyword can even be left out – it’s the implied default – leaving you with this:

@media (min-width: 500px) { ... }

Never miss an opportunity to shave a few bytes off your code and type a few characters less!