It’s been a long haul but thanks to Jim Revillini the final step in the jQuery stretchtext code for Tinderbox is complete. Here’s the code:
$(document).ready(function() {
$(‘.stretchTarget’).hide();
$(‘a.stretcher’).toggle(
function() {
//Here we find the talk-to element
var trg = getStretchTarget(this.rel);
trg.fadeIn(1500);
},
function() {
var trg = getStretchTarget(this.rel);
trg.fadeOut(1500);
}
);
});function getStretchTarget (trg_class) {
//console.log(trg_class, $(‘.’ + trg_class)); for firebug
return $(‘.’ + trg_class);
}
The trg variable and getStretchTarget call solve the problem of identifying multiple links in a Tinderbox note. In the first iteration, I was limited to one link and one target–okay but not thorough.
Here’s the new example, with some nested divs to show a “drilling effect” in one section of my poem “That Night I Saw . . .”
The preparation for implementation is interesting, but for those writers using Tinderbox I think the requirements are quite simple: the jQuery framework, a stylesheet linked to the Tinderbox template, the javascript code in the template so that exported notes can take advantage, and then–most importantly–a sense of “why” to implement the stretchtext aesthetic into prose, poetry or whatever other document. This, of course, is the fun part. This project has been about opening the canvass, as the code can be tied to any container element, any media type, and whatever design exists on the backend in a template. It can be simple, it can be complex.
Here’s what the note looks like in Tinderbox:
The markup in this example demonstrates how complicated two stretchtext elements can be, not in terms of additional symbols, but in terms of how the effect advances any one reading of the poem, as any link may be ignored. In the finalized poem, links to other stanzas and sections might exist within a hidden element, thus advancing a plural coherence.
That’s the idea at least. For, markup notwithstanding, this opens the Tinderbox note canvass to further exploration for written forms, the codework happening behind the scenes during export and during reading, leaving the writer to worry about the nature of their work. That Night I Saw on My Homeward Way as a poem will simply be one example of that exploration.
Very nice, and a lot of work behind the scenes.
Just realized where we should take this script next: cross page interactions. I mean, I know you’ve discussed doing this in the past, but I wanted to bring it up again because we need only hook into what you have here already to facilitate that. The logic for a click would become:
on click of ‘stretcher’ link {
capture rel attribute of this [link];
if (we find the target on the page) {
animate it (hide or show);
} otherwise {
save the rel to a cookie;
}
}
So that creates a cookie which was a queue of ‘rel’ strings that we need to be watching for in the future. The next part we need is a little more logic to make use of our cookie containing all the rels. so i would add this to my script:
on page load {
read rel cookie into a variable;
loop thru rels {
if (the current rel matches a target on the page) {
toggle that target (show or hide);
}
}
}
Also, start thinking about parameterization of the rel. As we see in shadowbox, we can arbitrarily make up our own convention for parsing these rel strings in interesting ways that customize the effect of clicking the link.
Right now, we simply read the whole rel attribute, look for a target that matches based on class, and go from there. What if our links were:
[a href=”” class=”stretcher” rel=”rocks?effect=blind&duration=2000&delay=5000″]…[/a]
I’m using a familiar syntax, URL query string, to identify my target, the intended effect, the duration the effect should last, and how long to wait before running the animation. Now we need to parse it, but that should be super easy. There must be a ton of query string parsing scripts out there we could use. We may even be able to leverage a built-in JQuery method. I bet there is one to parse the query string, as it’s a common necessity in Javascript and there is no built-in parser for them.
On the tinderbox end, let’s hope to see a plugin API someday. As we discussed, it would be nice to be able to add new menu items which could help tinderbox authors mark up their content for the type of template they were using.
Hey Steve, here’s a great discussion which brings out many of the differences in the philosophies of the frameworks. I never really thought about how a framework was geared. I wish there was a YUI to JQuery converter :).