For Gecko 1.9, I'd like to try to make the font size preferences meaningful. Every time there's a discussion about font size preference user interface, the argument for hiding it is that it usually doesn't have any effect. But this is critical for making the Web usable for many older users, especially since many young Web designers set font sizes on pages according to their preference rather than using the user's defaults. It's also going to become more important for high resolution displays.
What I'd like to see is the following:
* the font size preference is a length, in pixels
* the primary size change UI in apps changes that preference (e.g.,
Ctrl++, Ctrl+-, View -> Text Size in Firefox)
* As today, we use that preference as the default font size for the
root element, so that in many cases (well-authored pages) no scaling
will be needed.
* we enforce that preference by making scaling all pages so that the
25th (roughly) percentile sized text on a page is sized to be at
least as large as the preference (bug 31961). This should be
implemented at a pretty low level (e.g., text frames, perhaps after
checking visibility).
* we do the scaling using text zoom when the scaling factor is a ratio
of between (roughly) 3/4 and 4/3. Otherwise we use full zoom (bug
4821).
* To handle separate language-group and fixed-vs.-proportional
font size preferences, what we actually do is (instead of
accumulating the actual font sizes and comparing to the preference at
the end) accumulate actual-to-preferred ratios and look at the
appropriate percentile of those ratios.
Some questions I have about this proposal are:
* Is there a need for temporary zooming user interface?
* Does the scaling handle iframes/objects as a single unit or
separately?
* Is there a need for an opt-out, where the preference would only imply
the defaults that can be overridden by the author and the scaling
would not be done?
* Should we scale in both directions, or only scale larger? I think
it's probably better never to scale down, for a number of reasons:
* scaling down could kick in in weird ways during incremental
loading, since headers load first
* likewise, scaling down could kick in in weird ways as authors start
writing a page, where they write the headers first
* scaling down would be bad for pages that consist of just a header
and an image
* How often do we want to resize during incremental loading? I suspect
what we may want to do is not correct unless the size that we'd
previously chosen as the 25th percentile is no longer in the range
of, say, 15th percentile to 40th percentile. Although we'll then
probably want to do a final correction once the page is done loading,
although that could be disturbing to users depending on how common it
is. Then again, it may be that a percentile may not change very much
during the loading process.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
pgpEgwYunlXfo.pgp
Description: PGP signature
_______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
