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

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.

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;

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!

Some notes on bouncy CSS transitions

Customize the WebKit Inspector (Chrome Dev Tools)

I’ve never thought of this, but Darcy Clarke proved you can customize the WebKit Inspector (and Chrome dev tools) simply by editing your user stylesheet. Check the post and comments for some examples of syntax highlighting themes. Neat!

Considering my WebKit Inspector wish list, I added some styles to clean up and improve the styles panel – including moving the enable/disable checkboxes to the left (this is actually being implemented as well). Now that user agent styles can be hidden and Alexander Pavlov is implementing different highlight colors for paddings and margins, the wish list is getting a lot shorter!

This is before and this is after. Here’s the documented custom.css file.