A reason to install Microsoft Edge on your Mac: viewing cookies

As a web developer, I actually don’t use cookies that often (mainly because I’m not interested in tracking users’ behavior). But I do need to use them occasionally, such as to remember when they’ve clicked the “X” to close a modal alert, so I don’t keep showing it to them on each new page they visit.

That’s what led me to today’s surprising discovery. My cookie wasn’t working properly, so I wanted to investigate a) whether or not it was actually being saved, and b) what data it was saving.

I work on a Mac, and Safari is my primary browser. But I already knew Safari doesn’t let you inspect the contents of cookies, so I fired up Chrome, which is my go-to for testing anything that I can’t test with Safari. I know Chrome always used to let you inspect the contents of cookies, so imagine my surprise today when I discovered that, at some point fairly recently, Chrome apparently removed that capability. You can still see which sites have stored cookies, and how many, but you can’t investigate the details any further than that. Seriously??

Next I tried Firefox. Nope, same.

At this point I was highly dubious that the fourth browser in my testing queue would handle things any differently, but I had no alternative, so I reached for that rarely-clicked-upon blue-green swirl icon in my Dock, loaded my page in Microsoft Edge, and… what do you know, Edge does still let you inspect the exact contents of stored cookies.

But for how long?

Anyway… for now, I have a justification for keeping Edge installed on my Mac.

Get Gmail to scale inline images to fit the browser window (in Chrome and Safari)

If you use Gmail on the web as your main email platform, and your work often involves people sending you emails with large high-resolution images (which ideally would be attachments, but are often embedded inline in the message), you know this problem. The images are frigging huge in the browser window, and the viewing panel ends up with a horizontal scrollbar, with paragraph text trailing off the screen. Having to scroll horizontally to read emails is really awkward and irritating! Why doesn’t Gmail at least offer an option to auto-scale inline images to fit the width of the window?

I discovered there’s a Chrome extension to fix this. If you’re a Chrome user, just download it and you’re done.

But I don’t use Chrome, I use Safari. And there doesn’t appear to be an equivalent Safari extension. I did, however, continue down the trail to the CSS file in the GitHub project for that Chrome extension. The CSS is quite simple:

[data-message-id] > div:nth-child(2) img:not([role=button]):not([role=menu]):not([width]) {
max-width: 100%;
width: auto !important;
height: auto !important;
}

That’s all it takes to get Gmail to shrink inline images in an email to fit the window. But how do you get Safari to apply that CSS? This is not so hard, either.

First, save the above CSS code into a file, maybe called gmail.css so you’ll remember what it’s for, and save it somewhere that makes sense to you, such as your Documents folder.

Next, open the Safari preferences, and click on the Advanced tab.

Click on the Style sheet dropdown and navigate to the gmail.css file you saved. That’s it! If you have a Gmail message containing a huge image open in Safari while you’re doing this, you should immediately notice the image pop down to a reasonable size. Huzzah!

A passable but imperfect solution for full-bleed background images on Android and iOS

I’m working on a site right now that has a fixed, full-bleed (i.e. background-size: cover) background image on the <body>. The content flows over it, mostly obscuring it completely, but the background is occasionally revealed in the spaces between content blocks. Some blocks have a semi-transparent background so you can see the fixed background as if through frosted glass.

Here’s the CSS:

body {
  background: rgb(255,255,255) url('../images/ui/body_bg.jpg') center center no-repeat fixed;
  background-size: cover;
}

It’s a cool effect, but it really, really does not want to play nicely on mobile. Various odd things happen on both Android and iOS, and they are completely different.

Quick side note: Yes, the background image is a JPEG. Normally I only use PNG or SVG images in UI elements, but I had good reason to use JPEG here: even though it’s only two colors (with some in-between colors due to antialiasing), the pattern in the background is incredibly complex, and a JPEG version of the file is about 1/5 the size of the PNG. And since it’s an illustration, I tried making an SVG version first, but the pattern is so large that the SVG was about 2 MB! So JPEG it is… which may be a factor in the issue I’m having on Android, but I haven’t tested a PNG version of the image to verify that.

