Tag: Safari - Page 2 - UNDERDOG of PERFECTION

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!

When is a CSV not a CSV? When you’re downloading it in Safari

Here’s another post that’s basically a cry for help. I did find this forum thread on the topic, but not a solution.

The problem: when I download a CSV file in Safari, for some inexplicable reason, Safari appends a .xls (Microsoft Excel) extension to the filename.

Never mind that I don’t use Excel… I use Apple’s own spreadsheet software, Numbers, from the iWork suite. Never mind that I don’t even have Excel installed on my Mac. Why, why on Earth, would Safari append a .xls extension on a CSV file? It’s not an Excel file; it’s a CSV. Different format. Sure, Excel can open it. But, you know what? Numbers doesn’t open it properly when it has that stupid extension on it.

Take the exact same file, remove the .xls extension (leaving the .csv extension), and Numbers opens it just fine. Leave it the way Safari has it, and it’s a mess.

This is not the only annoyance I have with Safari’s handling of downloads. I also hate how it automatically expands “safe” files, placing the original .zip or .dmg file in the Trash. I don’t want to delete those files! But if I turn this option off, it also doesn’t open the files I want it to open automatically, like Amazon MP3 downloads.

But hands down, this CSV bug — yes, that’s right, I called it a bug — is my biggest source of frustration. Sure, it’s easy enough to remove the extension. But it shouldn’t be there in the first place!

Fun with site usage stats, part two

Back in February, I wrote about web browser usage by visitors to my site. Some of the discussion over my recent redesign has prompted me to do it again. Here we go!

Web Browsers

Compare to last time: Firefox has jumped from 34% to 47%. That gain has come at the expense of both Safari and IE, which have dropped from 33% to 27% and from 28% to 17%, respectively. (Note, of course, that I’m rounding the actual percentages to whole numbers because talking about “16.88%” makes me feel like Spock on Star Trek, and I’m enough of a geek without that.)

Also worth noting: Chrome. It is stuck in fourth place, but its share has jumped by 4.1% from 1.44% to 5.54%. (OK, in this instance I needed to Spock it up a bit.)

Operating Systems

Once again, as a Mac user who also (unfortunately, despite my feeble efforts at self-promotion) represents a hugely disproportionate amount of the total traffic, I’m skewing the results here a bit. Still, I have not significantly altered my own usage of the site since February, but in that time Windows has nonetheless dropped from 56% to just under 50% of my total traffic, while the Mac has gone from 29% to 43%. Interestingly, in February, iPhone/iPod represented over 12% of the traffic but now they’re just over 4%. Linux has stayed pretty even, in between 2 and 3%.

OS/Browser Combinations

In February, IE/Windows was the dominant combination, at 28%. Now it has dropped to fourth place, at 17%. Firefox/Windows has gone from #2 to the top spot, even though it just inched up from 25% to 26%. Safari/Mac and Firefox/Mac each went up a spot as well, moving into second and third, and going from 21% to 24% and from 8% to 18%, respectively.

Conclusions

This is far too small and skewed a sample to say a whole lot about trends on the Internet as a whole, but what I’m seeing here overall is that Mac usage vs. Windows is up, and Firefox usage vs. anything else is also way up. Specifically I’m seeing a significant surge in Firefox/Mac… which may suggest, I suppose, that I have been visiting the site a lot more lately than I did in February. Or maybe not.

It’s also worthwhile to look at the raw total numbers in the traffic. In the time between then and now I’ve split up room34.com into a number of separate sites. The totals back in February were across the board on room34.com; for October we’re looking at stats strictly from blog.room34.com. The date range is the same: 30 days. (The original data was from January 19 to February 18; the new data is from September 20 to October 20.) Back in February, the data I analyzed represented 2,845 unique visits to my site. This month’s data represents 3,810 visits, an increase of 965, or 34%. Since the old stats included visits to a lot of pages that are now parts of other sites, the increase in blog traffic is even greater. So while it’s probably true that I’ve been spending more time looking at the blog myself in the past month, vs. February (considering I just did a redesign this weekend), the majority of the traffic increase is most likely not from me. In fact, it’s probably quite likely that my own percentage of the total traffic is quite a bit less than it was in February. Traffic here spiked on October 13-14, when I posted a reply to Derek Powazek’s blog on SEO — visits to that single page, just on October 13, represent more than 10% of the total traffic the entire site saw all month.

Let’s take a look at the OS/browser breakdown for just that one day, October 13, 2009:

The traffic from this one date was likely responsible for some overall skewing of the totals. Derek Powacek’s blog appeals most strongly to Mac users, which would explain why the Mac/Safari combination is in the top spot (Safari being far more popular in general on Macs than Firefox, for the same reason IE dominates Windows — it comes with the OS).

Lessons to be learned? Well, if I want traffic, I should write about SEO. The SEO bots (both human and software) seem to love it. But beyond that, I think there probably is some valid evidence here that there’s some real movement in the directions of both Mac and Firefox. Something that sits just fine with me!

Final Thought

What’s the deal with this “Mozilla Compatible Agent” on iPhone and iPod? I haven’t seen that before, but I assume it’s one of two things:

1. A Mozilla-derived alternative to Mobile Safari, available only on “jailbroken” iPhones.
2. An embedded client in an app like Facebook, which allows you to view web pages without leaving the app.

