Internet Explorer 11, unlike Chrome or Firefox, renders a small 28px x 32px placeholder for an unloaded image. This might getcha if you are using responsive sizing img { width: 100% }. Other browsers will render a full-width unloaded image with 0 height, but IE11 will render it large, maintain its size ratio. See pen.

You can use event.currentTarget in place of this inside jQuery event handlers

$('.button').on( 'click', function( event ) { console.log( event.currentTarget === this ); // true }); 

While this inside event handlers has become commonplace, I feel the event.currentTarget pattern is more obvious. It is more compatible working with other patterns that use this differently.

WebKit/Blink has a bug where making a DOM change to video elements will pause the video. This can prevent or stop video autoplay. Arnaud Leyder has a solid explanation on Stack Overflow.

The hack fix is to re-trigger .play() on the video after the DOM change has been made.

// make DOM change to video elem.appendChild( video ); // trigger .play() to resume autoplay for WebKit video.play(); 

See the Pen html5 video autoplay DOM change WebKit bug by David DeSandro (@desandro) on CodePen.

You can use padding-bottom as a way to set height of an element based on its parent width, so that it is proportional with its own width.

/* item sized as a square 1/3 size of container */ .item { width: 33.3%; padding-bottom: 33.3%; } 

If you are using box-sizing: border-box and the element has border, you would expect that element to remain a perfect square.

.item { width: 33.3%; padding-bottom: 33.3%; border: 2px solid; } 

But that’s not the case. Because the height is faked with padding-bottom, it’s not actually setting its height. Consequently, the height of the border is added on top of the padding-bottom height.

This can be resolved either by using outline instead of border, or using calc to account for the border size.

See the Pen bug with padding-bottom, border, and box-sizing: border-box by David DeSandro (@desandro) on CodePen.

My loader spinner wasn’t spinning.

.loader-spinner { animation: spinLoader 600ms steps(12, end) infinite; } @keyframes spinLoader { from { transform: translate( -50%, -50% ); } to { transform: translate( -50%, -50% ) rotate(1turn); } } 

The problem was that the keyframes for transform need to match. Even though there’s an implicit rotate(0turn) in the transform value, it’s required to be explicit for animation keyframes.

@keyframes spinLoader { /* match transform values */ from { transform: translate( -50%, -50% ) rotate(0turn); } to { transform: translate( -50%, -50% ) rotate(1turn); } } 

See the Pen loader spinner with CSS animation by David DeSandro (@desandro) on CodePen.

jQuery event namespaces allow you to separate event listeners.

// bind click listeners $element.on( 'click.alpha', function() { console.log('Alpha click'); }); $element.on( 'click.beta', function() { console.log('Beta click'); }); // unbind alpha click listener only $element.off('click.alpha'); 

EDIT The rest of this post is false I had thought I verified this, but alas, no. Triggering with a namespace will not trigger that event without the namespace.

They can also be used when triggering events, to specify where that event came from.

$element.trigger('click.pluginName') 

I’m using namespace triggering in Flickity, as a way to distinguish Flickity’s select event from the native select event.

// create jQuery event from original event object var $event = jQuery.Event( event ); // set type, like select.flickity $event.type = type + '.flickity'; this.$element.trigger( $event, args ); 

Firefox has native .watch() method.

The watch() method watches for a property to be assigned a value and runs a function when that occurs.

Interestingly, it’s special to Firefox.

Warning: Generally you should avoid using watch() and unwatch() when possible. These two methods are implemented only in Gecko, and they’re intended primarily for debugging use.

I discovered this when I was using watch for an option property name options.watch = true. My stuff worked fine in Chrome & Safari, but it was absolutely broken in Firefox.

I use ievms to browser test Internet Explorer. Every couple of months, the IE8 VM expires (This copy of Windows must be activated…). The only solution is to reinstall the VM. ievms maintainer xdissent also made iectrl, a command line tool to make stuff like this easier.

iectrl reinstall 8 

I tried removing .ievms/ files, and re-installing via the bash script. No dice. iectrl is the way to go.

To move all children from one element into another.

function moveChildren( fromElem, toElem ) { while ( fromElem.children.length ) { toElem.appendChild( fromElem.children[0] ); } } // move all children in alpha into beta moveChildren( alpha, beta ) 

When an element is positioned partly outside the window AND that element does not have a width set, its text will wrap inside the window.

See the Pen absolute text wrap by David DeSandro (@desandro) on CodePen.

This behavior threw me for a loop on this Masonry bug.

Jeremy Keith’s Conditional CSS technique currently doesn’t work in Chrome.

@media all and (min-width: 45em) { body:after { content: 'widescreen'; display: none; } } 

The problem is with how Chrome will not generate pseudo elements when set to display: none.

My current solution/hack is to fallback to the head font-size code, as Opera now supports this.

@media screen and (min-width: 45em) { head { font-family: widescreen; } } 

Thx @overflowhidden for the assist.

The white noise you hear in this Vine is the sound of my laptop fan whirling away at top speed. This animation is rendered in <canvas>, in Chrome. While the animation does have thousands of particles being rendered, I hadn’t expected the top-speed fan.

I’ve been able to pinpoint its cause. The animation was using the width of an image, this.img.width, for every particle, every frame. Setting this value to a separate property this.imgWidth has slowed down the fan significantly. I speculate that this issue is similar to reflow triggers.

Clearly, debugging via hardware machinations is not a good strategy. I still struggle with making sense of anything in the Chrome Developer Tools around rendering performance – especially for a rendering like this one, involving thousands of particles over thousands of frames.

Firefox doesn’t support canvas globalCompositeOperation darker. As it turns out, the darker composite value was removed from the canvas spec in 2007. See the globalCompositeOperation examples on MDN.

The closest solution is to use difference (which oddly enough isn’t in the spec), which Firefox (currently v28) does support. But difference is different from darker. difference subtracts channel values, darker multiplies them. If you’re using primary colors (#f00, #f0f, etc.) it may work.

IE10 supports neither.

See the Pen darker/difference canvas composite by David DeSandro (@desandro) on CodePen.

I’m looking to measure the width of an element with width: 66.666%, whose container is width: 300px. Most browsers return a fractional pixel value, i.e. 199.98px. Safari rounds off the fractional pixel value to 199px. It’s a bit odd, as I would expect it would at least round up to 200px when the value is that close.

See demo:

See the Pen getComputedStyle width 66.666% by David DeSandro (@desandro) on CodePen.

I’ve opened WebKit bug #126844 to capture this behavior.

I have found that using calc() values produces more expected results. If I change the width of the element to width: calc( 100% * 2 / 3 ), Safari returns with 200px. It’s still problematic, but it’s an improvement.

See the Pen getComputedStyle width calc( 100% * 2/3) by David DeSandro (@desandro) on CodePen.