After Andrew’s presentation, somebody asked whether the content of HTML5 storage would survive the user clearing the cache, and nobody in attendance was certain. In retrospect, I’m sure I already knew the answer to this, somewhere in the bowels of my memory, but it eluded me at the time. But I got curious and decided to test it out:

The text boxes show what’s currently stored. Enter something in either one and click the button to store it. If you navigate to this page in a new window or tab, or quit and relaunch your browser and come back, localStorage will remain and sessionStorage will disappear.

Then try clearing your cache and reloading the page. It looks like everything survives. I only tried this in Firefox 3.6 and in Safari 4.1 and 5.0. Please try it out in the browser of your choice and leave a comment if you find different behavior anywhere. (Also, I’m not sure every detail of what I’ve done is cross-browser compatible, so please leave a comment if the basic functionality is missing in some browser that’s supposed to support this, and I’ll fix it.)

The way the Safari developer tool (the Web Inspector) lets you inspect this data suggests that it treats local storage more like cookies than like the cache. If you click on Storage, it shows three databases: “LOCALSTORAGE”, “SESSIONSTORAGE”, and “COOKIES”. Click on them and you can examine the contents of each. No sign of the cache in that panel.

Example code:

Here is some example code I showed the participants. It’s rather trivial, just a demo of the most minimal Google Chrome extension. It’s only four lines of JavaScript and simply inserts an image at the top of any page you navigate to.

• If viewing this page with Google Chrome, you can install it.
• Download the source as a .zip file.

Developer resources:

Chrome and Safari
These two are just joyfully easy.

• Google Chrome Extensions
• Safari Dev Center
• and especially: Safari Extensions Development Guide

Firefox
Mozilla’s API offers vastly more power and freedom, at the cost of greater complexity. You control the browser chrome in an XML-based language called XUL, the Javascript is a bit trickier to program, and the documentation isn’t nearly as well organized. You have to really hunt for what you need. Below are a few good starting points. One thing I forgot to mention during my presentation is that Mozilla is working on a special SDK called Jetpack, currently in beta, that presents a simpler, more manageable API but with more limited power (no XUL, for one thing). Much of the time you can do without the most advanced features, so this should suit many projects well and present a much gentler learning curve. I haven’t investigated deeply yet, but I imagine it might make Firefox a comparable developer experience to Chrome and Safari. (One can hope. ) Read about it at the links below.

• Mozilla Developer Network: Developing add-ons
• Add-on Developer Hub
• mozillaZine: Extension development
• Updating extensions for Firefox 4

Internet Explorer (MSDN)
Now this is a whole different kettle of fish, of course. The parts list is a lot bigger; I only became familiar with “browser helper objects” (BHOs), which was the part I needed. BHOs are written normally in C++, and particularly if you’re not used to Windows development, it can be slow going. The documentation is extensive, fragmented, and not at all self-contained; it bleeds into the rest of Windows development so there’s no real boundary around what you might have to know. And to deploy your app to the world, you need to create a separate installer, an adventure in itself. The links below are just a starting point. You’re gonna have to want this one bad! But it is definitely possible to get somewhere with this. The tutorial described below as “key” was extremely important for me. There was lots left to figure out after that, but I never would have gotten anywhere without that one.

• Overview of the whole parts list: Browser Extensions
• Key tutorial on BHOs: Building Browser Helper Objects with Visual Studio 2005
• Browser Helper Objects: The Browser the Way You Want It

Awesome annual conference, December in Silicon Valley:

I really enjoyed discovering this and attending in 2010. I was disappointed that Apple and Microsoft didn’t participate, though. MS had participated in previous years. Safari didn’t yet support extensions in 2009, so 2010 would have been Apple’s chance to make a big deal about it. Google, Mozilla, and Opera (all the way from Norway) were all there, which was great.

• Add-on-Con
• Videos of sessions from ’08 and ’09 cons (Hopefully they’re working on putting up videos from 2010.)

Extension repositories/galleries/web-stores:

• Chrome Web Store
• Safari Extensions Gallery
• addons.mozilla.org (AMO)
• IE Add-ons Gallery

Previously I described my solution for getting around a problem with text truncation using the new CSS3 text-overflow:ellipsis property. The property works great, making text truncation much cleaner and more elegant than it used to be – in all browsers except Firefox, which doesn’t support it yet. And there’s even a nice technique to get the effect working in Firefox as well. But that technique comes with some constraints: the block of text to be truncated can only handle very simple markup. Essentially, the entire text must be uniformly styled, because it can’t have nested HTML elements. So if you want part of it to be black and part to be red, you’re out of luck.

My company, Kachingle, has a JavaScript widget (the “Medallion”) that needed just such color variation to highlight important words in a truncated line of text, and I tore my hair out trying to find a way to get the text looking like it was supposed to in Firefox. I did manage to succeed, finally, and wrote that long post about how to do it if you need to. But today I learned that it’s possible to avoid all that pain.

Kachingle is working on a rebranding, so I’m working with our new designer, Frédéric Ranft, to rebuild that Medallion from scratch, to match his new site design. Frédéric does beautiful work. He designs visuals with impact, and then realizes them in HTML and CSS that are a joy to read, because they’re extremely simple and clean. I have to translate this into a working PHP template and sprinkle with JavaScript, and I couldn’t be happier than to work with his code.

But I’ve been anticipating some pain when the moment comes to make sure, once again, that the overflow text renders correctly in Firefox. Even now that I know the solution, there was still going to be a trial-and-error process to get it just right. But today I was looking over Frédéric’s HTML and it suddenly struck me that it’s going to be trivially easy this time. We’ll still need the special trick for Firefox that I had to dig up on the web, but we won’t need to fight with it this time – it’s going to just work, simple as that. Why? Because we’re starting from a better, cleaner design.

Now, when you get down to brass tacks, there’s nothing earth-shattering going on. The relevant difference is simply the content and layout of the text in question. In the old design, the highlighted text was embedded into a longer phrase, so it needed to be differentiated from the surrounding text by its styling; this is what caused all the trouble. The new design is less wordy, and the same text now stands by itself, so there’s no need to apply complex styling. But what gave me pause about this small change is the way the simple, clean writing and graphic design, expressed in simple, clean markup design, led to a really easy coding job for me. (So easy in fact that he can do it without me. I couldn’t have it any easier!)  The thing is, Frédéric wasn’t going out of his way to design around the truncation and styling problem. I’m sure it wasn’t even in his mind. But what he produced will be problem-free. This drives home for me the importance of the graphic design as an input to the engineering. I can easily see how a designer could make something pretty but in doing so, give engineers a big headache. But if it’s done right, the pretty display can be a gift to the engineers instead, having repercussions throughout the project.

I can’t show you the new design yet, of course. But check back later. When the rebranding goes live, those Medallions over in my sidebar and down in the footer will magically change to the new design. The ones in my original blog post were just screenshots so those will preserve a bit of history. It should make for an interesting comparison.

Well, I don’t know if I’ll achieve every day – nor that I really ought to! But let’s see if I can get myself in some kind of a habit, here. If you look at the dates on my posts, it’s obvious I’ve been a little sluggish getting into the swing of things. I will try to post more about what I’ve been up to lately. Let’s start with what I learned today!

Plugins, shortcodes, and custom fields. I much enjoyed Dave’s walk-through of a very simple plug-in. We first set up a development environment on our local machines. Easy as: 1. An apache/mysql/php stack (I already had WAMPServer running on my PC); 2: An editor (they recommended the Aptana Studio IDE which I installed for this occasion yesterday since I don’t do much development on this machine, but to be perfectly honest I missed the intro to using Aptana if there was one, and didn’t really feel like getting up to speed, so I just did this simple task in WordPad, which was perfectly adequate); 3: locally installed a test WordPress blog, rather than unleashing development code on this blog! Creating a simple plugin was pretty straightforward. You just create a PHP script in your wp-content/plugins directory, and it magically appears in the plugins page of your WP dashboard to be activated like any other plugin. Of course, it doesn’t do anything until you add some code.

