| 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). |
|
|
| Android style - On zoom, re-wrap text based on the zoom level (bug 578179). |
|
|
| iPhone style - Set a minimum font size per element based on its text width (bug 627842). |
|
|
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. |