The Hypsometry Blog.

XI.

2010-07-22T10:26:00-07:00

Last fall, after years of creating highly dynamic websites and web applications, I reversed directions. Now I aim for as much static HTML as possible. It’s simpler, faster, cleaner, more elegant, easier to read, and for most projects it’s all you need.

Hypsography and Hypsometry, for example, are both entirely static. Hand written HTML, CSS, and Javascript, served up simple and fast.

This site, the Hypsometry Blog, is built with Jekyll, Tom Preston-Werner’s elegant little Ruby hacker blogging tool. Jekyll takes Liquid templates and fills them with marked-up text, sprinkling a little YAML data over the top, and outputs HTML ready for your server. That works well.

Hypsography, however, is getting to the point where I don’t want to be maintaining all the code by hand (albeit with heavy help from Textmate), but I also don’t want to lose the simplicity and speed of serving static files. There’s no need to migrate to a full-bore content management system, with all the configuration and maintenance hassles that inevitably entails. Jekyll’s wonderful, but it’s not usable on sites that aren’t simple blogs.

Since Jekyll was released, a slew of static site generators written in Ruby have come along (and some have gone right along too). They all have a basic philosophy similar to that originally outlined by Tom Preston-Werner:

They all take templates and content and merge them together, creating static HTML sites ready for deployment. They tend to use YAML for configuration. Most accept multiple markup formats as input. They all can watch your directory for changes in order to rebuild the site dynamically as you work on it.

Their differences are smaller, but important. Each has a slightly different approach to the same problem, and thus each meets a slightly different need.

Having spent the past couple days (for the second time in six months) going through the options and evaluating them, I thought I’d summarize what I’ve found. Let me point out that all the programs discussed below seem excellent and worth investigation. There are other programs out there which seem less excellent, and I’ve ignored those here. Please let me know if I’ve missed anything, of course.

(There is one other useful approach to all this: Writing your own generator using Rake, YAML, and Mustache. This is quite appealing, but not what I’m in the market for today. Chris Wanstrath wrote about his approach last year, if you’re interested.)

Here follows my one-sentence summaries of all the Rubyist static site generators that I’ve looked at recently:

Bonsai.

Beautiful, simple, flexible (uses Tilt for template handling), progressive (HTML5 by default), but the current version doesn’t work out of the box and it’s intended primarily for portfolio sites. (Project site, Github.)

Middleman.

Rails-like (in ways both good and bad), highly configurable and flexible, and includes automatic minification of CSS and Javascript, as well as other useful optimizations. (Introductory post, Github.)

Nanoc.

Extremely powerful and extensible, perhaps too much so, and prefers configuration to convention. (Project site, Github.)

Staticmatic.

Simple, clean, but strangely Haml-dependent. (Ruby Forge, Github.)

Webby.

Simple, flexible, quite Jekyllish. (Ruby Forge, Github.)

Webgen.

Powerful, extensible, slightly rigid in operation. (Ruby Forge, Github.)

Not quite a conclusion.

That’s the list, and those are my notes. You can probably guess which I’m going to try out on Hypsography, but whether or not you can, you’ll be hearing more about the results here.

A historical aside.

Since I wrote once before about static site generation, I’ve taken this opportunity to begin restoring old articles to the Hypsometry Blog. As such, there is now an article zero: Nulla, actually, since the Romans didn’t really have notation for zero.

Nulla serves as a marker. All articles older than it are reprints, numbered negatively (which is also an anachronism, but hey), and probably slightly altered from their original forms. All articles newer are indeed new, part of this latest iteration of the Hypsometry Blog.

As time passes, I’ll continue working my way through the Hypsometry archives, digging out other older articles perhaps worthy of a second look. Or at least worthy of having their links preserved. Don’t take them too seriously – they’re oldies, but not necessarily goodies.

X.

2010-06-29T19:11:00-07:00

IX.

2010-06-23T15:56:00-07:00

Sometime in the mid-nineties, around the time I stopped reading Mondo 2000, Jaron Lanier stopped annoying me. I assumed he was still out there, being all far out and dreaded and inter-disciplinary, but he no longer forced his way into my attention, and was thus out of mind.

