Toolbar font size keeps jumping around

I consider this to be a won't fix. There is *absolutely no need* for the toolbar to look exactly the same across themes. On the contrary, each theme is free to adapt the toolbar to integrate with its visual appearance.

The toolbar and Shortcuts need their own font size. It is a fixed visual element and thus needs a consistend styling.

Generally this should be a percentage size, I guess?
I found that seven uses pixel sizes for the table element. If we are consequent in not using pixel sizes this should not be, if pixel sizes are allowed the Admin header might get some just as well - correct size would be 12px in this case.

I agree with eigentor, the font size should be consistent since the bar is not part of any particular theme and it's disorienting when it changes.

I think seutje mentioned in IRC yesterday that we're using percentage font-size to allow text-only scaling in IE 6 and 7. If IE forces us to use font-size: 100%, this is a won't fix.

I however vouch for font-size in px since that's the only way you can make it look consistent. If I remember right, admin_menu from D5/6 used px font-size and never had problems between themes. Also, newer browsers (not sure about IE7 though?) have full zoom so text-only zoom isn't that important anymore.

This needs a word from the accessibility people like mgifford.

We do not want Stark's CSS to have anything apart from some really basic stuff for putting columns in the right place. Therefore, a fix that requires Stark to have some font-size stuff in it isn't acceptable, IMO. This also makes it easier on new themers, since core would do the right thing by default.

I agree this is worth fixing though. Beyond that, I can't really offer much in terms of evaulating the various solutions.

This is definitely an accessibility concern so I'm adding a tag. I'd definitely like to see this fixed, hopefully for the alpha release in 15 days!

To meet AA WCAG 2.0 standards text "needs to be resized without assistive technology up to 200 percent without loss of content or functionality".

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 do find it a bit confusing that Seven's font-size is using em's and Garland is using % in #2. I do think it would be nice if both themes used the same relative standard for consistency.

I'm not sure using javascript to calculate the size and position in a way that scales with text size is one option to keep the font size more consistent between all themes.

It's also a best practice for mobile devices not to use pixels. This is also a useful reference on why this is an important issue.

So, +1 on option 2. Oh ya, and happy new year!

Things I didn't change, but which should be changed:
- Seven uses a different base font-size than Garland does, so things like the toolbar that persist over regular interface and admin interface show up in a different size if they use relative sizes (Garland uses body { font-size: 76%; } whereas Seven uses body { font-size: 0.8em; }) -> wil open a separate issue for this

I totally forgot about making that issue, didn't I? *blush*

I'd go for option 2 and make body font-size consistent over all core themes, I'd even go as far as putting base body font size on 100% or 1em
a) to eliminate the need for the style to be added to Stark
b) to quit overriding user browser settings. if a user sets his base font-size to 10px, he will expect the base font-size to be 10px and not 76% of that

or just a consistent one (both 80% or both 76%)

of course doing that will be annoying as hell, as all heights, widths and sizes that are currently defined as relative values will have to be patched to accommodate the change in base font-size

the whole base font-size discussion is an endless one though, I must of had it at least once a week

There are 14 instances of fixed fonts in Seven's style.css file. I've moved them all to em's using http://pxtoem.com

This is mostly for discussion. I was searching for relevant css using:

grep font-size seven/style.css | grep px 

I'm not a CSS guy though so really would want to have this reviewed by someone who is.

Chasing CVS (and removing bad cut/paste)

Is there any reason to keep this in pixels or should we just switch now to using proper formatting?

Adding usability review tag.

See also #698976: Fix toolbar height with CSS and make text zoom usable : We may need pixels to render the toolbar correctly without javascript enabled.

So could we define it initially in px & then use jquery to change the css to use em's on the fly?

That seems rather ridiculous.

How on earth do other projects deal with this type of conflict?

#698976: Fix toolbar height with CSS and make text zoom usable has been updated, the last patch uses ems only to make the toolbar play nice with text resizing, so it could help for this issue.

subscribe.

I'm all for setting the size in pixels. As stated before AA WCAG 2.0 standards don't prohibit the use of pixels.
There are 2 main reasons for not using pixels that I'd like to debate.

