How to change the font size in Chrome Developer Tools

When presenting on JavaScript or jQuery I’ll typically spend a lot of time in the Chrome Developer Tools window at the console. The problem is that, depending on the projection facilities and the resolution the fonts can be too small to read.

The Chrome devtools themselves are built out of HTML and CSS so I started digging for how I could edit the stylesheet. You can view the default devtool stylesheet by navigating to chrome-devtools://devtools/devTools.css. You can’t easily edit this though (it’s probably buried as a resource within Chrome), but you can override its styles using the standard custom user stylesheet Custom.css!

Custom.css lives at:

Windows: C:Users<user>AppDataLocalGoogleChromeUser DataDefaultUser StyleSheets
Mac OS X: ~/Library/Application Support/Google/Chrome/Default/User Stylesheets/

The style(s) to add and override in Custom.css are:

body.platform-mac .monospace, body.platform-mac .source-code {
    font-family: Monaco, monospace;
}

/* Keep .platform-mac to make the rule more specific than the general one above. */
body.platform-mac.platform-mac-snowleopard .monospace,
body.platform-mac.platform-mac-snowleopard .source-code {
    font-size: 11px !important;
    font-family: Menlo, monospace;
}

body.platform-windows .monospace, body.platform-windows .source-code {
    font-size: 12px !important;
    font-family: Consolas, Lucida Console, monospace;
}

body.platform-linux .monospace, body.platform-linux .source-code {
    font-size: 11px !important;
    font-family: dejavu sans mono, monospace;
}

A nice touch is that the styles update automatically as you save Custom.css so you can tweak it on the fly to get the right font-size for your audience.

Hope that helps!

Fight Spam with jQuery!

OK, maybe title should actually be “Prevent email address harvesting with jQuery”. But anyway – I came up with a technique for our company web site today which will hopefully prevent some of the email addresses that we publish being picked up by email address-harvesting bots. The idea is that an email address is put on the website using the following obfuscation:

<span class='email'>joebloggs [at] example [dot] com</span>

And then transformed by JavaScript into:

<a href='mailto:joebloggs@example.com'>joebloggs@example.com</a>

It’s a progressive enhancement in that the content is still quite legible by people with JavaScript turned off. Here’s the jQuery script that does it:

$(function() {
   $('.email').each(function() {
      var $email = $(this);
      var address = $email.text()
         .replace(/s*[at]s*/, '@')
         .replace(/s*[dot]s*/g, '.');
      $email.html('<a href="mailto:' + address + '">' 
         + address +'</a>');
   });
});

I’m perhaps being naïve about how email addresses are collected these days, and maybe embedding email addresses in images is a better approach – but this was quick and simple and worth a try.

IE 6 bug causes jQuery globalEval error

UPDATE: this is fixed in jQuery 1.2.6 and later, see ticket #2709.

After upgrading our code base to use the latest jQuery 1.2.3 (previously we were using 1.2.1) our testers discovered a quite ridiculous bug in IE 6 that caused jQuery to fail (IE 7 is fine, which is why we didn’t experience it development). The issue manifested itself as the script error message “Problems with this web page might prevent it from being displayed properly…”

Line: 24
Char: 76
Error: Invalid Argument
Code: 0
...

…and various document.onready handlers not running.

Of course line 24, char 26 doesn’t really help much because IE always seems to get this a few lines out of whack and with the minified version of jQuery it would be way out. So I replaced the minified version jQuery.js with the uncompressed version, cleared the browser cache and re-visited the web app in IE 6. This then gave line 659, char 4 as the offending location:

After whacking in a several alert()s in the lines in the vicinity of 659, it turns out the issue is with head.removeChild(script) in the globalEval function, 4 lines up. Obviously.

So, why was head.removeChild failing? I put the following debug code in:

alert(head.tagName) // displays "HEAD" as expected
alert(script.parentNode.tagName) // displays "BASE" !!!

So, it transpires that our pages having a <base> tag within the <head> contributes to the issue. IE 6 seems to get totally confused as to the structure of the document HEAD when there’s a self-closing or unclosed BASE tag. BASE tags I suppose are quite rare and this is probably why this issue doesn’t appear to be commonplace. (The BASE tag is in there for legacy reasons in our code, but they’re also quite useful when you save the source of HTML pages they still pick up images and script from the originating server which is handy for debugging automatically-generated HTML.)

So, before, the offending base tag looked something like this:

<base href='http://example.com/blah' />

After some experimentation it appears IE6 doesn’t exhibit its odd behaviour if you do this instead:

<base href='http://example.com/blah'></base>

Job done.

Update: Chris Venus comments about the reason for the weird behaviour in IE6 and earlier. Previously <base> was interpreted as a container, which could appear multiple times in a document: different sections within the page could have different bases, so would logically end up wrapped within each <base> (now there’s a feature everybody wanted, right?). Because of this, <head> got treated as a “section” of the document and elements added to it ended up as children of any <base> it contained rather than siblings. See IEBlog: All your <base> are belong to us.