I might not mean Felix Miata. Can't think who the dude is now.

I think you got it right in comment 0 Adam. https://bugzilla.redhat.com/show_bug.cgi?id=141361 is probably where I started bringing it up in a formal Fedora context, back when you were still with Mandrake. I filed https://bugzilla.redhat.com/show_bug.cgi?id=974780 too, which was wontfixed, plus https://bugzilla.redhat.com/show_bug.cgi?id=638726 that remains open.

12px is only 9pt if the display density is in fact 96 DPI. On a 133 DPI laptop (17" 1920x1200), 12px shrinks to 6.5pt.

Back before that 2005 article referenced, in 2003, in http://www.w3.org/2003/07/30-font-size the standards body responsible for CSS, W3C, published "Do not specify the font-size in pt, or other absolute length units." According to http://dev.w3.org/csswg/css-values/#absolute-lengths the px unit is an absolute unit, the unit used to set the base size on body (and elsewhere) in https://fedorahosted.org/fedora-websites/chrome/common/css/trac.css used on this very trac page.

The same 2003 doc also says "Avoid sizes in em smaller than 1em for text body". Yet, fedora.css is setting a smaller than 1em ''base'' size, based upon the 1em size inherited from HTML, which gets its size from the visitor's browser default size. Lest any reader here be unaware, the 76% "size" set in fedora.css is a nominal size only. Real size is a function of area, which is what any size seen by a human on a web page sees. That 76% nominal size actually works out to the square of 76%, or 57.76%, not a whole lot bigger than half size, as http://fm.no-ip.com/Auth/area76.html demonstrates.

Styling like in fedora.css and trac.css is little different from that used by the vast majority of web sites. That it is the case that it amounts to a standard practice doesn't justify it. It's rude. It countermands every personal computing device's innate ability to obey the needs of its user as established by personalizable font size settings in whatever application(s) present a Fedora web page for viewing and use.

Yes fedora.css has this in the ''html, body'' instructions and this file is used also by the other sites. Additionally to this the single websites have other css files, which are related to the fedora.css main file. If you look deeper at the fedora.css file you will find a lot of font-size overridings too.

I'm saying this because fixing this 76% size is not so easy as it seems, though. I guess in all these years people added or changed css classes here and there, specifying also font-sizes to override it.[[br]]
If we want to change this value (is there a new recommended minimum basic font size later than 2005?) we need to rewrite probably all the css files of all the webpages to make the pages look nice, so it's a really huge task. IMO we should not work on this at the moment, perhaps we can look at this when we will have to work heavily on the pages for fedora.next.

I also wonder how many people use a 1920x1200 resolution, laptops actually are mainly 15" and are still using a standard resolution of 1366x768, where the pages look acceptable IMHO.

robyduck: I visit a lot of Fedora websites, and I overrode it to 91% locally yesterday and they all look better to me.

Felix was giving an extreme example, but I'm using a 1920x1080 22" monitor - that's 103dpi, almost the same as your laptop which is 100dpi, and it still looks damn small to me. I wouldn't say 'acceptable', I'd say 'just barely readable'.

mrmazda: the stuff about densities only confuses the issue, which is why I was trying to avoid it. Especially since users and desktops know about density and try to compensate for it. If you leave it out of the question entirely and assume the 96dpi convention, you can just talk about equivalent point sizes - most people are comfortable with the concept of a 9pt font on a 'normal' display, which is the equivalent of what we're displaying with a 76% setting if it is not overridden later.

Yes, some Fedora sites fiddle with the sizes later, but I'd figure at least that the Wiki is one of the most commonly-visited sites, and it's badly affected by this. So is this domain itself.

Replying to [comment:4 adamwill]:

robyduck: I visit a lot of Fedora websites, and I overrode it to 91% locally yesterday and they all look better to me.

Nice, then it's less work than expected. Want to provide a patch? :) \
Is 91% not too big? I see many sites are using 82%, and that is not so far away from 76%, but still a bit bigger.

Felix was giving an extreme example, but I'm using a 1920x1080 22" monitor - that's 103dpi, almost the same as your laptop which is 100dpi, and it still looks damn small to me. I wouldn't say 'acceptable', I'd say 'just barely readable'.

I'm on a 15" right now and can read it without any problem, but if there are difficulties we should work on this.

mrmazda: the stuff about densities only confuses the issue, which is why I was trying to avoid it. Especially since users and desktops know about density and try to compensate for it. If you leave it out of the question entirely and assume the 96dpi convention, you can just talk about equivalent point sizes - most people are comfortable with the concept of a 9pt font on a 'normal' display, which is the equivalent of what we're displaying with a 76% setting if it is not overridden later.

Ok, better if we avoid it.

Yes, some Fedora sites fiddle with the sizes later, but I'd figure at least that the Wiki is one of the most commonly-visited sites, and it's badly affected by this. So is this domain itself.

I was thinking about the sites we maintain directly, such as fp.o, spins.f.po, fcomm, fudcon, start.f.po, ..

I think 76/82/91 is basically going up one size at each step, in effect (remember everything's ultimately gotta wind up as a whole number of pixels, still assuming our 16px default / 96dpi conventions). 91 might be 'a bit big' for some people, yes. It's really a very squishy area...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? Ehhhh. If you want to be conservative kicking it up to 82% is a smaller change for sure.

As we just saw on IRC, fedoraproject.org front page itself is actually a rather good example, as it's using Cantarell, which tends to render somewhat smaller than most fonts, exacerbating the effect. All the 'body' text in Cantarell on fp.o - see the front page, or http://fedoraproject.org/en/about-fedora#freedom for a really clear example - is pretty small.

Couple of notes on the theory here: AIUI (and I'm a CSS expert with three days of cloud-based training!), the 76% functions as a universal fallback, not a universal override.

It's not like sites that set their own text sizes have to take that 76% into account and make all their settings bigger than they would otherwise be because they'll be multiplied by 0.76 later, that's not how it works. The '76%' size is only applied to text which isn't styled in any other way by a later and/or more specific stylesheet. So basically, any site which actually decides to do its own font sizing has completely thrown that 76% away.

Therefore, poking that value is only going to change text for which no other size is explicitly set. The only sites that might be 'negatively affected' by the change are ones whose design is strongly tied to tinyfonts, but which don't explicitly set a small font size themselves.

Generally speaking I'd expect only text for which no-one really deeply cares about the size to be sized by that 76% directive.

So I think just changing that to 82% wouldn't actually be a terribly disruptive change; try it out, anyhow, and see what you see.

As discussed on IRC an even more conservative approach is just to find sites that specify Cantarell (if there are any other than fp.o itself) and explicitly set a larger size for those, since Cantarell renders pretty small.

Yes it is as you say, that's what I meant before with ''more css files for every single website''. So you have for example for f.po:

body {
background: #E6E6E6; \
color: #333; \
font-size: .8em; \
padding: 0 0 40px; \
font-family: Cantarell,"Droid Sans",Verdana,sans-serif;
}

And here starts the extra work, because if you define another size in there, it will affect all font styles, titles etc.

What if we just try to work around the "normal" text? I mean, aren't the other styles, such as titles or subtitles, the nav menu or other links "readable"?

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).

Perhaps it may be best to avoid specifying Cantarell given the problem that it tends to render smaller than other fonts, so that if we set a size more appropriate for Cantarell - like .9em - it might be a bit big for people looking at it in Verdana? But still, .9em (90%) Verdana is hardly huge either.

Why not use responsive design like bootstrap ?

attachment

Submitting attachment just threw away hours of composition begun prior to comment 5. What I was trying to do was as forum sites typically do is allow inclusion of an image in the comment, after clicking on the image icon failed to do what I expected. Now that it's attached I see on opening it that it is being displayed here much larger than life size, I'm guessing scaled up to 125%.

[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 disparate 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.

I tried some solutions yesterday, but what you're proposing is not doable (96% or 100%), unless you have a very high resolution, IMHO. I agree much more with a conservative solution Adam proposed (have still to test it with a Cantarell change), which will result also adaptable to the single websites.

Just as example, I tried a small generic change of f.po, assuming as font-size 0.85em instead of 0.8 in the specific f.po css file. Just this makes it look better for the 'normal' font IMHO, without modifying too much the other elements. On the other side, there are some sizes to adapt to make it all look better, but this can be done easily in a short time.

[Again I lost all my work. This time by attempting to open the WikiFormatting link in a new tab via right click.]

Replying to [comment:13 robyduck]:

not doable (96% or 100%), unless you have a very high resolution

Resolution absent screen size is not relevant. The two combined produce screen pixel density, which is eminently relevant. Density, and density alone, determines the physical size of any given number of px. User determined optimum takes density into account, as well as other factors, such as viewing distance, visual acuity, ambient lighting, display brightness/contrast, preferred viewport width, possible color-blindness, age, fatigue, and more.

http://wm4.wilsonminer.com/posts/2008/oct/20/relative-readability/ \
http://wm4.wilsonminer.com/posts/2008/oct/20/relative-readability/ \
http://wm4.wilsonminer.com/posts/2008/oct/20/relative-readability/

Doing it in stages would give users time to acclimate, leading slowly, but leading nevertheless.

mrmazda: you're spamming the bug again. please stop. when you post this much it just overwhelms people, it doesn't make them more eager to do what you're suggesting. I've filed the bug and I think explained the problem clearly.

To take some points very briefly:

I didn't mean most people were OK with reading a 9pt font, I meant most people were OK with the concept of what a 9pt font is. Saying "the current settings are basically displaying text at 9pt" is a clear and accurate-enough statement of the problem.

When you bring density into the consideration it just makes things very messy very fast and complicates the discussion so much it's hard for anyone to be comfortable moving forwards. Doing so is hurting your case, not helping it.

"DEs invariably do nothing WRT density"

This is not true. GNOME/GTK+ are doing OS X-style resolution doubling stuff now. If the density is close enough to 192dpi you get doubled everything, you'd get another jump at each 96dpi increment after that, IIRC. This landed in F20. http://blogs.gnome.org/alexl/2013/06/28/hidpi-support-in-gnome/

"It does constitute an override of user determined optimum, whether one wants to characterize it as "universal" or not."

You have the context wrong. I was talking about the perspective of the site designer, not the user, as we are talking to the site designer at present.

"Again I lost all my work."

It sounds like you should probably try composing things in a text editor and copy/pasting them into your browser...

I've pushed a try to the stg instance at http://stg.fedoraproject.org where you can see how it looks if we give the body a 0.85em. Some blocks which override this would have to be fixed to make it look with the same font size as the other ones, but the rest has changed.

As said in IRC we have another aspect we need to consider: translations often are longer than the english version, so I assume that many pages will not look good anymore. We always tell L10n to proofread their strings in order to avoid this kind of issues, but if we gave them less space now I guess we can't expect to have all the strings reviewed again.

Just an example: On the st.f.po homepage on the top-right we have the ''A Red Hat-Sponsored Community Project'', which ends at the limit of the page. Many languages here need a second line if we modify the body to 0.85em, that's not good and would have to be fixed. Just as an example of how many secondary issues we would have to face with and you are not thinking about in this moment.

Replying to [comment:15 adamwill]:

"DEs invariably do nothing WRT density"

This is not true. GNOME/GTK+ are doing OS X-style resolution doubling stuff now. If the density is close enough to 192dpi you get doubled everything...

Invariably was a poor word choice. And I was going by what Gecko does, what the W3C specs provide for all web browsers, nothing all all until the granular 192 threshold, the apparent integer multiple limitation of available hardware and software. The gap between 96 and 192 is too wide for nothing to happen in the wide middle range that includes 112-160 or wherever the trigger point is in Gnome actually is. The same problem will manifest as DPI grows from 192 into the 220+ range.

mrmazda: let's focus on the topic, we are not in a mailing list here where to discuss theoretical stuff. I like much more concrete solutions, summarized in a few words or a patch, not endless discussions which leads to nothing.

Replying to [comment:18 robyduck]:

mrmazda: I like much more concrete solutions, summarized in a few words or a patch

I would not mind contributing patches if there were a policy statement somewhere defining the goal in a way that could make me believe effort I would make would not be futile. Given history on the subject generally involving Máirín Duffy and others in website mailing list discussion, I have to be skeptical.

The subject says "much too small". To me, correction of that big a problem won't be solved by a modest change from .76 to .85 on the body rule, doing a little consequent adjusting, then saying a complete solution is in place.

I opened http://stg.fedoraproject.org/ just now. Without having been there before to know it was worse, the results look only typical of the rude web generally. .85 is still too small, particularly for gray text as in #four-fs that takes three hits of Ctrl-+ in FF to get the text size up to 100% of optimal in compensation for the suboptimal contrast.

What I really wanted to see on s.f.o post-fiddling is d.f.o content fiddled, but I couldn't find a way to get there. I want to see if the problem in the following is gone: \
http://fm.no-ip.com/SS/Fedora/fedoradocs01.png \
http://fm.no-ip.com/SS/Fedora/fedoradocs02.png \
http://fm.no-ip.com/SS/Fedora/fedoradocs03b.png \
http://fm.no-ip.com/SS/Fedora/fedoradocs04b.png \

If you would have read carefully my comment, I said ''Some blocks which override this would have to be fixed to make it look with the same font size as the other ones''. Why do you pick up a block which overrides the 0.85em? The text in the 4-fs block is the same as before, what do you want to prove? The goal of the change was to demonstrate how it would look for 'normal text', for example on the right sidebar or in http://stg.fedoraproject.org/en/using/

Do you need a policy to provide a patch? I was not involved in the last discussions with Mairìn about this topic, but I think she had more or less the same thoughts I have in this moment about the topic. And also, I'm not positive to bring the font size up to 100%, if that is what you want to demonstrate.

So please, if you want to help in this trac ticket to improve the readability of the text on the websites, be concrete, otherwise this is not the place where to discuss about unimportant things. We already have too much comments here and it's not useful for anyone who wants to step in to help solving the issue.

Thank you.

We will have a new layout (and new css files) in 2 months, so I'm closing this as a wontfix.