1. IE6 and IE7 don't zoom text set in pixels.
But
IE7 let the user zoom the whole page.
IE6 is a really old browser and I believe that while we should still support it we can't provide a worst UI for most users to prevent IE6 shortcomings on accessibility. Users willing to improve the accessibility of the web pages they visit should update their browser. It's free and easy.

2. Font set in pixels don't respect browsers font size preferences
True, but we're not dealing with a normal webpage, here. Drupal is an application an designing an application that is completely scalable is almost impossible. Having a toolbar that changes from page to page as soon as I install a different theme is not good UI design.

Developing themes in D7 confirms that the font size ist constantly switching in wide areas (drives you mad). Am definitely in support of nailing it to pixels if this is ok with the accessibility experts.

WCAG 2.0 priority AA requires that: "Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)"

In my opinion if all browsers that are supported by Drupal 7, which I believe includes IE6, meet the above requirement we are good to go. As the criteria mentions "without assistive technology" then screen-magnifiers need not be tested. Testing with the text resize / zoom features of browsers, where available, is sufficient.

Resources:

Thread: WCAG 2 and browser ZOOM and font units

Resize text: Understanding SC 1.4.4

Just a reminder : #698976: Fix toolbar height with CSS and make text zoom usable makes use of ems for the toolbar, usable with or without javascript, on all browsers including IE6. So text zoom is usable as far as the toolbar is concerned. A review of this patch would be welcomed btw ;)

#14: eliminating_fixed_font_sizes-v2.patch queued for re-testing.

Do we have a solution here? This keeps annoying the heck out of me when changing themes in D7.

The issue's objective got blurred a bit, the initial goal was to keep the font size from jumping to another size when you choose a different theme.

Accessibility concerns are valid, but actually another issue (even though closely linked).

If pixel sizes are not an option: How can we make sure the toolbar and Header do not use any theme's css? Maybe a solution would be to use much more specific classes, and somehow make sure it does not use the themes bas font size?
Actually the fact that Header and toolbar use _any_ theme css is a bug. Text should be resizable by setting the browser font size differently. But any dependence on the theme is a bug since we do not want to style it. If someone wants, they can still override it somehow.

I was looking for this issue...
Can't believe it is so hard to keep font size stable.

@aspilicions - it is not. But following accessibility guidelines not to use pixel sizes it is almost impossible at the moment. Since Accessibility is a big priority... Which is good, no doubt.

But with this issue it makes thinks a bit tricky.

I've updated the patch & re-rolled it to fit with head.

I've also attached a screenshot.

eigentor, can you check to see if this resolves your issue? Do we need to fork off the accessibility concerns & start a new thread?

@mgifford: no, it does not solve the issue. Corolla keeps the right font size for the toolbar, but Bartik does not.

Looking into the css it is easy to see why: The Toolbar takes the base font size of the theme. Bartik sets this to 0.8em, while Corolla uses 0.75em (75%), which by chance mirrors the size we know from seven.

The problem is still the same: Toolbar takes the base font size of the theme, which is the error. But it needs its own base font size.

Am really not sure how to do this without using pixels, but must be possible.

So, we should just set the base font in the toolbar here modules/toolbar/toolbar.css right?

And then also file a new issue under Seven for the use of fixed font sizes.

mgifford: Now what I'd like to know, since accessibility stuff still catches me on an insecure leg: Basically we eliminated all pixel sizes. If we cannot find another solution than setting a base font for the toolbar with px so all elements inside it inherit that and do not jump anymore: would this be acceptable or not?

I know we had this discussion already in the start of this issue. Jensimmons proposed some Solutions in #8.

The reason why I think the font size of the toolbar cannot be dependent on the theme's font size: People that create new themes cannot be expected to take care of the toolbar. It essentially does not belong to the theme. It would be a constant annoyance for Theme creators to deal with that and maybe having to write some special css.

Now imagine someone using some really LARGE or extremely tiny base font...

