Fennec/Features/readability

< Fennec‎ | Features
Revision as of 18:42, 29 June 2011 by Mbrubeck (talk | contribs)
Feature Status ETA Owner
Text Readability Needs a team; needs a plan to land early in release cycle 2011-07-01 Thomas Arend

Summary

Optimize zoom, reflow, and font sizes for best text readability.

Team

Who's working on this?

  • Feature Manager:
  • Lead Developer:
  • Product Manager:
  • QA: ioana.chiorean [ioanachiorean irc] [e-mail]
  • UX:
  • Security:
  • Etc.

Release Requirements

Next Steps

  • UX direction on high-level approach (see below).
  • Need an owner, implementation plan, and estimates for chosen approach.

Open Issues

We need to choose a high-level approach. The table below lists a few that we have considered; there may be other options, or some combination.

This feature has many potential issues with website compatibility. Whichever approach we choose will probably require iteration and tuning, so we should plan to have it enabled in Nightly for close to a full release cycle before enabling it on Aurora. (This means that if we start development work in the middle the Firefox 6 cycle, then we should probably plan on shipping the feature enabled no sooner than Firefox 7.)

Approach Pros Cons
Fennec 4.0 style - On double tap, change minimum font size based on width of tapped element (bug 611555).
  • Was possible to implement mostly in the front-end, late in the 4.0 cycle
  • Does not affect layout of pages until they are zoomed.
  • Does not work well with pinch zoom.
  • Mangles layout of some pages.
  • Does not work well with elements like input fields.
  • Requires re-layout after zoom (can be slow).
Android style - On zoom, re-wrap text based on the zoom level (bug 578179).
  • Works well with pinch zoom - the user can zoom text to any size and it will still fit on screen.
  • Android users expect it and like it.
  • Does not affect layout of pages until they are zoomed.
  • Does not mangle layout on most pages.
  • Works well with elements like input fields.
  • Requires re-layout after zoom (can be slow).
  • Will still mangle layout on a few pages.
iPhone style - Set a minimum font size per element based on its text width (bug 627842).
  • Does not require re-layout after zoom.
  • With proper tuning, does not mangle layout on most pages.
  • Can probably work well with elements like input fields.
  • Does not work well with pinch zoom.
  • Will still mangle layout on a few pages.
  • Alters layout on pages even before they are zoomed.
  • For Safari, web developers often work around layout mangling by adding -webkit-text-size-adjust CSS styles. Will they bother doing similar work for Fennec?
  • May not meet Android user expectations.
  • Some implementation issues need to be worked out to avoid feedback loops in the layout engine.

Related Bugs & Dependencies

  • bug 578179 - Option to wrap text to screen width rather than container width
  • bug 611555 - should reflow on zoom [see dependencies for related bugs]
  • bug 627842 - Allow minimum font size based on size of frame
  • bug 598736 - Use higher-quality image scaling. (Affects readability of text in IMG elements.)

Designs

Some rough specs for two of the options above:

Android/Opera-style re-wrapping (bug 578179)

When the user zooms the page, all text on the page reflows so that lines of text are no longer than the screen width, even if the containing box is wider than the screen. Only line wrapping is affected; the widths of block-level CSS elements are unchanged. We might choose to do this only when the user double-taps on a piece of text, or for both double-tap and pinch zoom actions.

If the user double-taps to zoom, then the browser will align the left edge of the tapped block to the left side of the screen (so the re-wrapped lines of text will fit entirely on the screen).

If the user pinches to zoom (and if we enable this feature for pinch zoom), then after zooming the browser should re-wrap text and then pan the page if necessary to move lines of re-wrapped text onto the screen. (This panning would occur only in cases where the rewrapped text ends up partly on-screen and partly off-screen. In cases where there is text partly off-screen in more than one direction, we would a rule to pan to the closest piece of text, or the largest, or whatever.)

This feature be enabled/disabled by a preference, and this preference should probably be exposed to the user. (Experience with Firefox and other mobile browsers shows that users are divided over this feature.) For the implementation, the platform could expose a setter to specify a maximum text width, and the mobile front-end could set the value based on the current zoom level. The panning behavior above might also require platform support.

Safari-style font zoom (bug 627842)

The font sizes of some text on the page is increased based on heuristics. The heuristics include the width of the text (wide text needs to be scaled up more so that it can be readable while still fitting on the screen). There may be additional heuristics to avoid resizing text in ways that is likely to interfere with the normal layout of the page.

WebKit provides a "-webkit-text-size-adjust: none" CSS property that authors can use to prevent this resizing in places where it breaks the intended layout of the page. We might need to to do the same for Gecko, and evangelize its use.

This feature should be enabled/disabled by a preference, so that (for example) it can enabled by default for mobile but not for desktop, or possibly exposed to the user through settings or add-ons.

Test Plans

Goals/Use Cases

Non-Goals

Other Documentation

Legend (remove if you like)

  Healthy: feature is progressing as expected.
  Blocked: feature is currently blocked.
  At Risk: feature is at risk of missing its targeted release.
ETA Estimated date for completion of the current feature task. Overall ETA for the feature is the product release date.