Comments on Vexing Viewports

44 Reader Comments

Back to the Article
  1. 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.

    Copy & paste the code below to embed this comment.
  2. 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.

    Copy & paste the code below to embed this comment.
  3. 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 1920x1080 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.

    Copy & paste the code below to embed this comment.
  4. I work daily on a beautiful MacBook Pro 15” with an Hi-Res screen that has a 1680x1050 native resolution. It’s not Retina/HiDPI, but with 128ppi ( “List of displays by pixel density on Apple computers”: ) 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 (1920x1080) 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”: 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.

    Copy & paste the code below to embed this comment.
  5. 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. ( ) 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.

    Copy & paste the code below to embed this comment.
  6. 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).

    Copy & paste the code below to embed this comment.
  7. @Nathan Ziarek

    “According to the W3C”: 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.

    Copy & paste the code below to embed this comment.
  8. 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…

    Copy & paste the code below to embed this comment.
  9. 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.

    Copy & paste the code below to embed this comment.
  10. The pixel density of the Nexus 7 is 216, correct? The “tablet chart”: states 160, is this a mistake? Not trying to be a prick about it, just wondering.

    Copy & paste the code below to embed this comment.
  11. 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.

    Copy & paste the code below to embed this comment.
  12. 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.

    Copy & paste the code below to embed this comment.
  13. 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.

    Copy & paste the code below to embed this comment.
  14. 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.

    Copy & paste the code below to embed this comment.
  15. 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.

    Copy & paste the code below to embed this comment.
  16. 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.

    Copy & paste the code below to embed this comment.
  17. @Miff - ‘Mobile’ WebKit supports SVG just fine. I just panicked when you said that and tested it again, in Android Chrome and iOS6 Safari.

    Copy & paste the code below to embed this comment.
  18. 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.

    Copy & paste the code below to embed this comment.
  19. 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.

    Copy & paste the code below to embed this comment.
  20. Wouldn’t specifying sizing in viewport units ( solve at least some of this problem? Your not trying to pinpoint some, possibly unreachable with the mini, target.

    Copy & paste the code below to embed this comment.
  21. 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.

    Copy & paste the code below to embed this comment.
  22. 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?

    Copy & paste the code below to embed this comment.
  23. 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.

    Copy & paste the code below to embed this comment.
  24. 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. ( 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.

    Copy & paste the code below to embed this comment.
  25. 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”: )

    Copy & paste the code below to embed this comment.
  26. 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.”

    Copy & paste the code below to embed this comment.
  27. 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.

    Copy & paste the code below to embed this comment.
  28. 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.

    Copy & paste the code below to embed this comment.
  29. 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.

    Copy & paste the code below to embed this comment.
  30. 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?

    Copy & paste the code below to embed this comment.
  31. 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 1024x768 they could have use the half resolution of 512x384, and everything would have been the normal size.

    Copy & paste the code below to embed this comment.
  32. 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

    Copy & paste the code below to embed this comment.
  33. Oops I meant; physicalPixels / idealPixels = devicePixelRatio ^^

    Copy & paste the code below to embed this comment.
  34. The end of this article kind of reads like an Anonymous manifesto…hmmm

    Copy & paste the code below to embed this comment.
  35. More like the shady manifesto.. double hmmm

    Copy & paste the code below to embed this comment.
  36. 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?

    Copy & paste the code below to embed this comment.
  37. 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 1024x768 allows for us to still use very precise layouts without worrying about new device sizes.

    Copy & paste the code below to embed this comment.
  38. 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.

    Copy & paste the code below to embed this comment.
  39. Yes, get rid of all of it!  Use the darn device width!  In centimeters!!

    Copy & paste the code below to embed this comment.
  40. Sorry, commenting is closed on this article.