A recent site I worked on had footnote references throughout the body copy, and a corresponding list of footnotes at the bottom of the page. That’s easy enough to mark up, but the client also wanted the footnote to display it a little tooltip-style popup when you moused over the footnote reference.
I didn’t want to duplicate the footnotes in the markup, so I used jQuery to copy the contents of the footnote and display it. Here’s the code.
HTML
<div id="content"> <p>Sentence with a footnote<sup><a href="#footnote3">3</a></sup>.</p> </div> ... <div id="footnotes"> <p id="footnote1"><sup>1</sup> This is footnote number one.</p> <p id="footnote2"><sup>2</sup> This is footnote number two.</p> <p id="footnote3"><sup>3</sup> This is footnote number three.</p> <p id="footnote4"><sup>4</sup> This is footnote number four.</p> </div>
Note that the href on the footnote reference must match the ID on the footnote, so that jQuery can associate them properly. As a bonus, in a non-JS environment, the footnote references will just link down to the proper footnote.
jQuery
// add markup to all footnote references
$("sup a").append("<span><em></em></span>");
// on hover, show the popup and add the matching footnote
$("sup a").hover(function() {
// show the popup
$(this).find("span").fadeIn();
// use our href to find the apprpriate content from the footnote list
var content = $(this).attr("href");
var content = $(content).html();
// copy the footnote content into the popup
$(this).find("span em").html(content).append("<br /><br />All references are listed at the bottom of the page.");
}, function() {
// hide the popup on mouseout
$(this).find("span").fadeOut();
});
This looks much more complicated than it is. In plain english, we add some markup (a span) to each footnote reference, and then use its href to find the correct footnote from down below, and copy its content into the span we just created. Then we show and hide the span when the user hovers over the footnote reference.
CSS
sup a {
position: relative;
}
sup a span {
display: none; /* hidden by default */
width: 294px;
height: auto;
position: absolute;
left: -125px;
bottom: 1em;
/* sliding door background image - bottom half on span, top half on em */
background: transparent url("/images/bg-footnote-bottom.png") no-repeat left bottom;
padding-bottom: 13px;
cursor: default;
z-index: 999;
text-decoration: none; /* other wise, this is underlined like a link */
}
sup a span em {
display: block;
font-style: normal;
background: transparent url("/images/bg-footnote-top.png") no-repeat;
padding: 20px 10px 15px 20px;
}
Nothing complex here. We’re using a vertical sliding doors technique to allow the background on the popup to grow to accommodate varying amounts of text. The only other hiccup is to remember to override your link styles within the span, since the browsers will treat your popup as part of the link.
You can see a version of this code in action over here.
There are certain terms used in the web industry that most people think of as “industry-standard,” but are actually used in slightly different ways at different companies. For instance, I’ve run into several definitions for “alpha,” “beta,” “wireframe,” and “comp” at different shops I’ve worked at. Learning how a new company uses these terms isn’t that difficult, and the definitions are usually similar enough that it’s an easy adjustment.
I recently ran into a situation where my new manager’s definition of a term was different enough to radically change the situation. That term was “front-end.” Now, I think most people in our industry share a similar definition of front-end – it’s anything that the user sees through the browser, as opposed to back-end, which is anything that has to do with the server.
The problem arose from a gray area in our definitions with regard to javascript. In my mind, javascript can be used for both front-end and back-end work, depending on whether you’re using it for style and effects or more ajax-y stuff where you’re talking to the server. To my manager, however, since javascript is run in the browser, it’s front-end, no matter what you’re using it for.
Neither of us is wrong, the problem is that we were trying to describe two different things. I was describing intent and he was describing technology. I was arguing that javascript that talks to APIs on the server is back-end because of the work it’s doing, and he was arguing that it was front-end because it’s javascript.
In the end, I adapted the way I was speaking to clarify what I meant, and started talking about functionality vs. styling instead of front-end vs. back-end. Neither of us changed our minds, but at least we were talking about the same thing now, instead of using the same words, but meaning different things.
There is a split in the web industry that you might not be aware of. No, I’m not talking about Mac vs. PC. I’m talking about companies hiring generalists or specialists.
When I say specialist, I mean an employee whose focus is on one particular skillset, eg, flash, copywriting or front-end development. They may have other skills, but the bulk of their training and experience is in a relatively narrow field. Conversely, when I say generalist, I mean an employee whose skillset is more broad, eg, a designer who has experience with flash, has spent some time doing front-end development, and maybe even dabbles in PHP programming. These jacks-of-all-trades delve less deeply into any given aspect of their field, but have (or claim to have) basic experience with everything.
I’m a