Dave walked us through a simple plugin to add some special navigation to individual posts, for example if you have a series of posts on a single topic and you want to have links to the other posts in the series. It consists of three simple elements. First, you use two custom fields (a standard WP feature found on your Edit Post page) to indicate which other posts you want to link to as “previous” and “next”; each custom field has a name that the plugin will recognize, and a url for the post to link to. Then you write a PHP function in the plugin script that will recognize these custom fields and build some HTML containing links to those URLs. It shouldn’t produce any output to the page; instead, the function just returns the HTML as a string. Finally you just need a shortcode so that you can invoke this function from your blog posts. I’d heard of shortcodes before but this took the mystery out. They’re just a simple name that invokes the function you added to the plugin script. I named my shortcode “post-series”, so I just type that right into my post in square brackets (“[post-series]“), and it magically invokes the PHP function and is replaced by the HTML the function returns. And voilà!

Screenshot of plugin output from WordPress Hackathon

Fun stuff! Thanks, Dave!

The discussion was wide ranging and certainly covered territory way beyond my expertise. It was both fun and humbling. I’m pretty sure this roomful of interested lay people who pay attention to science knew more science than I do. While I was scrambling to get lab results, publish papers, and keep up with the most esoteric minutiae of research related closely to my own, these folks had time to read up on nuclear physics, immunology, and volcanoes. Hopefully everybody learned a little something – I know I did!

Anyway, I was glad to be able to contribute in some small way to this fledgling organization in its early stages. Looking forward to seeing where this goes!

The new one does the same thing as the other one that was there already; it just looks different. (Sorry I haven’t had a chance to say much here about what these widgets are for; maybe that will be another post. But mouse over one of them and you’ll be on your way to finding out…)

In retrospect, it’s eye-opening for me to have seen what goes into creating something like this. We had a widget (the “Kachingle Medallion”) with two different display styles for our users to choose from, and we simply wanted to create a third design. Easy, right? It’s just a bit of art. But it took a long time!

Originally, there was just one Medallion style. I’ve added one of those originals to the footer of this blog for comparison. It’s pretty big, so the company created a second, narrower version of it that could fit more easily in sidebars (the similar-looking one in my sidebar over there…). When I joined the company, that was the status.

As I became involved with maintaining and developing the Javascript code behind the Medallion, I learned that it loaded two entirely different Javascript files for the two different designs. Any time I modified the function of the Medallion, I had to make the change in two places. And the only difference between them was a few hard-coded details of the dimensions. (Not even the layout itself, which is handled on the server side; only the dimensions of the iframe and its containing div are handled by the Javascript.) It was obvious that this should have been coded into a single script accessing a small table of style-specific parameters. Not only would it simplify development and maintenance of the code in general, it would also make it trivial (uh… hah!) to add additional styles, if we wished. So I did that. Back then I don’t think I fully anticipated where it would lead, I just knew it would make my life easier, and encourage creative thinking about the possibilities. But it was the first step toward today’s release, and that was back in March.

Then somebody came up with the idea of the “mini-Medallion”, and the associated “overlay” that pops up when you mouse over it. (Go ahead, give it a try, I’ll wait…) In those days, all the user controls appeared as a drop-down when you moused over. The wide Medallion, with the drop-down showing, looked exactly like (strangely enough!) the pop-up overlay you see here. The narrow Medallion had a similar drop-down, but fitting the same text and links into a narrower layout to match the width of the Medallion itself. The new idea was to have a new, still smaller, more fun and modern-looking Medallion. It made a lot more sense to switch to an overlay approach than to redesign that drop-down. This also has advantages from a marketing perspective because it frees the old drop-down section from the size constraints of the Medallion, and we can put more interesting content in it (something we’re working on now). So a major project for me was to redesign the Javascript to pop up an overlay instead of a drop-down. That had its own tricky issues and took some time.