Apparently he’s not yet out of sight. He has in the interim, however, become more articulate, more insightful, and more interesting. This past January his newest book, You Are Not a Gadget, was published, and in February Harper’s Magazine published an excerpt called ‘The serfdom of crowds.’

(The complete article is only available online to Harper’s subscribers, but there is an illicit version available on Scribd, in beautiful HTML5. That said, I recommend that you go to your local library and read the damn thing in print.)

Let me quote from it at length, to give you something of its full flavor. Here is Lanier discussing the collapse of the financial markets in 2008 and how that related to, and derived from, the essential inequality of the current structure of the web:

True believers in the hive mind seem to think that no number of layers of abstraction in a financial system can dull the system’s efficacy. The crowd works for free, and statistical algorithms supposedly take the risk out of making bets if you are a lord of the cloud. But who is that lord who owns the cloud that connects the crowd? Not just anybody. A lucky few (for luck is all that can possibly be involved) will own it. Entitlement has achieved its singularity and become infinite.

What has allowed this infinite entitlement, this neo-feudalism? We have, in a thousand little ways:

People degrade themselves all the time in order to make machines seem smart. We have repeatedly demonstrated our species’s bottomless ability to lower our standards to make information technology good.

I would amend the last sentence to refer more generally to ‘technology’, rather than just to ‘information technology,’ for this lowering of standards is wide-spread. For example, it is precisely what allows us to claim that items fabricated from synthetic chemicals and compounds and shaped roughly into the appearance of traditional foodstuffs are, in any way, actually food.

Lanier is focused here specifically on the web side of this argument, not on the general case; but many of the things he writes apply more generally. For example:

Enlightened designers leave open the possibility of metaphysical specialness either in humans or in the potential for for unforeseen creative processes that we can’t yet capture in software systems. That kind of modesty is the signature quality of being human-centered.

To return to my example, this is the difference between manufacturing bread in factories and baking loaves in a wood-fired oven. (Brief aside: When did we begin using ‘manufactured’ to mean ‘not manufactured?’)

The former method asserts that there is nothing special about having a human bake bread; everything involved can be simplified down such that mechanical and software systems can handle it. The latter method, on the other hand, recognizes that there is potential inherent in the baking process that only a baker can explore. Choosing the first method devalues the second – devalues the method, devalues the bread, and devalues both the baker and the eater.

To return to Lanier, on this devaluation and its causes:

What computerized analysis of all the country’s school tests has done to education is exactly what Facebook has done to friendships. In both cases, life is turned into a database. Both degradations are based on the same philosophical mistake, which is the belief that computers can presently represent human thought or human relationships. These are things computers cannot currently do.

And on the resultant effects of this devaluation, this forced technological simplification, this database as life:

When technologists deploy a computer model of something like learning or friendship in a way that has an effect on real lives, they are relying on faith. When they ask people to live their lives through their models, they are potentially reducing life itself.

VIII.

2010-06-14T12:56:00-07:00

As you know, Safari 5 came out last week. Two of its best features are the Safari Reader and much improved support for HTML5.

Reader you know about. You might not know, however, that Safari 5 now outscores all other browsers on the HTML5 test. That’s exciting. It’s not complete support, but it’s a lot of the essentials. And, after all, the spec itself isn’t even complete yet.

Another thing you might not know is that I’m working almost exclusively in HTML5 these days. If there’s a reason not to use it, I’m not; but it’s my default and my preference. That means that my photography portfolio site – Hypsography – is all HTML5 under the surface. And that, in turn, means that the news articles I write for Hypsography make appropriate use of the article element, along with many other semantic elements. One <article> equals one article. Simple and clear.

Let’s review what Apple says about Safari Reader:

As you browse the web, Safari detects if you’re on a web page with an article. Click the Reader icon in the Smart Address Field, and the article appears instantly in one continuous, clutter-free view. You see every page of the article — whether two or twenty.

Totally. And it works really well, at least when you’re reading the Times. When you’re reading Hypsography, however, it works a little less well:

