Archive for May, 2009

Internet Explorer 6 Duplicate Characters Bug

Monday, May 11th, 2009

Just for reference if you come across the old issue with IE 6 duplicating characters at the end of a block of text, check out this article at Position Is Everything.

Opening a Link in a New Window, and How Not To

Friday, May 8th, 2009

I often tell everyone here to avoid examples of JavaScript on the Internet, because more often then not it’s incorrect. The same goes for most of the popular examples of how to cause a link, an A tag more specfically, to open in a new window.

The most popular and incorrect way is using the target attribute:

<a href="http://www.example.com/" target="_blank">Using Target</a>

The target attribute was meant to direct content to load in a specific frame. In this case the keyword directs the browser to load the page in a new window, but with frames long dead and gone this little gem lives on as a reason people “can’t use HTML Strict.”:

The most common solution that people came up with this was to use JavaScript, but in some strange ways. Instead of opening the link directly, the page would go to an anchor and JavaScript would open the URL in a new window:

<a href="#" onclick="window.open('http://www.example.com/');">Using Onclick</a>

The HTML will validate, but if JavaScript is disabled the link won’t go anywhere, and it can’t be copied via a contextual menu. On top of that clicking on the link will cause the page to jump to the top, unless you add “return false;”:

<a href="#" onclick="window.open('http://www.example.com/'); return false;">Using Onclick</a>

Another approach to avoding the jump was to place JavaScript within the href attribute:

<a href="javascript:window.open('http://www.example.com');">Using inline JavaScript</a>

While inline JavaScript has its novel uses, this isn’t one of them. This method doesn’t offer much over the previous one and can be complicated even further when a wrapper function is called instead:

<a href="javascript:wrapperfunction();">Using inline abstracted JavaScript</a>

The only way to fix the issue of JavaScript being disabled was to put the link back in the href attribute:

<a href="http://www.example.com/" onclick="window.open('http://www.example.com/'); return false;">Improved use of onclick</a>

Using “return false;” stops the link from executing, allowing the URL to be put back in the href. This is the farthest I’ve seen any site go. it’s technically complete, but redundant. One last bit of JavaScript fixes that:

<a href="http://www.example.com/" onclick="window.open(this.href); return false;">Ideal use of onclick</a>

The redundancy is elimanted by using this.href. “this” refers to the current object in context, being the A tag. The “href” references the A tags href property and the value (URL) contained within.

The end result is a small generic addition to any A tag to make it open in a new window. The tag will pass HTML strict validation, “SEO” is preserved and if JavaScript is disabled everything keeps working.

Basecamp Writeboard & Message Erratic Formatting

Friday, May 8th, 2009

If you rely heavily on Basecamp, a project management service by 37signals, then you’ve probably run into issues with erratic formatting in Writeboards and Messages. The contextual documentation is sparse at best and doesn’t explain how to stop the unintended formatting caused by the inadvertent use of reserved sequences.

Through a little experimentation, it seems that most HTML tags are left unencoded. While unexpected and also potentially problematic this behavior has it benefits. The <code> and <pre> tags – and possibly more – turn off the Basecamp formatting engine and make it possible to preserve text that would otherwise be mis-formatted.

So next time you notice strange formatting, try surrounding your text in either <code> and <pre> tags. Remember that while these tags won’t show up in the message itself, they will appear in any notification e-mail, but the same is true for standard Basecamp formatting.