225639 - (rudehypocrite) [meta] Re-evaluate default font size and color settings

Status: RESOLVED FIXED

(www.mozilla.org :: General, defect, P2)

Description

[Felix Miata]

1-IF YOU CAN'T READ IT, NOTHING ELSE ON A WEB PAGE MATTERS.

2-Anything other than 100%-basing is essentially saying to everyone "Whatever
your default is, no matter how it got that way, no matter what your needs are,
it is wrong. We don't care what size is best for you. Regardless your choice,
9px, 12px, 24px, 48px or whatever, we think it is wrong, and are doing something
about it."

3-Further handicapping the handicapped (visually challenged in this case) is the
wrong thing to do, whether via user agent design or web page design.

4-Mozilla the tool must be consistent with the mozilla.org web site. If the web
site can't be 100% (user oriented) based because the default fonts are wrong
sized, then we need to make the initial browser default fonts right sized so
that the site can be 100%-based. If the initial browser default fonts are
currently correct (they are), we should be showcasing that fact by being
100%-based. As it stands, mozilla.org is a disrespectful hypocrite by not being
100%-based. What we are doing now is FOLLOWING widespread BAD practice, rather
than trying to be a LEADER demonstrating GOOD practice.

5-Quoting David Baron from http://bugzilla.mozilla.org/show_bug.cgi?id=24846#c2

"Web "designers" believe that users never change the default font size, so they
write all their pages to *lower* the font size from the default, since they
think the defaults look too [sic] big.  This causes problems for users for whom
the default isn't too big. . . .

". . . . The most common complaints I hear about using the web from people my
parents age are that all the fonts are too small, and they can't read anything.
 Many of these people don't know how to change the default font size."

David was and remains right. It's what they do. We should not do it too.

Comment 1

[Felix Miata]

Attachment: screenshot - disrespect (top) vs. honor (bottom)

Comment 2

[Daniel Wang]

*** This bug has been marked as a duplicate of 224263 ***

Comment 3

[Felix Miata]

Updating summary to reflect currently applicable css filename, post-FF 1.0
release. body {font-size: 100%;} rule is no less needed now that ever.

Comment 4

[Reed Loden [:reed]]

steven: Can this be easily done (or is it already done and nobody closed this bug)?

Reassigning to default assignee and qacontact.

Comment 5

[Felix Miata]

Updating URL for pending release of redesign.

Again with the new design most text is grossly undersize [*], and the reduced legibility is compounded by light gray text where the text should be black. The current #888 on #FFF is not even close to comfortably legible without substantially increasing text size above default.

* With my default set to 24px DOMI is telling me P text is a mere 14px (rudely set explicitly to 14px on line 104, totally disregarding user preference), 34% of my default setting.

Comment 6

[Steven Garrity [:sgarrity]]

