I recently suggested that links in task item notes should open in new windows, or at least they should add the option to choose that behavior. Toodledo responded that they originally had this, but some people wanted every link to open in a new window, while others wanted subsequent links to recycle the new window. With both camps complaining, they just removed targets from the links altogether.

Anyway, here are two bookmarklets for Toodledo. Clicking these will modify the task note links to open in a different window.

• Open each task note link in a new window: ✔
• Open task note links in a reusable window: ✔°

Note: You will need to click this each time you load the page, or add a new item. Yes it’s clumsy, but this is only a band-aid until Toodledo adds the feature.

Those little search bubbles that popup on the New York Times website whenever you select text really annoy me. Clicking this bookmarklet on any NYTimes page will prevent them from appearing:

NYTfix

This is a 2-minute solution, there’s no domain checking or anything, all it does is remove existing bubbles then cancel the document’s mouseup observer, which the NYTimes site uses to trigger the search balloons. The bookmarklet was very quickly checked in Safari, Firefox and IE8, NYTimes text selection doesn’t work at all for me in IE6 or IE7.

• YouTube.com pages are now supported (see notes)
• Daily Motion videos are supported for new-style urls (see notes)
• Kink.fm player and listings page are now supported
• Sideload.com play links are now supported
• WordPress Blogs using Viper Video QuickTags are supported for YouTube
• All media links now open into new windows, so you won’t have to re-transmogrify a page with several media files after playing one. Note that this is dependent on the iPhone, sometimes it will blank other windows)
• Some content in iframes will now be converted.
• MotionBox, Viddler and Vimeo embedded videos, while not supporting iPod/iPhone alternate content, now link to their respective detail pages.

The main bookmarklet code was updated. This was necessary to workaround a frustrating oversight with Google Code hosting. Everyone will need to update their bookmarklet, in the future all updates will be automatic.

This has turned out to be far bigger than I ever imagined. Thank you to everyone for the links, feedback, compliments and ideas.

Known issues

LiveJournal pages redefine a bunch of core JavaScript functionality, breaking all kinds of stuff including jQuery. Additionally, they’re serving media in an iframe from a different domain, meaning JavaScript couldn’t access the frame even if they hadn’t broken it.

Notes

YouTube Internal pages
Because of a strange iPhone quirk, these links all need to go through the Google redirector, otherwise they bounce back to uk.youtube.com instead of playing.

DailyMotion
DailyMotion videos using new-style urls, which are usually about six digits long, work correctly. Videos using the old-style alphanumeric ID do not work yet. I’m probably just going to resort to building a simple web-service to grab those. Additionally, there is no way to programatically access the mp4 alternate content url, so I just linked to their iPhone pages. I’d prefer embedding QuickTime directly, but it’s just not possible yet.

iTransmogrify! is a bookmarklet for iPhone which transforms embedded Flash content into direct links to natively supported formats. That means YouTube videos and MP3s can now be played from the iPhone’s Safari web browser with just a few clicks.

Seeing it work is the best explanation:

On an iPhone? Try it now: iTransmogrify! (works in Safari and Firefox too)

Sorry, it took YouTube a long time to re-encode that for iPhone, here’s a baby panda:

Installation

To install the bookmarklet, just drag the link to your Safari or Firefox Bookmarks, IE users should right click and choose “Add To Favorites…” After adding the link, sync your iPhone.

Grab it now: iTransmogrify!

You can also add iTransmogrify from your iPhone!

More information, source code and bug-tracking is available on the iTransmogrify Google Code page.

Currently supported content:
• Default YouTube Object-Embed code
• YouTube bare Embed
• YouTube bare Object
• A variety of Flash-based MP3 players including Digg Podcasts

Lots more added: iTransmogrify update

Support for other embedded media sites will be added as I figure them out. Please report broken sites or suggest additional sources using Google Code issue tracker.

Acknowledgements

The first robust, script insertion bookmarklets I ever saw was Sumaato’s original Flickr GeoCoding bookmarklet.

Other sites also deserving links:

• Jan Wolter’s Dynamic Script Loading
• Andrew Sumin’s Modularity in JavaScript
• Mike West’s Scope in JavaScript was the refresher I needed to resolve one especially annoying object-scope bug.

iPhone graphic reference:

• iPhone Graphics locations
• Huge iPhone icons

Also, John Resig’s amazing jQuery JavaScript library. This project was the excuse I’d been looking for to finally dig in and learn it.

The name came from a late-night brainstorming chat with Bruce and was far more fun and interesting than the utilitarian ones I was thinking of. So thank you Bruce, and of course, Bill Watterson.