iOS Problems

I’m an iPhone user, so I mainly test responsive sites on iOS. I do own an Android phone (a Motorola Moto E, which I highly recommend as a cheap-but-decent Android phone for testing), but I generally only break it out during the final round of browser testing prior to launching a site.

The issues with background images on iOS are well-known to most web developers. iOS has a number of rather arbitrary seeming limitations imposed upon the Mobile Safari browsing experience, generally for one of three reasons: 1) performance, 2) touch interface usability, 3) the whims of the ghost of Steve Jobs. In the case of background images, background-attachment is not supported. I’m not really sure how this would impact either (1) or (2) — although I think with the early underpowered iPhone generations, it did impact performance — so I think we’re dealing mostly with (3) here. At any rate, because you can’t have an attached background on iOS, I added this in my media queries:

@media screen and (max-width: 782px) {

  body {
    /* For background handling on iOS */
    background-attachment: scroll; background-repeat: repeat;
  }

}

Another quick side note: Why is my phone break point at 782 pixels, you ask? Because that’s where WordPress has its break point for the admin interface. I’m not exactly sure why the WP team chose that number, but why fight it?

Besides the background attachment, there’s also the issue that background-size: cover on a phone is going to make the background image huuuuuuuuuge because it’s scaling it to fit the height of the page content, not the screen size. I initially solved that with background-size: 100%;, since we’re now allowing the background to repeat. As you’ll see, however, that led to problems on Android, so I ended up scrapping it.

Android Problems

Yes, Android has problems. Don’t even get me started! But I wasn’t prepared for this.

I opened the page in Android, and, although the background image was displaying as I expected in terms of size and attachment, it looked… awful. The original source image I am working with is a generous 2400 x 1857 pixels, enough to look reasonably sharp on most displays, even at high resolution. And it looks great on my Mac, great on my iPhone. But on the Android phone it was splotchy and low-res looking… like it had been reduced to 200 pixels and then upscaled (which is maybe what Android is doing, somehow… and here is where I’m wondering if the image being a JPEG is a factor, but that’s just a stab in the dark).

I tried a number of possible solutions, the most obvious being to set exact pixel dimensions for the image. I tried 1200 x 929, basically a “x2” size for high-res devices. Still looked like crap. I even tried setting it to 2400 x 1857, the actual dimensions of the image, and it looked like crap… and I don’t mean pixel-doubled, which is what it actually should be; I mean the same splotchy weirdness I had been seeing at other sizes.

And then I discovered David Chua’s solution:

html {
  /* For background image scaling on Android */
  height:100%; min-height:100%;
}

Yet another quick side note: Here I am not placing this inside a media query. We don’t want to only fix this issue on phone screens. Granted, the iOS solution above needs to work on iPads, too… something I haven’t really solved here. I’m workin’ on it!

This change for Android worked perfectly! By this point I had, temporarily at least, removed the iOS workarounds I mentioned above, so on Android the background image was not only perfectly scaled to the browser window, looking sharp and clean, but it was even fixed-position, just like on desktop!

But… the image was back to being huuuuuuuuuge on iOS. Apparently this html trick for Android does absolutely nothing on iOS, so you’re left trying to find another solution that won’t simultaneously break Android.

An uneasy compromise

It’s not perfect, but I found that if I put both of these tricks together, everything works… the only thing we lose is the fixed-position treatment that Android allows but iOS does not. But the background looks great on both platforms and most importantly, behaves consistently on both.

Here’s the complete code I’m rolling with, for now:

html {
  /* For background image scaling on Android */
  height:100%; min-height:100%;
}

@media screen and (max-width: 782px) {

  body {
    /* For background handling on iOS */
    background-attachment: scroll; background-repeat: repeat;
  }

}