I’m inclined to guess that #1 is correct. I’d be surprised if any Apple-approved apps were running a Mozilla-based web browser; it seems it would be far easier and more logical to develop legit apps using the official WebKit/Mobile Safari engine. I haven’t seen any hard numbers (nor do I think it would be possible to obtain them) on the percentage of iPhones in use that are jailbroken, but if this assumption is correct, and we can assume that the ratio of “Mozilla Compatible Agent” to Safari on the iPhone/iPod platform represents at least the percentage of iPhones that are jailbroken (since I’d assume some jailbroken iPhone users still use Mobile Safari), then the numbers are staggering indeed.

However… given the fact that over 8% of the total traffic on October 13 came from this user agent, and I myself visited the site numerous times on that day from my (non-jailbroken) iPhone, to monitor and respond to comments, I suspect a much more innocuous explanation. But a brief yet concerted effort to find an explanation on Google turns up nothing. Anyone in-the-know out there care to shed some light on the situation?

Download those PDFs!

This post is strictly for web developers/server administrators. The rest of you can resume your daily activities, confident that nothing that was even remotely relevant to you transpired here.

PDFs. Web browsers. Both are a daily, or at least frequent, part of the lives of most computer users. But not all web browsers are created equal when it comes to the matter of handling PDFs. Some browsers (say, the ones developed by commercial OS makers) take the approach of trying to manage everything for the user. They include PDF readers that are embedded right into the browser, and PDFs load almost like another web page. Other browsers (most notably Firefox) treat PDFs as downloadable files, and when the user clicks a link to one, the file gets downloaded to their hard drive to be opened in a “helper app” — usually Adobe Reader.

Most website owners prefer the latter approach, and I suspect most users do as well. PDFs in general are not much like web pages, and it does not seem logical that they should be viewed within a web browser. Generally when people are accessing a PDF, it’s because they want to download the document to their computer to be used offline or to print. It is illogical for these actions to take place in a web browser. Sure, savvy users can right-click (or on Mac, Ctrl-click) and select “Save linked file as…” or some such nonsense from the contextual menu. But a lot of Windows users don’t even know their mouse has a right button, a lot of Mac users have no idea that you can press keys and click the mouse button simultaneously to perform special actions, and a lot of both would be confused by this entire process.

So we come to the matter of web developers (such as myself) trying to find ways to force the web browser to download the file instead of loading it directly. A trick I have used often is to link not to the file directly, but to a special PHP script that reads the file into the server’s memory, changes various aspects of the response (such as the MIME type), and then streams the content out to the browser. This is especially useful when you want to restrict access to files, say only to logged-in users, or only to users who have entered a special passcode. The PHP script is perfect for that, because it allows you to execute some code before sending the file to the browser. It even lets you store your files in a directory on the server that web browsers cannot access directly, ensuring (more or less… this article isn’t about hacking) the security of your files.

But what if your files aren’t in a protected area? What if you don’t want to bother with the mucky-muck of the PHP wrapper — you just want to link directly to the (browser-accessible) file, but you still want to force the download? Well, if you’re using Apache, you’re in luck. I found this great explanation of a small block of code you need to add to your httpd.conf file to achieve the same effect.

Ultimately, what you want to do is change the MIME type of the response. Browsers that are inclined to load PDFs internally perform this magic by seeking out files that are sent with the application/pdf MIME type. But there’s a very handy, “generic” MIME type for binary files, which all browsers treat as files to be downloaded rather than displayed directly: application/octet-stream. It may sound like a group of 8 singers standing in a small river, but it really just means… a generic binary file.

Here’s the complete block of code to put into your httpd.conf file, or into the appropriate virtual host configuration, however it’s stored on your particular server. I placed the code just within the virtual host configuration for the client in question, so the change applies only to their site, and not to any others that are also running on the server:

<FilesMatch "\.(?i:pdf)$">
ForceType application/octet-stream
Header set Content-Disposition attachment
</FilesMatch>

If you’re not the server admin, you should also be able to put this in a .htaccess file in your site’s root directory, but I haven’t actually tested that to see if it works.

Why does Safari 4 Beta take SOOOOO LOOOONG to start up? Am I the only one having this problem?

I downloaded and began using the new Safari 4 Beta the day Apple released it. I’ve complained (mostly on Twitter) about various aspects of it, things that I’ve now (more or less) gotten used to: most significantly the still-awkward title bar tabs.

But one thing I haven’t gotten used to is the ridiculous amount of time Safari 4 Beta takes to get up and running, at least for me. The window appears promptly after clicking on the icon, but then I’m visited by the dreaded spinning beach ball of death. This situation endures for at least a minute or two (if anything, I am exaggerating that time down), and then things proceed as normal.

At first I thought maybe it was something peculiar about my own site (even though it loads just fine in other browsers, including Safari 3), which I have set to load as the home page. But I just waited out Safari’s ridiculous start-up time, then went into the preferences and set it to load with a blank page. And it still took just as long, not even loading anything from the Internet. So clearly it’s just something in the internal workings of the app itself.

I have not seen anything anywhere about this issue. Everyone seems to love Safari to death, and says nothing about its speed other than how blazing fast it is. I guess it’s pretty snappy once it gets going, but for me all I can think about is this ridiculous load time at the beginning.

And so, this humble blog post shall serve as a beacon in the darkness, calling out to all those who suffer as I do (oh, such suffering) from an inexcusable lag at the start-up of Safari 4 Beta.

For what it’s worth, I’m running a stock black MacBook purchased just last August (right before Apple retired them, of course), 2 GB of RAM, Mac OS X 10.5.6. In other words, this should not be happening.

Also, for what it’s worth, once Safari has gotten going, my site loads very fast… less than a second on my cable connection. So it’s definitely not something with my site (thankfully, since I can’t imagine what it would have been).