(In reply to comment #5)
> Again with the new design most text is grossly undersize [*], and the reduced
> legibility is compounded by light gray text where the text should be black. The
> current #888 on #FFF is not even close to comfortably legible without
> substantially increasing text size above default.

The #888 text has been darkened to #666 for primary body text.

Comment 7

[Felix Miata]

The current contrast ratio of #666 on #FFF is 5.74:1 on a 4.5:1 threshhold, which passes at Level AA _for regular text_. The 14px used is typically subnormal (subregular) size, and worse yet at high DPI. The color needs to be much darker, preferably #000 for maximum contrast, to compensate for the readability/legibility reduction from the tiny text.

It is normally only those with maladjusted displays that reduced contrast helps. OTOH, many of those with older displays cannot get adequate brightness and/or contrast due to deterioration from the overbright, overcontrasty factory settings most displays come set to (and left at after purchase) in order to impress retail buyers standing in brightly lit stores.

Comment 8

[David Boswell]

I'd be fine with making things a bit darker, although I recognize there is a balance here so there are arguments against going all the way to #000.  Steven, do you think that giving #333 or #444 a try on stage makes sense?

Comment 9

[Steven Garrity [:sgarrity]]

The default font size was increased in r49696, but this was just the base font size - most elements still have a pixel font setting. Just noting here for the record.

Comment 10

[David Boswell]

Changing summary to reflect that this bug is covering font size and color settings and this is no longer about the staging site.

Comment 11

[David Boswell]

We received a note recently that was sent to webmaster saying the font was too faded to read clearly.  We had already suggested trying out a slightly darker font color in comment #8 anyway, so I changed things to #666 to #444.  Please feel free to comment about this being good or bad.

Comment 12

[David Boswell]

Along those lines I made the home page text a bit darker too -- there were some #777 and #888s in there that I made #666.

Comment 13

[Felix Miata]

(In reply to comment #12)
> Along those lines I made the home page text a bit darker too -- there were some
> #777 and #888s in there that I made #666.

To extend comment 7:

#444 is nothing but artsy bling, just not so bad bling as #666 or #888. Contrast reduction from maximum helps few who have a properly adjusted display, while hurting many who can't afford better than they have, and need 100% brightness and/or 100 contrast just to see anything. Those who find maximum too harsh can normally adjust down to normal levels.

On http://www.apple.com/safari/download/ the dominant text color is #000. Maybe that's where usability consultqnts and similar should send people to get a better browser?

Comment 14

[Felix Miata]

Bug 577317 has screenshots showing the latest styles update continues the top design mistake of 2005:

"Legibility Problems
Bad fonts won the vote by a landslide, getting almost twice as many votes as the #2 mistake. About two-thirds of the voters complained about small font sizes or frozen font sizes; about one-third complained about low contrast between text and background." http://www.useit.com/alertbox/designmistakes.html

Comment 15

[David Boswell]

To follow up on this, I think a good forum to discuss this issue is the websites task force.  There's already a proposal about coming up with standard typeface recommendations for Mozilla sites and the size and color to use for fonts seem like it could be relevant for this proposal too.

https://wiki.mozilla.org/Websites/Taskforce/Proposals/Typefaces_for_Body_Text

I think addressing this as a general proposal for all Mozilla sites in the task force is a better approach than fixing this on any one particular Mozilla site.

I'm happy to help with presenting this to the task force as part of an updated proposal or as a new proposal if anyone is interested in driving this issue.

Comment 16

[Mike Alexis [:malexis]]

Going through old bugs and marking this resolved.

I believe these issues were addressed with our new style guide and One Mozilla theme.

For more info in our bug triage process and if you want to help:
https://blog.mozilla.org/websites/2012/11/15/mozilla-org-bug-triage-process/

Comment 18

[Felix Miata]

Attachment: 1600x900 120 DPI screenshot of devmo home

Comment 19

[Felix Miata]

Attachment: 1920x1200 144 DPI screenshot of Mozilla.org home page

Comment 20

[Felix Miata]

Attachment: 1920x1200 144 DPI screenshot of Firefox addons page

Comment 21

[Felix Miata]

Attachment: 2560x1440 168 DPI screenshot of mozilla.org personalize/customize page

Comment 22

[Felix Miata]

(In reply to Mike Alexis [:malexis] from comment #16)
> I believe these issues were addressed with our new style guide and One
> Mozilla theme.

The new screenshots properly viewed with their black 25.4mm/1" blocks accurately sized demonstrate Mozilla.org pages are are worse now than when this bug was filed, and little different from when bug 577317 was filed.

Comment 23

[Jennifer Bertsch [:jbertsch]]

John - Could you please comment and either define a next step or resolve?  Thx.

Comment 24

[Andrei Hajdukewycz [:sancus]]

So, the DPIs you listed in these screenshots are clearly based on small screen sizes(15" or so, by my guess). If you have such a screen, it's pretty much assumed that you will increase the default font size because the normal desktop/laptop DPI assumption is 100.

Proposing that we significantly increase ALL the default font sizes on mozilla.org for accessibility is very unlikely to happen, regardless of how many times you reopen this bug or how the request is phrased in terms of percentage sizes. But, I'd like to hear from our design team, in any case.

Comment 25

[David Bolter [:davidb] (NeedInfo me for attention)]

Generally we should indeed strive for a minimum contrast ratio for text of 4.5:1.

Given that we have good zoom functionality getting the minimum font size perfect is not catastrophic but is desirable. Unfortunately visual designers seem to have great eyesight and don't like contrast :(

Filtered WCAG Spec here: http://webaim.org/standards/wcag/checklist/
Futher filtering: https://wiki.mozilla.org/Accessibility/WebDev_Recommendations

Comment 26

[David Bolter [:davidb] (NeedInfo me for attention)]

cc+ iaaaq

Comment 27

[John Slater]

Hi all. Thanks for looping me in. Representing the design team, I'll note that although we definitely take accessibility very seriously, it's only one of many concerns that we consider when putting together websites. I'm inclined to think that the balance we strike now is pretty good.

At any rate, like sancus said we don't have any plans for a site-wide increase in font size. Is there another action item here? Otherwise I feel like this is as a WONTFIX like malexis noted a few months ago.

Comment 28

[Felix Miata]

Anything other than 100% basing is needless and offensive. Mozilla.org due to the character of its products ought to be a leader in best web design practices, but is consistenly choosing to follow the herd in pleasing designers instead of users.

Zoom is a defense. Minimum font pref is a defense. Disabling site styles is a defense. Stylish is at least in part a defense. Defenses aren't needed absent encountering offensive behavior.

Comment 29

[John Slater]

It's hard for me to have a very productive discussion if it's going to veer into name-calling so quickly. Sorry you're offended.

Comment 30

[Felix Miata]

Exactly what did you see that you think constitutes name-calling?

Comment 31

[Andrei Hajdukewycz [:sancus]]

FWIW I think that Felix has a point here now that I looked through mozilla.org and especially the style guide. While stating it in terms of 'offensive' design is needlessly inflammatory and not a good way to get anyone to care about this issue, the official style guide recommends font sizes set in pixels and that's completely contrary to best practices for font sizing.

It also becomes an actual, significant technical issue going forward with the expanding number of different DPI screens available. In the current marketplace you have 720p screens that are 4.5" and 720p screens that are 15", and DPI differences will only get more significant as supoer higher resolution screens are becoming more common. Setting font sizes in unscaling pixel sizes ignores this issue entirely.

I don't think we can or should redesign mozilla.org to accommodate this, but it seems like we will need to do something eventually. Phones are hitting desktop levels of resolution already, and non-scaling font sizes aren't going to work forever.

Comment 32

[fantasai]

Regardless of how big the design team thinks the fonts should be by default, I don't see any reason why they should be absolutely-sized. At the very least, even if we don't default to the user-preferred font size, we should scale along with it. This is pretty easy to do with 'rem' units, just write

  font-size: 14px;
  font-size: 0.875rem; /* divide px size by 16 to get rem */

This way if the user pref is 16px (the default), the font size will be 14px. But if the user pref is 20px, the font size will be 17.5px, so, correspondingly larger. The ratio of font sizes will remain the same across the page; they'll just all be 25% larger, just as the user's default is 25% larger than the browser default.

Using the user pref as the base paragraph size, rather than downscaling by 12.5%, is a separate issue. There's actually three bugs being reported here:
  1. font sizes don't scale with user-preferred font size
  2. paragraph font sizes don't match user-preferred font size
  3. text-background contrast ratio is too low

I can't think of any reason why the design team should be opposed to fixing #1, at the very least. I would split the bug report into three, though, so they can each be addressed independently.

Comment 33

[Felix Miata]

(In reply to fantasai from comment #32)
There's actually three bugs being reported here:
>   1. font sizes don't scale with user-preferred font size
>   2. paragraph font sizes don't match user-preferred font size
>   3. text-background contrast ratio is too low

There have been a number of site style overhauls in the 113 months since I filed this. Reducing contrast to compensate for improperly adjusted (OEM setting overbright, overcontrasty for impressive display in retail environments) LCDs had not yet become "the way" to style at that time. Thus, low contrast was not a part of comment 0.

Body size most likely was not  set in px at filing. December 2004's content.css set size on body to x-small.

Comment 34

[Gérard Talbot]

Reopening and marking as a meta

Comment 35

[Isac Lagerblad (:icaaq)]

+1 on using rem units

http://snook.ca/archives/html_and_css/font-size-with-rem

Comment 36

[Gérard Talbot]

There are other factors which may be affecting readability and legibility of webpages: heavily styled text with advanced "cosmetic" styling and with heavily styled background properties.

When opacity styling is involved, when there is a gradient, linear-gradient or radial-gradient involved, when there is text-shadow applied, when text is italicisized, decorated text, reduced letter-spacing, etc: all these can contribute to make a text more difficult to read.

There are now many stylesheets applying onto mozilla.org websites that heavily style text (paragraphs) and heavily style backgrounds.

Comment 37

[Gérard Talbot]

(In reply to Felix Miata from comment #33)

> December 2004's
> content.css set size on body to x-small.

This was true although this is not the whole story.

    body, td, th, input { /* redundant rules for bad browsers  */
            font-family: verdana, sans-serif;
line 82     font-size: x-small;
            voice-family: "\"}\"";
            voice-family: inherit;
line 85     font-size: small;
    }

http://www-archive.mozilla.org/css/cavendish/content.css

The resetting (line 85) was successful in non-IE browsers; so, only IE5.x and IE6 were "bugwardly" applying 'font-size: x-small'. The used font-size was 'x-small' in IE 5.x and IE6; lines 83, 84 and 85 were ignored by IE 5.x and IE6. The used font-size was 'small' in non-IE browsers.

Comment 38

[Gérard Talbot]

> only IE5.x
> and IE6 were "bugwardly" applying 'font-size: x-small'. The used font-size
> was 'x-small' in IE 5.x and IE6; lines 83, 84 and 85 were ignored by IE 5.x
> and IE6.

I have tried to verify, to double-check this with IE8's compatibility rendering view and with browsershots.org and even such is not confirmed. It seems that 'font-size' was (displayed as) 'small' (and not as 'x-small') in IE5.x and IE6 too for unknown reasons.

Comment 39

[Gérard Talbot]

Light fonts
-----------

Several mozilla.org webpages declare 
font-family: 'Open Sans Light',sans-serif;
and, by the way, such font is an embedded webfont via 
@font-face{
	font-family:'Open Sans Light';

One consequence of such declaration is that a light type of font face is less readable than a regular type for the same font face. There are other consequences (fallback is - or rather would not or could not necessarly be - of type light, mixing of different types of fonts and font formatting in a page) with such declaration block by the way which can affect readability of the webpages.

Reduced letter-spacing
----------------------

At least a few mozilla.org webpages also declare reduced letter-spacing (eg. 'letter-spacing:-0.02em;' 'letter-spacing:-0.01em', 'letter-spacing: -0.25px', 'letter-spacing: -1px' and several others in mozorg.cdn.mozilla.net/media/css/firefox_all-min.css) for some block elements. Even if, in some cases, the font-size is relatively big, this sort of styling may not promote legibility. Tall and light glyphs with reduced inter-character space is not necessarly easy to read and/or easy to adjust to.

Comment 41

[Gérard Talbot]

> when there is a gradient, linear-gradient
> or radial-gradient involved, (...) these can
> contribute to make a text more difficult to read.

There's a site saying exactly this:

"
Gradient backgrounds almost always create legibility issues because some part of the text will suffer from poor contrast and reduced legibility. (...)
"
http://webstyleguide.com/wsg3/7-page-design/3-visual-design.html

Comment 42

[Steven Garrity [:sgarrity]]

Attachment: Link to Github pull-request: https://github.com/mozilla/bedrock/pull/2570

Comment 43

[[github robot]]

Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/e471457a90924a0c3a57b4b6a5c951df7c81d5c0
Fix bug 225639 - use relative font sizes

https://github.com/mozilla/bedrock/commit/510f0cc712292aa88ea3fd50a6375a8685eca271
Use new REM-enabled font-size mixin
Bug 225639

https://github.com/mozilla/bedrock/commit/985cbc8c789e0c840b04d20ea655e3609cc9d502
Merge pull request #2570 from mozilla/bug-225639-relative-font-sizes

 Fix bug 225639 - use relative font sizes