Regression: Absolute font-sizes used in Seven

Is there a tool for finding fixed fonts? I haven't really checked to make sure this patch caught all of them. Firefox zooms pixel-denominated fonts without hesitation, so i expected no difference before/after patch. Instead, however visual inspection of the patch and the seven theme (used as a main theme as well as an admin theme) before and after the patch in Ubuntu Firefox 3.5.9 revealed some unexpected changes.

With the patch, a number of admin-oriented fonts are smaller than without the patch, and do not zoom as much either:

• "dashboard" link (on #overlay=admin/people or admin anything)
• all description text under modules on admin/config, also admin/reports and elsewhere
• the helper text for filefields and such
• The helper text for input formats on node/add/[contenttype] became all but illegible.

Much, much smaller for the latter two, so much so that i doubt it's only in that browser.

Unlike pixel font sizes, em font sizes are relative to the font sizes of parent elements. This makes it a lot trickier than a find-replace conversion. I'm not up for refactoring the theme this way right now...

It might be nice if Garland and Seven both used em or %, however, getting rid of px is the big step forward that we need. Thanks for working on this.

I listed everything i noticed.

The only way i know to fix it is to go through and play with it until it looks a good size in Firefox, and i don't feel quite comfortable doing that with someone else's design.

Though, since we're aiming for pixel sizes we could theoretically fiddle with the nested relative sizes (i'm pretty sure it's the nesting that's messing things up) until it equals the original pixel specification at normal zoom. I used to use a Free Ruler program (that's its name) on mac, though i'm sure there's firefox extensions or something that will be better and easier.

But i don't know if it would be much cleaner and better for zooming, for instance, to refactor the theme to be sure that em font sizes are always relative to the original body text size or whatever (in which case mgifford's sizes will almost certainly be correct).

This needs an HTML/CSS best practices person-- i can ask a few, or google around to see if this has been discussed, but i hit the limits of my knowledge after simply looking at the pages!

Perfect! I thought the helper text in the vertical tabs on node/add pages was a little small, but it's exactly what it is without the patch.

Very, very nice. Thank you Mike for doing it all.

Looks good -- I tested this patch and I don't see any visual changes. Committed to CVS HEAD. Thanks.

WCAG 2.0 does not prohibit the use of the pixel unit of measure but use of percents, named font sizes or em units is much preferred for accessibility.

I'm not sure why this was changed at all then. While a theme can certainly implement absolute or relative units on its own decision, modules like Toolbar have to use absolute units and have to enforce them as much as possible, since they need to work regardless of theme.

Due to this patch, various across Seven fonts are much too small now. I recommend to roll back this patch, and if required, re-start it from scratch.

Subscribe. Lots of elements showing too small, probably because of CSS inheritance: 0.75 of 0.75 etc. (see #3)

Table headings are now too small, e.g. modules page:

Enabled Name Version Description Operations

I also recommend rollback here, or we'll be fixing symptoms.

sub

WCAG 2.0 does not prohibit using absolute font sizes, provided that the fonts can be magnified to 200% without the use of assistive technology.

As long as * all * D7 supported browsers are capable of resizing absolute fonts to 200% without the use of assistive technology then there is no problem.

Noticed lots of "too small fonts" in the latest - will be giving a look over.

Everett - thats the problem, no version of Internet Explorer can text re-size absolute units except for the keyword unit. IE7 and IE8 have a page zoom feature much like Opera has had for years but its shockingly bad, especially in IE7. Also just saying "magnified" is not really good enough either, the zoom feature in IE7 and 8 is handy but can quickly degrade text so badly its unreadable. IE has some really whacked approaches to font re-sizing and to be fair the there are only two 2 units that can safely be used - em and percentage. Keywords can be used but sparingly, since they don't do so well with IE's zoom feature (but are re-size-able using the real text re-size tool, unlike all the other absolute units).

Based on what Jeff has said it would seem clear to me that absolute font sizes should not be permitted in core, regardless of the annoyance this may cause to theming.

I've been trough and made quite a few changes to bring the sizes and overall "look" back into the typography that was so good about Seven.

Its pretty hard to just swap out pixels for ems and hope its going to be all good - we needed do things a little bit different so there are some changes that probably look dramatic (code wise) but really are not. The most notable change here is that nearly everything is now set relative to the body font size - in Mikes patch there are inheritance issues so I have juggled things around font-size wise and even removed some. Also I used what I call pixel-relative em values - meaning these are actually proper px to em calculated font sizes and not some random value that "sort of looks right".

Notable changes are some changes to tabs and the required addition of vertical tabs font size overrides (they were a bit small).

There might be some slight variation from the "original" and I was mostly testing against a fairly recent version, although I noticed some differences they appear to be few and far between and only very minor (barely discernible for the most part). Please check it over.

I tested in all the major browsers and nothing appears broken, although the more the merrier (IE6, 7, 8, Firefox 3.6, Opera 10, Safari 5, Chrome 5 - all Windows, running on Win7), all the comparative testing (original vrs patch) were done in Firefox.

When testing in IE7/8 please don't use the Zoom tool, use the real Text Size tool (that's the real test).

