The virtual-image problem

Mobile Safari problems

It seems that browser writers are adding ‘features’ to deal with the proliferation of abominably wide or fixed-width sites. Mobile Safari, as supplied on the iPhone, supports a zoom feature for its 320×480 screen, whose image can famously turn to match the orientation of the device. Here's how it appears to work:

  • The browser plots the page in a virtual space, apparently 980 virtual pixels wide, to create what I'll call a virtual image. The default font-size is applied in terms of these virtual pixels. The virtual space is widened to fit the page if necessary, but always has a minimum of 980 pixels.

  • It then scales the virtual image down in order to present the full width of the page neatly in the screen space available.

    The text is usually very small and difficult to read at this size, although headings are legible.

  • The user can make the screen zoom in on areas of the virtual image in order to read them. This doesn't re-wrap the text in a smaller space; the virtual image is simply scaled up.

This works fine if the area of interest itself has a limited width, such as a news column alongside others that together make the page as a whole quite wide. Zooming in makes the text readable in terms of font size, while the limited width ensures that the line length does not exceed the physical screen size at this level of scaling.

But no page is required to have any width limitation applied to it by the author. By design, that limitation is supposed to be made only at the point of rendition. When Mobile Safari tries to show an unstyled page, it allows it to fill the 980 pixels of its virtual space, but then is forced to shrink it to show the whole page. If the user zooms in to read the text, the lines no longer fit the screen, and the page becomes difficult to use.

Effectively, this feature has made all the well-designed pages invalid, just to cope with badly designed ones better, pandering to their designers' insane fixed-width cravings. This clever feature of coping with pages that demand more space than the browser initially offers has been broken by being uncleverly configured to initially claim to offer more real space to a page than it has available. It should initially offer exactly as much virtual space as it has real space available.

The <meta> solution?

Apparently, the author of a well-designed page can add a <meta> element to tell (only) Mobile Safari to offer less space than the default 980:

<meta name="viewport" content="width=320">

But if Mobile Safari can cope with pages wider than 980px when that is its minimum, it ought to be able to cope with them just as well if it initially offers something much narrower. Why doesn't it simply use 320px as its default instead? (I assume that medium text in a virtual image of that size is readable at the default zoom level; if not, re-configure minimum virtual image size or the default font size by an appropriate factor.)

You could argue that authors are responsible for routinely adding the <meta> to all their pages if they expect them to work on an iPhone, but:

  • No! They are only responsible if they diverge from defaults.

    A page that is already width-agnostic should not have to sacrifice that just to work well in an iPhone.

  • What size should they specify? What happens to the page when viewed with the next version of the device (or a rival) with a 20% bigger screen? The browser is best placed to know what is a good default minimum, so let it specify.

    Solving the problem just for one particular browsing environment is not scalable.

There is no need for an author to specify a width, because the virtual-image mechanism above copes fine with pages that demand more width than it offers by default. Just get the default right in the first place! Reconfiguring the device to a more ‘honest’ default will make width-agnostic pages display better, while not breaking the fixed-width and width-hungry sites.

To demolish my thesis, you need to find a site that operates better in a configuration other than 320px as an initial virtual viewport width. Here's how to do a test:

  • Download the raw HTML of the page. You could download the images too, but it's not normally necessary.

  • Edit the file so that it contains the following line at the start of the <head> element:

    <base href="the page's address">

    You need to fill in the page's real address, of course.

  • Elsewhere in <head>, find a <meta> viewport element:

    <meta name="viewport" content="something">

    If it doesn't exist, simply add it with the following setting:

    <meta name="viewport" content="width=320">

    Otherwise, set it to that.

  • Make sure there are no other <meta> viewport settings

  • Publish the page somewhere so you can view it with an iPhone, and compare it with the original page.

You might notice a difference during loading, but is the original better than the adjusted copy when the page is fully rendered?

The vw solution?

What if we want to exploit the zoom feature offered by the iPhone to do complex layouts, while still providing simple layouts for unavoidably narrow media? This requires that the browser declare its virtual viewport size as much wider than its physical display (as it does now), as a max-width media query would depend on that. Does this mean that pages with only simple layouts will have to rely on something other than a change to the default virtual viewport width? And if the complex layouts are going to involve columns for the user to zoom in on, what would their ideal width be?

CSS3 proposes several new units, including vw, which is the width of some kind of viewport. But which viewport should it describe in the iPhone – the virtual one or the physical one? If it's the virtual one, that presents some options.

A page that uses a complex layout when more space is available could limit the widths of each of its columns to 1vw. A page that only uses a simple layout could apply that limit to its whole self.

However, it seems likely that vw refers to the virtual viewport (i.e. viewport as defined by CSS2.1, and then interpreted by the iPhone's implementation of media queries). The media feature width is defined in terms of a viewport, while device-width is defined in terms of a rendering surface.

Perhaps we need a new set of units to describe the rendering surface (e.g. the iPhone's physical display) …?

Suppose you wanted to limit the width of a column of text. You could mark it up like this (with a redundant <div> so you can apply two limitations):

<div class="column">
  <div>
    <!-- Column text -->
  </div>
</div>

Given a new unit rsw to mean the width of the physical rendering surface, you can specify two restrictions on the text, with the smaller applying:

.column { max-width: 35em; }
.column > div { max-width: 1rsw; }

With some other CSS3 features, you could make it adapt to the font size applied to the column:

.column { max-width: 35em; }
.column > div { max-width: calc(1rsw * 1em / 1rem); }
Standard Navigation info

Ĉi tiu paĝo disponeblas ĉi-lingve, depende de la lingvo-agordo de via krozilo.