That’s not ideal. The ice photograph that’s intruding in the middle of the text is enclosed in an aside, which should be considered “tangentially related to the content around” it, but Safari apparently doesn’t get that. But at least it’s readable, somewhat. And, looking under the surface with the Web Inspector, this misinterpretation looks fixable via CSS.

What’s worse is what happens when you scroll to the end of the article:

Safari has decided that the article ends there. Arbitrarily decided, it seems, since the article does not end there. In fact, of the five sections into which that article – An end of the year review, inspired by Mr. Dalton Rooney – is divided, Safari has chosen to include only two of them. The first and the third sections. Naturally.

Let me clarify this a smidge more: The five sections into which this article is divided are delineated by section tags, all of which are contained with the one parent article. This is semantic, this is simple, and this is clear. You might figure it’d be easy too.

Oh well.

If anybody out there has an understanding of what precisely Safari Reader looks for in an article, please let me know. Thanks, and good luck.

VII.

2010-06-07T13:59:00-07:00

After a diapause of several years, Hypsometry again has a portfolio section.

VI.

2010-01-15T11:27:00-08:00

One small, but quite good, reason to rejoice at the coming of a widely useable @font-face: True small capitals are now possible on the web.

Small capitals are, as Alec Julien put it, “upper case glyphs drawn at a lower case scale.” They are not, however, simply regular capitals shrunk down; they are properly their own font, with their own characteristics, designed to work with both regular capital and lower case letters.

To be more precise: 1. The cap height of a small capital is the same as, or just slightly larger than, the x-height of the typeface’s lower case letters. 2. The weight of the strokes of a small capital are comparable, visually speaking, to the weight of the strokes of the typeface in general, at the size being used. 3. The proportions of a small capital are also comparable, visually speaking, to the proportions of the characters of the typeface in general, at the size being used.

Two implications of the latter two points are that the strokes and proportions of a given small capital letter will be heavier and more spread out than the strokes and proportions of the same letter upper cased, at the same point size. This is because small capitals have the form of regular capital letters, but the characteristics of the lower case.

Unfortunately, true small capitals are hard to come by these days. Computer software, as a rule, uses fake small capitals, created simply by scaling down upper case letters so that they are smaller than the originals, but larger than the associated lower case. This is true of web browsers as well as word processors, desktop publishing applications, and vector editors.

For instance, the second line above should look about like this, using true, properly designed small capitals: But, had I not @font-face to rely on, your web browser’s fake small capitals would make it look more like this: Not at all the same thing, clearly. The proportions of the second example are all wrong – simultaneously too big and too thin, tracked too tightly, and rather difficult to read. The first example is balanced, strong, eminently legible.

Using true small capitals on the web was not possible until recently, at least not with type that is actually type. Let’s look at how it works, and also, along the way, at several ways to fake small capitals. Comparing them all side by side will make even clearer the import of the differences I described above.

1. Setting the `font-variant` property to `small-caps`.

This is what should work. The W3C CSS standard tells us that font-variant: small-caps will instruct the browser to do the right thing. “A value of ‘small-caps’ selects a small-caps font”, it says.

This is how your browser interprets font-variant: small-caps:

Giambattista Bodoni: February 16, 1740 in Saluzzo – November 29, 1813 in Parma.

That looks okay, I guess. In comparison to the small capitals, the upper case letters and numerals look overly heavy. Some of the small capital letters – the t and the m, for instance – have strokes that are so thin as to almost vanish.

Let’s look at a second example, to make the differences clearer:

A a a — M m m — X x x

Now you can see quite clearly that the cap height of the small capitals is substantially larger than the x-height of the lower case letters, to say nothing of the overshoot of letters like a and m. Also, you can see how the proportions and weights of these fake small capitals match neither the upper case nor the lower case. All in all, this style of fake small capitals works quite poorly.

But why is this? The typeface in which this page is set – IM Fell Great Primer – has a small capitals variant, so why do the browsers not use it? After all, the CSS standard says that they should when font-variant: small-caps is used.

Sadly, no browser has actually implemented this. Instead of looking to see whether true small capitals are available, they all jump to the next portion of the standard:

