By John Gruber
Plan your novel, finish your dissertation, launch a product. You need Tinderbox.
15 years ago this week, I started Daring Fireball with this piece on a then-new lineup of PowerMac G4’s. I groan at the use of “the Daring Fireball” in lieu of the first person, but otherwise it holds up pretty well stylistically.
Not bad. ★
Back in May I wrote a piece titled “Safari vs. Chrome on the Mac”. From my conclusion:
In short, Safari closely reflects Apple’s institutional priorities (privacy, energy efficiency, the niceness of the native UI, support for MacOS and iCloud technologies) and Chrome closely reflects Google’s priorities (speed, convenience, a web-centric rather than native-app-centric concept of desktop computing, integration with Google web properties). Safari is Apple’s browser for Apple devices. Chrome is Google’s browser for all devices.
I personally prefer Safari, but I can totally see why others — especially those who work on desktop machines or MacBooks that are usually plugged into power — prefer Chrome. DF readers agree. Looking at my web stats, over the last 30 days, 69 percent of Mac users visiting DF used Safari, but a sizable 28 percent used Chrome. (Firefox came in at 3 percent, and everything else was under 1 percent.)
As someone who’s been a Mac user long enough to remember when there were no good web browsers for the Mac, having both Safari and Chrome feels downright bountiful, and the competition is making both of them better.
But really, taken as a whole, the response to my piece was about one thing and one thing only: the fact that Safari does not show favicons on tabs and Chrome does. There are a huge number of Daring Fireball readers who use Chrome because it shows favicons on tabs and would switch to Safari if it did.
The reaction was so overwhelming I almost couldn’t believe it.
The gist of it is two-fold: (1) there are some people who strongly prefer to see favicons in tabs even when they don’t have a ton of tabs open, simply because they prefer identifying tabs graphically rather than by the text of the page title; and (2) for people who do have a ton of tabs open, favicons are the only way to identify tabs.
With many tabs open, there’s really nothing subjective about it: Chrome’s tabs are more usable because they show favicons. Here are two screenshot comparisons between Safari and Chrome from my 13-inch MacBook Pro. The first set shows 11 tabs: the TechMeme home page plus the first 10 stories linked today. The second set shows 17 tabs: the Daring Fireball homepage and the 16 items I’ve linked to so far this week.
This is not even close. Once Safari gets to a dozen or so tabs in a window, the left-most tabs are literally unidentifiable because they don’t even show a single character of the tab title. They’re just blank. I, as a decade-plus-long dedicated Safari user, am jealous of the usability and visual clarity of Chrome with a dozen or more tabs open. And I can see why dedicated Chrome users would consider Safari’s tab design a non-starter to switching.
I don’t know what the argument is against showing favicons in Safari’s tabs, but I can only presume that it’s because some contingent within Apple thinks it would spoil the monochromatic aesthetic of Safari’s toolbar area. I really can’t imagine what else it could be. I’m personally sympathetic to placing a high value on aesthetics even when it might come at a small cost to usability. But in this case, I think Safari’s tab design — even if you do think it’s aesthetically more appealing — comes at a large cost in usability and clarity. The balance between what looks best and what works best is way out of whack with Safari’s tabs.
And it’s highly debatable whether Safari’s existing no-favicon tabs actually do look better. The feedback I’ve heard from Chrome users who won’t even try Safari because it doesn’t show favicons isn’t just from developers — it’s from designers too. To me, the argument that Safari’s tab bar should remain text-only is like arguing that MacOS should change its Command-Tab switcher and Dock from showing icons to showing only the names of applications. The Mac has been famous ever since 1984 for placing more visual significance on icons than on names. The Mac attracts visual thinkers and its design encourages visual thinking. So I think Safari’s text-only tab bar isn’t just wrong in general, it’s particularly wrong on the Mac.1
I really can’t say this strongly enough: I think Safari’s lack of favicons in tabs, combined with its corresponding crumminess when displaying a dozen or more tabs in a window, is the single biggest reason why so many Mac users use Chrome.
You can even make an argument that adding favicons to Safari wouldn’t just make Safari better, but would make the entire MacOS system better, because Safari gets dramatically better battery life than Chrome. For MacBook users who spend much or most of their days in a web browser, it can mean the difference of 1-2 hours of battery life. This is actually a common refrain I heard from numerous readers back in May: that they wished they could switch from Chrome to Safari because they know Safari gets better battery life, but won’t because Safari — seemingly inexplicably — doesn’t show favicons in tabs.
Favicons wouldn’t even have to be displayed by default to solve the problem — Apple could just make it a preference setting, and power users would find it. The fact that it’s not even a preference, even though it may well be the single most-common feature request for Safari, seems downright spiteful. And not just mean-to-others spiteful, but cut-off-your-nose-to-spite-your-face spiteful. It might sound silly if you’re not a heavy user of browser tabs, but I am convinced that the lack of favicons is holding back Safari’s market share. ★
And iPad, for that matter, which arguably places even more emphasis on icons over names than the Mac. ↩︎
Thanks to last week’s inadvertent release of an unredacted build of HomePod’s version of iOS, we know some things that we didn’t know before. One of those things is that the new edge-to-edge iPhone is codenamed D22, and that the OS explicitly supports an iPhone display with hardware resolution of 2436 × 1125 pixels.
For reference, all 4.7-inch iPhones to date (6, 6S, and 7) have a display resolution of 1334 × 750, at 326 PPI. All Plus models to date have a display resolution of 1920 × 1080, at 401 PPI. Apple publishes these numbers on the iPhone tech specs comparison page.
Back in 2014, in the lead-up prior to the announcement of the iPhone 6 and 6 Plus, I tried to guess the pixel dimensions of both phones:
But after giving it much thought, and a lot of tinkering in a spreadsheet, here is what I think Apple is going to do:
- 4.7-inch display: 1334 × 750, 326 PPI @2x
- 5.5-inch display: 2208 × 1242, 461 PPI @3x
@2x means the same “double” retina resolution that we’ve seen on all iOS devices with retina displays to date, where each virtual point in the user interface is represented by two physical pixels on the display in each dimension, horizontal and vertical. @3x means a new “triple” retina resolution, where each user interface point is represented by three display pixels. A single @2x point is a 2 × 2 square of 4 pixels; an @3x point is a 3 × 3 square of 9 pixels.
I could be wrong on either or both of these conjectured new iPhones. I derived these figures on my own, and I’ll explain my thought process below. No one who is truly “familiar with the situation” has told me a damn thing about either device. I have heard second- and third-hand stories, though, that lead me to think I’m right.
My guess about the 4.7-inch display was exactly correct. My guess about the 5.5-inch display was wrong, but my logic was right. All 5.5-inch iPhone Plus models have hardware 1920 × 1080 displays at 401 PPI, but at their default scaling (“Standard” as opposed to “Zoomed” in the Display section of Settings) they pretend to be 2208 × 1242 displays at 461 PPI, exactly as I predicted. (Actually, it’s better to think of it as 462 pixels per inch, because 462 is evenly divisible by 3, which is what you need to do convert pixels into points on an @3x retina display. So let’s use 462 henceforth. I should have thought of this back in 2014.)
iOS scales the user interface on the Plus models from the virtual resolution of 2208 × 1242 to the actual hardware resolution of 1920 × 1080 on the fly. The upside of this is that the display is less expensive and consumes less power. The downside is that the UI is not rendered pixel perfectly — the scaling uses anti-aliasing to fake it. But because the pixels are so very small, almost no one has sharp enough eyes to notice it, and because the physical resolution is so high (401 PPI), it looks sharper than the 4.7-inch displays which are running at their “true” resolution, with no scaling. But pixel-perfect “true” @3x would look even better.
Using similar logic, and considering all of the rumors and purported part leaks, I have a highly-educated guess as to the dimensions of the D22 display:
5.8 inches, 2436 × 1125, 462 PPI, true @3x retina with no scaling.
We’ve seen the numbers 2436 × 1125 before. Supply-chain rumor savant Ming-Chi Kuo suggested those numbers in a report back in February, which was summarized by both MacRumors and 9to5Mac. But what Kuo has predicted is different from what I’m suggesting. Kuo said the OLED display in this year’s new OLED iPhone will measure 5.8 inches diagonally and will have a total hardware resolution of 2800 × 1242. That’s corner to corner, the entire front face of the device, minus the bezels on the sides, top, and bottom. Within this 5.8-inch display, Kuo said there would be a 5.15-inch “display area” with resolution 2436 × 1125. The remaining area at the bottom of the display would be a “function area” (his term) where, presumably, a virtual home button would appear.
Here is the actual image from Kuo’s report, illustrating this.
I think Kuo has it wrong, and is conflating the pixel dimensions of two different iPhones. I think this year’s new flagship iPhone, D22, has a 5.8-inch 2436 × 1125 display. I wouldn’t be surprised if Kuo heard about a 2800 × 1242 display, too, but if so I think that phone is a Plus-sized version of this new form factor, with the same 462 PPI density and a size of around 6.6 inches diagonally. Such a display, with the reduced bezel design of D22, would be exactly as tall as an iPhone 7 Plus and slightly narrower. I wouldn’t be surprised if such a phone is in the pipeline for 2018.
From what I’ve seen, Kuo specified the size (5.8 inches) and the pixels (2800 × 1242), but he didn’t specify the PPI density. But given the size and the horizontal and vertical pixel counts, you can work out the PPI. Benjamin Mayo did so, and the result is 521 PPI.
A 521 PPI display doesn’t actually make sense though. I didn’t really think about this until today, but that number should have stuck out like a sore thumb back in February. Here’s the thing. It matters how big a point is, because it directly affects the real-world size of on-screen elements.
All non-Plus iPhones to date — every one of them from the original iPhone in 2007 through the iPhone 7 — has a display with 163 points per inch. In the pre-retina era, that meant 163 pixels per inch, too. Each pixel was a point, each point was a pixel. All @2x iPhone retina displays have 326 pixels per inch. Divide by 2 and you get 163 points per inch. That means that a 44-point touch target is exactly the same physical size on screen on all non-Plus iPhones. 16-point type renders at exactly the same size, and so on.
The 6/6S/7 Plus phones have a slightly lower points per inch density: take 462 (the number of pixels per inch in the scaled version of the UI), divide by 3 (because it’s an @3x retina display) and you get 154 points per inch. That’s OK, though, because fewer points per inch means that a, say, 44-point touch target will be slightly bigger on screen. 16-point type will render slightly larger, and so on. Larger tap targets are easier to hit, and larger type is easier to read. The iPhones Plus use most of their extra pixels (compared to their non-Plus siblings) to show more content on screen. But they also use them to make all content slightly larger.
A 521-PPI display doesn’t make sense because if you divide by 3 (because it’s @3x retina), you get around 174 points per inch. That’s not a huge difference, but everything would appear smaller on screen compared to an iPhone 7, and quite a bit smaller than on an iPhone 7 Plus. The only two natural pixel-per-inch densities for an @3x iPhone display are 462 PPI (154 × 3) and 489 PPI (163 × 3).
“What about scaling?” you might be thinking. Couldn’t the resolution of the display be 521 PPI and Apple could make the points per inch work out by scaling the interface dynamically, like they do on the Plus models? They could, but that would be really dumb. For one thing, if it’s @3x, they’d have to scale the UI up, not down. They’d be using a smaller image to fill a bigger screen. With the Plus, they use a larger image to fill a smaller screen. Scaling down is a reasonable and interesting compromise. Scaling up would be stupid. Surely a 521-PPI display would cost more to manufacture than a 462-PPI display. So why would Apple pay more for a display and use scaling when they could pay less for a 462 PPI display on which they don’t have to do any scaling at all? It would cost less, look better, and be more efficient.
So we know that iOS 11 has support for a 2436 × 1125 iPhone display. We know that 462 PPI is the “natural” (no scaling) resolution for @3x retina on iPhone. We know that a 2436 × 1125 display with 462 PPI density would measure 5.8 inches diagonally. We know that all rumors to date about the D22 iPhone claim it has a 5.8-inch display. We know that a 5.8-inch display with a 2.17:1 aspect ratio (2436/1125), combined with 4-5mm bezels on all sides, would result in a phone whose footprint would be just slightly taller and wider than an iPhone 7. And we know that all rumors to date say that D22 is slightly bigger than an iPhone 7.
We also know that the same section of iOS 11 that specifies the 2436 × 1125 display does not mention anything about a 2800 × 1242 display. Further, that same section of iOS refers to the iPhone Plus as having a 1920 × 1080 display — this is part of the OS that deals with the actual hardware resolution of the displays, not the virtual scaled display size.
We also know that a 2800 × 1242 display would have a slightly different aspect ratio: 2.25:1. Stephen Troughton-Smith noted today with a mockup that a purported schematic of D22 made from precise blueprints, which was leaked on Twitter by Benjamin Geskin back in April of this year, shows a display that exactly matches the 2.17:1 aspect ratio of a 2436 × 1125 display. A 2800 × 1242 display doesn’t come close to fitting that schematic.
We know these things. All of these facts point to the same conclusion: D22’s display is 5.8 inches, 2436 × 1125, 462 PPI. The only reason to think otherwise is that Ming-Chi Kuo reported otherwise back in February. The simplest explanation is that Kuo got this wrong, and either he or his sources conflated the displays of two different iPhones.1 ★
It also never made sense to me how Kuo would know about the precise dimensions of a single display that would be split into separate “display” and “function” areas. That’s something that would be handled by iOS in software, not something in the hardware. Kuo’s sources seem to be exclusively or almost exclusively in the Asian supply chain. I can’t recall him ever getting a major scoop related to software. My understanding is that Apple does not even send prerelease builds of iOS to China. Instead, Apple employees fly prototype iPhones from China back to the US for testing with development builds of iOS. ↩︎