Results are in milliseconds (ms), smaller numbers are better. Asterisks indicate errors returned during the test.

All tests were served and run from a MacBook Pro 2.16 GHz Core Duo, iPhone tests were run on a 1st Generation 8 GB model. Firebug was disabled for the Firefox tests.

A few things which are immediately apparent:

MooTools is a solid performer. Not the fastest and not the slowest, but Valerio Proietti’s code is consistently impressive.

JQuery has gotten significantly faster in the most recent version, John Resig is also writing really good code.

At least as applies to Valerio’s set of selector tests, JQuery is the fastest library on iPhone, nearly twice as fast as MooTools and almost three times faster than Prototype. Joe Hewitt’s iUI project uses Prototype, how much would iPhone performance benefit from switching to JQuery?

The Webkit team is writing some seriously crazy speed optimizations. If they could just get Safari to stop leaking memory we’d be all set (don’t go looking all smug Firefox, you’re standing in a puddle). As it stands now, when Leopard ships Safari will have the fastest JavaScript engine available. The difference between jQuery and Prototype on Webkit and iPhone is surprising, iPhone runs JQuery nearly three times faster than Prototype using the same browser core.

Firefox runs faster in virtualized Windows than it does native on the Mac. Camino (Mac native version of Mozilla/Firefox/Gecko) was slightly faster, but still not as fast as Firefox Windows.

I’ve got one project wrapping up soon which used MooTools and I’ve been very happy with it. Lately I’ve been reading a lot of buzz about JQuery and might be working that into another project. These tests were mostly just done to satisfy my own of curiosity.

February 2011 Update: This post was originally published in 2007 and hasn’t aged well. For code snippet syntax coloring, I currently use Google’s Prettify script (prettify.js). The script is dynamically inserted by jQuery if there are code elements to style.

Recently I’ve been experimenting with two very different methods of syntax coloring source code in web pages. The first method uses a Dan Webb’s CodeHighlighter JavaScript library to convert appropriately tagged content into syntax colored code. It’s necessarily simple, but easily extensible. As an example, here are the CSS rules I’m using to style CodeHighlighter’s conversions:

