Bite-sized CSS & HTML nuggets

Say hello to the color picker in WebKit Inspector

If you’re using the Chrome dev channel or the WebKit Nightlies, you might have noticed this already: previously, when you clicked the colored square on the left of a color code in the WebKit Inspector, it used to cycle through different color formats. That’s still possible when you shift-click it (alt-click on Windows), but a regular click will now spawn a color picker. It was on my WebKit Inspector wish list 2 years ago, and now seems to have finally made it in! No more need to switch to another app just to pick a color for an element on your page. It doesn’t allow you to sample colors on screen, but I presume that’s a lot harder to do.

Since you can easily customize the WebKit Inspector, I got rid of the confusing double background of the widget. Here are the selectors you can use for the color picker – though I’m not sure where the original yellow background is defined?

/* color picker styles */
.spectrum-container {
    background: #ffffc2 !important;
    border: 0 !important;

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.

Simple responsive design test page

There are some pretty complex testing tools for responsive designs out there. I even see people constantly resizing their browser window using on-screen rulers. The easiest approach to me is just a simple page with a bunch of iframes, like Matt Kersley’s test page. Because I always ended up refreshing the whole page rather than the URL bar on that page, I saved the file locally and tweaked it a little.

Somebody recently asked me to share it, so here it is. Just drop this HTML document in the same folder as your index page and open it – it’s dead simple, really!

<!DOCTYPE html>
    <meta charset="utf-8">
    <title>Responsive Design Testing</title>
        body { margin: 20px; font-family: sans-serif; overflow-x: scroll; }
        .wrapper { width: 6000px; }
        .frame { float: left; }
        h2 { margin: 0 0 5px 0; }
        iframe { margin: 0 20px 20px 0; border: 1px solid #666; }
    <div class="wrapper">
        <div class="frame">
            <h2>320 &times; 480 <small>(mobile)</small></h2>
            <iframe src="./" sandbox="allow-same-origin allow-forms" seamless width="320" height="480"></iframe>
        <div class="frame">
            <h2>480 &times; 640 <small>(small tablet)</small></h2>                   
            <iframe src="./" sandbox="allow-same-origin allow-forms" seamless width="480" height="640"></iframe>
        <div class="frame">
            <h2>768 &times; 1024 <small>(tablet - portrait)</small></h2>                   
            <iframe src="./" sandbox="allow-same-origin allow-forms" seamless width="768" height="1024"></iframe>
        <div class="frame">
            <h2>1024 &times; 768 <small>(tablet - landscape)</small></h2>
            <iframe src="./" sandbox="allow-same-origin allow-forms" seamless width="1024" height="768"></iframe>
        <div class="frame">
            <h2>1200 &times; 800 <small>(desktop)</small></h2>
            <iframe src="./" sandbox="allow-same-origin allow-forms" seamless width="1200" height="800"></iframe>

Update: Ben Keen turned this into a very handy bookmarklet. Reloading the page will kill the effect of course, but still very useful for quick one-shot tests.

Update 2: Here’s another bookmarklet based on this idea by William Golden.

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!

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

Using letter-spacing breaks right-to-left text in Opera on Windows

Granted, this might seem a pretty exotic scenario, but a very plausible one nevertheless: using letter-spacing breaks right-to-left text in Opera on Windows. On Windows XP the character order seems to be reversed, and on Vista and Windows 7 the order is fine but characters are no longer joined – while scripts like Arabic, Urdu, etc. rely on this. (Thanks to @BifterComic for the Vista results.)

Here’s a JSFiddle to test, and some screenshots to get an idea. The first line is without any letter-spacing, the second one has a positive value, and the third line has a negative letter-spacing.

So if you have a page with RTL text, remember to reset any letter-spacing to avoid running into this issue. I filed a bug at Opera to report it.

Update: Apparently the Opera team was working on some issues with hardware acceleration, which fixed this bug. The fix is in the new development snapshot, so it shouldn’t take too long for this bug to eventually disperse into thin air.

Using an icon font as a web font – introducing Fico

A technique that hasn’t been researched and used enough in my opinion, is the use of an icon font as a web font. There are many advantages to this approach, rather than using images. You can:

One problem with icon fonts that can make them less than ideal for font embedding, is that they’re often big files. That’s one of the reasons I created Fico, a limited set of simple icons specifically tailored to use on the web. The icon set might grow in the future, but it will always remain a lightweight solution for using icons on your website. Give it a spin!

There’s some more info and techniques about this on the Fico website, and coincidentally Chris Coyier from the excellent CSS-Tricks posted this today as well: Icon Fonts are Awesome.

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.