Skip navigation
Help

Peter-Paul Koch

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

Vexing Viewports

“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 (768x1024 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

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 640x960, would pack four times as many pixels into the same space as the 320x480 screen on left.

The first is 320x480 pixels, the second 640x960. 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” 352x416-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

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

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

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?

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, 1024x768-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 1024x768 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

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.

RSS readers: Don't forget to join the discussion!

0
Your rating: None

As the year draws to a close, we asked some A List Apart readers to tell us what they learned about the web in 2011. Together their responses summarize the joys and challenges of this magical place we call the internet. We need to continue to iterate, to embrace change, and challenge complexity to keep shipping. Above all, we must continue to reach out to one another, to teach, to support, to help, and to build the community that sustains us.

0
Your rating: None

By Tony White

Some of you may remember the days when 30KB was the recommended maximum size of a web page, a value which included HTML, CSS, JavaScript, Flash, and images. I find with every new project with even the slightest bit of complexity, it’s not long before that 30 KB ideal is well out of my reach. With the popularity of CSS layouts and JavaScript-enriched web page experiences, it’s not uncommon, particularly for large sites, for the CSS files alone to jump well beyond that 30KB ceiling.

But there are some principles to consider during and after you write your CSS to help keep it tight and optimized. Optimization isn’t just minimizing file size — it’s also about being organized, clutter-free, and efficient. You’ll find that the more knowledge you have about optimal CSS practices, smaller file size will inevitably come as an direct result of their implementation. You may already be familiar with some of the principles mentioned below, but they are worth a review. Being familiar with this concepts will help you write optimized CSS code and make you a better all-around web designer.

1. Use Shorthand

If you’re not already writing in shorthand, you’re late to the party. But fortunately, this party never ends. Using shorthand properties is the single easiest practice you can do to cut down your code (and coding time). There’s no better time than the present to start this efficient coding practice, or to review it.

Margin, border, padding, background, font, list-style, and even outline are all properties that allow shorthand (and that’s not even an extensive list!).

CSS Shorthand means that instead of using different declarations for related properties…


p { margin-top: 10px;
	margin-right: 20px;
	margin-bottom:  30px;
	margin-left: 40px; }

… you may use shorthand properties to combine those values like so:

	p { margin: 10px 20px 30px 40px; }

By specifying a different number of values, browsers would interpret the rules in a specified manner, illustrated in the diagram below.

Illustration of how shorthand declarations are interpreted depending on how many values are specified for a property
Illustration of how shorthand declarations are interpreted depending on how many values are specified for a property. This order also applies to padding and border-width among other properties.

Font is another helpful shorthand property that helps save some room and keystrokes.

Illustration of font shorthand examples
Examples of the font shorthand property. Note: leaving some values unspecified will mean that those properties will reset to thier initial values.

Those are just two examples of shorthand, but by no means should be considered a comprehensive guide. Even if you are familiar with the rules above, be sure to look at the articles mentioned below for more helpful reminders of those powerful properties that help keep your code succinct. Because of the number of lines and characters saved, going from a previous version of a CSS file which used no shorthand properties to one that makes full use of shorthand can have dramatic effect on file size.

See CSS Shorthand Guide (dustindiaz.com) and Efficient CSS with shorthand properties (456bereastreet.com) for more information about shorthand properties.

2. Axe the Hacks

Jon Hick's blog hicksdesign.co.uk/journal makes use of conditional comments
Jon Hick’s blog hicksdesign.co.uk/journal makes use of conditional comments

Hacks against dead browsers are safe, but hacks against the living aren’t. None of them. Ever.

Keep CSS Simple - Peter-Paul Koch (digitial-web.com)

If you’re like me, those words from Peter-Paul Koch’s nearly 5-year-old article may make you feel a little embarrased. After all, who hasn’t served hacks to Internet Explorer 6 and even Internet Explorer 7? As bad as we may want IE6 to lay six pixels under, the truth is it’s far from dead.

But now we know that using conditional comments to serve hacks correctional declarations for IE6 and IE7 is an accepted practice, even recommended by the Microsoft IE development team. Using conditional comments to serve IE-specific CSS rules has the added benefit of serving a cleaner, and therefore smaller, default CSS file to more standards-compliant browsers, while only those browsers that need the hackery daiquri (i.e. IE) will download the additional page weight.

Here’s how to use conditional comments to serve styles only to Internet Explorer 6:


	<!--[if IE 6]>
		<link rel="stylesheet" type="text/css" href="ie6.css">
	<![endif]-->

For IE7, you can use the above and substitute “6″ for “7″.

Alternatively, if there is hack-less way of getting the desired result using CSS, with all other things being equal, go for it! The less hacks you have to write, the simpler and lighter the code.

3. Use whitespace wisely

Whitespace, including spaces, tabs, and extra line breaks, is important for readability for CSS code. However, whitespace does add, however miniscule it may be, to page weight. Every space, line-break, and tab you can eliminate is like having one less character.

But this is one area where I would not encourage you to skimp just to get a smaller file. It’s still important that you write in a way that is readable to you (and hopefully to others), and if that includes using whitespace for formatting, so be it. After all, if you can’t read it, you’re going to have a hard time applying the other principles mentioned in this article. Just be aware of the fact that whitespace is like air - you might not be able to see it, but it does weigh something.

The figure below shows two different extremes in formatting style, with much whitespace, and the other with very little. I happen to favor the single-line formatting option without tabs, as I can scan the selectors a little easier, and I develop using the full width of my wide-screen monitor. But that’s just me. You may like your selectors to appear nested, and your declarations on each line.

Illustration of two extremes in CSS formatting, one with lots of whitespace, one with little whitespace
Illustration of two extremes in CSS formatting: lots of whitespace vs. very little whitespace

Using whitespace effectively is great, and a recommended practice for easy-to-manage code, but be aware that the less whitespace you have, the smaller the file. Even if you choose work with whitespace with your working file, you can choose to remove it for the production version of your CSS file, so your files stay skinny where it really counts.

4. Prune frameworks and resets

Nathan Smith's 960 Grid System uses a reset
Nathan Smith’s 960 Grid System CSS framework uses a reset rule.

If you’ve chosen to use a CSS framework (including ones you’ve written yourself), take the time to review the documentation as well as every line of the CSS file. You may find that the framework includes some rules that you don’t care to use for your current project, and they can be weeded out. Also, you may find that the framework includes a more elegant and concise way of achieving a presentational detail than what you normally use, and knowing about them can help prevent you duplicating rule sets unintentionally.

This goes for resets as well. YUI Grid CSS uses a reset, and Eric Meyer’s Reset is also very popular. Resets are great to use because they help to neutralize a browser’s default style. But if you know the nature of the site you are building, you may find some declarations that you know you’ll never need. <pre> and <code> will likely go unused on my Aunt Martha’s recipe blog. A design portfolio probably won’t ever use <sub>, <dfn>, <var>, etc. So ditch what you don’t need. It’s not only ok, it’s encouraged, even by Eric Meyer:

As I say on the reset page, those styles aren’t supposed to be left alone by anyone. They’re a starting point.

Crafting Ourselves - Eric Meyer (meyerweb.com)

Using a framework and/or a reset set of rules can help keep your work optimized, but they should not be accepted in their default state. Considering each declaration and cutting back on unneccessary ones can further help you keep your CSS files lean and readable.

5. Future-proof your CSS

Doug Bowman's stopdesign.com CSS reveals specially crafted selectors used for layout
Doug Bowman’s stopdesign.com CSS reveals specially crafted selectors used for layout.

Another way to optimize your code is to separate layout-specific declarations from the rest of your rules. I’ve heard options of separating typography and colors from layout-specific rules in the CSS file. I’ve never been fond of this practice, as I don’t care to repeat selectors just because I have different types of declarations to associate with them.

However, I’m warming up to the idea of separating layout styles from the rest of the styles, and giving layout it’s own file, or at least it’s own section. This is also advocated in Andy Clarke’s Transcending CSS. Within the book, Clarke reminds us of the following:

Full CSS layouts have always been a compromise. The current CSS specifications were never designed to create the visually rich and complex interface layouts that modern Web demands. The current methods — floats and positioning — were never intended as layout tools.

Transcending CSS - Andy Clarke.

One way of interpreting this is that floats and positions to establish sidebars and columns are, well, layout hacks. And though we really don’t have an alternative, we hopefully will once a layout standard is agreed upon and browsers start supporting them. When that happens, it should be easy to swap out those hacked up box-model properties for ones intended for layout. Though it will be a while before new layout modules are here, using the right properties to handle layout instead of compensating for the quirks of our current limited set of properties will most certainly help condense page weight.

6. Document your work

David Shea's markup guide at mezzoblue.com
David Shea’s markup guide illustrates the proper usage for HTML tags and how those are represented on his site, mezzoblue.com. Even sites without dynamic HTML can have this simple and effective guide (using its own CSS file, of course!) as a starting point of documentation.

For a team of designers, it is extremely important to communicate regularly so that markup and style rules are created in a consistent way, and also to create site standards. For example, if someone comes up with way to markup a tab interface for the site, documentation will keep others from duplicating that effort, preventing code bloat in the HTML and CSS.

Documentation, including markup guides and style sheet guides, is not just for group efforts — they are just as important for a one-man design team. After all, a year after working on other things, revisiting one of your own projects can feel quite foreign. Your future self might appreciate reminder of how your CSS grid framework is supposed to work, or what pages already have a treatment for a secondary action form button, and it will save you or someone else from appending redundant and unnecessary rules to your CSS.

The choice to use documentation has a bonus side effect of being a great place to park explanations that otherwise must be included as CSS comments. CSS comments are great for sectioning off chunks of long CSS files, but verbose comments that are used to explain design choices can add to file size, and might be better suited to a markup and style guide. Documenting your code using CSS comments within your working file is most definitely better than nothing at all, but housing that material in separate documentation is a great way to keep the code focus and free from bloat.

7. Make use of compression

Some great applications have been created to compress and optimize CSS for you, allowing you to serve a human-unreadable but still browser-friendly files that are a fraction of the origional working copies. Applications like CSSTidy and the YUI Compressor can compress whitespace, detect and correct for CSS properties that are overwrite each other, and look for opportunites to use CSS shorthand that you may have missed. (These types of applications are excellent sources to read about, if for no other reason, to learn what things you can further do by hand).

Even popular text editors like BBEdit, TextMate, and TopStyle, can help format your CSS files to your liking. There are also options serve zip versions of your CSS files using PHP. You can find more CSS compressors and optimizers in the post List of CSS Tools.

It is important to note that these applications do their best to minimize errors, but they aren’t always perfect. Also, they work best when browser hacks are not included in the file set (which is yet another reason to keep those hacks external).

There is one last type of application that can help prune CSS file size I’d like to mention. It can crawl a web site and log which CSS rules and declarations are not being applied, then bring these to your attention. Unfortunately, this tool hasn’t been inventend yet, but I would gladly pay for such a application.

I can recall times when I’ve been afraid to delete certain rules because there is no documentation that explains to me that those selectors are leftover from previous iterations of development. If an app can bring those rules to my attention, that will help with maintenance and keeping CSS files lean.

Conclusion

Clean and optimized code is important not just for file size, but for maintenance and readability as well. The principles mentioned above are good considerations not just for CSS, but can be applied to HTML, JavaScript, and other programming languages. CSS files are not as prominent as the rendering of your web site to an end-user, but consideration of the above principles can help with both the user experience (in the form of smaller file sizes) and the developer experience (cleaner code). Apply these principles to your current and future projects, and and you will surely appreciate the efforts.

About the author

Tony White runs the one-man show Ask the CSS Guy, an after-hours blog devoted to peaking under the hood of CSS and JavaScript web-design techniques, as well as troubleshooting CSS-related problems. He resides in Memphis, Tennessee.

0
Your rating: None