14
Pixel imperfect

S&T Pixel imperfect 150716

Embed Size (px)

Citation preview

Page 1: S&T Pixel imperfect 150716

Pixel imperfect

Page 2: S&T Pixel imperfect 150716

MOANA teeny bit of a

about how hard it is to be a designer

Page 3: S&T Pixel imperfect 150716

Basically, if we pass certain browsers a fractional value they’ll actually display a fraction of a pixel. Which is very cool.

Except when it isn’t.

6.45px

The way of things

Page 4: S&T Pixel imperfect 150716

It’s called subpixel rendering.

“Subpixel rendering is basically a resolution technique where a machine or browser uses the individual RGB sub-pixels within a pixel to help increase

resolution of an image or type”

+ + =

Bits of pixels? What the heck…

I’m not going to get in to the science so just trust me on this.

Page 5: S&T Pixel imperfect 150716

Why can’t you all just get along?

If we don’t feed a browser a full pixel value - 44px, 300px, 95px - but instead make it try and calculate something like 25.2749% of 1035px

we get very different results across the browsers.

This type of calculation is not unusual in responsive web development.We want flexible measurements that can adapt and change.

We regularly ask browsers to figure out the spacing for themselves once we’ve

given them an indication of the sizing we want.

Page 6: S&T Pixel imperfect 150716

The way of (some) things

The first thing that happens - depending on the browser - is that the number is truncated and then calculated. After that it applies the rounded percentage

number to the element width.

Our example of 25.2794% of 1035px pans out as follows:

1035 * .252794 = 261.64179px

And it’s here where it all goes a bit Pete Tong…

Page 7: S&T Pixel imperfect 150716
Page 8: S&T Pixel imperfect 150716

Firefox truncates the percentage to three decimal places resulting in a width of 260.82px

Subpixel rendering

Chrome truncates after 13 decimal places resulting in a width of 261.64179px

Subpixel rendering

Safari truncates after 15 decimal places resulting in a width of 261.64179px

Subpixel rendering

IE9 uses 1035px * 0.25 to get 258.75px. It rounds to 259px

IE10/11 doesn’t round the final width so ends up with 258.75px

IE 9 - Full pixels

IE 10/11 - Subpixel rendering

Page 9: S&T Pixel imperfect 150716

260.82px

260px

261.64179px

261.64179px

IE9 259px

IE10/11 258.75px

Page 10: S&T Pixel imperfect 150716

That’s almost 3px difference

Page 11: S&T Pixel imperfect 150716

Who cares about a few px?

We do. Seriously. It keeps us awake at night. Things display ever-so-slightly differently on almost every browser.

Page 12: S&T Pixel imperfect 150716
Page 13: S&T Pixel imperfect 150716

It’s not quite that simple…

There are a couple of things we can do to try and mitigate the problem.

Give the browser what we want, what we really, really want… We can pass the browsers full pixel values only. Which works perfectly.The only downside is that it sets us back to the web design stone age.

Hackety, hackety, hack… A little bit of tweaked padding here, a few px of extra margin there, a smidgen

of random class names and Hey Presto! and we’ve got a solution that is probably worse than the problem itself.

There’s no solution from a standards perspective.

Page 14: S&T Pixel imperfect 150716

Time to accept the pixel imperfect

Vive la différence

The pristine translation of pixel-perfect design mockups to web pages is a thing of the past

We need to understand and embrace the differences between browsers. They aren’t going away.

We have to think in flexible terms and design with these in mind. Components should react to their surroundings, re-flowing to an optimal width.