It is acceptable (but not required) if the small-caps font is a created by taking a normal font and replacing the lower case letters by scaled upper case characters.

I’m not sure who, precisely, thinks that that is acceptable, but even if it were, it is surely not acceptable to ignore existing small capital fonts created by proper methods in favor of bogus ones created on the fly.

2. The Joe Clark method.

Faced with the problems above, Joe Clark suggested a simple alternative: Convert the text to capitals and reduce its size. This is, of course, exactly what the browsers do when you specify font-variant: small-caps. The slight theoretical advantage provided by Joe Clark’s method is that you can more precisely and carefully control how much the fake small capitals are scaled down, leading, perhaps to better matching of heights, proportions, and weights. A simple example:

Giambattista Bodoni: February 16, 1740 in Saluzzo – November 29, 1813 in Parma.

Of course, applied like that, Joe Clark’s method forces all letters and numerals to small capitals, even if that’s not what you desired. A slightly more sophisticated version of his method would apply the technique selectively – say, to letters that are already lower cased. Let’s assume that you have an automatic way to do so – a CMS plugin, for example, or a clever piece of Javascript:

Giambattista Bodoni: February 16, 1740 in Saluzzo – November 29, 1813 in Parma.

This, of course, is a total pain in the ass, and it makes a bit of a hash of the text’s HTML. On the other hand, it does allow for more precise control of the size of the fake small capitals, which might be helpful.

To see that more clearly, here is a third example – the same as the one in §1:

A a a — M m m — X x x

You see the same problems as in §1: The Joe Clark small capitals are too big and their proportions are wrong. The weights, however, are not quite as bad. Let’s look at a fourth example, comparing the font-variant method and the Joe Clark method, in that order, to see how the two compare:

a a — m m — x x

The proportions and weights of Joe Clark’s fake small capitals are better than those of the font-variant method, but only because the letters themselves are even larger. Hard to call that an improvement.

3. The Nick Shinn method.

This problem of how to fake small capitals when no proper ones exist, or the software will not let you access them, is not unique to the web. Nick Shinn has suggested that, in addition to capitalizing and reducing the size of the text, you should increase its weight. This allows for making the small capitals a little smaller – a little closer to the actual x-height of the typeface – while better preserving their weights and proportions.

A simple example:

Giambattista Bodoni: February 16, 1740 in Saluzzo – November 29, 1813 in Parma.

A more sophisticated example, again – as in §2 – imagining some sort of automated helper, and ignoring the complexity of the technique and the hash it makes of the HTML:

Giambattista Bodoni: February 16, 1740 in Saluzzo – November 29, 1813 in Parma.

This looks better in some ways, and worse in others. It is still basically unacceptable. Perhaps in some contexts, with some combinations of typeface and size, this might work well. Here, despite the improvement in small capital size, the overly heavy weight is too much. Of course, the typeface you see here has no true bold weight, so your browser is faking it; perhaps it is too much to hope that a faked heavy weight could help us, in turn, fake small capitals.

Let’s compare upper case, lower case, and Nick Shinn small capitals:

A a a — M m m — X x x

Correct height and proportions with excessively heavy weight is no better than incorrect height. And it turns out that the x-heights are not in fact correct: They only appear correct at this size of type. Try resizing the text in your browser window, and you’ll see that the evenness is limited to the sizes I’ve set here.

A fourth example, this time comparing the font-variant method, the Joe Clark method, and the Nick Shinn method, presented in that order:

a a a — m m m — x x x

Of these three, the browser scaling method seems the best, despite is many flaws. None produce good results, and it’s far and away the simplest.

4. Using `@font-face`.

There is an additional problem here, besides the technical failings of the browsers and the limits of what you can express using CSS: Proper small capital fonts are a rarity. Type designers design them, foundries sell them, but few non–professionals have them on their computers.

The typeface in which the Hypsometry Blog is set is IM Fell Great Primer, a beautiful typeface first cut by Peter de Walpergen, acquired by John Fell in the late 1680s, and digitally revived by Igino Marini. In its original metal, IM Fell Great Primer consisted of romans, italics, and small capitals. Sr Marini has created OpenType versions of all three, and made them freely available. As such, I can use @font-face to specify the use of the small capitals variant.

