It’s been a while since I last published anything about my pagering project — and a while since I last worked on it. But over the past few days I’ve put in some time and made some major changes.

The most significant change is that pagering has been rewritten as a jQuery plugin. This comes with a number of benefits; primarily, it’s now generalized for use outside the example page. The use of jQuery also means that I was able to greatly simplify the code, making it easier to track down logical issues related to calculating offsets.

Practical use

Let’s say you have an HTML page marked up with hAtom:

<div class='hatom'>
  <div class='hentry'>
    <h1 class='entry-title'>…
    <div class='entry-content'>…
  </div>
  <div class='hentry'
    <h1 class='entry-title'>…
    <div class='entry-content'>…
  </div>
  …
</div>

You want pagering to operate on all the entries:

jQuery(".hentry").pagering({ contentClass : "entry-content" });

(Note: "entry-content" is, in fact, the default contentClass the plugin will look for, but I’m being explicit for demonstration purposes.)

You can control how many columns are visible on a ‘page’ with the columnGap and columnWidth properties:

jQuery(".hentry").pagering({ contentClass: "entry-content",
    columnGap: "3em", columnWidth: "18em" });

Both properties will accept inputs of the form N, "N", "Npx", "Nem", "N%". columnGap defaults to twenty pixels, columnWidth to three hundred pixels.

Technical notes

The plugin is known to work correctly in Safari 4, WebKit nightlies, and Chrome 5. It’s broken in Firefox 3.6 because my hack to check for CSS property support indicates the browser recognizes column-gap, but the rule does not apply successfully. All other browsers are unknown.

Get the plugin

You can find all the code in the git repository, provided under the MIT license. Bug reports, corrections, and enhancements are welcome.

Last night I made some adjustments to the theme/design:

I changed my markup to be more in line with HTML5, primarily as a result of Mark Pilgrim’s Dive Into HTML5 chapter on the changed semantics. It’s not yet clear how microformats will be affected, so I’ve largely left the existing classes intact.

Of note:

• I had to add a CSS rule to make HTML5 elements display as intended: article, footer, header, nav, section { display: block; }
• I added quite a few rel='external's
• I was pleased to see that we can, in fact, remove type='text/stylesheet' from CSS declarations (because what other stylesheet language is there?)

I also un-hid the Tumblr bar. Previously I’d had the CSS rule iframe#tumblr_controls { display: none; } because I felt the bar interfered with the design.

Keywords are now exposed for each post. This is something that I’d written about ten months ago, but was reluctant to implement because I liked the minimal amount of metadata I displayed on entries. I’m not entirely satisfied with the way it came out, but it works okay for now.

There are other changes I’ve been working on, but I don’t think they’re quite ready yet.

Yesterday I wrote about my difficulty in getting certain CSS properties that I needed for my code. Today I discovered the solution.

After unsuccessfully poking around at a simplified version of my code, I decided to try looking at the complete list of the relevant element’s DOM properties, to see if I was simply asking for the wrong thing. I quickly discovered that element.style doesn’t give back an array; instead, it gives a CSSStyleDeclaration.

This wasn’t much use, so instead I went to the ever-helpful DOM reference provided by Mozilla. I hopped to the reference for element.style, and from there to window.getComputedStyle. Here I found what I wanted:

var element = document.getElementById("elemId");
var style = document.defaultView.getComputedStyle(element, pseudoElt).getPropertyValue(property);

This was too unwieldy to be used three different times (column-gap and variants), so I made slight rewrite and put it in my dom namespace:

var dom = {
  …

  getCSSValue: function(element, property) {
    var cs = document.defaultView.getComputedStyle(element, null);
    return cs.getPropertyValue(property);
  }
}

Now I can simply call dom.getCSSValue(paged, '-webkit-column-gap'); and move on.

When I first released pagering, I wrote:

It’s not bug free — the ‘pages’ don’t all appear at the same spot, and so on — but it’s written, and it works. Now I can move on to making it better.

Today I decided to work on making it better, and quickly figured out why the ‘pages’ render inconsistently. It turns out there are three variables involved:

1. the width of the ‘paged’ element in the CSS box model;
2. the padding of the element that holds the paged element; and
3. the CSS3 column-gap of the paged element.

I was only accounting for the first one. The second was easy to add, but the third is proving quite difficult. Currently, column-gap has only experimental implementations (in the WebKit and Gecko engines), so I can’t simply test against column-gap; I also have to check -webkit-column-gap and -moz-column-gap.

Fortunately, this much works — I can test against undefined and get a result from the different browsers. Unfortunately, that result is always a null string. This means that it doesn’t matter whether I’ve specified something like -webkit-column-gap: 2em; I’ll always get the same unhelpful answer. Here’s the code I’m using:

if (text.style.columnGap !== undefined) {
  columnGap = text.style.columnGap;
} else if (text.style.webkitColumnGap !== undefined) {
  columnGap = text.style.webkitColumnGap;
} else if (text.style.MozColumnGap !== undefined) {
  columnGap = text.style.MozColumnGap;
}

alert(columnGap.length); // always 0

Without knowing the column gap, I can’t entirely fix the rendering problem.

This brings us back to the entry’s title: how can I get vendor-specific CSS properties from the DOM? Have I overlooked something simple?

Update: I found a solution! Read about it here.