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.

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.