“The Web is Agreement.” Jeremy Keith’s eloquent statement neatly summarizes the balance that makes it possible for us to build amazing things. Each week, new devices appear with varying screen sizes, pixel densities, input types, and more. As developers and designers, we agree to use standards to mark up, style, and program what we create. Browser makers in turn agree to support those standards and set defaults appropriately, so we can hold up our end of the deal.
This agreement has never been more important.
That’s why it always hurts when a device or browser maker does something that goes against our agreement. Especially when they’re a very visible and trusted friend of the web—like Apple.
You see, Apple’s newest tablet, the iPad Mini, creates a vexing situation: Its device-width viewport tag defaults to the same values as Apple’s original iPad (768×1024 pixels), even though the Mini’s screen is physically 40 percent smaller. That means every button, graphic, link, and line of text on a web page on the iPad Mini appears tiny—even when we try to do the right thing and build flexible, multi-device experiences.
Two iPads, one too small.
But Cupertino isn’t the only culprit out there. This is a problem that’s been brewing since we started using the viewport—and it has to do with not just pixels, but our own practices as well. Let’s take a step back and understand what’s really causing today’s woes—and what all of us need to do about it.
The trouble with pixels#section2
Today’s viewport woes can be traced right back to pixels—yes, those tiny elements we work with every day.
The first pixel challenge is quantity. The more pixels in the display, the more information can be displayed. But as these are physical pixels whose number can’t be altered after the fact, a second factor comes into play: the screen’s physical size.
Imagine two two-inch-wide displays (about the width of the iPhone), as shown below.
Two devices, each with a two-inch-wide display. The one on the right, at 640×960, would pack four times as many pixels into the same space as the 320×480 screen on left.
The first is 320×480 pixels, the second 640×960. This gives the second display four times as many pixels as the first, but fits all of them into the same physical space. This smaller pixel size results in content that is also smaller—making it crisper, but much harder to read as well.
This is exactly what happened on the Nokia E60. In 2005, most mobile phone displays were about an inch and quarter wide, with an average of 176 pixels in that width. But the E60, which sported a “huge” 352×416-pixel display, crammed twice the number of pixels into a similar amount of space. The result: A gorgeous, crisp—but often hard-to-read—display.
The E60 also introduced a now-familiar problem: how users would manage to surf “big” sites on a tiny device. Nokia’s solution was a new browser, the Mini Map. This browser behaved similarly to today’s smartphone browsers by first rendering the full-sized page, then scaling it to fit the available screen size. Superimposed onto this rendering was a transparent red box that could be repositioned using the device’s joystick. Clicking the joystick would zoom the content indicated within the box.
Enter viewports#section3
Mini Map was probably one of the first commercial uses of a dynamic viewport—a construct designed to dynamically change the size or scale of the visible screen area in order to improve the user experience. But it was far from the last.
In 2007, Apple released the iPhone, a much larger device than the E60, but one with a similar problem. Even on a “huge” two-inch display, surfing the “real web” on an iPhone meant loading large pages onto a small device. Apple chose to solve this problem through a series of carefully orchestrated enhancements.
The first was the creation of a virtual viewport similar to the one Nokia designed for Mini Map. When encountering desktop websites, the browser would render them at their full size (based on a default canvas width of 960 pixels). It would then scale them down to fit the two-inch display. Users could interact with the page to scroll and zoom in on areas of their choice.
Apple didn’t stop there. It also developed a new viewport meta tag. Sites not using the tag would be rendered using the default, legacy-web viewport of 980 pixels. But developers who opted to use the tag could declare the viewport for their sites, including setting the width to the all-important device-width value. This value tells the browser, “please pick a width that fits this specific device’s screen best.”
Other mobile browser vendors were quick to follow Apple’s lead. Nowadays just about every mobile browser supports the viewport meta tag, including the device-width value. This provides us with an even playing field: It respects the efforts of those who take the time to adapt sites for the multi-device web, while those who haven’t yet made this transition still receive a “good-enough” default experience.
Mini problems#section4
The value device and browser vendors assign to device-width is directly related to that device’s physical dimensions. Physically smaller devices need a smaller device-width value (which will result in larger content). Set a value that’s too large, and most content will be too small to comfortably read.
And that’s why Apple’s iPad Mini has a vexing viewport. It uses the same 768-pixel device-width as the regular iPad, even though its physical size is much smaller. One would expect to see a device-width more in line with those of similarly sized tablets like the BlackBerry PlayBook or second-generation Samsung Galaxy 7″—around 500 to 600 pixels, as shown in this chart.
Because of this device-width, web pages appear 27 percent smaller on the iPad Mini than they do on the Google Nexus 7 (calculated based on the relative size of device pixels)—all because Apple decided to describe the device’s viewport as 768 pixels.
Solving for content size#section5
One of the first places this causes problems is in text: More pixels in a smaller space means that fonts sized in pixels will look correspondingly dinky.
Of course, many of us aren’t sizing in pixels anymore—we’re using relative dimensional elements like ems, right? Only, that doesn’t quite solve the problem this time.
When we use ems, we imply a certain trust that the browser’s baseline font size at the default zoom level—1em or 100 percent in unit parlance—is sane and readable. But that’s not always the case. The browser’s baseline font-size value (1em) roughly equates to a 16-pixel square. This ratio serves as a ligament that binds absolute and relative units, but it can vary from browser to browser.
On the iPad Mini, font-size at baseline is precisely 16 pixels. That may have worked fine when fewer pixels were packed into our screens, but on a dense display with an improperly defined viewport, that’s going to be uncomfortably small.
Not all browsers toe the 1:16 em-to-pixel line, though. The Kindle Touch’s browser, for example, has a high-density viewport, but adapts by using a 1:20 ratio, kicking the default font size up a few pixels for readability.
This might not fix all of iPad Mini’s viewport problems, but at least the content would be legible.
Three seven-inch tablets. Note the difference in rendering.
So why did Apple do this?#section6
To understand why Apple would release a product with such a vexing viewport, we don’t have to look further than our own habits.
In the wake of the iPad’s initial release, web folk worldwide scrambled to adapt sites to look good on the new tablets. Somewhere along the way many of us collectively settled upon pixel-based notions of tablet-ness, and those notions often resulted in fixed, 1024×768-pixel layouts precisely targeted at these devices.
Were Apple to decrease the device-width value for the iPad Mini on account of its smaller physical size, it would guarantee a second scramble as existing tablet-adapted sites assuming a 1024×768 viewport suddenly looked unexpectedly wretched on the new device.
The responsibility here goes two ways. Browser makers need to provide reliable baselines of viewport and text sizing, yes. But we as implementers also need to stop grasping for pixel-perfect control over our layouts (the “control” is an illusion, anyway).
A way forward#section7
The only way for us to move forward is together. As developers and designers, we need to hold up our end of the bargain and be mindful of how we do our work—and that means letting go of the notion of pixel precision once and for all. We need to earn the trust of browser makers so they hear us out when things just frankly aren’t right. We hope this article illustrates we’re trying to do the right thing. We hope browser makers acknowledge that and follow suit.
Standards and consistency are more important now than ever before. Please let browser makers and device manufacturers, like Apple, know that we rely on consistent and reliable decisions about default viewports and their zooming. We’re willing to hold up our end of the agreement, and we need them with us.
Let’s move into the future—together.
I’m not sure why we’d want any device maker to lie about their device width. If the screen is 768px wide, that’s what it should report. I can be ok with it abstracting the notion of pixels away, but it better be able to do so cleanly (unlike Retina displays that make images look horrible, but still report a low device width).
I think what I’d prefer to have is a pixel-density metadata value that I could use to determine any changes. But reporting a bad number to deal with designers that didn’t understand how to design for the device seems like a one-way trip to incompatibility town and builds up legacy cruft that well have to wait for HTML7 to clean up.
No thanks.
Well like Nathan said, the iPad mini’s screen is actually 768 pixels wide, so it’s not exactly “wrong” to report it as such.
Rather than (or as well as) pixel-density values, though, I think it’d be more useful to use physical units (mm, in, pt, whatever) and make them meaningful rather than 96px = 1in.
Some important points that are not mentioned in the article:
The iPad mini has a 7.9inch screen it is therefore 35% larger than the 7 inch Nexus 7
You can alter the orientation of the device making the view port 768 or 1024.
View port does not guarantee pixel density. Many devices are moving to 1920×1080 even at “small sizes” (<5") and the nexus 10 has a surprisingly large 1600 x 2560.
Touch screen mobile devices have far easier horizontal scrolling that desktop devices as well as easy zoom (many desktop users are not aware of browser zoom functions, but mobile users are). Which to some extent lends itself to avoiding constriction of view space to a single axis.
Many mobile devices are viewed at closer distances than desktop devices and the size of the device tends to impact on the distance the device is held.
I have not visited a website which successfully uses viewport to the extent that it is superior to the "desktop" version of the same site on the same device. Whether this is a technical, cost or skill issue is unclear.
I work daily on a beautiful MacBook Pro 15″ with an Hi-Res screen that has a 1680×1050 native resolution. It’s not Retina/HiDPI, but with 128ppi ( “List of displays by pixel density on Apple computers”:http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density#Apple ) it’s quite difficult to read texts on some websites. I often increase the base font-size to read, using _Zoom Text Only_ in Firefox.
I also occasionaly surf the Web on a Mac mini plugged to my 52″ FullHD TV (1920×1080) which is 3.5 meters away from my couch. Needless to say, it’s also extremely difficult to read text on most websites. I’ve increased the base font-size in Firefox’s settings to @24px@ instead of @16px@, but websites using @px@ font-sizes are not affected and a lot of websites even if using @em@ font-sizes break if the base font-size if increased above @20px@.
What I want to show there is that there is no way to be 100% satisfied with devices default font-size and viewports, because not everyone use same devices the same way.
I agree Apple’s choice here is a bad one, but it’s moreover one that makes the issue more visible, it’s the visible part of the iceberg.
What we really need IMHO to be “Future Friendly”:http://futurefriend.ly/come-aboard.html is:
* on every device/browser a way to set a base font-size different from the one the manufacturer chose;
* true @em@ based webdesign, and even Responsive Web Design, that really responds to users needs/choices.
One of the problems we designers/developers have is with the hardware and software (browsers), for sure. The other is deciding what is best for the user. This can lead us into all sorts of trouble.
About a month ago I penned an article about this same iPad Mini issue, and let it be known that we plan to bring back font-size controls and present them to the user on our sites. ( http://www.projectevolution.com/activity/font-size-controls-are-relevant-again ) This does a few things… the controls change the body’s font-size, the whole design scales, and our EM-based media queries fire. This gives the user control over the reading experience, irregardless of device, pixel density, and browser default font-size.
Presenting the user with these controls also gives them a feeling of empowerment over the design. On desktops, with keyboard commands, it is very easy to control the font-size or zoom-level of a site. With touch devices, these controls are usually more hidden, deep in a preference setting somewhere, and will sometimes will effect text-size across the entire device, not just in the browser.
While we cannot control which devices will be used to view our content, we should not try to control how the user decides to view it in any other way, either. Further, let’ give them the tools to customize the experience and make it more comfortable for them.
Perhaps now really is the time to drop the px alltogether and move on to points or other physical units. Since the pixel is fairly relative (though abstracted) I belive we will only run into more of these problems as we move forward.
When it comes to TVs and such perhaps we would need a new media query (one that actually work) and a setting in the browsers where one can choose normal reading distance and/or physical screen size of this particular browser. With more and more smart TVs being sold and all of the game consoles as well as other TV-connected devices people are spending more and more time browsing the web on their tellies. Web design sadly hasn’t caught up yet (nor is is technically easy).
@Nathan Ziarek
“According to the W3C”:http://www.w3.org/TR/css3-values/#absolute-lengths a pixel should appear .28mm when 28in away from the viewer. If device pixels do not match this it is recommended that the browser scale screen pixels to match. This allows for high resolution devices to render websites the same as lower resolution devices.
What Apple is doing is a great short term solution for people designing at fixed widths but it breaks both web standards and everything we are trying to achieve with web standards.
And yes, I agree, the W3C unit definitions are a mess and filled with circular logic. Still, due to differences in pixel density and viewing distances there is good reason as to why the specs are what they are.
I’d like to produce pixel-independent layouts, but I have no idea how I’m supposed to do that while I’m still shackled to PNG.
It’ll be nice if Mobile Webkit ever starts supporting SVG…
I start getting twitchy when people talk about targeting the iPad mini for special responsive layout treatment vs. the standard iPad. When I bought an iPad 2, I loved it for all kinds of reasons, but I never liked the physical size and heft of it. It was too awkward for comfortably reading and doing a little casual computing in bed (which turned out to be my primary use for a tablet).
I was 100% willing to trade some “ease of clicking” (and pixel density — fortunately, my eyes are still in great shape) in order get THAT EXACT EXPERIENCE, but at a smaller size. Then Apple delivered precisely that, and I was thrilled. I don’t want developers to make assumptions about what physical font sizes I want, to be comfortable. I want an iPad, but smaller. Period.
I’m a focus group of one here, but I’m sure I’m not the only person who is perfectly happy that Apple did things the exact way they did.
The pixel density of the Nexus 7 is 216, correct? The “tablet chart”:http://quirksmode.org/tablets.html states 160, is this a mistake? Not trying to be a prick about it, just wondering.
The current unit specs are not suited to task. At the end of the day designs are viewed by humans, so human units are needed to make them. eg: centimetres that are 1cm when you put a ruler up next to your screen.
I’m sure the technical hurdles to that are probably great, but some way or some how we’ll have to find a way.
I think that we need to start considering not only pixels but physical dimensions in order to target more appropriately. I’ve not been completely comfortable with our current media query usage just for these reasons, and it makes handling responsive images quite difficult as well. I really like what @jHogue mentioned about using EM-based media queries so that while zooming in and out you can effectively control the application of media queries (zoom in and the media queries fire and reflow the content). That’s a very intriguing part of a solution. If that were coupled with the availability of not just ‘device-width’ in pixels but ‘device-width-physical’ as a true physical measurement of height and width of the display, we could then account for any future developments of pixel densities that may come along.
Were we to couple that with responsive images that look at pixel density and dimension of the CONTAINER and not the screen, we might really get somewhere.
Thanks for a lot of great food for though.
I know that ALA is concerned primarily with the open web, but: A bunch of these issues hold true for font sizing in apps as well. Since there is no unique selector for the Mini (there are some hacky ones), fonts are rendered in identical size for the iPad 1/2 and Mini. For most apps, this means default font sizing needs to go up. Not a bad thing usually, but it does mean a different experience between the two devices that usually leaves one or the other feeling off.
Hoping Apple will address this at least for apps.
I found this an odd read. You outlined a clear problem (the high DPI of the iPad Mini), but then only vaguely wandered towards a solution – presumably you want Apple to ‘keep up its end of the bargain’ and change the iPad Mini viewport size.
Of course, this opens up a much larger discussion about the relationship between device DPI and viewport size. The iPad Mini is a “new normal” for baseline DPI at ~160dpi – that horse has bolted. The only difference will be a more tolerable display when it inevitably goes retina in a year or two.
Over the long term, it’s worth considering what we should do when resolutions at (and around) 1366 x 768 appear on ~10″ tablet,s 15.6″ laptop screens, and 40″+ TVs. Viewing distances, screen resolution, and screen physical size all have a much looser relationship to each other than they have in the past. That’s an important issue. But asking Apple alone to change the iPad Mini viewport size seems to miss this forrest for one particular tree, IMO.
Not a single mention of device-pixel-ratio in this article which is WebKit’s answer to this exact problem? This allows WebKit browsers, ie. most mobile browsers, to automatically resize to present content at a reasonable size. For example, the Nexus 7 has a device-pixel-ratio of around 1.3 so text and images are presented at around the same physical size as the iPad 2 without any user interaction. Apple’s retina MacBooks have a device-pixel-ratio of 2 for the same reason. The problem has been solved, it’s just that Apple dropped the ball with the iPad Mini, which really should have a device-pixel-ratio of around 1.2.
This article is highly useful, thanks, and I think things need to go even further.
As one who needs to think about accessibility, I am moved point out that we need to consider visual acuity in the mix, something that no device can tell us.
Ideally, for each device, there would be a preference wizard that let a human indicate:
* “This is the smallest font size I am comfortable reading on this screen,”
* “This is the smallest area I can accurately tap on this screen” and
* “This is the largest font size I am comfortable reading on this screen.”
Then all apps and web pages would constrain their font sizes to within that range and make their targets at least the size indicated.
Other techniques that would help things along:
* rewrap the text at screen edges within paragraphs to alleviate the need to horizontally scroll every line. The mobile device convention to double-tap to fit the paragraph horizontally doesn’t cut it because it shrinks to fit, which may put the font size smaller (or larger, but most likely smaller) than the visitor’s minimum comfortable font size.
* Abandon absolute positioning, as it often leads to overlapping text, obscured text and unusable links once font sizes are changed.
@Miff – ‘Mobile’ WebKit supports SVG just fine. I just panicked when you said that and tested it again, in Android Chrome and iOS6 Safari.
I am glad that your article addressed this issue. I was frustrated when I found out that the mini would not have anything to differentiate it from a iPad.
One thing you did not get into but is related is the fact that TVs are not identifying themselves with the tv media query. This is another issue I believe we need to address and work to get those manufacturers to use standards so that we can provide the best experience for those devices.
I first encountered this back when I got my first high resolution display (in 1985) and the problem isn’t really about the web at all.
The physical dimensions of the display need to be available in real units like inches or mm. Then the pixel density needs to be available either as total pixel width and height or pixels per unit of length like pixels per mm or pixels per inch.
At that point, applications can scale properly. “em” is not a real physical length. It is the size of the M for the font being used. Same for “ex”. A “pica” IS a real physical unit. I’m sure you guys know all this better than I do.
One person states that the user needs to be in control and he does. Somewhere, he should be able to adjust the effective physical screen size. This should be done both globally and also per application. A person with greater than average eye sight can say that his device is physically bigger than it really is and get a higher density of text. A person with lower than average can go the other way. Indeed, late at night, I want a different viewing density than mid-afternoon. That should be easy for me to do.
The resizing, etc, is all being done already. There just needs to be some reality thrown in instead of all the pretend units like pixels or em.
A number of the thoughtful comments here have made me realize that clarification would help on the problem set in the sense that (in my opinion, at least) there are actually two problems here.
1. Browser and device venders don’t give us enough information to determine what kind of device we’re working with, nor enough implemented standard ways to adapt our content and web apps for that specific device or kind of device.
2. Browser and device vendors are inconsistent with baseline defaults—that is, the experience that users have if designers and developers do *not* make device-specific adaptations.
I feel like, as an industry, we pay a fair amount of attention to problem one. We’ve employed many different tactics to take the time to adapt our work to look and work well on different kinds of devices. Some of these ideas are seminal: Responsive Web Design, e.g. Not that this problem is *solved*, per se, but that we’ve thrown a lot of great minds at it.
So the questions of “wouldn’t everything just be OK if you could get the correct dimensional information from an iPad Mini?” don’t really have simple answers. Yes, you could do more to adapt your stuff—for an iPad Mini. But what about everything else? And when will you sleep?
I find the second problem equally (or maybe more) compelling. We acknowledge that the device landscape is pretty much insane. At a certain point, our ability to adapt for each kind of device will break down. The process does not scale. Not that I’m suggesting jettisoning adaptation for devices overall—far from it—but the concept of trying to adjust for the details of every single outlier or specific device does not scale in even the immediate term.
So what I think we need are solutions to both problems. First, we need to be able to tell what we’re working with and make our own decisions about it. But we also need to be able to *not* do anything and have that be OK, too.
The same goes for @Charles Belov’s ideas. Yes, having user ability to define comfortable viewing settings honors the user and makes it possible for users to tailor what works for them. On the other hand, we have to make sure that what the user encounters by default is still tolerable.
The other variable that makes this whole thing tricksy is the confounding nature of viewports in general. They are hard to understand. The relationships between virtual pixels and real ones, device pixel ratios, physical size, and just what a pixel actually *is* makes viewports hard to discuss, as they are so many things at once.
@Luke Stevens is right. The concepts here shouldn’t be constrained to arguing that Apple should mend its ways vis-à-vis the iPad Mini. The iPad Mini is merely a symptom of a far-reaching issue.
Wouldn’t specifying sizing in viewport units (http://generatedcontent.org/post/21279324555/viewportunits) solve at least some of this problem? Your not trying to pinpoint some, possibly unreachable with the mini, target.
It’s kind of disappointing that Apple is pushing super-high-density displays while at the same time ignoring any kind of true resolution independence. All their solutions involve simply doubling/halfing pixels/dimensions.
Android has device-independent-pixels (dp), and Webkit has device-pixel-ratio (as pointed out above by dazweeja) to allow designers to create layouts that should be approximately the same physical size regardless of a display’s actual physical size or density. Android apps can easily reference a device’s dimensions in dp, and a smart web layout can easily compute an equivalent to dp using device-[width|height]/device-pixel-density. In this regard, the Web (well, at least Webkit) is actually far ahead of OSX and iOS in resolution independence.
The issue isn’t whether the iPad Mini should lie about its dimensions, it’s that it should have a proper density attribute.
While I appreciate all the suggestions on what would be the *right* way to describe screen variance to developers (physical dimensions, different units, etc)… I think the core issue is still a set of common defaults. Even if we were dealing with different descriptions of screens, wouldn’t the need for a sensible default remain?
For me, this isn’t just a developer connivence issue. It is a user experience issue.
Based on the “data”:http://www.lukew.com/ff/entry.asp?1549 I’ve seen, as tablets get smaller people’s use of the Web drops.
* 10 inch tablets (like Samsung’s Galaxy Tab) average 125 page views in the browser per tablet.
* 9 inch tablets (like Apple’s iPad) average 116 page views in the browser per tablet.
* 7 inch tablets (like Amazon’s Kindle Fire) average 90 page views in the browser per tablet.
* 5 inch tablets (like Samsung’s Galaxy Note) average 79 page views in the browser per tablet.
Why is that? Usability testing of Amazon’s 7 inch Kindle Fire seems to reveal some answers.
* The most striking observation from testing the Fire is that everything is much too small on the screen, leading to frequent tap errors and accidental activation.
* For 7-inch tablets to succeed, service and content providers must design specifically for these devices. Repurposed designs from print, mobile phones, 10-inch tablets, or desktop PCs will fail, because they offer a terrible user experience.
Because of this I consider it my obligation as a designer for the Web to provide the bet possible experience for people. One that is adapted for each screen as much as possible. This is not an issue of me (as a designer) trying to “control” the experience and take it away from users.
Quite the opposite, I want to craft something that has a good enough default experience so that the burden of making things readable/tappable is not on the user. As this “data”:http://www.lukew.com/ff/entry.asp?1549 shows a bad rendering can cripple engagement.
This is why I still maintain the iPad Mini has a vexing viewport. A sensible default (like those discussed in the article) could address these kinds of issues. But instead of erring on that side of the consideration set, Apple seems to have focused on not “fragmenting” the work developers have already done to build/design things for the full-sized iPads. Hence the situation we’re in now.
The intent of this article isn’t to illustrate a “new” problem. It’s suggest that today (given standards already implemented in browsers) we would really benefit from sensible, consistent defaults. Please device & browser manufacturers -help us out.
Secondarily, we as makers of the Web need to do our part. To prove to browser maker/device manufacturers that when they set sensible & consistent defaults, we’ll do our best to create a great experience that takes advantage of the information they have lovingly given us. This in turn will create more use, enjoyment, and utility from the Web our their devices.
Luke, just want to make sure I follow the principle you are trying to state/uphold, especially with the size stats in this last post: If we’d all be allowed to build great small-tablet experiences, at the right scale and everything, then use would become more equal among all devices, right?
@shoobe01
At the very least, experiences wouldn’t be automatically crippled because no adaptation/optimization can occur.
At the very best, engagement would go up substantially. I have many data points that show just optimizing layout for smartphones drives core metrics (like conversion/use) 2x-3x higher. So if that model/example carriers over to other form factors… yes.
I would love to see some articles written by the people that make device browsers talking about the other side of this issue. We often treat browsers like they’re handed down to us from a deity, but the design decision behind the iPad Mini’s viewport width was made by a person, and that person probably has some interesting insights into making a non-desktop browser that works with the modern Web.
I know these people are often locked behind some monolithic corporations, but I can’t think of a better publication than A List Apart to seek them out and add them to this conversation.
@Ryan Cannon
Here’s “my conversation”:http://storify.com/lukew/viewport-on-the-ipad with Matt Brubeck at Mozilla mobile who implemented meta viewport support in mobile Firefox
The rise of Zoom as the universal means of sizing and resizing the content within the viewport had an inescapable side effect (but please please correct me, anybody, if you’ve found an escape hatch I’ve overlooked):
Abandoning Text Size for Zoom placed the responsibility for providing the user with a means for enlarging or reducing the size of TEXT THAT WRAPS within the viewport, squarely onto the shoulders of developers. It’s too bad screen real estate has to be allocated to this, but there is no choice. So I agree very much with jPogue’s comment about this. (http://www.alistapart.com/comments/vexing-viewports/P0/#5) But I would go a step further and say that Text Size controls used along with font-sizes specified using em or percent, are not merely relevant again, they are essential.
Android Chrome and Mobile Webkit (as featured in Android 4.x) does support SVG, yes, but not Mobile Webkit as features in Android 2.x. Half of all Android users are still on Gingerbread, and almost a quarter of Android users are still on Froyo! ( “source”:http://www.androidtapp.com/android-fragmentation-less-than-3-on-googles-latest-most-devices-on-two-year-old-software-not-the-case-with-apple-products/ )
Could this not be solved by having physical device viewport widths for each device as opposed to one based of the number of pixels?
If you know the “physical” size of the view port, there’s no margin for error? There may be some issues if people are using larger monitors but not at full resolution, however that would just be some fairly simple math on the device makers behalf to basically say “This browser window is X cm wide.”
We need to move away from this old-world notion of pixel-based designs. What we really need to base our designs on are the physical dimensions of the screen (fully available to us through media queries).
‘Number of pixels’ are a nice to have to make sure our images are as crisp as possible and it would be beneficial if the browser would return the truthful amount rather than impersonating an older version of itself.
I agree with one premise of this article (web designers and device designers each have to hold up their end of the bargain) but not the other (Apple failed to do this). You see, I think the bargain is a complex one. Web designers do their best to predict what will work best for the user and design to that standard, but device designers are doing the same thing. They won’t always agree, that is the _point_ of the agreement, we can agree to disagree and trust one another in our different world views.
In this case I believe Apple carefully considered the matter and decided that the market for the mini would be people who wanted to trade size and weight for slightly smaller rendering. This choice positions the mini for a younger (less eye-challenged) crowd. Apple made this choice evident not simply with its viewport setting, but with the whole interface of the mini, which renders all of iOS a wee bit smaller than the regular iPad.
Apple’s choice gives people in the market, you and I as we survey devices to buy, a real choice to make. Do we want everything a bit bigger, or do we want a smaller/lighter device. We make that bargain when we buy the device.
As web designers we should not be second guessing that bargain. Our end of the bargain is to render for a 768 viewport. That’s what the user, implicitly, expects because that is how the device is designed. As a mini owner, I would be _very upset_ if a web page rendered in any way differently on the mini than it did on the iPad. After all, I would have bought the mini based on the bargain Apple offered: same iPad, just smaller. Who am I as a web designer to decide that my personal preference for “bigger” is the “right” choice.
We should keep our end of the bargain, design for the viewport we are given. Leave it to the hardware manufacturers to set the viewport they intend for their product and the market of buyers to vote with their purchases on whether that configuration makes sense. So far, Apple seems to have no problem selling the mini’s value proposition.
One more thought on this issue. Some have advocated bringing back font size controls and the like. Actually, what would be much simpler for browser makers would be for them to offer users the ability to modify the viewport. In other words, create an “accessibility” type setting that lets the user zoom the viewport by a few set multiples. If my eyesight is very poor, I might choose a 2x “view” and then the browser on the mini would report 384 for the viewport. Or I might choose a less aggressive 1.25x view just because my fingers are a bit too fat for the tiny buttons and then my viewport would be reported as 614.
This would have an advantage over font size choice of being (A) universal across websites and (B) giving the website designers the cues they need to fix up the whole design, not just the fonts, while (C) adding no extra work for the web designer who is already dealing well with viewports.
It would also be (relatively) easy for browser designers to implement, since other forms of zooming are already common in their frameworks.
This would provide a three-way bargain: web designers design for viewports, manufacturers set reasonable standards for their device’s intended market, users get to override manufacturers if they so desire.
By the way, I don’t think this setting would be used very often. I think it could be relegated to the purgatory of the iOS Settings app, for example, as part of Safari or Accessibility options. It would not have to be as immediately available as the old font size widgets.
Everyone, Yes it would be great to have better information about screens. However device-width (for viewports) is a mechanism in place today on many of the most popular browsers (esp. mobile) out there. So we can use it now to adapt/optimize designs. Which is is why we’re bringing up the issue of consistency & sensible defaults in its implementation in different devices/browsers.
You don’t have to use device-width in your sites/designs. There’s LOTS of ways already out there to get screen info. It is not the only measure of how many pixels a screen has. If you want to get scared, check out “James Pearce’s in depth-analysis”:http://tripleodeon.com/2011/12/first-understand-your-screen/
If you use “device-width” for your layouts, you are saying “browser use the size that is best for this device” that does not mean a literal translation of physical pixel size. In fact, viewport is variable by design. Having a different “device-width” from the number of physical pixels is not “lying” it is setting a sensible rendering baseline based on the size/form factor of the device.
As we outline in the article this can be done with different default zoom levels as well (i.e. 1em = 20px vs. 16px)
Thanks for writing this, it is perplexing. I’m having a hard time justifying these high-def mini devices because all they do is make our sites look like garbage. As a photographer I struggle with uploading higher resolution photos to my site verses keeping them small for browser speed. I can see how having higher resolution viewing screens would be beneficial for other tasks (like editing photos) but is anyone really doing anything on these devices other than searching the net?
The way to solve this problem with iPad Mini is to declare them as retina devices. They could have done the same as with Ipad Retina: declare 2048 pixel device a 1024 resolution. IPad Mini could have been declared also a half resolution device to browsers. Instead of their 1024×768 they could have use the half resolution of 512×384, and everything would have been the normal size.
The device width is—and should remain—the physical amount of device pixels. The issue here is how the devicePixelRatio is calculated. As Scott mention, the W3C has suggested a baseline target to aim for. Just use the correct devicePixelRatio
physicalPixels * idealPixels = devicePixelRatio
Oops I meant; physicalPixels / idealPixels = devicePixelRatio ^^
The end of this article kind of reads like an Anonymous manifesto…hmmm
More like the shady manifesto.. double hmmm
I suspect the optimal solution to ‘fix’ responsive design is to calculate widths and heights based on actual size, that is inches or centimeters, since the implementation of ems is skewered. Is that a safe assumption? Is there a way to calculate how many px or em translate to in or cm using device-width and pixel density?
Great read. I generally use pixels on font-sizes because of the difference between different browsers and devices. One of the biggest headache’s is the difference between iOS and Android in the font baseline they use. It was to the extent that our layout was breaking because the font-size was a good 1-2 px larger on Android.
Also, I think that we can still strive for “pixel” perfect but in a different way. Responsive Web Design adding breakpoints when the design/layout “breaks” vs. just doing the specific 1024×768 allows for us to still use very precise layouts without worrying about new device sizes.
Should 960 be replaced with 980 in the first quoted sentence, or do I miss something?
1) When encountering desktop websites, the browser would render them at their full size (based on a default canvas width of 960 pixels).
2) Sites not using the tag would be rendered using the default, legacy-web viewport of 980 pixels.
Yes, get rid of all of it! Use the darn device width! In centimeters!!