code.html span.comment         { color: #999;}
code.html span.tag             { color: #07f;}
code.html span.string         { color: #080;}
code.html span.attribute     { color: #07f;}
code.html span.doctype         { color: #07f;}

code.css span.comment          {color: #999;}
code.css span.keywords         {color: #fd2;}
code.css span.selectors        {color: #0b0;}
code.css span.properties    {color: #66f;}
code.css span.units            {color: #33c;}
code.css span.urls            {color: #4a0;}

code.javascript span.comment     { color: #999; }
code.javascript span.brackets     { color: #07f; }
code.javascript span.string     { color: #4a0; }
code.javascript span.keywords     { color: #07f; }
code.javascript span.exp         { color: #808; }
code.javascript span.global     { color: #06e; }

The second method uses two more fantastic TextMate features, Create HTML From Selection and Create CSS from Current Theme. What these two commands do is translate exactly what I’m seeing in TextMate into very precise and valid XHTML with accompanying CSS rules. The main disadvantage of this is the weight of the code, the above 721 bytes of CSS converts to nearly 36k of HTML and CSS rules. It’s a seriously heavy pile of span tags, but the cost is immediately outweighed by 148 very specific reasons. And that’s just bundles, there are dozens of great themes too.

Aaron Quint also deservingly gushes over these two commands.

What these do is convert exactly what I’m seeing in TextMate into very precise and valid XHTML. Here’s the same CSS as above translated by TextMate:

code.html span.comment      { color: #999;}
code.html span.tag          { color: #07f;}
code.html span.string       { color: #080;}
code.html span.attribute    { color: #07f;}
code.html span.doctype      { color: #07f;}

code.css span.comment       { color: #999;}
code.css span.keywords      { color: #fd2;}
code.css span.selectors     { color: #0b0;}
code.css span.properties    { color: #66f;}
code.css span.units         { color: #33c;}
code.css span.urls          { color: #4a0;} 

code.javascript span.comment    { color: #999;}
code.javascript span.brackets   { color: #07f;}
code.javascript span.string     { color: #4a0;}
code.javascript span.keywords   { color: #07f;}
code.javascript span.exp        { color: #808;}
code.javascript span.global     { color: #06e;}

Just for the sake of comparison, below is a screenshot of how my code looks in TextMate. It’s not a perfect translation, but it’s a very good start:

One of the purported advantages of the JavaScript method is that the source code remains unchanged. That’s sort of true, but not really. The JavaScript functions work by inserting a bunch of spans, so by the time the user sees it the main difference between JavaScript converted code and pre-processed code from TextMate is the detail (and weight) of the TextMate result. Also, any HTML would need to have entities escaped which is another step and a further degradation of the original code.

The main advantage then becomes convenience. A simple block of code doesn’t need to be run through TextMate (on the off-chance I’m writing somewhere else), it can be entered directly and tagged for styling without breaking focus.

Yesterday morning I noticed a change to the JavaScript/DOM getSelection() behavior in the new Safari 1.3 (in 10.3.9) and the most recent version of Firefox 1.0.3.

I’ve been using this method for years to pull selected text from web pages for several of my bookmarklets. The one I use most frequently generates a link from whatever text is selected. If nothing is selected, it grabs the document’s title. The change in getSelection() broke that bookmarklet, no selected text was recognized.

After a bit of research, I found Mozilla’s Safely accessing content DOM from chrome page which describes the security fixes behind the modification and detailing other problems the changes had caused. Based on Mozilla bug 290777 and this post by Buzz Anderson, both browsers seem to have problems with the change. Despite those bugs, I managed to find the simple workaround as described below.

What Safari and Firefox now seem to be doing is creating a DOM selection object from getSelection() instead of treating it as a simple string. The result is that getSelection() appear to be a string, but few of the string manipulation functions work without additional considerations.

The following examples are all intended to be tested as bookmarklets, drag them to your bookmarks bar for testing:

• getSelection() test 1
  javascript:d=window.getSelection();
alert(d);

  Works as expected in Safari 1.2.4, Safari 1.3 and Firefox 1.03, popping an alert containing the selected text. Trying to measure that returned string fails in Safari 1.3 and Firefox 1.0.3 but works in Safari 1.2.4:

• getSelection() test 2
  javascript:d=window.getSelection();alert(d.length);

  The older version of Safari returns a character count for the string of selected text. Firefox and Safari 1.3 return “undefined”. There are quite a few other problems:

• getSelection() test 3
  javascript:d=window.getSelection();
alert(d.toString());

  Works in Firefox and Safari 1.2.4 but not in Safari 1.3.

• getSelection() test 4
  javascript:d=window.getSelection();
alert(d.toString().length);

  Getting the length after toString works in Safari 1.2.4 and Firefox.

Further inconsistencies between Safari 1.3 and Firefox 1.0.3:

• getSelection() test 5
  javascript:d=window.getSelection();alert(d.type);

  Returns “Range” in Safari with a selection, returns “Caret” or “None” with nothing selected. Fails with “undefined” in Firefox. (I think the Firefox 1.0.3 DHTML regression bug might be preventing it from working in Firefox but I didn’t try any of the recent nightly builds.)

• getSelection() test 6
  javascript:d=window.getSelection();
alert(d.getRangeAt(0));

  Fails silently in Safari, returns selected text in Firefox. Safari dumps this into the Console log:
  [5956] :TypeError - Value undefined (result of expression d.getRangeAt) is not object.

• getSelection() test 7
  javascript:d=window.getSelection();
alert(d.typeDetail);

  Fails with “undefined” in both.

There is some good news:

• getSelection() test 8
  javascript:d=window.getSelection();
alert(d.isCollapsed);

  Works in both Firefox and Safari 1.3; fails in Safari 1.2.4 as “undefined”. This means (finally!) there is a workaround for my problem.

I was using the length property to determine whether a selection was empty or not, then fetching the title of the window if that value was 0. Knowing that length no longer works in Firefox and Safari, isCollapsed can be used as a conditional switch.

• getSelection() Workaround
  javascript:d=window.getSelection();
d=(d.isCollapsed||d.length==0)?document.title:d;
alert(d);

  That will return any selected text or the document title if there is no selection. Tested successfully in Safari 1.2.4, Safari 1.3, Firefox 1.0.3 and presumably Safari 2.0 as well.

Line breaks were added to visible code examples because my style-sheet choked on long lines and I can’t redo the CSS right now…

Update: After working through all of the above, I realized there is a far simpler solution: +''. The Safari problem seems to be that string methods do not work on the returned object from getSelection(). Forcing the result into a string by concatenating with an empty string fixes all of my bookmarklets. Concat() fails because it’s a method of string, use the "+" joining operator and an empty string '' instead.

• getSelection() Faster Fix
  javascript:d=window.getSelection()+'';
d=(d.length==0)?document.title:d;
alert(d);