An example:

Giambattista Bodoni: February 16, 1740 in Saluzzo – November 29, 1813 in Parma.

And, again, a comparison with the upper and lower cases:

A a a — M m m — X x x

Glorious. The cap height of the small capital x is precisely the same as the x-height of the lower case x – and this holds true even if you resize the text away from how I’ve set it here. The cap heights of the small capitals a and m are smaller than the overshoot of the lowercase a and m. The visual weight and proportions of the small capitals are all quite similar to those of the lower case letters, even while the forms of the small capitals remain true to the appearance of the upper case.

Just to be absolutely clear, let’s see all four methods lined up side by side – font-variant: small-caps on the left, followed by the Joe Clark method, the Nick Shinn method, and the true small capitals of @font-face:

a a a a — m m m m — x x x x

The @font-face method is far and away the best. Unfortunately, it is the best in appearance and the worst to use.

The biggest problem, as mentioned above, is that few typefaces have proper small capital variants. Of those that do, some include them within the regular roman file, which puts them off limits to web use. Unicode currently does not define a place for small capitals, which means that browser cannot access them.

For example, you’re likely to have the typeface Didot on your computer. The roman of that Didot includes small capitals, but as glyphs 264–389, located in the Unicode range called “Glyph Variants”, which you cannot access within a browser.

Assuming that you’re using a typeface that includes proper small capitals, and that those small capitals are included as their own distinct font file, then you must declare a @font-face rule that makes use of them. In theory, you would do have already defined your romans and italics something like this:

@font-face {
  font-family: "IM Fell Great Primer";
  src: local("IM FELL Great Primer");
}

@font-face {
  font-family: "IM Fell Great Primer";
  font-style: italic;
  src: local("IM FELL Great Primer Italic");
}

In other words, we’re defining a font family named IM Fell Great Primer, the roman of which can be found locally as “IM FELL Great Primer”, and the italic of which as “IM FELL Great Primer Italic.” The browser loads both of those fonts, and when a reference to font-family: IM Fell Great Primer is found it uses the former when font-style is normal, and the latter when italic.

According to the W3C standard, there should be no difference when defining a small capitals variant:

@font-face {
  font-family: "IM Fell Great Primer";
  font-variant: small-caps;
  src: local("IM FELL Great Primer SC");
}

In other words, the font referred to by this @font-face rule is the small capitals variant of the IM Fell Great Primer family, and can be found locally under the name “IM FELL Great Primer SC.” When the browser encounters a reference to font-family: IM Fell Great Primer with font-variant: small-caps, it should then go ahead and use the font referenced above. An example of such a reference:

p strong {
  font-variant: small-caps;
}

However, the browsers do not yet understand this. Firefox, for instance, only understands font-weight and font-style within @font-face rules. That means that you cannot rely on the browsers to automatically use the proper small capitals variant, even when you have explicitly told them the necessary details. Instead, you must define a redundant rule like this:

@font-face {
  font-family: "IM Fell Great Primer SC";
  src: local("IM FELL Great Primer SC");
}

And then use it like this:

p strong {
  font-family: "IM Fell Great Primer SC";
}

That way you have explicitly told your browser where to find the small capitals variant and when to use it. And, when forced in this fashion, the browsers do finally get things right.

5. Other details.

It’s a bit convoluted, all this, and I haven’t even touched on how to properly prepare your font files for browser use, or how to really make use of @font-face. To summarize, use the Font Squirrel.

To see the CSS for all the methods discussed above, take a look at my Hypsometric CSS project. If you have any questions or suggestions, do let me know.

V.

2010-01-07T11:00:00-08:00

Over at Hypsography my work is continuing apace, and that pace is increasing. I’m continuing my explorations of humane typography there. The site is now set in Sorts Mill Goudy, an excellent revival of Frederic Goudy’s incomparable Goudy Old Style.

