Fennec/Features/readability: Difference between revisions

Jump to navigation Jump to search

Fennec/Features/readability (view source)

Revision as of 21:07, 13 March 2012

780 bytes removed ,  13 March 2012
no edit summary
No edit summary
No edit summary
 
(13 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{FeatureStatus
{{FeatureStatus
|Feature name=Text Readability
|Feature name=Text Readability
|Feature stage=Definition
|Feature stage=Development
|Feature version=Firefox 9
|Feature status=In progress
|Feature status note=Needs a team
|Feature version=Firefox 11
|Feature health=At risk
|Feature 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).
}}
}}
{{FeatureTeam
{{FeatureTeam
|Feature product manager=Thomas Arend
|Feature product manager=Jay Sullivan
|Feature feature manager=Sheila Mooney
|Feature lead engineer=David Baron
|Feature qa lead=Ioana Chiorean  [[irc://irc.mozilla.org ioanachiorean irc]] [[mailto:ioana.chiorean@softvision.ro e-mail]]
|Feature qa lead=Ioana Chiorean  [[irc://irc.mozilla.org ioanachiorean irc]] [[mailto:ioana.chiorean@softvision.ro e-mail]]
}}
}}
Line 14: Line 18:
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.)
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.)


{| border="1" cellspacing="0"
<table class="fullwidth-table">
|-
<tr>
! Approach
<td>Approach</td>
! Pros
<td>Pros</td>
! Cons
<td>Cons</td>
|-
</tr>
| '''Fennec 4.0 style''' - On double tap, change minimum font size based on width of tapped element ({{Bug|611555}}).
<tr>
|
<td> '''Fennec 4.0 style''' - On double tap, change minimum font size based on width of tapped element ({{Bug|611555}}).</td>
<td>
* Was possible to implement mostly in the front-end, late in the 4.0 cycle
* 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 affect layout of pages until they are zoomed.
|
</td>
<td>
* Does not work well with pinch zoom.
* Does not work well with pinch zoom.
* Mangles layout of some pages.
* Mangles layout of some pages.
* Does not work well with elements like input fields.
* Does not work well with elements like input fields.
* Requires re-layout after zoom (can be slow).
* Requires re-layout after zoom (can be slow).
|-
</td>
| '''Android style''' - On zoom, re-wrap text based on the zoom level ({{Bug|578179}}).
</tr>
|
<tr>
<td> '''Android style''' - On zoom, re-wrap text based on the zoom level ({{Bug|578179}}).
</td>
<td>
* Works well with pinch zoom - the user can zoom text to any size and it will still fit on screen.
* 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.
* Android users expect it and like it.
Line 37: Line 46:
* Does not mangle layout on most pages.
* Does not mangle layout on most pages.
* Works well with elements like input fields.
* Works well with elements like input fields.
|
</td>
<td>
* Requires re-layout after zoom (can be slow).
* Requires re-layout after zoom (can be slow).
* Will still mangle layout on a few pages.
* Will still mangle layout on a few pages.
|-
</td>
| '''iPhone style''' - Set a minimum font size per element based on its text width ({{Bug|627842}}).
</tr>
|
<tr>
<td> '''iPhone style''' - Set a minimum font size per element based on its text width ({{Bug|627842}}).
</td>
<td>
* Does not require re-layout after zoom.
* Does not require re-layout after zoom.
* With proper tuning, does not mangle layout on most pages.
* With proper tuning, does not mangle layout on most pages.
* Can probably work well with elements like input fields.
* Can probably work well with elements like input fields.
|
</td>
<td>
* Does not work well with pinch zoom.
* Does not work well with pinch zoom.
* Will still mangle layout on a few pages.
* Will still mangle layout on a few pages.
Line 53: Line 67:
* May not meet Android user expectations.
* May not meet Android user expectations.
* Some implementation issues need to be worked out to avoid feedback loops in the layout engine.
* Some implementation issues need to be worked out to avoid feedback loops in the layout engine.
|}
</td>
</tr>
</table>
|Feature overview=Optimize zoom, reflow, and font sizes for best text readability.
|Feature overview=Optimize zoom, reflow, and font sizes for best text readability.
|Feature dependencies=* {{Bug|578179}} - Option to wrap text to screen width rather than container width
|Feature dependencies=* {{Bug|578179}} - Option to wrap text to screen width rather than container width
Line 71: Line 87:
So, the approach is to:
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.
# 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.
# 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.
# 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
# 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)
## 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.
# Double-tap zooming to a further-in nested area would further apply the aggressive inflation to that area to ensure its readability
## 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)
## Double-tap zooming to a further-in nested area would further apply the aggressive inflation to that area to ensure its readability




=== Discussion ===
=== Older Discussion ===
Some rough specs for two of the options above.  (See also [https://groups.google.com/forum/#!topic/mozilla.dev.platforms.mobile/FDlBO8f1dCM this newsgroup discussion].)
Some rough specs for two of the options above.  (See also [https://groups.google.com/forum/#!topic/mozilla.dev.platforms.mobile/FDlBO8f1dCM 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.
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.
Here's a quick breakdown of the pros and cons (sorry - there are some formatting issues in this table (i.e. bulleted lists should not have levels here - they are flat lists).
<table border="1" cellspacing="0">
<tr><th>Approach</th><th>Pros</th><th>Cons</th>
<tr><td>'''Android style''' - On zoom, re-wrap text based on the zoom level ({{Bug|578179}}).</td>
<td>* 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.</td>
<td>* Requires re-layout after zoom (can be slow).
* Will still mangle layout on a few pages.</td></tr>
<tr><td>'''iPhone style''' - Set a minimum font size per element based on its text width ({{Bug|627842}}).</td>
<td>* 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.</td>
<td>* 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.</td></tr>
</table>


==== Android/Opera-style re-wrapping ({{bug|578179}}) ====
==== Android/Opera-style re-wrapping ({{bug|578179}}) ====
Line 123: Line 116:
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.
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.
|Feature implementation notes=* https://bugzilla.mozilla.org/show_bug.cgi?id=627842
|Feature implementation notes=* https://bugzilla.mozilla.org/show_bug.cgi?id=627842
* https://wiki.mozilla.org/User:Dbaron/Readability
}}
}}
{{FeatureInfo
{{FeatureInfo
Line 131: Line 125:
}}
}}
{{FeatureTeamStatus
{{FeatureTeamStatus
|Feature security status=sec-review-active
|Feature security status=sec-review-complete
|Feature security health=Assigned
|Feature security health=At risk
|Feature security notes=Jesse::fuzzing
|Feature security notes=Jesse added the relevant prefs to the DOM fuzzer. {{bug|718290}}
}}
}}
Curtisk
canmove, Confirmed users, Bureaucrats and Sysops emeriti
2,776

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/340148...407239"

Navigation menu