Font sizes in CSS should be "em", not pixels

[anonymous]

Pixel units in css files of trac are bad! I had to replace tens of ??px to get the whole interface slightly larger.

If we had "em" units, the page would be displayed correctly scaled (depending on system resolution (dpi)) in every modern browser. This is what "em" units are for, normally.

Furthermore, usage of "em" units is considered as better design.

[nkantrowitz]

If you have already done the changes, a patch would be nice.

[Ivan G Shevchenko <linuxadmin@…>]

notes to my "patch":

the problem with replacing absolute (px) values with relative (em, %) values is: it's a different concept. if we have nested blocks with font-size 0.9em each, the nested blocks will become smaller and smaller, because the size is interpreted relatively to parent block.

i wasn't able to understand the whole "concept" behind trac's css files (IF there is a concept, which i doubt, seeing that sometimes 3 different font-size notations are used: %, em, [smaller|larger] ).

so i can't guarantee that nested blocks won't be displayed wrong. but as far as i can judge, the appearance is OK overall.

it would be great, if someone who is familiar with trac's css-"concept" could re-structure the whole thing ;)

i changed only font-size properties. following conversion was used: i set 12px to 1em, each pixel additional pixel being 0.1em, so that 14px would be 1.2em and so on.

[Ivan G Shevchenko <linuxadmin@…>]

BTW: now, to change all font sizes, one has to edit just a single line!

it's line #3 of trac.css:

change 1em -> 1.1em to increase all font sizes

change 1em -> 0.9em to decrease all font sizes

(well, i hope, no one will decrease fonts, they're already pretty small in trac)

[eblot]

I remember a mail or a ticket comment from one Trac developer (cmlenz, mgood ?) writing about this topic.

I might be wrong, but I think it was about ex/em and the fact that they were badly supported. Before making any changes, it might be useful searching for this ticket.

[cboos]

Related tickets: #633 and #3575. The three of them (i.e. this one included) should probably be consolidated in #633, perhaps targeting an earlier milestone if someone steps up for handling this.

(Ivan: you should create your patches in unified diff format, e.g. by using svn diff. See TracDev/SubmittingPatches).