Changing fixed-width font size along with default when user changes in UI.

We have to change the "default_fixed_font_size" along with "default_font_size"when user varies the sets the font size under chrome://settings/fonts, as we don't have separate ui option for that.

BUG=91922
TEST=As you change the slider under Standard Font in "chrome://settings/fonts" page, size of text against Fixed-width Font should also change. This effect should reflect in any web page for instance http://jsfiddle.net/casaschi/pSAkD/ opened containing fixed-width fonts.

Patch by: rosen.dash@motorola.com

[roseN, 2011-10-03 13:39:07]

We have to change the "default_fixed_font_size" along with "default_font_size"
as we don't have separate UI.

[groby-ooo-7-16, 2011-10-04 01:48:06]

Please add short description of test how to verify fix. (I.e. TEST=Do A, should
observe X)

csilv: I assume there is no _design_ reason why we don't set the fixed font
size, correct?

http://codereview.chromium.org/8118003/diff/1/chrome/browser/resources/option...
File chrome/browser/resources/options/font_settings.js (right):

http://codereview.chromium.org/8118003/diff/1/chrome/browser/resources/option...
chrome/browser/resources/options/font_settings.js:37: 
Add prefChanged callback to set fixed font size

http://codereview.chromium.org/8118003/diff/1/chrome/browser/resources/option...
chrome/browser/resources/options/font_settings.js:78:
Preferences.setIntegerPref('webkit.webprefs.default_fixed_font_size',
Please call this in a prefChanged callback - as the comment says, UI updates and
pref changes should be decoupled.

[roseN, 2011-10-04 09:25:24]

On 2011/10/04 01:48:06, groby wrote:
> Please add short description of test how to verify fix. (I.e. TEST=Do A,
should
> observe X)
> 
> csilv: I assume there is no _design_ reason why we don't set the fixed font
> size, correct?
> 
>
http://codereview.chromium.org/8118003/diff/1/chrome/browser/resources/option...
> File chrome/browser/resources/options/font_settings.js (right):
> 
>
http://codereview.chromium.org/8118003/diff/1/chrome/browser/resources/option...
> chrome/browser/resources/options/font_settings.js:37: 
> Add prefChanged callback to set fixed font size
> 
>
http://codereview.chromium.org/8118003/diff/1/chrome/browser/resources/option...
> chrome/browser/resources/options/font_settings.js:78:
> Preferences.setIntegerPref('webkit.webprefs.default_fixed_font_size',
> Please call this in a prefChanged callback - as the comment says, UI updates
and
> pref changes should be decoupled.

I have added a notifyPrefChanged callback for "default_font_size" and setting
"default_fixed_font_size" in the callback.

[roseN, 2011-10-04 09:25:44]

I have added a notifyPrefChanged callback for "default_font_size" and setting
"default_fixed_font_size" in the callback.

[csilv, 2011-10-04 19:30:13]

The decision to not set default_fixed_font_size is intentiona.  See this issue
for the detailed discussion:
http://code.google.com/p/chromium/issues/detail?id=10524

[Peter Kasting, 2011-10-17 07:12:12]

On 2011/10/04 19:30:13, csilv wrote:
> The decision to not set default_fixed_font_size is intentiona.  See this issue
> for the detailed discussion:
> http://code.google.com/p/chromium/issues/detail?id=10524

csilv, I scanned that issue but didn't see much detail on that particular point.
 It just looked like you said "answering my own question: leave things alone to
match Safari".

We do normally try to match Safari from a web-compat perspective, but I don't
think that extends to preventing users from making a11y-related changes because
they can't make those changes in Safari.

As long as we can implement our controls in such a way as to not change our
current default behavior -- e.g. by linking the fixed and non-fixed sizes, but
with one at a constant offset from the other -- I think it's pretty important
that we allow users to change both with the current "font size" control.

[groby-ooo-7-16, 2011-10-17 17:41:07]

Orthogonal point to rosen.dash: It seems (unless I missed something) that you
haven't signed the contributors agreement yet, which is necessary so CL's can be
accepted. Here's some more info:
http://dev.chromium.org/developers/contributing-code

[csilv, 2011-10-17 18:18:57]

On 2011/10/17 07:12:12, Peter Kasting wrote:
> On 2011/10/04 19:30:13, csilv wrote:
> > The decision to not set default_fixed_font_size is intentiona.  See this
issue
> > for the detailed discussion:
> > http://code.google.com/p/chromium/issues/detail?id=10524
> 
> csilv, I scanned that issue but didn't see much detail on that particular
point.
>  It just looked like you said "answering my own question: leave things alone
to
> match Safari".
> 
> We do normally try to match Safari from a web-compat perspective, but I don't
> think that extends to preventing users from making a11y-related changes
because
> they can't make those changes in Safari.
> 
> As long as we can implement our controls in such a way as to not change our
> current default behavior -- e.g. by linking the fixed and non-fixed sizes, but
> with one at a constant offset from the other -- I think it's pretty important
> that we allow users to change both with the current "font size" control.

Peter,

The detail that I was looking at was the proposal by ojan@ that appeared to have
consensus:

"The proposal is currently to make the 13px font size only apply to font-
family:monospace as Firefox does and *then* remove the option in the fonts menu
to 
set the monospace font size, leaving a single font size option."

I think my comment was actually wrong.  I probably meant to say was that the
intention was to match Internet Explorer's behavior, not Safari's.

We need to keep in mind that in the normal default state for Chrome (and IE),
regular fonts are 16pt, monospace 13pt.  If you change Chrome's font size
preference to apply to both regular and monospace, it will be impossible to get
back to the default state (unless you are also considering changing the default
monospace font size to 16pt).  Either choice seems very risky for website
compatibility.  So I believe that we either need to have separate font-size
settings for regular/monospace, or we need to leave the behavior as is.

[Peter Kasting, 2011-10-17 18:21:53]

On 2011/10/17 18:18:57, csilv wrote:
> We need to keep in mind that in the normal default state for Chrome (and IE),
> regular fonts are 16pt, monospace 13pt.  If you change Chrome's font size
> preference to apply to both regular and monospace, it will be impossible to
get
> back to the default state (unless you are also considering changing the
default
> monospace font size to 16pt).  Either choice seems very risky for website
> compatibility.  So I believe that we either need to have separate font-size
> settings for regular/monospace, or we need to leave the behavior as is.

It doesn't seem like you understood what I was proposing.  I was suggesting that
we link the sizes, not make them equal, e.g. always set the monospace size to 3
points less than the regular size.  That makes the font sizes customizable
without breaking default behavior or making it impossible to return from a
custom setting back to the default.

[csilv, 2011-10-17 18:25:17]

On 2011/10/17 18:21:53, Peter Kasting wrote:
> On 2011/10/17 18:18:57, csilv wrote:
> > We need to keep in mind that in the normal default state for Chrome (and
IE),
> > regular fonts are 16pt, monospace 13pt.  If you change Chrome's font size
> > preference to apply to both regular and monospace, it will be impossible to
> get
> > back to the default state (unless you are also considering changing the
> default
> > monospace font size to 16pt).  Either choice seems very risky for website
> > compatibility.  So I believe that we either need to have separate font-size
> > settings for regular/monospace, or we need to leave the behavior as is.
> 
> It doesn't seem like you understood what I was proposing.  I was suggesting
that
> we link the sizes, not make them equal, e.g. always set the monospace size to
3
> points less than the regular size.  That makes the font sizes customizable
> without breaking default behavior or making it impossible to return from a
> custom setting back to the default.

I like that plan.

-Chris

[rosen.dash, 2011-10-25 07:42:12]

On 2011/10/17 18:25:17, csilv wrote:
> On 2011/10/17 18:21:53, Peter Kasting wrote:
> > On 2011/10/17 18:18:57, csilv wrote:
> > > We need to keep in mind that in the normal default state for Chrome (and
> IE),
> > > regular fonts are 16pt, monospace 13pt.  If you change Chrome's font size
> > > preference to apply to both regular and monospace, it will be impossible
to
> > get
> > > back to the default state (unless you are also considering changing the
> > default
> > > monospace font size to 16pt).  Either choice seems very risky for website
> > > compatibility.  So I believe that we either need to have separate
font-size
> > > settings for regular/monospace, or we need to leave the behavior as is.
> > 
> > It doesn't seem like you understood what I was proposing.  I was suggesting
> that
> > we link the sizes, not make them equal, e.g. always set the monospace size
to
> 3
> > points less than the regular size.  That makes the font sizes customizable
> > without breaking default behavior or making it impossible to return from a
> > custom setting back to the default.
> 
> I like that plan.
> 
> -Chris

I think instead of maintaining a constant gap of 3pt we should maintain the
ratio of 13/16 to link both the font sizes with a single control.

[Peter Kasting, 2011-10-25 18:46:17]

On 2011/10/25 07:42:12, rosen.dash wrote:
> I think instead of maintaining a constant gap of 3pt we should maintain the
> ratio of 13/16 to link both the font sizes with a single control.

I considered that but rejected it because I thought that, based on how the fonts
really look and are used by web pages, that this would be much more broken for
users of non-default sizes than maintaining the constant gap.

If normal fonts were really only 80% the size of monospace fonts, in every way,
then maintaining proportionality would be better.  But in reality the two types
of fonts are approximately the same size and having an internal sizing gap is
basically compensation for websites skewing the fonts the opposite way by
default.  My impression was that this skew will not scale proportionately as we
scale the font sizes but is instead an absolute skew.  If that's correct then we
need to do it the way I've proposed.

[Peter Kasting, 2012-06-13 19:44:00]

Closing since I think the issue was fixed by a separate change later.