Last modified: 2012-09-27 01:10:55 UTC
# Sizing fonts and sizing by font metrics The only way the WWW author has to know the what size of type is well readable by a user is the default size selected by the user. When a font is displayed at a size smaller than the user's default font size, that creates a usability and accessibility problem. This is more widespread a problem than only affecting those who's eyesight is so poor that they count as disabled. Screen resolution, in the sense of dots per inch (DPI), will determine how much space on the display a glyph occupies, making measurements in pixels (px) an especially ineffective unit to use in specifying typeface size. ## Units and methods for typeface sizing Relevant information about the (CSS properties is at)[http://www.w3.org/TR/2009/CR-CSS2-20090908/fonts.html#font-size-props] See also: (Chapter 4 : The amazing em unit and other best practices)[http://www.w3.org/WAI/GL/css2em.htm] The Wikipedia entry on em is illuminating.
Where are you seeing font-sizes defined in pixels?
phase3/skins/vector/screen.css it occurs twice: font-size: 13px; Looking further, I see that more often it is a relative sizing which is less than 1em (100%). Nothing smaller than the user's specified body text font size can be presumed to be sufficiently legible. If these are applied to the user's default text size, the result will be a font which is too small. Easier is to not specify any size <100% or <1em or "smaller".
Those 13x font-size contain: DON'T PANIC! Browsers that won't scale this properly are the same browsers that have JS issues that prevent this from ever being shown anyways.
I have interpreted that as meaning that it will be either hidden or 13px . Is that not that the meaning?
This is a very limited and documented, well tested browser compatibility trick. I don't think there is anything wrong here. Browsers are horrible things, and we usually just to do whatever it takes to get things working. There's no room for being a purist in front-end development.
What trick is 'This'? It seems there are at least 2 'thises' being discussed. Browsers are capable of making the main issue work as it should. If you wish to make a case to the contrary, please explain or discuss. Perhaps I can help find a way. If you have bug reports handy to the relevant deficiencies of the browsers, that would be best. Pointing to the aforementioned trick documentation would be good. The current implementation not "working" as well as it could. Designing a user interface goes beyond WORKSFORME. Marking this report as INVALID is invalid. Marking this report as WONTFIX is, in my estimation, unnecessary. Tell about what problem(s) you encounter so that we can fix it. I have written HTML & CSS, but I do not know of anything preventing making text legible. Text is a fundamental thing. This is an important issue to get working.
To make it clear, this is not only about the single item which may be sized 13px.
(In reply to comment #7) > To make it clear, this is not only about the single item which may be sized > 13px. Ah, well then, I ask again, as I did in comment #1, "Where are you seeing font-sizes defined in pixels?"
The original title of this bug was falsely narrow, in that it only mentioned sizing in pixels. After your question, I responded and changed the title of this bug. Please, examine the new title if you have not. From my previous response: "Looking further, I see that more often it is a relative sizing which is less than 1em (100%)." To give some concrete examples of this from vector-main-ltr.css: font-size: 0.75em; font-size: 94%;
Have you experimented with changing this? I am not opposed to using 1em text, but there will need to be yet another redesign for that to play out well, because Vector, like Monobook was designed for 0.75em text. We already have issues with people complaining that the site doesn't work well at resolutions below 1024px wide, and sometimes even complaints about lower resolutions like 720px wide. Increasing the font size will make these problems even worse.
I don't understand why, and it is probably not important, but Monobook looked slightly larger. Maybe it was a different typeface. I don't know in what way it "doesn't work well" at low resolutions. Some times clipping happens which is also undesirable; a narrow column of only 10 characters for body text is also impractical. Nothing stops users from decreasing their font size settings to a size that is suitable for them if they are comfortable reading smaller type: in fact that is the sensible premise. For users with narrow screens there are skins also exist which do not have the column to the left of the article: MySkin at least. There is also en.m.wikipedia.org. I have tested size of 1em by using the feature in FireFox for enforcing a minimum font size. It works well with Vector.
In the Firefox Tips & Tricks, Wikipedia was selected for the screen shot next to the Zoom feature, introduced with the catchy question, "Tired of tiny text?" http://www.mozilla.com/en-US/firefox/tips/
There is a new CSS unit which could help, at least in new browsers: "rem". 1rem is the base size which I meant should be considered the minimum. A Wikipedia specific Gecko/Firefox AddOn was made for this issue: https://github.com/mrothe/wikipedia_font_size_firefox_ext
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734
As a developer myself[1] I hate to be whiny user and put a "me too" comment, but this font bug makes Wikipedia nearly unusable (without zooming in of course) in OSX/Safari. In Linux/Firefox, the font size is too small but still legible without zooming in. I've no clue about Windows/IE since I don't have those available to test. If I understand correctly, as the bug title suggests, it's a bad idea to specify an em size less than 1 because 1.0em means the size of the font that the user has set (or is default) in their browser. As mentioned in the previous comments, this a well known problem such that people are starting to make browser extensions and user scripts to fix it themselves. There's a massive list of (almost exclusively negative) user feedback about it here: http://en.wikipedia.org/wiki/Wikipedia:User_experience_feedback/font_size For the record, I'm on a 13" Macbook Air with OSX 10.7, Safari Version 5.1.6 (7534.56.5), Standard Font is set to "Geneva 14"[2]. My screen resolution is 1440x900. I've pushed a screenshot of what I see when I visit Wikipedia here: https://github.com/codebrainz/misc/raw/master/screenshots/wikipedia-screenshot.png This seemed like an appropriate bug report to comment on, but let me know if there's a better one or if I should create a new report or if there's a Wikipedia-specific bug tracker I missed. [1] Not a web developer FWIW [2] I can't remember if I changed the default font but Wikipedia is the only site I can remember where it's not perfectly legible, and it'd be a shame to have to set it bigger and zoom out on every other website except Wikipedia.