If you view the site using a recent version of Firefox, you’ll even see that the f and i of field are joined into one ligature – as they should be. Firefox is currently the only browser that supports serious OpenType typographic enhancements. Where by serious I mean kerning and ligatures. Yes, 460 years have passed since Gutenberg began printing with moveable type, and we are just now returning to those basic capabilities.

At any rate, Sorts Mill Goudy is a beautifully rendered typeface. Barry Schwartz is its author, and he has made it available under both the Open Font License and the MIT License: OFL Sorts Mill Goudy and MIT Sorts Mill Goudy. You can also find it in the Typedia, along with another excellent, though less completely realized, Goudy revival by Mr Schwartz: Goudy Bookletter 1911.

I used the Font Squirrel’s @font-face generator to prepare the files for Hypsography, and I highly recommend it. To make the process even simpler, the Font Squirrel already has OFL Sorts Mill Goudy in its archive, along with a pre-generated @font-face kit. Or, if you prefer, both Kernest and Typekit also include Mr Schwartz’s Goudy revival.

From the information available on the project site, Sorts Mill Goudy appears to be a work in progress. Nonetheless, it seems quite ready for use right now. Using Tim Brown’s web font specimen, I’ve put up a demonstration page for Sorts Mill Goudy on Hypsography, for your further inspection.

To return to my initial point: Hypsography has a new look, a new section for news and other ephemera, and a newly added tetraptych. Enjoy.

IV.

2009-11-27T00:00:00-08:00

III.

2009-11-22T10:00:00-08:00

While updating my reset stylesheet last week, I realized that if I wanted to reset the new HTML5 elements I would have to determine precisely how they were supposed to be styled. Which proved to be a challenge, since no browser yet supports anything like the full array of new elements and styles.

Luckily, the current HTML5 specification contains extremely detailed descriptions of how browsers should render HTML documents. These are not requirements, of course, but rather “a set of suggestions.” These descriptions, found in §11 Rendering, are of reasonable expectations; and thus it seems reasonable, in turn, that I base my expectations for the future behavior of browsers on them. (Realizing full well how deeply foolhardy that might be.)

Within the many suggestions listed in §11 – and they are many and detailed – there is one in particular that is relevant here: §11.2 The CSS user agent style sheet and presentational hints. This section walks through the varieties of default styles and describes how each HTML element is to be handled. Specific CSS is provided, and additional instructions and suggestions are noted. From time to time, the additional notes refer to styles best handled by CSS, though for the most part they don’t.

Regarding the new HTML5 elements, my goals are to:

Set up the appropriate display properties, so that blocks display as blocks by default.
Make sure that any elements that shouldn’t be visible are not.
Counteract, in a speculative, preventative manner, any styling that browsers are likely to apply.

§11 contains all the information I need to meet these goals. It describes the display types of the elements, including their visibility, and it describes all the other styling that should be applied by the browsers, once they support HTML5 more completely.

Therefore I compiled all the recommended CSS into one stylesheet. In doing so, I realized that the styles recommended are entirely too comprehensive. Styles for deprecated elements and elements modified by deprecated attributes are listed, so I removed them from my stylesheet. CSS bindings for each element are listed in §11.4 – but only Gecko supports that functionality, and it currently only supports it in a proprietary way; so I left out the bindings styles too.

In other ways, the recommended CSS does not go far enough. Two sets of styles, describing the appearance of h1 elements nested within the new semantic content elements, are so complicated that the draft standard only summarizes how they are supposed to work. Both §11.2.3 and §11.2.5 note that the styling of an h1 element varies depending on its context. Of course, h1 has its own default styling – font-size: 2.00em, for instance. But when you have an h1 nested within a section element – section h1, that is – it should receive font-size: 1.50em. And if you have another heading, nested even further - article section aside h1, for example – that should have font-size: 1.00em applied. This is important, since HTML5 has radically redefined how we are supposed to use headings.

Sadly, the draft standard authors have left it as an exercise to the reader to actually write the relevant styles, for all the nesting depths. I have done so, though I’m not entirely sure I’ve done so correctly. The permutations involved are reasonably complicated, particularly since section elements can nest within each other, though none of the others can.

