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.