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.

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.

CSS Sass preprocessors Chrome WebKit tricks source maps

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!

layout spec WebKit Opera Firefox CSS

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.

subpixel WebKit browsers letter-spacing

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;
    }

colors webkit Inspector customize

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!

opera webkit benchmark profiling css performance

Some notes on bouncy CSS transitions

• Earlier this year the CSS transitions specification was rewritten so that transitions with a custom timing function (using cubic-bezier) would no longer be clamped between the start and end values, making it possible to add a rubber-band bounce to your transitions. Opera and Firefox already implemented this, and recently the related WebKit bug was fixed, so we can start experimenting with bouncy transitions now!

• This rubber-band bouncing doesn’t only work for things like position and transform, it equally applies to animated colors, shadows, borders, font-sizes, etc. Of course, transitions won’t extend across minimum or maximum values – you can’t go darker than rgb(0,0,0) for example.

• If you need real bouncing though – with more than one bounce – you’ll still have to use keyframe animations, as cubic-bezier curves only take two user-defined control points. Dan Eden made a nice library of ready-made animations to drop into your project. Apparently browser vendors and spec writers are currently looking into defining more timing functions like bounce however.

• If you want to play around with cubic-bezier curves look no further than Cubic-Bezier or Ceaser, two essential tools to comprehend and play with CSS timing functions.

animations css spec cubic-bezier webkit

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.

css tricks chrome webkit inspector customize