Ready to make a mini-Medallion yet? Nope! Part of the point of a mini-Medallion is to make it easier to incorporate into a page layout on mobile devices. In the sidebar, it would often be eliminated entirely when a page was viewed on mobile; the small size of the mini would facilitate including it within the body of each post instead. But that required other changes, not just small size.

Being included in each post means the Medallion needs to appear multiple times on a page. The original design was only allowed to appear once, and contained HTML that prevented more (id attribute), as well as overly simple Javascript that couldn’t handle more. So another project along the way was to generalize the code to allow multiple instances on a page. And without causing the older version to break, since it was already installed on our users’ sites.

Furthermore, the Medallions are activated by mouseover, and there’s no such thing as a mouseover in a mobile browser! (The stopgap solution had been to leave the drop-down always open on mobile instead of being activated by the user. But this made the Medallions even bigger! And the new mini-Medallion we were designing didn’t even have such a drop-down.) So I had to make the Medallion clickable.

This turned out to be non-trivial. For one thing, because it’s an iframe, the host page can’t see the clicks. (In a non-mobile browser it can see a mouseover as you cross the edge of the iframe or surrounding div. But a click inside the iframe is completely hidden.) That was a head-scratcher for me for awhile until I figured out how to get around that problem. (Tip of the day: a transparent div absolutely positioned in front of the iframe does the job nicely, thanks!)

And yet, it still didn’t work on mobile! Some crazy subtleties in the event models (yeah, plural; of course they aren’t all the same!) of mobile browsers were at fault. This was my introduction to programming for mobile, and solving this one didn’t just involve scratching my head, but pulling out a lot of my hair! I’m happy to say that it now seems to work well in Mobile Safari for iPhone, in the native Android browser, and in Opera Mini on both platforms.

And all of the above is only the part I worked on myself. There was also all the work by other people — several graphic designers involved in creating prototypes, preparing the final artwork (in several versions since the Medallion that finally appears is color-coded according to the status of the visitor to the site), and wrapping it all up with some HTML and CSS. I then incorporated their work into the PHP templates used by our server to deliver the right version to the visitor.

Five months! Just for that little thing! I had other projects along the way, so it wasn’t a full-time five months, but it has all been a major part of what I’ve done since I joined the company back in February. I find it striking when I look back on it. Today at Kachingle we’re celebrating!

The YouTube link happened to be mentioned in a discussion in the “Computational Biology” LinkedIn group about how to teach biology to programmers. I’m not sure this video will do the trick, but if you already know a little something about the process of protein synthesis (by analogy, the execution of the code), or just enjoy creative expression, you will find this really fun — especially if you have a fondness for the 60′s! I’m really glad I ran across the link.

CSS3 provides a great convenience when it comes to truncating too-long text: the text-overflow property, which automatically selects the best truncation point and adds ellipses. Unfortunately, it doesn’t work in Firefox. There’s a hack to make Firefox do this, too, but it comes with tight constraints on the structure of your HTML, preventing any but the absolute simplest text styling. Here’s a way to get around those constraints and style your text however you want.

For my first “serious” post in this blog, I’m definitely diving into the deep end of the pool, because I am by no means a CSS expert; I’m not even all that good at it. But I seem to have hit upon the answer (or at least the last 10% of the answer) to a problem that other people are struggling with, too, so I thought I should share it – and get off my duff and finally launch this blog before I forget what I did!

The problem: automatic text truncation

In my work at Kachingle, I’m responsible for the widget we call the “Kachingle Medallion”. This medallion sits on participating websites, and we serve it up dynamically, customizing it with a color-coded coin and the number of “Kachinglers” for each site. But now I needed to further customize it by adding the name of the hosting website:

Since the site names are provided by our users, of course they can be any length. And that means we need a way of truncating the name when it’s too long, and adding an ellipsis.

One could always impose a simple character length limit to decide where to truncate, but that would be less than ideal here. The size of the space available is constrained, and we’d like the ellipses always to appear at the right edge, allowing as many characters as will fit, but no more. That number will be different depending on whether the site name contains lots of i’s or lots of W’s; and it will change if I happen to change the dimensions of the containing element or the style of the text. What’s needed is a way to truncate at the time the text is rendered, based on its rendered dimensions.

CSS3 text-overflow (except in Firefox)

Justin Maxwell’s fabulous article, CSS String Truncation with Ellipsis, starts by explaining the basic CSS3 solution for this. Most modern browsers already support the CSS3 text-overflow property, which will automatically calculate the right place to truncate text, and add the ellipsis. In my case, like this:

<p class="ellipsis">
    2 Kachinglers
    <br />for <span class="emphasize">Sharon's test site</span>
    <br />How about you?
</p>

where the “ellipsis” rule gives me the required properties for the truncation:

.ellipsis {
    white-space: nowrap;
    overflow: hidden;
    text-overflow: ellipsis;
}

and the “emphasize” rule gives me my highlighting. So now, when I replace “Sharon’s test site” with “Site With a Really Long Name”, I get this:

Alas, I said “most” modern browsers. We can include Opera by using their proprietary name for the same property, -o-text-overflow. (And Justin suggests IE8 requires -ms-text-overflow, although it seemed to work without it for me.) But unfortunately, Firefox doesn’t support this at all yet, by any name whatsoever; so the exact same code renders in Firefox like this:

The very clever work-around for Firefox

Justin goes on to explain a work-around, originally worked out by Rikkert Koppes, which simulates this feature in Firefox. I won’t repeat all the details here but I urge you to check out both articles. The technique requires adding the “-moz-binding” property to my .ellipsis class, and linking that to a special XML file, like this:

.ellipsis {
    white-space: nowrap;
    overflow: hidden;
    text-overflow: ellipsis;
    -o-text-overflow: ellipsis;	/* required for Opera */
    -ms-text-overflow: ellipsis;	/* required for IE8, allegedly */
    -moz-binding: url('ellipsis.xml#ellipsis');    /* for Firefox; details here */
}

That last line will have no effect on the other browsers, so I should be all set.

Unfortunately, implementing this solution has some requirements that force me to change around my HTML a bit. If I simply enhance my .ellipsis class as described above, the <span> containing my highlighted text disappears entirely in Firefox! As do the <br /> elements between the lines. That’s because, as Justin explains, this technique constrains the truncated text to contain only minimal markup structure. It can’t contain “mixed” content, e.g., text next to other nested elements, as I have above. This makes it hard to apply any but the simplest styling to the text.

No problem, I thought — I’ll just put the .ellipsis class on the <span> itself, instead of on the paragraph:

<p>
    5 Kachinglers
    <br />for <span class="ellipsis emphasize">Site With a Really Long Name</span>
    <br />How about you?
</p>

But this caused a cascade of other problems. Because now the truncation point (in all browsers, not just Firefox) is calculated relative to the right edge of the span instead of the right edge of the (fixed width) paragraph, and the span overflows well past the edge of the paragraph, making any truncation or ellipsis invisible. In order to rein it in, I need to apply style display:block to it. But that in turn prevents it from appearing on the same line with the preceding text (“for”)! (Admittedly, this was where my inexperience with CSS was apparent, and maybe I missed something there.) My stopgap solution was to put the entire line, including the “for”, inside the span (and I have to remove the <br /> after the span as well), leaving me with this:

<p>
    5 Kachinglers
    <br /><span class="ellipsis emphasize">for Site With a Really Long Name</span>
    How about you?
</p>

and:

.ellipsis {
    white-space: nowrap;
    overflow: hidden;
    text-overflow: ellipsis;
    -o-text-overflow: ellipsis;
    -ms-text-overflow: ellipsis;
    -moz-binding: url('ellipsis.xml#ellipsis');
    display: block;
}

This works. I now have proper truncation with ellipses in Firefox (and everywhere else):

But this was pretty disappointing. I did not want to be forced to have uniform styling for the whole line. (And this will be the appearance in all browsers, unless I add additional, more complex code to distinguish between them.) What’s at the root of the problem is the limitation that this solution imposes on markup structure. There was no way to divide the line into separately styled subsections and still get them both to coexist on the same line. Justin’s and Rikkert’s posts, along with the numerous comments on each of them, point out this problem but don’t suggest any way around it.

Making it do my bidding

I tried many different ways to structure the markup and the CSS that would give me the styling I wanted, along with the ellipsis. But nothing seemed to work. My choices seemed to be either to accept the uniform styling, or to put the “for” someplace else (which is not really a solution). I reluctantly accepted it, and gave up for the day. But a good night’s sleep helped me think outside the box model (so to speak).

The solution is to use absolute positioning for the <span>. This takes it out of the rendering flow, so I can now put it wherever I want it.

Perhaps this takes a hack and turns it into even more of a hack – but it works! The <span> now has to be carefully positioned, and this was somewhat of a trial-and-error proposition for me. And that positioning didn’t work too well until I put the “for” in its own absolutely positioned <span> as well, otherwise getting the two to line up was difficult and browser-dependent. And both spans need to have class .ellipsis applied, even though the first one will never actually need truncation. The second span must now be given an explicit width in order for its margin to line up properly, since its default width seems no longer tied to the width of the <p>. Finally, two adjacent <br /> elements put the third line in the right place, to leave a gap for the absolutely positioned line.

The final result looks like this:

<p>
    5 Kachinglers
    <span class="ellipsis position1">for </span>
    <span class="ellipsis position2 emphasize">Site With a Really Long Name</span>
    <br /><br />How about you?
</p>

and:

.ellipsis {
    white-space: nowrap;
    overflow: hidden;
    text-overflow: ellipsis;
    -o-text-overflow: ellipsis;
    -ms-text-overflow: ellipsis;
    -moz-binding: url('ellipsis.xml#ellipsis');
    display: block;
    position: absolute;
}

/* The following are particular to my case and are only for illustration */
.position1, .position2 {
    top: 42px;	/* both spans lined up the same */
}

.position1 {
    left: 8px;	/* Same as the padding in the <p>, so that the margin lines up */
}

.position2 {
    left: 24px;	/* come right after the preceding text */
    width: 81%;	/* truncate in the right place */
}

And there we are. Proper truncation in Firefox, without being constrained by the markup rules of the -moz-binding solution! This approach should work for any kind of styling or formatting that would normally require nested elements, including making a link out of a subset of the truncated line, and maybe other uses I haven’t thought of. So, what do you think? I’d love to hear if this is of use to anybody, and what you do with it.

But apparently nowadays if you don’t have a blog, then you don’t fully exist, professionally. And it’s about time I existed. So here we go! I hope I can make this blog a little bit different from the other hundred and forty-three million!

Maybe my odd background will help with that. As the blog title and graphic hopefully convey, this blog will be inspired both by my past work as a research biologist and my current work as a web developer. I have returned to software development after many years away, and I knew nothing at all about web development before starting my current position at Kachingle in Feb. 2010. So I have been learning a ton of new things every day, and I’m sure they will give me something to write about now and then. I expect (but no guarantees) this will be a mix of technical and non-technical posts. They’ll probably be mostly about software and my software career but with a biologist’s perspective occasionally injected. And I have years of programming experience, yet am coming at many things as a beginner, which should add an interesting perspective to the posts, particularly the more technical ones.

Welcome, and I hope you enjoy!