Fennec/Features/readability

Please use "Edit with form" above to edit this page.

Status

Text Readability
Stage	Development
Status	In progress
Release target	Firefox 11
Health	At risk
Status note	Core code has landed in time for Firefox 11; uncertain whether the heuristics for dealing with Web pages are going to be able to be in shape in time (or how much change will need to happen to get them in shape).

Team

Product manager	Jay Sullivan
Directly Responsible Individual	Sheila Mooney
Lead engineer	David Baron
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.)

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.

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

Design of record

The design is to create a hybrid approach that has the benefits of iOS-style font inflation on page load, but that also covers the cases where Android-style reflow zoom is preferable. The approach described here should achieve readable font sizes, even when some reflow is required, without creating blocks of empty whitespace as in the native Android method.

The advantage to the initial font-inflation is that it's quick and results in:
- and initial page where text should be a little to much more readable even without zooming in; often this won't be enough to really read an article on a news page, but might be enough to let a user see if he/she is interested in zooming in
- a font size for the "body" article text on a page that, when zoomed into by either pinch or double-tap, is close to an optimal reading size without any reflow required (that body font, on page load, was inflated to a size that would be readable when zoomed into such that the column fits the screen). When this is good enough, it is a seamless experience from the user's experience
The shortcoming is that sometimes the body text cannot be inflated enough to be readable when zoomed without that font, at full zoom out, looking comically big; on iOS, then make a compromise by picking some in between font size, which means that, even on zoom in, the font is still not big enough to be readable.
- To do something about this last case is where the Android-style mechanism comes in, though in our case, we're going to try accomplishing it with more font inflation, on double-tap.

So, the approach is to:

On page load, inflate the font size of the "body" part of the page. As on iOS, this requires some heuristics so that areas of the page where font inflation would break the page layout (anything in a table, sidebar areas, etc.) do not get inflated. The inflation that does take place should increase the body font size such that, when that area is zoomed to fit by pinch-zooming, the font is at a good baseline readable size. This size may not be quite as large as our optimal size.
If step 1 does not get us to where we want to be, we will pursue step 2 which will apply a more aggressive metric on double tap
1. On double-tap of a particular area, the browser should further inflate the font size of that particular area if necessary to get to our optimal reading size. I think (someone correct me) that this involves some reflow. This would not happen on pinch zoom -- just on doubletap, because then we know exactly what block a user is trying to read.
2. Zooming back out, either by double-tap or pinch, would return the page to its initial font-inflated state (i.e. what the page looked like on load)
3. Double-tap zooming to a further-in nested area would further apply the aggressive inflation to that area to ensure its readability

Older Discussion

Some rough specs for two of the options above. (See also this newsgroup discussion.)

The following sections describe two approaches to making designed-for-desktop web pages readable on phones. Of the two, the UX team's preference is for the first one: Android-style reformat on zoom. It is what android users are used to, and it solves a broader range of readability cases.

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	`	`
Engineering	`	`
Security	sec-review-complete	Jesse added the relevant prefs to the DOM fuzzer. bug 718290
Privacy	`	`
Localization	`	`
Accessibility	`	`
Quality assurance	`	`
User experience	`	`
Product marketing	`	`
Operations	`	`