So my vote to set a px size for the outermost element for the header/toolbar and set all children elements with em, and write up the css for toolbar and Admin Header in a way that they inherit that fixed base font size.

I'm pretty tired right now and I just chatted with Mike, I can't really see a clean way out of this without using a fixed unit on an isolator wrapping div with big fat ID selector, then setting everything relative to that aka #33.

forgot to set this to needs review

I'm implementing the solution that Jeff & I talked about.

It includes the previous patch, but also the addition of a fixed font size as a base.

#toolbar ul li,
#toolbar ul li a {
  float: left;
  font-size: 16px;
}

I tested with the following: http://jsbin.com/ayemi3 (fixed px size on container, relative em on children) and it doesn't allow text zooming in IE7

another possible solution is to have themes (that have a base font-size other than most of the themes) have toolbar specific styles in their css to baseline the font-size on the toolbar wrapper (using relative values)

if we do this, we really need to take a second and see what the most used base font-size is and use that as the one that would automatically make it the right size without requiring toolbar specific styles in the theme's css

Argh, argh. What is making this worse is that the font size even keeps jumping when you enter admin area and come back to your front end theme again. For D7 has a separate Admin theme by default. I can already foresee tearing out my hair over this - seemingly a small issue. But being a mean little dog.

If we really want to :

• Keep relative font sizes for the toolbar
• Let themers set any base font size font the body tag
• And have a fixed font size for the toolbar

the only way to go is to compute the font size with javascript. We have already used something similar to compute the toolbar height in ems with seutje in #698976: Fix toolbar height with CSS and make text zoom usable. Something like : get the font size of the parent of the toolbar, and compute the relative font size of the toolbar accordingly.

This would mean of course that with JS disabled, it would not work. As a fallback, we can set the toolbar font size in px with CSS, and if JS is enabled, set it back to ems after computation. This would make toolbar resizable in IEs if JS is enabled, and would work in all other browsers in any case.

Any thought ?

Here is my attempt, but this approach has a problem : In IE, it works if the initial zoom state is 100%, but if you text-zoom and then reload the page, it will resize the toolbar font size wrongly. In other browsers it works fine though. I don't have much time to dig further, but here is a patch anyway.

Why not just go with #36 but then add Jen's suggestion from #8:

Option 4) Set the main spec to fixed-width size, but override that in an IE6 & 7 stylesheet with a relative size

I really don't care if the toolbar looks perfect in IE6, and only care a little bit if it does in IE7 - plus from the above discussion it sounds like the IE7 override might not even be necessary to preserve accessibility. So if the ugliness ends up in an IE6 override only, then we really really shouldn't care :)

If on top of that we could add some JavaScript to make the font size not jump around in IE6 (i.e., sort of the opposite of what #40 does) then all the better, but I don't think we should rely on JavaScript for the accessibility issue here, only potentially for the "let's make it pretty even for poor IE6 users" functionality.

...except that pixel fixed font size won't be zoomable in IE6, 7 and 8, so we would have to use relative font sizes for all IE versions, which would cause the issue remain for the vast majority of the users (that is, font size will keep changing from theme to theme).

With the above technique (if the little problem can be resolved) we would :

- Keep font size consistent in all browsers
- Keep text zoom possible in all modern browsers
- Make text zoom possible in all IE versions if JS is enabled

Sorry, just realized what you meant about IE7 and IE8 allowing page zoom in addition to text zoom. So if it is acceptable to drop support for text zoom in an accessibility POV, IE6 would be the only browser with this issue.

WCAG 2.0 priority AA requires that: "Except for captions and images of text, *text* can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)"

Makes me wonder if *text* explicitly refers to text zoom instead of page zoom. Any accessibility expert opinion on this ?

I think the patch from #36 should really be like this, what I mean is placing the font-size on the wrapper (#toolbar), then use relative sizes on all internal elements - I don't think there are any elements other than a that we need to worry about (needs checking).

Looks good to me Jeff. I've applied that patch here http://drupal7.dev.openconcept.ca/

Splitting off issue with Seven's use of fixed fonts:
#849642: Regression: Absolute font-sizes used in Seven

You are aware that this does not resolve the issue of text zoom in IEs, and is exactly the same as setting a pixel font size for #toolbar and #toolbar * ? (Sorry to ask, I'm simply not sure of the purpose of the patch).

ok, good point jide, lets test with a keyword:

Good try Jeff, but "small" is evil even more ;)
It has different defaults on each browser, and is relative to the font size of the parent element, so it is the same as using ems, minus control over the proportions.

