Last modified: 2014-09-23 23:31:59 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 9119 - Improper base font size in monobook
Improper base font size in monobook
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
All All
: Low minor with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: accessibility, design
: 15581 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2007-02-27 20:52 UTC by Daniel Kinzler
Modified: 2014-09-23 23:31 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Daniel Kinzler 2007-02-27 20:52:26 UTC
*** I'm reporting this on behalf on an anon who posted it on while bugzilla was down. ***

The monobook theme use a base font of x-small, then enlarge the font back to
127%. The result is a font which is NOT the user specified font in the browser
preferences, and is too small to read. Impossible to fix with a general user CSS.

/* Font size:
** We take advantage of keyword scaling- browsers won't go below 9px
** More at

body {
	font: x-small sans-serif;
	background: #f9f9f9 url(headbg.jpg) 0 0 no-repeat;
	color: black;
	margin: 0;
	padding: 0;

/* scale back up to a sane default */
#globalWrapper {
	font-size: 127%;
	width: 100%;
	margin: 0;
	padding: 0;

The problem here is that x-small * 120% is NOT a sane default. There is only one
sane default, which is 1em - the font size defined in the user browser.

Browsers let you have your own CSS, which make it possible to fix bad sites css.
This CSS works for me on most sites:

html, body {
   font-family: Arial ! important;
   font-size: 1em ! important;
   line-height: 1.25em ! important;

input, select, textarea {
   font-size: inherit ! important;
   font-family: inherit ! important;

This CSS does not fix monobook correctly, because I get 120% * 1em font size,
which is too big.

* MoinMoin got this right
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-02-27 21:10:00 UTC
It looks dodgy.  The question is why Gabriel Wicke did it in the first place. 
I'm hesitant to fix it until I know that.
Comment 2 Gabriel Wicke 2007-08-20 12:53:50 UTC
Most users don't change the browser default (usually 16px), and using that directly would mean too-big fonts for most people. As the entire UI scales with the font size you get wrapping tabs on smaller displays, especially for sysops. You can try that with #globalWrapper{font-size:16px;} (or 1em if you spec it on body too) in your [[User:You/Monobook.css]]. With the nonlinear scaling you get a reasonable minimum size for anybody with the browser pref < 16px (127% of 9px) and a bigger font for the ones with browser pref >= 16. Take a look at the linked refs for an explanation of the nonlinear part.

Of course in an ideal world the browser default would be the default desktop font size and could be used directly with good results for practically all users. As too many sites use a plain percentage (often 75%) for the font size though this doesn't work too well anymore. I'm using a smaller browser font myself and need to hit ctl-+ occasionally to rectify this on those sites.

So overall there's no perfect way, it's a matter of using a good compromise for most users, especially casual ones. For power users it's quite easy to paste a line to their stylesheet for fine tweaking.
Comment 3 Christopher Yeleighton 2008-09-15 06:49:48 UTC
See also bug 15581.
Comment 4 Christian Thiele 2008-12-30 13:03:05 UTC
It's a nice trick, Gabriel used. But it isn't true, that it's always the same size for anybody with the browser preferences <16px. No browser uses 9px as size for x-small, so setting the browser preferences to 14 results in smaller fonts in the wikipedia. So it only works for even smaller preferences.

Besides other effects, there is the problem, that "x-small" isn't "x-small". All three versions of the CSS standard have different recommendations for implementing this and it seems, that every browser handles it different. Only for the standard size (16), Opera, Chrome und Firefox render the same. The next problem is the calculation. For example the main menu ("Main page") is: x-small * 127% * 95% * 95%. And there are rounding differences: Opera/IE always round up, FF/Webkit round mathematically.

I think relative font sizes should be part of Acid4 ;).
Comment 5 Miraceti 2009-06-11 07:53:50 UTC
The font size specified by x-small keyword is different on each platform (see ).

It's true that webpages use often smaller fonts than the default one. Unfortunately. This has a historical reason. I my opinion, Wikimedia should probably do the same until something happens in the outer world.

The "minimimum size" trick _does not work_ as Gabriel wanted. Try this in your project:

  <p><span style="font-size: 10%"><span style="font-size: 1000%">Lorem ipsum!</span></span></p>
  <p><span style="font-size: 1000%"><span style="font-size: 10%">Lorem ipsum!</span></span></p>
  <p><span><span>Lorem ipsum!</span></span></p>

Both major browsers, Firefox 3.0 and IE 8 display all three texts in the same way (however, Konqueror 3.5 does not). There is no real protection against too small font.

In my opionion, if Wikimedia projects really wants to use an advantage of keywords, only keywords should be used. For special cases like menus, it is possible to use percentage in addition at the last level of a style definition but the number of font sizes on a page should be limited.  No 127% * 95% * 95% should be used because it only complicates the design and makes keywords impossible to use in higher levels of the style definition.

I suggest to leave the concept of globalWrapper or use it for something else than changing font size. Let's keep things simple. The css should look like this:

/* Font size:
** We take advantage of keyword scaling
** More at

body {
	font: small sans-serif;
	background: #f9f9f9 url(headbg.jpg) 0 0 no-repeat;
	color: black;
	margin: 0;
	padding: 0;

/* wrapper for free use */

#globalWrapper {
        /* empty by default */

This change won't have a significant impact on an ordinary user since "x-small" * 127% is about the same as "small" on major platforms. However it makes the whole css simpler and more understandable.
Comment 6 Siebrand Mazeland 2009-06-11 09:03:39 UTC
Comment 7 Andy R 2010-01-06 17:54:11 UTC
The "trick" used doesn't fit modern webdesign criteria. Wikipedia is the only Webpage, in which I usually have to adapt the browser font size manually.

Usually, every browser uses a default for html elements. This might be 12px for p and 16px for h1 whatsoever. Handicapped people are used to use a higher standard value.

If we use "p:1em", then em can be understood as a variable with the value 12px (or maybe 20px, if you use a very large screen resolution).

It is common webdesign practice to use 1em for p, so there is no need for "tricky workarounds". Many important webpages use em values, i.e.

I recommend the usage of 1em for p.
Comment 8 Erwin Dokter 2010-09-04 14:25:40 UTC
*** Bug 15581 has been marked as a duplicate of this bug. ***
Comment 9 Erwin Dokter 2010-12-18 01:16:14 UTC
The Modern skin uses the same 'trick', but scales back up to 130%, which improves consistency across browsers.
Comment 10 Sumana Harihareswara 2011-11-09 02:49:44 UTC
Removing the "need-review" keyword since we are using that for bugs that have code patches attached, and that require code review.

This does seem to be an accessibility & design issue, so, adding those keywords.

Note You need to log in before you can comment on or make changes to this bug.