#246: fedora.css sets a universal scaling factor of 76%, which is much too small
---------------------------+------------------------
Reporter: adamwill | Owner: webmaster
Type: defect | Status: new
Priority: major | Milestone:
Component: General | Resolution:
Keywords: css font size | Blocked By:
Blocking: |
---------------------------+------------------------
Comment (by mrmazda):
[this reconstruction done in a plain text editor, then pasted, then
tweaked, so as not to get accidentally destroyed by errant clicking]
"most people are comfortable with the concept of a 9pt font on a 'normal'
display"
Please cite respectable authority for that assertion. Every web doc I've
found on the subject of what "most people" prefer or are comfortable with
has determined the range to be 10pt to 14pt, with the average ever so
slightly below 12pt. All such I ever found are small in number to be sure,
and old, but in those times display densities averaged less than they do
now (average size of each px was bigger), and the range of densities was
much narrower than now. >120 DPI then was rare, if it even existed at all,
80 and less commonplace, while now upwards of 220 DPI is available for
both desktop and laptop displays, 96 or nearly so is rather common, while
less than 40 is common among those using large HDTV screens.
In stark contrast to the assertion, in one Jakob Nielsen report
'''Top Ten Web Design Mistakes of 2005'''
https://web.archive.org/web/20051013063651/http://www.useit.com/alertbox/designmistakes.html
the #1 problem was legibility. "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..."
"the stuff about densities only confuses the issue"
It certainly can. But density is is an inseparable component of the
subject of how many px make just right, too big, or too small. One size
cannot fit all. A big reason why is the considerable variability of
density among devices that display web pages.
Each of the December 2012 attachments to
https://bugzilla.redhat.com/show_bug.cgi?id=638726 were put there to
demonstrate the impact of Fedora site styles when viewed on systems at
moderately elevated display densities. Except for 657935, which has a
small window with a Fedora page zoomed via user CSS overrides to bring P
text up to the browser's default size as comparison to the same page as
site styled, the vast majority of text on the Fedora page images is a
fraction of the size of most of the DE's UI text, and a smaller fraction
of the browser default. The smaller than UI text is in significant part a
function of density, the rest due to sub-100% font size set on body and
elsewhere in the various Fedora stylesheets applied to those pages.
"users and desktops know about density and try to compensate for it"
I doubt very many users really do know, and as a result compensate
directly because they know. What is common though is making things bigger
by configuring display resolution to below the device's optimal or native
resolution, making everything bigger, even though apparent quality
necessarily goes down as density goes down.
DEs invariably do nothing WRT density, invariably assuming 96 DPI
regardless of actual device density. Mac assumes 96. AFAIK, as I've not
used any Mac newer than 10.5, and have no idea whether escape from 96 in
any fashion has since become possible or readily discoverable, at least
through 10.4 96 has been hard locked in place. While Windows post-3.1 has
always assumed 96, it has provided a way for users to escape that
assumption. Unless something changed in versions newer than I'm familiar
with, XP latest, compensation is not automatic, taking place only for
users who dig into the bowels of its settings to personalize. Exceptional
effort is required to match actual display density to a Windows assumption
unless the particular display happens to match one of the preset
assumptions 96, 120 or 144 (25% increments). And, there are drawbacks to
divergence from 96 in Windows. Many Windows apps have failed to take into
account any possibility of other than 96, making elements difficult or
impossible to find or use, or ugly at the least. Microsoft itself has
acknowledged this in newer versions by instituting incentive for apps to
be accommodating to non-default display density. Xorg assumes 96 as well.
All DEs running under Xorg that I've ever used default to acceptance of
Xorg's assumption, and compensate only via user personalization taking
various forms that vary by DE and version.
" the 76% functions as a universal *fallback*, not a universal *override*"
Body {font-size: 76%} redefines the base size what was inherited from the
user's predetermined optimum (his browser's default font size), changing
the nominal value of the root em from 1.0 to .76, altering its '''size'''
by 1-0.76^2^ (-42.24%). .76em becomes the nominal size inherited via
cascade (the "C" in "CSS") by all text content that does not have its size
more specifically set by other rules, including rules in the browser's
internal styles. It ''does'' constitute an override of user determined
optimum, whether one wants to characterize it as "universal" or not.
"everything's ultimately gotta wind up as a whole number of pixels"
Because of anti-aliasing, that's not accurate in terms of what the eyes
see. Each px is made from usually a triad of three color elements in close
proximity. Turning on only selected elements of a physical pixel, or
turning on elements at reduced brightness, via smoothing techniques allows
apparent fractional size increments.
"In general a smaller size is more acceptable for smaller elements, yeah,
as you're not straining to read a sustained block of text at a small size
(for me, anyway)."
This precisely explains why UI text (typically 9pt) is smaller than the as
shipped from vendors browser default text size (nearly always 12pt/16px
all the way back into web antiquity).
"do you make the default on the larger side and tell people who like it
small to zoom out, or make default on the smaller side and tell people who
can't read it to zoom in?"
Please read at least the 3 paragraphs from
http://wm4.wilsonminer.com/posts/2008/oct/20/relative-readability/
starting with "Actually it’s not that big...".
Does Fedora want to be a leader by example, inducing the rest of the web
to full respect for user default sizes, optimal as determined only by
those in position to make such determination, users looking at their own
screens, personalizable by each via each's default browser text size
settings if not more in the form of DE zoom or other density compensation?
Maybe change in stages. In that fedora.css body rule, goto 81% soon. 6
months later, bump it to 86%. In 6 more, goto 93%. After another 6,
finally 100%, presumptive optimal for everyone. Assuming competence in the
rest of that sheet and others applied, other changes shouldn't be
required, or desired after the initial jump.
Users who complain that text has become "too big" should be instructed
that the size they see is as it is because it is exactly the size
logically assumed to be their optimum, as it is exactly as specified to be
their browser default; and they have the option to personalize that
default or zoom minus if the text really is too big; and they should
complain elsewhere where their optimum is not being respected.
What is happening now across the web, hardly just in Fedora, usurping
predefined-by-the-user optimal (any % size other than 100 set on body
and/or primary content like P text and blockquotes) or ignoring it
altogether (sizing in absolute units like px or pt), is rather like it
would be if on every TV channel change you make, the cableco or the satco
turns the box's volume down an arbitrary amount, requiring you on each
change to turn it back up if you want to hear at a level comfortably
optimal for you.
Leaving font-size out of html and body altogether, or setting it to 100%,
1em or medium as a sign of acceptance of browser default and user respect,
and the same for ordinary P text and most other text making up the main
content of each page, should be the ultimate goal and result of this
ticket.
--
Ticket URL: <https://fedorahosted.org/fedora-websites/ticket/246#comment:12>
fedora-websites <https://fedoraproject.org/wiki/Websites>
Fedora Website Team's Trac instance
--
websites mailing list
websites@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/websites