There is only one additional change that I’ve made, a quite small one, but potentially useful. §11.2.2 Display types describes how each element should be displayed by default – head is hidden, blockquote is a block, table is a table, ruby elements are displayed like ruby characters, et cetera. The list of block level elements, however, does not include the details element.

An element new to HTML5, “the details element represents a disclosure widget from which the user can obtain additional information or controls”, according to §4.11.1. It is what the standard calls an interactive element, and is meant to act as a wrapper for other content which may be displayed or hidden as the reader prefers. The usage example provided – as well as the description of how to use the details element – suggests wrapping it around a dt and a dd, as if it were a special type of definition list. As such, it seems appropriate to style the details element as a block, and I’ve done so.

You can see the stylesheet that resulted from my compilation and editing on GitHub, along with some notes. You’re free to use it as you like. As always, please do let me know if you notice any problems or have any suggestions.

II.

2009-11-16T00:00:00-08:00

There are two important reset stylesheets out there, on the loose: Eric Meyer’s reset.css and YUI’s CSS Reset. Both are highly useful, though they differ slightly in the details of their approach and implementation. Eric intends for you to take his CSS and alter it to your needs, creating a reset stylesheet that works for your own projects. He describes it as:

The reset styles given here are intentionally very generic.… In other words, this is a starting point, not a self-contained black box of no-touchiness.

Yahoo, on the other hand, is aiming for a more complete resetting. They write:

The foundational CSS Reset removes the inconsistent styling of HTML elements provided by browsers. This creates a dependably flat foundation to built upon.

For a couple of years now, since Eric first described his ideas, I’ve used my own reset.css. A combination of Eric’s original code and YUI’s more comprehensive styles, modified here and there as needed. It has served well on many projects.

Now that HTML5 is at last upon us, my reset.css no longer quite fits the bill. For one thing, there are new elements that bring with them new default styles, which of course need resetting. For a second, other elements have been deprecated, and so I no longer need to worry about them. (Of course, you might, since your project might be different.) And for a third, and possibly most important, few of the new elements are supported sufficiently by the browsers.

Given all this, I’ve updated my reset stylesheet. It ignores deprecated elements, and gives the new ones display styles as needed. This also is not a self-contained box of resetting, but I do find it quite useful. You can find it on GitHub, along with some additional notes. You’re free to use it as you like. As always, please do let me know if you notice any problems or have any suggestions.

I.

2009-11-07T00:00:00-08:00

It’s not yet a new year, but I have a new home, this blog has a new life, and I’ve begun work on a new — though long overdue — project. The project is the realization of Hypsography, my field guide. This blog was given new form based on the beautiful typography of Cities of the Plain. And I’ve moved back across the country, to a valley limited by the Cascade and Siskiyou mountain ranges.

Let’s begin with the mountains. They call this valley the Rogue, but the Rogue River is north of here. The Klamath is to the south. Both rivers run from the Cascades to the Pacific, along vaguely parallel courses. Between the two lies a range of mountains called the Siskiyous, which are the northernmost of the Klamath ranges. The Klamath ranges extend inland from the Coast, covering the territory of what are — to the north and south, that is — the Coast ranges, though they are not two parts of the same system of mountains in geological or historical terms. Just south of here, around the border, the Siskiyous finish their eastern push where they collide with the Cascades. Ashland, the town where I now live, sits in the valley of a creek that flows into the Rogue, just north of that Siskiyou-Cascade intersection.

And, as you can see, the Hypsometry blog is back, for yet another go round. I’ve lost count of what incarnation this is — perhaps the sixth? The driving force here, this time, is simplicity.

The design was inspired by the gorgeous work done on Cormac McCarthy’s border trilogy; in particular, the title page of the first edition of Cities of the Plain, the concluding volume of the three.

In technical terms also, this site is as simple as it has ever been. Since I began designing and building websites — five years ago now — I’ve worked with a wide array of techniques for producing blogs. None has ever been quite right for my needs, so I’m trying yet another. With luck, this new system will have a little more sticking power. Whether it does or does not, expect my notes on the subject sometime soon.

