Almost no-one has given informed constent to being tracked through spy pixels in emails, and yet the practice is endemic. This is wrong. It needs to change.
remwork with the user’s font size;
pxcompletely overrides it.
I love this kind of spelunking into the history of why things are they way they are on the web!
Here, Detective Chief Inspector Suzanne tries to get to the bottom of why every browser has eight pixels of margin applied to the
body element in the user-agent stylesheet.
I use Apple’s Mail app for my email so this is very handy:
An email tracker, read receipt and spy pixel blocker plugin for macOS Apple Mail.
This broke my brain.
The challenge: in the fewest resources possible, render meaningful text.
- How small can a font really go?
- How many bytes of memory would you need (to store it and run it?)
- How much code would it take to express it?
Lets see just how far we can take this!
I have to admit, I didn’t realise that text reszing behaved differently for user preferences compared to page zoom. For that reason alone, I’m going to avoid setting font sizes in pixels.
If 2 to 3% (or more!) of your users are relying on a custom font size, you should know that so you can either support that user preference or make a conscious decision to not support it. Doing anything less is frankly irresponsible, especially considering that users with larger font sizes may be using those sizes to compensate for visual disabilities.
Just recently on a Clearleft project, some of us were discussing whether there was a reason not to use
rems instead of
ems for media queries. Apart from one older browser implementation difference, we couldn’t come up with much.
Some in-depth research here supports the use of
em values for media queries. Very good to know.
You’ve probably seen this already, but it’s really worth bearing in mind: when you’re scaling up JPGs for retina display you can safely reduce the image quality by quite a lot—to the point of getting the exact same file size as a higher quality image that’s half the size.
Aaron should definitely skyblog more often if this is the result.
A great examination of the default settings for pixel density and how it can effect reported device width values on mobile.
This looks like being a fun little local event ‘round at the Skiff in May.
We need to make sure that Shaun Inman never discovers this site.
A clear explanation of device-width from PPK.
A handy tool for calculating grid and gutter widths although you'll still have to some calculating to get the figures to work in percentages (assuming you're designing for the Web).