Bite-sized CSS & HTML nuggets

Using Sass source maps in WebKit Inspector

Here’s a second topic I talked about in my Fronteers 2012 jam session presentation. If you’ve been using a CSS preprocessor in your workflow, you’ve no doubt encountered this issue: you’re inspecting some element and want to edit the CSS, but finding that selector proves to be difficult as the inspector shows you file names and line numbers for your compiled CSS.

If you’re using Firefox and Sass you might have heard about FireSass, but Chrome users have been out of luck until recently. This is where source maps come into play. Source maps are a language-agnostic way of pointing your inspector to the right location in your unminified and uncombined files. Originally devised for JavaScript, they can equally be applied to CSS preprocessors.

Heads up: most of the instructions below are deprecated. There’s an excellent and up to date overview of the necessary steps on the Chrome DevTools blog.

A fairly recent commit enabled experimental support for Sass source maps in Chrome, so make sure you’re running at least Chrome 24. You’ll want to turn on Enable source maps in the settings, and Support for Sass in the experimental settings tab. Update: If the “Experimental” tab is not visible yet, visit chrome://flags first and turn on “Enable Developer Tools experiments”.

Next, make sure the output style of Sass is anything but ‘compressed’. Finally you’ll have to enable debug info – if you’re compiling from the command line, pass the --debug-info flag. If you’re using Compass, add this line to your config.rb:

sass_options = { :debug_info => true }

Now when you compile your CSS you should see lines like these preceding every selector in your compiled CSS:

@media -sass-debug-info{filename{font-family:file\:\/\/\/Users\/lensco\/Sites\/lensco\/sass\/style\.scss}line{font-family:\0000336}}

The WebKit Inspector will turn all this into exactly what we need: original file names and line numbers!

Don’t forget to turn off the debug info in your production environment afterwards – you don’t want all these lines littering your final CSS.

box-shadow vs filter: drop-shadow

This post is the first topic I discussed in my jam session presentation at Fronteers 2012. It’s about the drop-shadow filter. You may have looked at it and thought “this is pretty much the same thing as a box-shadow” right? Well, not exactly. The big advantage of the drop-shadow filter is that it acknowledges the outline and transparency of an element.

Have you ever wanted a box-shadow that followed the shape of an element, including generated content, like a tooltip with an arrow? Or you wanted a box-shadow to take transparent parts of a .png into account? That’s exactly what filter: drop-shadow() does. It has the exact same syntax as the box-shadow property, except that inset drop-shadows and the spread value are not supported (yet?).

Yes, it’s an experimental property, and yes, it’s only supported in some WebKit browsers now. But according to caniuse.com there’s already 32.51% of web users with support. And since it’s usually a decoration type of enhancement you can start using this today. Or even use a regular box-shadow on browsers that don’t support filters yet. Keep an eye on browser performance though, as things tend to get laggy pretty quickly with these experimental filters. Here’s a final example with a transparent PNG:

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!

Prevent background-color bleed on touch screens

Here’s an issue I’ve ran into a couple of times related to subpixel rounding on touch screens: while zooming in, I was seeing background colors bleeding through on the edges of an element that also had a background image applied. Open this fiddle on your smartphone or tablet and zoom in, you may see something like this:

Browsing this thread on Stack Overflow I found a really simple workaround that may not work in every situation, but it did the trick for me:

outline: 1px solid #fff;

Just a 1 pixel outline in the same color as your page background, et voila!

Forget loading spinners, use a wait cursor

Update: Right after posting this I received quite a bit of feedback in defense of regular loading spinners. Some valid arguments in favor are summed up nicely in this Hacker News thread:

So think carefully before applying the following technique on a large scale. It might be suited in specific conditions though.


There are loads of funky “loading” animated gifs out there, and these days I also encounter a few CSS spinners. But a technique I haven’t seen a lot is simply using the cursor property to convey the message.

Desktop apps usually use the cursor to indicate that users have to wait. Most of the time the cursor is exactly where the user is looking, so they won’t miss the message. Browser support for cursor is very good too.

You shouldn’t solely rely on the cursor – graying out the loading parts of the interface works well too – but for your next web app you could try slapping a loading class to your body, or any other element, and using

body.loading { cursor: wait; }

You might have to explicitly add form elements and links to the selector, so they don’t trigger the default or pointer cursor. Adding !important won’t work. So something like this:

body.loading, body.loading input, body.loading a { cursor: wait; }

Here’s a quick demo. You can use other cursors as well, or even a custom one with the url(...) value – although animated images won’t work, and other restrictions apply.

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!

The CSS profilers are coming!

Back in August I talked about the lack of benchmarks or performance tools for CSS. In the meantime, the fine folk we call browser makers have been working hard on new developer tools to do just that: measure CSS performance. First the Opera team showed off their upcoming style profiler, and now the WebKittens are tinkering on a CSS selector profiler too.

One of the features of these tools is to calculate how long your selectors take and then show a list of the worst offenders. But as you can see from the screenshots, and as noted by Pavel Feldman:

I can see selector matching taking single digit milliseconds. I know from the timeline panel that layout takes hundres of milliseconds or even seconds.

So the relevance of this information may be rather marginal. Perhaps more interesting then is the fact that the Opera Dragonfly style profiler shows the exact moment and location of paint events and layout reflows. Definitely some exciting developments to keep an eye on!

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!)

Working with 8-digit hex colors (aRGB) in Internet Explorer filters

You’ve probably come across the use of CSS filters as fallback techniques for RGBa colors or CSS gradients for example. They have their limitations and implications, but they do come in handy sometimes. They look something like this:

.awesomesauce {
    background: rgba(0,0,0,.6);
    filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=#99000000,endColorstr=#99000000);
    }

Maybe you’ve noticed these weird colors that have 8 instead of the usual 6 hexadecimal digits. Well, these are aRGB colors, used in Internet Explorer filters but also in Android development among others.

The syntax is pretty easy: first a pair of digits for the alpha channel and then 3 pairs for the RGB channels, just like regular hex colors. But instead of specifying alpha as a percentage or a floating point like for RGBa colors, it is defined in a range from 00 to FF. To calculate the hex value from a decimal number in JavaScript:

hexAlpha = Math.floor(decimalAlpha * 255).toString(16);
// so:
// rgba(255,255,255,0) = #00ffffff
// rgba(0,0,0,.5) = #7f000000
// rgba(255,255,0,1) = #ffffff00 = #ffff00 = #ff0

To make it even easier, there are several RGBa to aRGB convertors out there.