Hypsography is my newest project, though I’ve been planning it for a couple years now. I have a hard time summarizing exactly what it is that I’m working on, in part because there’s so much to come and — so far — so little to show. I’ve written a few words about it on the site itself. But really, it’d be better if you just took a look yourself.

Nulla.

2010-07-22T10:07:00-07:00

This article serves an imaginary purpose: Dividing the old Hypsometry from the new. All articles older than this one are on their second or third go round the course; all articles newer are fresh, on their first legs.

Thus, do not take the old ones too seriously. They are preserved here, in internautical amber, for reference, for humor, and to help keep the links alive.

-I.

2006-02-20T21:00:00-08:00

Since last summer I’ve been working with Xenium Group’s excellent PivotCMS. At the time I started using it, my only real CMS experience was with TextPattern – a CMS of a fundamentally different design.

TextPattern is one of the new breed of small CMSes: very dynamic, conditionally structured, blog-oriented (which is to say: chronologically-oriented). Pivot, on the other hand, has been around as long as Blogger, and seemed more static and stodgy, overly concerned with things like security and documents.

In hindsight, I realize that Pivot’s intended audience is not that of TextPattern’s. As Xenium Group puts it: Pivot’s “targeted feature set is not all things to all people.”

Since last summer I’ve continued to build sites with TextPattern and Pivot, and have become quite familiar with ExpressionEngine and Typo. Doing so has made three of Pivot’s best features stand out clearly.

Pivot is a hosted CMS.

Being hosted means no installation, no need to familiarize myself with a client’s hosting arrangement, no need to talk to tech support, no dealing with .htaccess files, et cetera – all of which means less time spent by me and less money spent by my client.

That also means that Xenium Group provides support for Pivot’s operation, as part of the package, which means that my clients don’t have to wait for a hole in my schedule to get help – they can just go straight to the source.

Pivot publishes sites via FTP.

At first I hated this idea: Why not generate the site dynamically? That’s the slick way to do it. Creating the site in one place, then pushing it to another via FTP seemed unnecessarily complicated and needlessly time-consuming.

Now I get it.

When I redesign a site using ExpressionEngine, I build the new version on a staging server of my own. Then, when it comes time to launch, I have to do a multi-part dance:

The customized installation of EE needs to be moved to the client’s server, though without disturbing the old site that’s already in place;
That installation needs to be tweaked to match the client’s server’s setup, which always differs from mine; and
The old site needs to be turned off, and the new site turned on, simultaneously, and without interfering with each other.

That operation can go well, or it can go poorly; but it’s never simple. There’s always too much room for error.

When I redesign a site that uses Pivot, I can mess about with things on the CMS side to my heart’s content. Then, when everything’s ready to go live, I just click the Publish button and the new version gets sent out, via FTP. Simple as can be.

Pivot offers real previews.

Every CMS lets you preview articles; that’s a given. But Pivot’s the only one I’ve seen that lets you see a preview that actually shows what the final web page will look like.

Again, this is because Pivot is hosted and publishes its sites statically, via FTP. When you’re working with Pivot, you’re working on a Xenium Group server. You make changes to a document and click Preview, and Pivot generates a new version of that document from the appropriate templates, including all images and stylesheets, and serves it up for your previewing pleasure.

Makes sense, right? On the other small CMSes I have to jump through hoops to accomplish the same thing.

In conclusion.

Pivot isn’t right for every project, but then it isn’t meant to be. For sites that are suited for Pivot, it offers a solid array of features, plus a few stand-outs. It’s worth a look.

The Hypsometry Blog.

XI.

Bonsai.

Middleman.

Nanoc.

Staticmatic.

Webby.

Webgen.

Not quite a conclusion.

A historical aside.

X.

IX.

VIII.

VII.

VI.

1. Setting the font-variant property to small-caps.

2. The Joe Clark method.

3. The Nick Shinn method.

4. Using @font-face.

5. Other details.

V.

IV.

III.

II.

I.

Nulla.

-I.

Pivot is a hosted CMS.

Pivot publishes sites via FTP.

Pivot offers real previews.

In conclusion.

1. Setting the `font-variant` property to `small-caps`.

4. Using `@font-face`.