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;

Auto-hiding scrollbars in IE10

Was just looking for a way to make the scrollbars in Internet Explorer a little less obtrusive, and I found this.

-ms-overflow-style: -ms-autohiding-scrollbar;

This gives you scrollbars that appear during touch and keyboard interactions, and fade out again after a few seconds. Nice. redesign - feedback wanted

I’ve posted the following earlier this week on Dribbble, and we’ve got some great feedback so far. But we can use as much input as possible, so I’m posting this here as well.

Over the course of the past few months, I’ve been working on a redesign of together with Alexis Deveria aka @Fyrd, author of the site. If you don’t know yet, it’s an essential resource with compatibility tables for support of HTML5, CSS3, SVG and more in desktop and mobile browsers. Its current design is in need of a refresh, and while we’re at it we’re improving the usability, clearing up some clutter and making it responsive. The goal was to make a really clear and simple design so you can get to the information you’re after as easy and fast as possible.


This is just a screenshot of a work-in-progress prototype I’ve built, you can see it in action at Some notes:

It is our intention to gather feedback from this prototype and continue improving the design, out in the open, on Dribbble/Twitter/etc. So, do you see something that needs improvement? Is the responsive design not working on your device? Does this design make sense for color-blind people? Let us know on Dribbble or Twitter!

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 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:

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!

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!

Subpixel layout coming to WebKit

If you’ve ever tried to get precise em-based values of letter-spacing to work in a WebKit browser, you’ve probably wondered why that isn’t really possible, while Firefox or Internet Explorer 10 for example do allow fine-grained control. Play around with this demo in various browsers and you’ll see what I mean.

The underlying reason is that WebKit currently uses integers to calculate pixel positions, while Firefox allows subpixel units to represent locations and sizes. This affects not only letter-spacing of course, but also things like rounding errors while zooming or applying transforms. There has been an ongoing effort to switch WebKit to use subpixel layout, and a few days ago Levi Weintraub and Emil A Eklund landed a patch that should put subpixel layout on the fast track. Look forward to more precision coming soon to WebKit-based browsers.

Here’s some technical background on this matter, and an article on subpixel rendering and the CSS Object Model from the IE team.

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