Just to make it clear : my patch proposal does not mean "won't work with JS disabled", It means "pixel fonts + adding relative font sizes for IEs through JS".
So it adds text-zoom for all IEs in addition to page zoom in IE 7 and 8.

To summarize our options :

- Have pixel fonts, resolves the issue "Toolbar font keeps jumping around" on all browsers, but IE6 users won't be able to zoom at all, and IE7 + IE8 users won't be able to use text zoom, but only page zoom. As David proposed, IE6 could still use relative font size with a dedicated stylesheet though.
- Have relative fonts, does not resolve the issue, but is accessible on all browsers (I believe we already discarded this one).
- Have pixel fonts, and use JS to convert to ems, resolves the issue on all browsers + adds zoom for IE6 with JS and adds text zoom for IE7 + IE8 with JS. The tradeoff is that IE6 users without JS enabled won't be able to zoom the toolbar. But seriously, IE6 users without JS enabled ? ;)

There is still doubt about the fact that it is possible to resolve the little bug remaining in the JS technique (I did not have time to have another look), but let's see if that's worth trying.

About what David mentioned :

If on top of that we could add some JavaScript to make the font size not jump around in IE6 (i.e., sort of the opposite of what #40 does) then all the better

This is not possible, since if we have a relative font size, and then want to "fix" it, we won't be able to determine the final font size. Or we would have to set it in pixels, and that would be the opposite of what we want here ;)

The patch from #49 successfully locks down the font size, but it does so one pixel too large (I think before in Seven it was 11px, now it is 13px), this is FF 3.6 http://screencast.com/t/NTEyOTBj
http://screencast.com/t/ZGM1Y2FkZjY

As Seven always used 11px, I feel this as "right". But this is our chance to object, if we feel differently :P
While I feel 13px is definitely too large, 12px might be a good middle ground.

Did not test Jides patch yet.

Keywords are relative to the browser default - this is good, not evil - trying to have precise pixel-like control over the font-size is rather pointless and not the issue. The issue is that it changes dramatically between themes, not user agents, which is very little in any case afaikt.

Keywords are in fact an absolute unit and immune to the cascade, their relativity is only to the browser default, I think this should be tested before jumping to even thinking about using JS, which should be an absolute last resort for something so simple.

Preserving the 11px like font sizing is rather trivial - we can use a relative font size to pull down the small default, since we know that for the most part small is going to equal around 13px.

Ah OK. I realize there are quite some things in CSS I never knew...
Anything is fine by me, as long as it stops the jumping and is reasonably controllable.

Jeff, sorry I rushed without even testing the patch, and I was wrong about the cascading.

This is brilliant, it resolves the issue while preserving text-zoom in all browsers. And relying on the browser defaults is perfectly fine (in this case anyway), you are right.

Tested in FF 3.6, Safari 5, Opera 10.01, IE6, IE7, IE8, and all work fine, whatever the base font size is, and text zoom works on all browsers ! Holy grail !

I'd set this as RTBC, but maybe a few more reviews would be better.

This works for me. I've applied the latest patch here - http://drupal7.dev.openconcept.ca/

jumped between Stark, Garland, Seven & Zen with the toolbar maintaining the same position.

This is awesome.

I would suggest adding a code comment here that explains the rationale for using "small". As we can see from this thread, it is definitely not well-known, and it's the kind of thing someone else is very likely to come along later and try to change, thinking they are making an improvement to the CSS :)

Other than that, looks RTBC to me.

Then let us mark it so. Tested on Ubuntu Firefox too. Congrats, Jeff!

Let's add the code comment, please - like in the attached.

Oh, great. This drives me absolutely bananas.

Committed to HEAD!