I've been backposting stuff originally posted on tumblr, SVrider1, and ADVrider2 onto my blog here. To make the older posts more accessible, I decided the blog needs a lazyloader.

I'd recently read a post by Alexander Micek on infinite scrolling, and I appreciated his aversion to hashbangs and poor user experience. After a day of adapting his code to this blog's purposes, I'd managed to make it very generic.

If you're interested in adding infinite scrolling to your own site, you're welcome to use it as inspiration or implementation. I've added a whole bunch of documentation and put it on gist.

edited on friday january 13th, 2012 at 14:06:

Henry took an interest in the code and we discovered that you can't easily pull others' changes back into a gist. The infinite scrolling code is now part of jslib, as infScr-x.y.z.js and infScr-x.y.z.min.js.

1 the death valley trip (original)
2 cross country trip parts: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13/14, 15, 16 (original)

composing stick stores posts as xml snippets that, after being sent through a simple markup translator, can be dropped on a page with any content (especially other posts). care is taken to make sure that posts do not interfere with each other or change any global state.

but lately I've been using a fair amount of javascript in posts, and I wanted a way to prevent loading libraries multiple times. if a library is not written well, reloading its source file could destroy its internal state. some sort of include guard is needed for posts to continue to be able to stand alone.

I think I've found a solution. put the following into a file called include_once.js:

String.prototype.trim = function () {
  return this.replace(/^\s*/, "").replace(/\s*$/, "");
}

String.prototype.basename = function() {
  return this.replace(/^.*\//, '');
}

Node.prototype.insertAfter = function(newNode, refNode) {
  if(refNode.nextSibling) {
    return this.insertBefore(newNode, refNode.nextSibling);
  } else {
    return this.appendChild(newNode);
  }
}

var scripts = document.getElementsByTagName('script');
var tracked_files = tracked_files || {};
// unfortunately, Javascript doesn't do __FILE__
var this_file = "include_once.js"

for(var i = 0, ii = scripts.length; i < ii; i++) {
  if(!scripts[i].src || scripts[i].iterated) continue;
  scripts[i].iterated = "yes";

  /* if there's a # in the filename and the preceding portion is this file's name,
   * then include the string after the # as the script to guard.
   */
  var files = scripts[i].src.split('#', 2);
  if(files.length == 2 && files[0].basename().trim() == this_file) {
    //console.log("called to include: "+files[1]);

    // only load each script once.
    if(tracked_files[files[1]]) continue;
    tracked_files[files[1]] = files[1];

    // first time!
    var newcontent = document.createElement('script'); 
    newcontent.src = files[1];
    newcontent.type = "text/javascript";
    newcontent.charset = "utf-8";
    newcontent.iterated = "yes";
    scripts[i].parentNode.insertAfter(newcontent, scripts[i]);
    //console.log("included file: "+files[1]);
  }
}

use it like this:

<!-- comments show DOM state after the preceding include_once.js has been run -->
<script src="include_once.js#a.js" type="text/javascript" charset="utf-8"></script>
<!-- <script src="a.js" type="text/javascript" charset="utf-8"></script> -->
<script src="include_once.js#a.js" type="text/javascript" charset="utf-8"></script>
<script src="include_once.js#b.js" type="text/javascript" charset="utf-8"></script>
<!-- <script src="b.js" type="text/javascript" charset="utf-8"></script> -->
<script src="include_once.js#b.js" type="text/javascript" charset="utf-8"></script>
<script src="include_once.js#b.js" type="text/javascript" charset="utf-8"></script>
<script src="include_once.js#a.js" type="text/javascript" charset="utf-8"></script>

this code works reliably in Firefox, but it doesn't work consistently under Safari. haven't tested with other browsers.

this post continues a trend of doing stupid things with Javascript.


this blog generates its pages by shell script, and it's been a bit of a challenge to make the engine portable, so generated content and the code itself can be run anywhere.

one way this is made easier is by using <base href="<?= $blogroot ?>" />, which tells the user agent to prepend every source and reference with $blogroot. as I developed on Safari, everything worked.

then I asked for some friends to look at it, and it turned out that the base tag doesn't quite work like I'd hoped: you can't use a relative path as your base href, and Firefox enforces this strictly.

there's two options for fixing this: the blog engine itself has to know where it lives on the server, so it can populate the base href correctly, making generated content less portable -or- the output generation could be smarter and append the relative base href to the beginning of every source and reference it sees, making the output code messier.

luckily, if you're ok with requiring that your clients support javascript (which I am), there's a third option. behold:

<script type="text/javascript" id="base_href">
  Node.prototype.insertAfter = function(newNode, refNode) {
    if(refNode.nextSibling) {
      return this.insertBefore(newNode, refNode.nextSibling);
    } else {
      return this.appendChild(newNode);
    }
  }

  var newcontent = document.createElement('base'); 
  newcontent.href = document.baseURI.substring(0, 
    document.baseURI.lastIndexOf('/')) + '<?= $blogroot ?>';

  var here = document.getElementById('base_href');
  here.parentNode.insertAfter(newcontent, here);
</script>

put that in the beginning of your <head> and it will emit the correct absolute base href at runtime.

thanks to Christian Hammond for the idea.

edited on friday february 19th, 2010 at 21:38:

unfortunately this blog no longer uses this hack because the base href was interfering with document bookmarks.

edited on friday april 9th, 2010 at 15:26:

this post used to feature a version using document.write() that didn't work in Opera, IE, and Konqueror. while I haven't extensively tested this new version, I expect it to work better.

the PHP library makes me sad sometimes, like earlier tonight.

I've been working on the blog engine, trying to figure out how to get various bits of markup working that I don't want to have to write by hand every post1, and it requires doing XML manipulation in PHP.

if you take the time to look around on the internet (and I did), you'll see a lot of people who want to manipulate HTML or XML in PHP, and all the replies recommend things like SimpleXML, which can't remove or change tags, or DOM, which also didn't work for my needs2. exhausting these options, every thread ends with "use str_replace" or "use preg_replace". sigh. what's the point in having these libraries if they're not actually useful?

I want to do this right, damnit, and I'm going to use a tool that parses my pseudo-HTML fragments into a tree and allows me to add, change, or remove tags at will!

luckily, as I was resigning myself to writing a library from scratch, I discovered simplehtmldom. unlike other libraries I've tried using recently, simplehtmldom worked right out of the box with no issues whatsoever. code example follows.


1 especially footnotes
2 DOM only accepts properly formed XML or HTML with an all-containing root node and will only create output with a doctype and a single root node. I wanted something that would create output as close as possible to the input.