Inline SVG

Okay, I’m currently ripsnort delighted to have found a solution to this problem of rendering SVG element dynamically. As in:

  1. My web apps receive some <svg>...<svg> from an Ajax call
  2. ???
  3. Super, there’s a drawing on the page!!!

What is the secret sauce in step 2?

After a merry frolic through the majority of the internets and a dozen prototypes, I finally found the answer. In essence, you just create an “object” element with type and data settings:


  1. var svgObject = document.createElement('object');
  2. svgObject.setAttribute('type', 'image/svg+xml');
  3. svgObject.setAttribute('data', 'data:image/svg+xml,'+ svgCode); // the "<svg>...</svg>" returned from Ajax call
  4. $("#reportSVGDiv").append(svgObject);

It works in Firefox, and the article explains how to get it working in IE too, which I don’t need just yet.

A few other things I learned and tried:

  • I initially, naievely, tried just adding the SVG via innerHTML. As Jeremy explained to me, this doesn’t work because the browser uses a different compiler for HTML compared to pure XHTML. (And TiddlyWiki, like most things on the web, is HTML.) Even with an <object> tag around it, it won’t just switch over.
  • The easiest way to do this is to use a .svg suffix (or probably set mime type to svg, but this is tiddlywiki and I’m working from file:// URLs, where it’s not possible to set mime type). But then you can’t embed it on the page – you’d have to point to it from an embed tag or object tag.
  • You can inline the SVG if you write “pure” xhtml, and for this, you have to give the file a .xhtml suffix. As in this example.
  • I tried the Inject HTML into an iframe technique. I was hoping that with the right XML declaration and HTML type, I could convince the iframe it was hosting XHTML. But no, I could not. I’m still interested to know if there’s any way I could convince a dynamically generated iframe, with dynamic content, about the type of content it contains.

This is all part of some recent prototyping on an exciting TiddlyWiki project involving rich text editing, among other things. In a later blog post, I’ll explain how we’ve used this SVG stuff to mash up an online chart drawing tool with TiddlyWiki. I’m currently packaging it into a plugin.

Google jQuery CDN

NO LONGER UPDATED: July 2012. This page is no longer indexed prominently in Google, so keeping it up-to-date is not much use to anyone. So consider updates finished. Try this link instead

SUMMARY: Get the latest jQuery here:

To include in your web app, cut-and-paste this:

<script src=””></script>

You can also cut-and-paste one of the following to suck it down:

  • curl -O
  • wget

With the release of JQuery 1.3, I thought I’d mention the Google JQuery CDN, one of several libraries you can yoink from Google’s Ajax Libraries API. Instead of hosting your own JQuery, you just point your web app to Google’s JQuery:

<script type=”text/javascript” src=””></script> (Modified version from 1.3. I’ll try and keep this post linking to the latest version.)

Google’s documentation would lead you to believe you need to import Google’s library, and then call google.load(), but it’s unnecessary; just pull in the script directly using the link above. The link is officially documented, so it’s going to stay put for a very, very, long time.

There are also other libraries available on Google’s CDN and elsewhere.

The main point of the CDN is caching. If a user hits 100 JQuery sites, the library will only be downloaded once, and the remaining 99 sites will pull it from the local cache. From an operation cost, you also get to offload the cost of server Javascript to Google. As an added bonus, I also find it easier as a developer to kick off a new project by just linking to the CDN – no need to download and copy the latest version of JQuery.

Great. So when not to use a CDN?

Obviously, whenever you’re working offline. This sometimes occurs as a developer working locally, and with Single Page Applications like TiddlyWiki. (The next “major minor” release of TiddlyWiki, v2.5 is JQuery-powered.)

Another case would be when you can deliver faster than the CDN, and care about that. This might be the case when all users are close to the server. Even then, though, you won’t get the local cache benefit from users who already have the JQuery.

Finally, privacy and security concerns. Using the CDN, you are trusting the CDN to faithfully serve JQuery and relying on no third-parties injecting funniness in between the CDN and your user’s browser. If anything went wrong here, your user could be subject to a world of XSS and CSRF attacks. Or, in a more mundane scenario, the CDN might simply go down, thus breaking your web app. Furthermore, you’re giving the CDN data about your users this way. Although Google doesn’t use cookies, others might; and even if they don’t, the IP number is going to be sent back to them. The referrer – being your website – will also be sent to them, so they can, if they want, track your website’s usage.

For many websites, though, it’s great that we can use a reliable CDN like Google’s to fetch JQuery fast.

Update (11-Feb-2009): In a show of recursive linking, I should fess up as to why I originally sat down to wrote thistwitter message.

Update (erm, mid-2009 sometime): Montana left a comment pointing out you can also drop off the minor numbers to get the latest version. So, for the latest JQuery (since 2.0 doesn’t exist), use Or, for the latest in the old 1.2 series:

Update (19-March-2010): Scratch that. @premasagar pointed out to me that the link to just the latest version (until 2.0, i.e. as opposed to a specific version ( is undesirable; Google will expire the “latest” content after one hour, as opposed to one year for a specific version. This is for good reason of course, as the latest version is subject to change. For this reason, I’ve reverted the link at top to be a specific version, which I’ll endeavour to update upon each new release.

“Ajax”, not “ajax”: A Fitting Name for a Pattern

Consider this “Ajax”, not “AJAX”, Part II. A blog post in two parts, each part as trivial-bordering-on-absurd as the other.

Spotted as a parenthetical remark in a recent Doug Crockford article:

I am writing ajax in lower case because I think ajax has become ordinary enough that the caps are no longer justified.

That’s a new one.

“AJAX” in 2009 is as ridiculous as RADAR or LASER, but “ajax” is a step too far. I still prefer “Ajax” to “ajax”. Reason being, it’s a design pattern. Just as we say Strategy, Abstract Factory, or Singleton, we ought to say Ajax. Admittedly, each of those patterns includes an entity sharing the same name as the pattern, and being a class, the entity is capitalised; in Ajax, there is no actual “entity” called Ajax, so you might say ther’es no reason to capitalise. However, patterns outside software design are still capitalised, e.g. among Tim O’Reilly’s patterns of Web 2.0 are Hackability and Play, not hackability and play.

The objctification, even anthropomorphisation, of patterns is a big part of their power. Once you see a pattern as a living thing, you can see it as something that evolves over time and is capable of forming relationships with other patterns. In that, there is a close analogy between patterns and such software entities as classe and tables.

ajax > AJAX, but I <3 Ajax.