Function: noun
Etymology: Latin, from Greek kolophOn summit, finishing touch; perhaps akin to Latin culmen top
1 : an inscription placed at the end of a book or manuscript usually with facts relative to its production
2 : an identifying mark, emblem, or device used by a printer or a publisher
—Webster’s 10th Collegiate Dictionary
In a nutshell, the colophon usually tells you what fonts were used to layout a book, and on what sort of paper it was printed. Because there are potentially many more layers of sophistication required to produce a website, as opposed to a book, the decision was made to make this page more like an annotated list of technologies employed to bring the site to life.
Over the years, this site has evolved from a hodgepodge of HTML 4.0 to valid transitional XHTMLExtensible HyperText Markup Language 1.0 and CSSCascading Style Sheets. After years of serving some of the ugliest (though functional) table code imaginable, it’s a great source of pride to announce that the site is now utterly devoid of tables, having replaced them with a brief smattering of CSS. Bye-bye spacer GIF’s! With the demise of the tables, the site is now fully scalable and in preliminary testing shows consistent behavior in both Firefox and IE.
There are various “holy grails” of web design – highly sought after, potentially tricky to implement features which distinguish cleverly well-executed code from a mishmash of (usually) machine generated garble. As browsers are developed and improved, they can be moving targets. Since this site largely exists as a placeholder on the web, the design is done as needed, and not by a professional. I would never claim it to be cutting edge – nor does it have to be. The site functions as required. It’s uncluttered and easy to navigate, with an emphasis on content. Design, in this instance, refers to the underlying code and not to the layout itself.
As web design and the surrounding technology has evolved, certain techniques and technologies have gone in and out of vogue. Sometimes, by “out of vogue”, we mean going from trendy to utterly loathed. No matter how you term things, site owners and designers make deliberate choices about presentation and implementation. The colophon is a brief nuts and bolts look at the jumble of parts under the hood.
The site is built by hand using UltraEdit. It is occasionally fiddled with in an ancient copy of HomeSite.
Some features include...
In addition to validating the XHTML and CSS (see the linked icons at the bottom of the navigation column to the left), the site is tested in both Firefox and MSIEMicrosoft Internet Explorer. This is done more out of curiosity rather than a burning desire to cater to the dominant browser vendor, but since both are present on the dev machine, it’s just an issue of being thorough. Every so often, differences in rendering crop up and usually the fault lies with my code. It’s always interesting to see which things break in which browser. Since there’s no real exotic coding going on, things should be expected to work on any modern, standards compliant browser.
It seems to be a little known fact that the W3C CSS validator can test for CSS3 compliance. The default is CSS v2.1, but if you check under “More Options” you’ll see that there are all manner of different profiles – including CSS3. Woo-hoo! That means that things like opacity style rules (for browsers that have started supporting a subset of CSS3 functions) won’t break the validator. And if someone is using an older, or non-cutting-edge, browser, the rules are simply ignored and things fail gracefully. It took a bit of work to figure out how to specify the CSS3 profile in the dynamic validation link, but it works like a charm.
Here’s something I’m proud of – the sort of evil genius idea that winds up being the perfect solution to a particular problem, one that delights you to no end when it actually turns out to work. CSS3, though it’s nowhere near “release”, has some very cool typographic features – things like the ability to do multi-column layouts, which will be really valuable in cleaning up the layout of lists. Because the column spec is still a working draft, implementing it in a browser is/could be something of a moving target (as opposed to the spec being a candidate recommendation, where you would expect things to be much more set in stone). Firefox implements column properties with a -moz- prefix (since v1.5, Q3 2005), and the Safari development team just announced multi-column support in their browser nightlies through the use of the -webkit- prefix. Very nice! Now we have a dilemma: here we’ve gone to all this trouble to make sure the CSS is compliant and hack-free, and those blasted developers go and introduce a working model of something so cool that we look for excuses to include it. (Rock)—> me <—(hard place).
It’s the very definition of a moral quandary – one that I’d cheerfully lose. But wait... Maybe there’s some way that I can game the system. But how...? Even though I was pretty much opposed to the idea from the start, I did a bunch of research on the feasibility of using JavaScript to replace the column property in a compliant style sheet with the appropriate prefix (moz or webkit) based on sniffing the browser. It’s probably possible, but I don’t know the first thing about JS, and I rapidly lost interest in trying to figure it out. Basically the logic was that the style sheet would validate (which would mean that things wouldn’t have to change when the implementation is finally finalized) and then get replaced with something that actually works. BAH!
I’ve been kicking around various ideas pertaining to SEOSearch Engine Optimization, and have been gravitating towards using SSIServer Side Includes to keep from having to load up the actual content pages with cruft and crumbs. It finally dawned on me that styles placed in the head of a document (a practise sometimes frowned upon) do not get passed to the CSS validator because of a functionality loophole created by the standard practise of placing the style block inside an HTML comment. And there’s the solution: since it all goes in the <head>, we can define the column properties in an include that inserts meta tag info. Now we can have a style sheet that passes validation and sneak in some bits that would otherwise make the thing spit errors. As it stands, you get a warning – “Do not put style rules inside HTML comments as they may be removed by user agent” – but so what? It’s better than the Wikipedia approach of adding notes to their style sheet stating that the code “is correct, but the W3C validator doesn’t accept it”. They both work, but this is like having your cake and eating it, too. (If you eliminate the comments to eliminate the warning, the code fails just you would expect.)
The site is intended to be viewed at somewhere around a 1024 pixel browser width. Running a browser smaller than that reflows the pages fairly well. A wider browser – such as maximized on a widescreen monitor – will start to cause things to look askew (such as pages with sidebars). The problem is that when everything scales dynamically, paragraphs get shorter the wider your browser is, so you can wind up with what would otherwise be a reasonably-sized paragraph stretched out to only a couple of obnoxiously long lines. And if you have images that are supposed to float next to said paragraph, when it’s only a couple lines, the traditional concept of what a paragraph “looks like” kind of goes out the window.
It’s one of those pitfalls of web design that seems to escape the attention of code zealots. Print media has benefited from years – if not decades, and possibly centuries – of refinement. Newspapers, for instance, are laid out in columns for specific reasons: readability and economy of space. Granted, those reasons are directly related to the style in which newspapers are written – short sentences and equally short paragraphs – but it’s a case where having control over the final layout is imperative. The web basically destroys all that. As soon as everything goes dynamic – and if it’s not, you get criticized for that – then you’re at the mercy of the common sense of your visitors. Or the decided lack of same, because you just know that there’s gonna be some idiot complaining that your site looks crappy running full screen on their 30" Cinema Display. Thank you for visiting. Here’s your sign.
If you’d like to see what the site looks like in a 1024×768px layout, then click the badge above. If you’re using a browser that gives you the ability to disable certain types of JS functionality (read “annoyances”) – like resizing browser windows – this may not work, depending on your settings.
JavaScript, or “JS” as it’s colloquially known, tends to be one of the more controversial technologies used in web design. There was a time when websites were veritably carpeted with JavaScript, causing almost as much hatred and backlash as pages littered with Flash ads and applets. JavaScript is exceptionally powerful (witness the sophistication of many Firefox extensions), but there are some obvious limitations, most notably the fact that not all browsers use the same “rendering engine” which means that extensive testing must be done to insure that complicated scripts behave identically on all (desired) platforms.
There is almost no JavaScript employed on this site. Some form-related code on the contact page, the resize button above, and a hyperlink click-suppression in the image zoom code which, failing gracefully, will redirect users to the following alert:
It is possible to get to the alert by forcing the browser to follow the link via context menu commands, but that’s a special case that would require deliberate effort on the part of the visitor. Under normal circumstances, the link in the thumbnail should be null, so you should never encounter this alert without reading the colophon.
Though it would cause only minor inconvenience to have it disabled, we recommended that you enable JavaScript for this site – i.e. whitelist us – for the most optimally deluxe browsing experience.
To make the site as flexible as possible, navigation menus (except on the homepage) are placed via SSI. These menus are supposed to be fixed in place, giving the impression that they are housed in a frame. In fact, the site is frameless and this effect is accomplished with CSS. Since not all browsers support the position:fixed style rule – Internet Explorer (prior to v7) being the obvious worst offender – a workaround is necessary.
Conditional comments are used to load additional “fix-it” style sheets when elements in the main sheet either wreak havoc on layout in Explorer, or simply use style elements that Explorer does not support. (See the section on Styled Lists for more info on the differences in rendering and behavior.) In a nutshell, it works like this: you’re coding along, checking your progress, and you do something that you either know or discover will not render in some flavor of IE. You create an additional style sheet with rules that rewrite the problematic rules from the main sheet to address (and presumably solve) the whatsit. In the <head> section of your page, you create an [if] condition inside of an HTML comment: if some or all levels of IE are discovered, then do some command – such as load this additional style sheet.
Using conditional comments is only half the battle in achieving the fixed sidebar. IE needs a bit of persuasion in order to deal with the longstanding box model bug. This persuasion comes by forcing Explorer into “quirks mode”, in which it will emulate the behavior of previous versions of the browser. That’s all well and good, but since IE7 supports position:fixed, we theoretically want to differentiate it from previous versions. And this is where things get ug-ly...
In IE6 and earlier, anything other than the DocType declaration on the first line will throw the browser into quirks mode. The standard way of accomplishing this was to include a comment on the line. It could say anything (or nothing, so long as it’s there), but the one used on this site is “<!-- http://devnull.ronin-group.org/quirksmode -->“. With the introduction of IE7, the behavior changed. A comment on the first line will still invoke quirks mode, but an XML declaration (which accompanies an XHTML DocType) will not. That’s fabulous, since it will help maintain a well-formed website, freeing IE7 to act on its new found standards compliance, and using quirks mode to keep an appropriate boot on lesser versions of Explorer.
Unfortunately, that is the only way to achieve that goal. With the presence of the XML declaration – but without changing the content type (text/html) – IE6 decides that the page is not HTML and renders it as raw code instead of, well, rendering it. Firefox doesn’t care one way or the other and happily serves up a proper page. That’s a dilemma. Apparently, the way to properly handle this situation is to run various hunks of code on the server so that your web server can identify different browsers and explicitly serve them specific content types, based on their capabilities. In this particular case – and in most cases of shared hosting, I would assume – this isn’t practical. And in this instance, it’s not even necessary. We can force all versions of IE into quirks mode and everything renders just fine. It’s not an issue of writing (or keeping) non-compliant, deprecated code in order to support legacy browsers – all pages validate and there are no wonky CSS hacks. It’s simply an issue of maintaining my sanity.
The technique works with IE5.x, 6.x, and 7, but if it fails, it should do so gracefully, and the menu will scroll along with the rest of the page. You can read more about how this is done at The Jotsheet, Tagsoup, or Simon Jessey’s page. More info and links to articles can be found at the CSS-Discuss wiki.
By sheer coincidence, I ran across this excellent tutorial on creating the sorts of inset article sidebars that you see in books and magazines, as opposed to the multi-column page layouts or fixed sidebars (such as the one featured to the left) usually discussed in CSS forums. The article shows how to set up columns of multiple widths in a variety of positions. All code provided.
Full-size Image
On early versions of the site, thumbnails were scaled in Photoshop and posted separately from the full-sized images. This technique was abandoned after moving to the in-page CSS image zoom. The result is a much more elegant user experience, though the thumbnails don’t look as nice when scaled in the browser vs. a dedicated graphics application, since detail can become blurred and thin lines look jagged. This slight degradation in image quality is considered an acceptable limitation. The common alternative would be to use JavaScript rollovers to swap pre-loaded thumbnail and full-size images. Again, this would require the creation of separate thumbnail graphics.
The code for the in-page CSS image zoom is Scott Kimler’s PZ3Photo-Caption Zoom, version 3. It’s an amazing combination of CSS and valid XHTML (no JavaScript) that is flexible, compact, and easy to implement in pages. The nicest thing about the code is the fact that it does not reflow the page layout when switching scales, and behaves identically in both Firefox and Internet Explorer. There’s even a caption option which can be toggled on and off. Various info, tutorials, and explanations of the code can be found at his site.
Since the concept of expanding thumbnails is anything but intuitive, the instruction box was included to offer a gentle hint as to the functionality. Though it appears here in the middle of the page (to accompany the placement of the blurb), in practise, the instruction box is placed over the first thumbnail and is used only once on a page. For consistency throughout the site, all expanding thumbnails are sized to 128px wide.
There are two kinds of lists utilized on the site: navigation menus, and lists of textual elements. After years of building the navigation menus as individual line items – a practise frowned upon since it breaks the semantic concept of the list – I finally broke down and did some research into using CSS to style list elements. One of the main reasons I took to the original way of doing things had to do with the fact that I could get a consistent look to the bullets. For reasons that I never figured out, when using <ul>, the default bullet shape rendered in Firefox as more diamond-shaped than round. It looks round when the font is scaled up, but small wasn’t cutting it at all. Strangely, things looked a-okay in IE – and what I really wanted was as close to an identical look across browser platforms as possible. Plus, I liked the round and hated the diamond. Instead of wasting time trying to figure out that bit of rendering weirdness, I just sidestepped the whole thing and used • • • for my bullets.
As the concept of the site layout evolved to include elements such as experimental column support – something at the time that only Firefox could handle – certain aspects of the layout were starting to diverge from that long-sought consistency. Once the threshold of inconsistency was crossed, it was easier to accept the fact that certain things simply would not and could not be the same. And that was fine.
Having made the decision to do something different, the question became an issue of what. The problem with using graphical bullets is that they don’t scale. For my purposes, menu elements can appear at different font sizes, so this demands a bullet that can scale to match the text. I’ve been doing a lot of furniture design lately, and the double-colons are reminiscent of Charles Rennie Mackintosh’s four-square – four aligned squares which in turn form a square of their own. Because Firefox supports generated content and the :before pseudo-element, this is easy to accomplish. Internet Explorer does not, and therefore requires a different solution – and some additions to the IE fixes style sheet – but using the commonly available square bullet seems like a logical stylistic alternative. The progression of the menu design can be seen in the accompanying figures. (The effect of placing bullets only on the indented menu items is done by globally removing all list formatting and then styling only that nested level. To see how that’s done, check the style sheet.)
After solving the issue of menu styling, it seemed reasonable to dress up the text lists. I could have left them alone, but that seemed like something of a cop-out. Not wanting to get into a case of having to style text lists differently across browsers, I decided to use graphical bullets. There are different ways of handling this. The most simplistic is to simply replace the bullet with an image, but this can lead to positioning problems, especially if the font is resized in the browser. There is, however, a better way: use the background-image property. This technique keeps the bullet much more vertically centered on the line, and that helps to maintain the overall orientation if visitors start adjusting your font sizing.
After years of user interface development and refinement, the concept of the hovering tooltip is fairly well-established as an element on the desktop. While tooltips on a web page could be fantastically usefulThis is an example of a hovering tooltip on a webpage – tres spiffy, no?, there’s no intrinsic way of implementing such a beast. There are a number of “behave-alike” solutions, but unfortunately, most of those have the potential of breaking either the user experience – by having to load a whole bunch of JS code, and/or having the tooltips display off screen (in the case of pure CSS solutions) – or by violating the specific semantic usage and definition of certain tags, such as <acronym> or <title>. (Read why titles are not tooltips.)
Determined that this feature would be useful, I cast about for a workable solution, and wound up using a slight modification of Eric Meyer’s pure css popups experiment. Where Eric used the popup as a caption for, and immediately beneath, a sidebar menu, the relationship between caption and menu element was obvious. Here, the only consistency is the placement of the box – it overlays part of the menu space – since the terms being defined can be anywhere on the page. Instead of creating a hover tip near the defined element, the danger of the box disappearing off-screen or interfering with other elements on the page is thereby eliminated.
Since there’s no standard metaphor for hover tips on a web page, this is where things can get sticky. The first hurdle is to alert a reader that there’s supplementary information accompanying a particular term – rather like a footnote signifier. Since the tips only appear when moused-over (a point of failure for keyboard-based browsers), the terms are styled like links – but with some crucial differences. Since it’s important to distinguish both the look and the function from “normal” links (without losing the stylistic metaphor of the hyperlink), three things are done: the link is underlined, the cursor is changed from the selection hand to a question mark (indicating “help”), and finally, the link is deactivated so that clicking it doesn’t yield confusing results. This last feature also requires that none of the tooltip links can/will ever lead anywhere – because that would break our established pattern of behavior and lead to confustication.
The first two styling elements are basic CSS. No big deal, them. Nullifying the link chewed up hours of research, resulted in a fit of Hobbes-like puddle-splashing ecstasy, and was immediately shot down when I remembered to do a cross-browser compatibility check. Here’s what happened:
After a little more head-pounding, it dawned on me that there’s already a link nullification feature built into the PZ3 code. So I decided to use that. I’m sure that Scott Kimler has forgotten more about coding for the web than I will ever know – and that belief leads me to assume that if there was a better solution, he’d have used it.
Once the links have been styled, the next challenge is to create a consistent visual metaphor for display. Since there is potentially a good deal of visual space between a term and its definition, the styling of each is specifically designed to echo the other. Tooltip links are marked with a dashed underline. When hovered, a matching “overline” appears and the background of the term changes to match the color of the definition box which has a corresponding dashed border. (Links that go somewhere turn red, info links stay blue and get a background color.) There’s also a minimum size on the box to make it hard to miss. The simultaneous appearance of identical colors and similar styling provides a visual link between the two elements wherever they appear on screen.
There’s still a problem: the behavior is not consistent between browsers. Firefox renders the hover tips as described. IE, on the other hand, refuses to place anything in the sidebar space and does crazy things with the placement of the note. There are multiple issues centering around some kind of conflict between the code for the frameless menu sidebar and the placement of the tooltip. It has something to do with HTML DocType/DTD, forcing IE into quirks mode, and IE’s lack of support for position:fixed. The best I’ve been able to do is to position the hovering notes near the source terms. Aside from the presentation being inconsistent, the tips will happily run off the edge of the screen.
Thanks to the good folksThanks, Sophie! over at the css-d list, there is a solution. The downside is that it involves things like dropping into an HTML 4.0 DocType, using a loose DTD, and using * html hacks to beat IE into line. Taken as a whole, having to rely on that kind of code is a whole lot more distasteful than just letting the two browsers render differently. It’s not optimal, but it’s not entirely awful, either. I think that this is a better solution than having to run CSS hacks or other frowned upon (but functional) weirdness [that I don’t really understand]. The technique has not seen widespread use throughout the site, though it is used excessively here, in the colophon, as a proof of concept and will be deployed more extensively as the need arises.
The favicon – the little icon that appears in the URL bar as well as in the bookmark list – is a detail from Hokusai Katsushika’s famous woodcut, Beneath the Great Wave at Kanagawa. It was converted from a JPEG by the web-based FavIcon from Pics utility.
It’s widely reported that favicons will not appear in IE6 unless the site has been bookmarked. This isn’t true. While it is true that if you have a favicon that isn’t appearing, bookmarking it can/will make it appear, there are all sorts of sites around the internet that you are pretty much guaranteed not to have bookmarked, and their favicons show up just fine. Apparently, IE6’s implementation of favicon display is erratic. In my research, no one has anything more definite than a list of suggestions of what might help. These include:
- Make sure to use absolute, not relative, links
- Make sure the file is called favicon.ico and is placed in the root folder of the web site
- Add the page to your favorites (of course this does nothing for the rest of the internet which won’t have done this, so it’s not much of a solution)
- Try deleting your browser cache
At some point, you have to draw a line when it comes to the amount of effort you should go to in working around Microsoft’s (or anyone else’s) poor implementation issues. All of the graphics for this site live in a subfolder. If the browser can’t manage to follow a simple path statement, then no icon will be served. (Firefox renders the pathed favicon just fine.)
Back in 2002, Jeremy Hedley created an internet sensation when he introduced a set of replacement buttons for advertising various under-the-hood technologies used on his Antipixel blog. They were nicely colored, easy to read, and consistently compact: 80 pixels wide by 15 pixels tall. News traveled swiftly through the blogosphere and soon everyone was creating buttons to announce or evangelize one thing or another. Quite a few of the 80×15 buttons that appear on the site – on this page, especially – were created by the graphicsguru’s online button generator. It’s very cool: plug in the hex numbers for your borders, field, and font colors, add some text, specify how wide to make the rectangles, hit “generate”. Voila – your own custom Antipixel badge!
The geo-location plotting of site visitors comes from Shawn Hogan at Digital Point Solutions. It’s basically a hack of Google’s mapping API that shows the origin of visitors during the last 24 hours. It works by hosting the Geo Visitors badge seen on most pages on the Digital Point servers. When the image is pulled to your website, the requesting IP address is logged, then resolved in a commercial geo-location database and plotted on the map. The code to add this to your own site/page can be found at the Digital Point link.
Since tracking visitors to all pages requires the Geo Visitors badge to be present on all those pages, this can potentially interfere with your page layout. A simple workaround is to use CSS to include the badge as a DIV background, but to use position:absolute to stake it down in a location where it will never be seen – in this case, 3500 pixels down on the page. By way of comparison, the 30" Apple Cinema Display is only 1600 pixels high, at its native resolution, so this cöordinate should be well out of range (even if you’re running four of them).
Stephen Ostermiller has put together a very nice Perl webmail form that is released under the GPL. It’s fairly easy to customize and integrate into your site, and best of all – it works! All relevant info for installation and customization, as well as a download link can be found at his site. If this one won’t do what you need, he also includes links to other, similar webmail gateways.
This site has, in no way, been optimized for search engine page ranking. It’s something that probably needs to happen, but there are so many conflicting opinions about what is good or bad, elegant or fugly, in terms of implementation and best practises that it will require a decent amount of research to sort out.