Fennec/Features/readability
Status
| Text Readability | |
| Stage | Definition |
| Status | ` |
| Release target | ` |
| Health | At Risk |
| Status note | Needs a team; needs a plan to land early in release cycle. |
"At Risk" is not in the list (`, OK, Blocked, At risk) of allowed values for the "Feature health" property.
Team
| Product manager | Thomas Arend |
| Directly Responsible Individual | ` |
| Lead engineer | ` |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ioana.chiorean [ioanachiorean irc] [e-mail] |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
Open issues/risks
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.)
{
Stage 1: Definition
1. Feature overview
Optimize zoom, reflow, and font sizes for best text readability.
2. Users & use cases
`
3. 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.)
4. Requirements
`
Non-goals
`
Stage 2: Design
5. Functional specification
`
6. User experience design
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. (Needs more research or testing of approaches.)
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.
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
`
Feature details
| Priority | P1 |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | Firefox Mobile |
| Secondary roadmap | ` |
| Feature list | Mobile |
| Project | ` |
| Engineering team | Layout |
Team status notes
| status | notes | |
| Products | tbd | ` |
| Engineering | tbd | ` |
| Security | tbd | ` |
| Privacy | tbd | ` |
| Localization | tbd | ` |
| Accessibility | tbd | ` |
| Quality assurance | tbd | ` |
| User experience | tbd | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |