Confirmed users
1,492
edits
No edit summary |
No edit summary |
||
| Line 63: | Line 63: | ||
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 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. | * 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. | ** 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 ( | # 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 | # 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. | ||
# 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 | |||