Bite-sized CSS & HTML nuggets

Quickly toggling elements in the Web Inspector

Here’s one Web Inspector shortcut I didn’t know about (although it’s listed in the shortcuts): just press the h key in the Elements tab and the currently selected element will be hidden. What happens is that the __web-inspector-hide-shortcut__ class is toggled on that element, with the following CSS:

.__web-inspector-hide-shortcut__, .__web-inspector-hide-shortcut__ * {
    visibility: hidden !important;
    }

Now, maybe you don’t want this hidden element to take up any space, and use display: none;? (In fact you can easily ‘hijack’ this shortcut and apply whatever CSS you want.) Just add these lines to your Custom.css:

.__web-inspector-hide-shortcut__ {
    display: none !important;
    }

Super easy quick toggling of DOM elements in the Web Inspector, yay! The Safari Web Inspector behaves somewhat similarly, but it doesn’t use a class, and applies these properties inline instead:

pointer-events: none !important;
opacity: 0 !important;

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:

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!

Easily checking in JavaScript if a CSS media query has been executed

For quite a while I have been looking for a way to “mirror” my CSS media queries in JavaScript, but without duplicating the actual queries. Of course, you can use matchMedia to evaluate a media query in JavaScript, but then you have to maintain your breakpoints in two places – not ideal.

Paul Hayes devised a clever method in his fork of the match­Me­dia poly­fill, using transitions on dummy elements and watching for the tran­si­tio­nEnd event in JavaScript. But a truly simple solution – one that doesn’t really need watching for resize events – was still lacking.

Fortunately Jeremy Keith turned to his readers for help, and together they came up with a delightfully straightforward technique:

@media (min-width: 45em) {
    body:after {
        content: 'widescreen';
        display: none;
        }
    }

Which basically doesn’t do anything, except that you can check for it in Javascript:

var size = window.getComputedStyle(document.body,':after').getPropertyValue('content');
if (size == 'widescreen') {
    // go nuts
}

Nice!

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.

One-sided box-shadows

Credit for this trick goes to Stephanie (Sullivan) Rewis – and commenters – who came up with a solution to a problem a few of us have encountered: you want a box-shadow to appear on one side only, without any faint shadows bleeding through on other sides.

Turns out you can use a negative spread value for this. The trick does have its drawbacks so it might not work in every scenario, but it’s definitely interesting. It also works for inset box-shadows, check out these examples from Conceptboard.

Going unprefixed with border-radius?

Can you believe it’s more than 6 years ago that the WebKit team implemented border-radius? Looking at the support tables you can see that basically all browsers now support the border-radius property unprefixed. (Unfortunately Firefox 3.6 seems stuck with a long tail, but if you don’t care about that remaining 8% you can now safely dump those prefixes.)

Edit: There are still several dozens of mobile WebKit-based browsers, so you might want to hold on to those prefixes a little while longer. Also, Firefox 1.0 implemented -moz-border-radius back in 2004 already…

All of the layout and rendering issues with border-radius have been fixed in the meantime, allowing you for example to make a simple class for completely round corners when you don’t know the height of the element:

.radMax {
    border-radius: 999px; /* when it needs to be really round */
    }

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!

A few notes on CSS hyphenation

By now you’ve probably read about CSS hyphenation somewhere on the web. Using it is as simple as:

p {
    -webkit-hyphens: auto;
    -moz-hyphens: auto;
    hyphens: auto;
    }

But maybe you missed some of the finer details about it, so here’s the lowdown.

(Edited with some additional info)