As noted above, this doesn’t really address iPads. A simple solution would be to change the media query to @media screen and (max-width: 1024px), but a) that doesn’t account for the larger iPad Pro and b) it also means a desktop display will lose the proper background effect if the window is smaller than that size. I don’t really have a solution; an adaptive treatment using either server-side or JavaScript-based browser detection would be a consideration, but I don’t really like resorting to that sort of thing for something as basic as this.

It doesn’t help that I recently gave my iPad to my daughter so I don’t currently have a tablet of any kind for testing. That’s about to change as I have a newly ordered Kindle Fire arriving today, but of course that’s not going to give me the answer for an iPad. I can try Responsive Design Mode in desktop Safari, but that’s not always a perfect representation of the quirks of an actual mobile device.

Still… this combined solution for phones is an improvement over the default behavior in both cases.

My (just-discovered) workaround to the WebKit letter-spacing bug

Update (5/29/2012): Upon working further with the project that formed the basis of this post, I discovered that my solution did not work, or at least, no longer worked. It’s not uncommon as I get deeper into a project with a large CSS file that there are subtle, inadvertent effects of the various CSS properties that get added along the way. Looking back now, I can’t determine for sure whether my solution did once work with the simpler version of the site, and something else I added later counteracted it, or if I was just too eager about a solution to realize it never quite worked in the first place. As a result, I had considered deleting this post entirely, but I have decided to leave it live, to further the discussion of the topic, or at the very least to serve as a monument to my challenges.

WebKit, the rendering engine “under the hood” in both Safari and Chrome, has a known issue handling the CSS letter-spacing property at certain small increments, and at certain font sizes.

Specifically, if defining letter-spacing in increments smaller than 1px or 0.1em, it seems to just ignore the property altogether… except at larger-than-default sizes.

I typically use em or % these days to define text sizes in CSS. So in my situation, I’ve found that my letter-spacing: 0.05em works if I also specify font-size: 125% (or larger), but if I have font-size set to 100% or less, the letter-spacing gets ignored.

Typically, after loading reset.css, I set a baseline font size for the document with body { font-size: 100%; } (or some size… actually it’s usually 80% but these days I’ve been leaning towards larger type).

I decided to play around with this a bit to see if I could resolve the letter-spacing issue, and I found a nice, easy solution that works at least for the particular site I’m currently testing it on. Your experience may vary, depending on how your HTML is structured and how complex your design is.

Here’s the solution:

body {
  font-size: 125%;
  letter-spacing: 0.05em;
  line-height: 1.3em;
}

body>* {
  font-size: 85%;
  line-height: 1.3em;
}

You may want to adjust the exact values of font-size to suit your needs. (And, yes, I’m aware that mathematically 125% and 85% don’t cancel each other out, but they’re close enough for my purposes.) It’s important to include the line-height property in body>* to define your target line height; otherwise your lines will be too far apart. Set it to whatever your ideal value is. (I usually prefer line-height: 1.5em personally, but for larger type, as on the site I’m currently working on, it gets too spaced-out.)

So what’s going on here? Well, strangely, it seems WebKit can actually render smaller type with line-spacing less than 1px or 0.1em just fine, but it won’t unless somewhere in the “cascade” the type has been defined as being a certain amount larger than 100%. I don’t get it, but until the bug (which it seems clearly to be after all of this) gets fixed, at least this seems to be a reasonably clean workaround.

It’s very important that you use body>* and not just body *. If you don’t know why, well… try it out and see. (The upshot: we’re applying a uniform scaling-down across the board on all elements directly under body, which is practically the same as just defining our target font size directly on body itself, but with the benefit of working around the letter-spacing bug.)

Note: I have only tested this using em as the unit of measure for letter-spacing. I’m aware of the issue with px as well, but I’m not sure this solution will work for that. But… really… just use em instead!