Within Mike Taylor’s demo for Introducing the HTML5 History API, you’ll find this note:

window.addEventListener('popstate', function(e){
 // be nice to Chrome, the spec changed
 // and they haven't caught up yet
 // http://code.google.com/p/chromium/issues/detail?id=63040
 if (history.state){
   self.loadImage(e.state.path, e.state.note);
 }
}, false);

Per Chromium issue 63040, Chrome dispatches a popState event on initial page load. This was okay when HTML5 history was first introduced, but then the spec changed. It’s been over a year, and the bug still persists.

The easiest hack/solution, as proposed in comment 11, is to add the popstate listener right after the initial page load, in a setTimeout.

setTimeout( function() {
  window.addEventListener( 'popstate', myPopStateHandler, false );
}, 10 );

I’m weary of throwing a setTimeout in for a resolution, always seems like a kludge. But for now, hey it works.

The zoomed-out font-size threshold in WebKit is a mysterious anomaly I’ve long had my suspicions about, but now have finally tested. Take some body copy, start zooming out the page, and observe how copy with smaller font-sizes seem to maintain some legible size, even though they should be much smaller. Try hitting ⌘- too see the effect on this fiddle.

View fiddle - zooming font-size threshold

Here’s how Chrome 16 renders the fiddle with Zoom Out hit twice. Zoomed-out font-sizes 13px-9px are all rendered as the same size. Smaller font-sizes return to proper proportions. Note that this is not Safari’s preference to limit small font-size, as the teeny-tiny font-sizes are still rendered.

Zooming out four times, it appears that the threshold is setting a font-size to 9px. Any text set to 9px font-size or greater will be rendered at least the minimally-legible size of 9px. Anything smaller will be rendered proportionally.

The zoomed-out font-size threshold in WebKit is a mysterious anomaly I’ve long had my suspicions about, but now have finally tested. Take some body copy, start zooming out the page, and observe how copy with smaller font-sizes seem to maintain some legible size, even though they should be much smaller. Try hitting ⌘- too see the effect on this fiddle.

View fiddle - zooming font-size threshold

Here’s how Chrome 16 renders the fiddle with Zoom Out hit twice. Zoomed-out font-sizes 13px-9px are all rendered as the same size. Smaller font-sizes return to proper proportions. Note that this is not Safari’s preference to limit small font-size, as the teeny-tiny font-sizes are still rendered.

Zooming out four times, it appears that the threshold is setting a font-size to 9px. Any text set to 9px font-size or greater will be rendered at least the minimally-legible size of 9px. Anything smaller will be rendered proportionally.

Along with WebKit hardware-accelerated anti-aliasing, CSS 3D transforms can have adverse affects on type rendering when translate X/Y values have subpixel, or decimal values.

View fiddle: Subpixel type rendering. Hover over elements to disable transforms.

In WebKit, the first two elements will have fuzzy type and borders, as rendered elements don’t exactly line up with pixels on the screen.

Just to be thorough, I took a look at 2D subpixel translation transforms (i.e. translateX(0.5px)). In WebKit, the type seems to render appropriately with the subpixel values. However the borders don’t look so good. They get positioned in between pixel spaces, rendering a 1px border with 2 pixels. Firefox doesn’t have any issues with borders.

The fix is to prevent decimal values when using translate and round those values to the nearest integer.

via Apple Support Communities

Vertical editing isn’t a new concept. Googling it with regards to TextMate, I see that it’s oft-referenced as one of the top features. But darnit, I didn’t just start using it until a couple weeks ago. So killer. In TextMate, trigger vertical editing by holding Option and then select using the mouse.

Looking back at CSS3 formatting, vertical editing pairs best with vertically aligned properties. It totally makes sense for editing big blocks of vendor-specific redundant properties. No more cringing when you have to tweak a transition style.

  .foo {
    -webkit-transition: opacity 1s;
       -moz-transition: opacity 1s;
         -o-transition: opacity 1s;
            transition: opacity 1s;
  }

<figure> elements a good amount of margin from Firefox and WebKit’s user agent styles.

figure {
  display: block;
  -webkit-margin-before: 1em;
  -webkit-margin-after: 1em;
  -webkit-margin-start: 40px;
  -webkit-margin-end: 40px;
}

See fiddle figure margin

This is a new style within the past year, as 3dtransforms use <figure>s for the panels of the 3D objects. The default margin was offsetting all the panels.

normalize.css already has the situation under control, setting figure { margin: 0; }.

Quickly link to a commit in a GitHub message. SHA: followed by the first 7 or so of the commit SHA for that project will be converted into a link. For example, I just dropped:

SHA: 49b5c3a6eb509

which became - SHA: 49b5c3a

More goodies in GitHub Flavored Markdown. You can also quickly reference other projects and branches.

isFinite() is a top-level function (like isNaN()) that “Evaluates an argument to determine whether it is a finite number.” JFSIII pointed this out to me, debugging my code. I got lazy checking a numeric value was not undefined and had something like this:

// check if value is defined
if ( value ) {
  // do stuff..
}

The problem was that 0 would be a proper value, but it is evaluated as falsey in the above conditional.

!!0
// >> false
!!isFinite(0)
// >> true

// check if value is numeric
if ( isFinite(value) ) {
  // do stuff
}

isFinite() does not specifically check if the value is a number, as it returns true for booleans.

isFinite('foo')
// >> false
isFinite(function(){})
// >> false
isFinite(true)
// >> true
isFinite(false)
// >> true