I note we need a new issue also - "Overlay sets some fonts in pixels"... grrrr.

Yes, its built against CVS, lets see how the bot takes it and look for an error... I sometimes have issues with these things :(

I'm for not supporting IE6, 7 and 8, then.

If you are using IE, you are twice impaired.

I strongly suggest we start by reverting this patch (reverting patch attached).

Agreed with Damien.

Additionally, if IE doesn't properly support font scaling, then users who need to scale fonts won't use it in the first place, no? I mean, there must be gazillions of sites that can't be read right in IE, or not? Thus, it's only logical to use a different browser, one that works. And since other browsers don't seem to have issues with scaling absolute font sizes, and since WCAG doesn't prohibit use of absolute font sizes, I fail to see the logic in converting our core themes to use relative font sizes. The time and energy spent here is mostly wasted, because the intended audience for this change most probably won't notice anyway.

I created no patch. I just RTBC-ed sun proposal of reverting that first.

This is how it looks today on Windows XP + IE = small font-size, rough font.
The probable cause could be not only the font-size but the font itself.
It could be more safe to use "Core fonts for the Web" - http://en.wikipedia.org/wiki/Core_fonts_for_the_Web
Windows XP (still used by many users) does not have vector interface engine like Mac or Win Vista & 7.

I think not supporting IE runs counter to the direction Drupal is going in for D7 - to be more accessible and more supportive of the broad range of technologies / browsing devices. Yes there are many poorly built sites out there that are basically inaccessible to millions of users - that's not a mandate that we can do the same - that's a call to action and an opportunity to redress the issue, in our own small way.

In any case arguing over whether to support IE or not is not the issue here, that's a debate that took place quite some time ago and a major tenant of D7 is accessibility. The issue is to get relative font sizes into Seven and have it looking good.

The patch in #20 is not really a fix for the previous patch, its a total rework of font sizing in Seven - in short it skips the necessity for a rollback and do-over, jumping strait to the do-over - and it works. I'm not really seeing a big need to revert - time to move forward guys, please review the patch, its a good one.

WCAG does require that fonts can be resized without the use of assistive technology, Drupal supports IE6 - 8, therefore we need to enable users to be able to resize fonts with IE6 - 8. Users do not always have control over the technologies that they are using. Users in an organization with software policies mandating a particular browser, users at public workstations, users who are borrowing a friend's computer.

Users in an organization with software policies mandating a particular browser, users at public workstations, users who are borrowing a friend's computer.

"IE6’s death has been agonizingly slow for several reasons:
1. IE7 and IE8 can only be installed on Windows XP SP2+ or Vista. Many people continue to use older versions of Windows or avoid automatic updates.
2. Many large corporations have legacy applications that only support IE6. Upgrading these systems incurs significant costs which may not be justifiable – especially in the current economic climate. As a result, their employees have been unable to switch to alternative browsers.
3. Many IT novices are ignorant of what a browser is, how to upgrade, or why they should.
4. Some users simply prefer IE6 to IE7 and the competing browsers."

( source: http://www.sitepoint.com/blogs/2009/02/24/the-death-of-ie6/ )

Also: http://www.sitepoint.com/blogs/2009/08/18/microsoft-support-ie6-2014/

font: 0.81em/1.25em "Helvetica Neue", font: 0.813em/1.538em normal Lucida Grande... normal is the default value even without that, and this font is not shipped with Windows which dominates..
What was wrong with %s? It is the same failsafe thing as em. Garland has been using it since ancient times.
- font-size: 1.313em; + font-size: 1.385em; + padding: 0.769em ... looks like a magic spell... Why so precise and bulky? That's why Drupal has 300+ KB of CSS, right?
- line-height: inherit; - this is one is good, cause IE does not support "inherit" in none of the versions
vertical-align: baseline; - default value anyway
float: right; margin: 0 0 -10px 0; - all browsers hate floats and negative values
May be not to use resizing at all? Those who need it will do it. The less chances for problems - the better.

I'm getting tired of this one. Could we please revert this patch, and get a sane situation for everyone and *then* worry about allowing resizing on IE, which feels more like a feature request?

@34 - you're raising a bunch of issues that aren't really in the scope here, such as the other font property's and values - this is just about font size. There's no magic formulas going on, I think you're reading the patch file as if its the CSS, you need to apply it to see how it works. Precise units were used for, well, more precision - this is pretty normal CSS in any case.

The issue is correct - absolute fonts shouldn't be used (thus the patch in #25 is a defeat).
But none of the patches solves the problem.
The problem is the default font-size for the body. It shouldn't be in em.

Yes, the em size unit is recommended by the w3c. But as soon as you start all those sizing/zooming, in can not be used. Well it can but it will lead to problems for IE. Unfortunately. There is still a problem with IE - when resizing the text, it becomes larger than it should when made larger, and smaller than it should when made smaller.

We need a combination of percent and em.
The solution that works in all browsers, is to set a default font-size in percent for the body element:
So, it should be: body {font-size: 80%;}
After that you can use whatever em you want.

Sorry, I am unable to write a patch. Just do not know how to do it properly. Can anyone do it?
Here what should be edited:

--- in style.css ---

body {
color: #000;
background: #fff;
font-style: normal;
line-height: 20px;
font-size: 80%;
font-family: Lucida Grande, Lucida Sans Unicode, sans-serif;
}

.form-item label.option {
font-size: 1em;
}

div.admin-options label {
text-transform: uppercase;
font: 0.75em/1.875em Lucida Grande, Lucida Sans Unicode, sans-serif;
}

--- in reset.css ---

delete all this:

/**
* Font reset.
*
* Specifically targets form elements which browsers often times give
* special treatment.
*/
input,
select,
textarea,
body {
font: 13px/20px "Helvetica Neue", Helvetica, Arial, sans-serif;
}

Now it works. It shows the same text size in all browsers, and allows all browsers to zoom or resize the text.

Good spotting with the % on body, thats how I normally do things.... sheesh...

- body font set to 81.3% (16 x 81.3% = 13px), since 13px was the original font size.

- Kept the font-family "Helvetica Neue", Helvetica, Arial, sans-serif; for input, select and textareas and kept the font-size and line-height reset for textarea, but removed it from select and input as it caused a vertical alignment issue in IE (text was pushed to the bottom of the input field rather than vertically centered).

- added an override for #overlay-tabs which perhaps should be in Overlay module, it sets its neg margin & line-height in px which is not so good for resizing, I converted to ems and now it darn near perfect across a really big range of font sizes. Even IE8 is playing well.

Good work mertskeli - do you know how to apply a patch? If not usually Mike runs a dev site with these patches applied for testing. Cheers, or you can find out http://drupal.org/patch/apply

Spotted a mistake for ul.node-type-list .label (needed to be slightly larger) and tweaked tabs in overlay a bit more, now should be better across browser (we're talking 1px differences here from the previous patch to eliminate unwanted space below the tabs in some font sizes). This actually makes more sense now as overlay uses neg margin on an absolutely positioned element - its container is relative so using bottom: 0; makes more sense and then tweak it to account for resizing adjustments (I hope that makes sense to someone...).

Couple more screenshots attached comparing alpha 6 and dev from a couple of days ago with the new patch.

Visually, the patch in #40 fixes the problem in #12 of fonts being too small.

@Jeff Burnz - Thank you for the patches.
@#40 - Yes, would be nice to clean it up. It can easily be reduced twice (or more) with no visual regression. Besides, it leads to unexpected behavior. But the issue is about absolute font-size only. And Seven theme only. Unfortunately :) For example, yesterday I found the following Bartik's css element (font-family: Georgia, "Times New Roman", Times, serif;). 1. It is a copy from Worpress. A pure "copy/paste". 2. There's no need to spend bytes for "Times". It is the default web font and will be used anyway if a browser fails to load Georgia (or any other font). Sorry for nagging :)

For example, yesterday I found the following Bartik's css element (font-family: Georgia, "Times New Roman", Times, serif;). 1. It is a copy from Worpress. A pure "copy/paste". 2. There's no need to spend bytes for "Times". It is the default web font and will be used anyway if a browser fails to load Georgia (or any other font).

None of those are true:

1. http://www.google.com/search?hl=en&q=%22font-family%3A+Georgia%2C+Times+...
2. The "Generic font families" (serif, sans-serif, cursive, fantasy, monospace) are user-configurable, and there is no default defined in the CSS specification.

Ok, I'll edit it now:
1. The whole Seven theme looks suprisingly similar to the current Wordpress 3 default theme, not just visualy, in CSS as well. Most likely the font element was taken from there. Maybe not. But anyway I'd change it in order not to look so identical.
2. There's no need to spend bytes for "Times". It is the default browser font and will be used anyway if a browser fails to load Georgia. If a user sets his own custom default font in his browser properties it means he prefers that font, not Times.
Ok, Damien, I understand. If the current Seven CSS is ok, no need to touch it. Sorry for inappropriate remarks.

@44 - neither of these issues pertains to this particular issue, we try to keep on one central topic per issue as much as possible. If you have an issue with font-family or what-have-you then please open another issue and discuss it there. Webchick, Dries and others need to read through these issues and off-topic-crap regarding Wordpress and Bartik are quit literally spam to the issue reviewers.

If you believe that the patch in 40 "leads to unexpected behavior" please provide screen-shots, browser and OS details and an accurate description of the the issue. Please stick the specific issue pertaining directly to font sizing in Seven.

I RTBCd the patch that got in, but didn't have Yoroy's eye (or check the installer, my bad) and missed some of the reduction inheritance issues, so i feel a little strange RTBCing again. However, Jeff Burnz did fantastic work with the full conceptual overhaul it needed and mertskeli had one of the better non-patch assists i've seen.

mgifford in #39 checked the installer thoroughly and jbrown (#41) checked on Yoroy and his own spotted bugs.

A look by Yoroy would be ideal but i call this is ready to go in.

Great!

Committed the patch in #40.