Last modified: 2014-09-23 23:31:59 UTC
*** I'm reporting this on behalf on an anon who posted it on http://www.mediawiki.org/wiki/BadFontSize 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. http://www.mediawiki.org/skins-1.5/monobook/main.css: <pre> /* Font size: ** We take advantage of keyword scaling- browsers won't go below 9px ** More at http://www.w3.org/2003/07/30-font-size ** http://style.cleverchimp.com/font_size_intervals/altintervals.html */ 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; } </pre> 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: <pre> 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; } </pre> This CSS does not fix monobook correctly, because I get 120% * 1em font size, which is too big. Reference: *http://www.w3.org/QA/Tips/font-size *http://moinmoin.wikiwikiweb.de/ MoinMoin got this right
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.
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.
See also bug 15581.
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 ;).
The font size specified by x-small keyword is different on each platform (see http://style.cleverchimp.com/font_size_intervals/altintervals.html ). 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 http://www.w3.org/2003/07/30-font-size ** http://style.cleverchimp.com/font_size_intervals/altintervals.html */ 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.
+need-review
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. http://news.bbc.co.uk/ I recommend the usage of 1em for p.
*** Bug 15581 has been marked as a duplicate of this bug. ***
The Modern skin uses the same 'trick', but scales back up to 130%, which improves consistency across browsers.
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.
