Fixing A Small CSS Issue
Am I right in thinking that all government bodies are legally bound to make their websites accessible to all? Maybe it's just an American thing. Either way I was surprised when I visited my local County Council's website and noticed fonts on certain pages were unreadable in Firefox, while ok in IE.
Being an upstanding member of the local community (ahem) I used the contact form to let them know. Hey, I was bored. So bored in fact, that I went even further and decided to look in to what the problem was. Here's how:
The first thing I did was view source. As expected, they use a stylesheet. To find out which bits of this applied to which parts of the page I needed to understand the make-up of the page. To do this I opened the DOM Inspector, which is under the Tools menu in Firefox. Using the Inspector (detailed explanation of how in my next blog entry!) I found that the small text links live in spans with class "leftnavlinks", which live within cells of a table. Looking through the stylesheet I found the following rules:
td {
font-size: x-small;
}
.leftnavlinks {
font-size: 75%;
}
Can you see what's happening? As the styles cascade down from the cell to the span, Firefox is making the font size equal to 75% of the normal size of "x-small"!
Here's some text that demonstrates the effect:
| This is x-small and in a cell. | This is in a span with class "leftnavlinks" and is 75% of x-small |
Why the difference between the way IE and Firefox render the text? They both make the text in the span 75% of x-small! It's just that they both have different ideas about how big x-small is in the first place. In IE it's fairly small, whereas in Firefox it's really small. Because it's down to the browsers to decide, there's bound to be differences in interpretations. Having font sizes based on a percentage of an "unknown" size can therefore have a devastating knock-on effect.
It's also affectged by the doctype of the page. In this case the council have used the following DOCTYPE (coincidentally the same as Domino uses for this site):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
This puts the page in "Quirks Mode" (Tools -> Page Info to see which mode a page is in). Now, if you change this to the following DOCTYPE, which includes the DTD, the page is put in to "Standards Compliance Mode" and then IE makes the font unreadable as well! Here's a sample page in HTML 4.0 Transitional and one in HTML 4.0 Strict. Notice the different renderings in IE and note that all that's changed is the DOCTYPE.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
This doesn't solve the problem for NCC so. They need to re-consider using font sizes that are a percentage of a certain size. If they want the links on the left to be slighlty smaller than x-small they could use "xx-small", as below, or maybe "smaller":
| This is x-small and in a cell. | This is in a span where the font-size is xx-small |
And the moral is? Well, be careful when sizing fonts that may inherit other size properties from their ancestors. When nothing seems to be going as you'd expect, remember that the page's doctype can have an effect on the way different browsers apply styles.
But, we're Domino developers, and so don't have much control over the DOCTYPE. My only advice is to develop and test your CSS with the same DOCTYPE as the target server uses. I normally mock-up a site using a dummy HTML page created in TopStyle. This page is normally in Compliance Mode and so it's probably better to edit the doctype and use Domino's. Alternatively TopStyle allows you to switch between doctypes while in edit and preview mode.
Skip to the 
You can subscribe to an individual
I noticed this problem on a website I was building a few months ago. Instead of using "x-small", you can use the actual font point size "font-size: 9pt;". This makes the font size look the same in both IE and Firefox.
Speaking of digging around CSS with Firefox, have you seen the excellent "Web Developer" extension by Chris Pederick? {Link}
I can't say enough good things about it. For example, the "CSS > View Style Information" mode. The cursor changes from an arrow to cross-hairs. Whatever the cursor is pointing at is displayed in the status bar (more or less the DOM structure along with and any classes/ids). Click the mouse, and the relevant CSS is displayed in a new tab.
Its vast capabilities have been a real time saver/productivity boost in my Domino web development. Check it out (assuming you haven't already ;).
- Rod
Chris:
There are some major accessibility issues with using actual font size (font-size: 9pt;).
In terms of web accessibility, you never want to 'hard-code' the font size on a given page. The reason for this is that you eliminate the zoom/text size features of the browser. For example, if you have a visually impaired person coming to your site, and they set the browser's text size to "largest", the hard-coded font size (font-size: 9pt;) will not adjust accordingly. Given that, the page is not readable to the user.
Adjusting font size using relative/comparative means is a much better approach. For example, if you set the element's style to "font-size: 80%;", the font size will be 80% of the parent's font size. Using this means allows for the same results, but in a way that will work for more users.
Now, there are some things to remember. If you do not specify a specific point size, it will use the browsers default (12pt or <font size="2">). For many persons, this font it simply too big, but you can set your body/container element to use font-size: 75% (9pt) as its style. This will give the same 'look' as you want, but still allow users with the largest text size to increase their view of the font.
Chris. Careful! You could well open a whole new can-0-worms there. Whether to use absolute or relative font sizes... the debate on font sizing is endless.
Rod. I've been use the Web Developer bar for a while now and I love it too. Still, on Monday, I'll talk about the DOM Inspector and try and prove it's the bee's knees for us developers when it comes to decomposing a webpage.
Thanks for the warning Doug & Jake! I was not aware of this issue. Glad I posted here. I went to my site and sure enough -- the text size of those areas did not increase when I changed the browser's text setting. We'll need to get that changed.
Thanks - guess I'm going to have to go change all my CSS... I've been kind of going through the paces of switching from admin to doing more development. I've found many of the articles at this site useful and have implemented some of them.
Before getting into development as much, we worked with a company to get an Intranet up for us. It's a great Domino app but the colors just looked horrible in Firefox. So I decided to tinker with the CSS some and found that we had something like:
color: "#FFFFFF"
Well, I changed it to the following and it was beautiful in Firefox:
color: #FFFFFF
Don't know whether to praise FF or IE...lol
I think this issue comes from the fact the IE not all browsers treat TABLES as descendants from BODY (which of course they are). If you specify a CSS rule for BODY to change its size, you need to remember to apply the same size to TD as well. IE fixes that in compliance mode I beleive.
NCC obviously only tested in quirks mode on IE, hence the oversight. It's not so much an issue of relative or fixed sizes, but understanding how the browser applies those sizes in all cases.
Good point Dave, I'd forgotten about that, but I'm not sure it's right in this case. The NCC stylesheet didn't specify a font-size for "body" directly. Instead it applied x-small merely to all TDs (with it being a table-based layout this covers all content). The 75% rule is applied to a descendant then of the cells - the span. IE does make the span 75% of x-small, it's just that x-small is bigger in IE.
The problem with their testing is probably that the design dates back about 2.5 years (I'm guessing this from looking at the meta data for the page). Back then it was for more acceptable to be IE-only.
There's a great article on CSS font sizes that has a magic solution:
{Link}
The answer is "76%"
Ever since I've followed this advice I've not had problems with css font sizes.
Also there's a good article about font-size keywords on ALA:
{Link}
I was about to post a link to the same Noodle Incident article, and then realised that Andrew had already mentioned it.
Setting the font size to 76% on the BODY element, and then using em's for font-sizes elsewhere in the document works like a dream in all browsers that i've tested. Highly recommended!
Echo the Noodle Incident.
Applying the 76% rule and the CSS Centering rules at Simplebits {Link} should provide a nice basis for starting any Style Sheet
Goind back to your initial point I think the fact that site is still accessible in IE and there is no real reason why one can't use IE (or other compatible browser) means that it meets the accessibility rules on that score.
David. It's probably wrong of me to pull them up on the font-size thing as an accessibility issue, as it doesn't make the site UNaccessible as such. I guess it's just bad design rather than law-breaking in any way.
Not sure I agree about a site being "accessible" if it's at least available to IE users. What about Linux users?
Hi there,
I was going to mention the Noodle Incident as well .... 76% and then 1em for all fonts, headings up to 1.4em or 1.6em or whatever is required ... sizes beautifully cross-browser.
Jake - your page sized on IE 6 here is weird - medium is too big, smaller makes headings/sub-headings and body text appear the same, and smallest is beyond miniscule! :-)
Marky
Having just fallen foul of Konqueror's shortcomings I can appreciate the Linux issue. [Maybe it's me but it didn't present the notes.net site properly.] However the NCC site is designed to be compatible with later versions of Netscape which is available for Linux.
Just an addendum for prosperity.....
p {
font-size = 8px;
}
.... will work in IEwin, but not in Firefox.
Tip, use ":" instead of "=" for cross browser compatability.
Hint, when you spend an hour or so trying to debug a piece of css and it's because you're using syntax that would be more at home in a maths class, step away from the screen for a while.
*bangs head against wall*
I was being crazy until I found this page.
I am running a small scale website. I created it with Mozilla because of my symphaty to open source. I made .css file with Cascade Light.
I use Mac OS. I like Firefox very much. My web site had no problem with Mac's Safari and Firefox. But when I opened it with Firefox on a XP running machine I was shocked. I saw a big white page with nothing inside. Than I tried ctrl+- to minimize text size. Fonts was horribly big!
Than I started to work with css file. Font size adjust was 72! I made it 12. But that did not solve my problem. I didn't understand why. Four minutes before, I wrote to my file as Chris wrote first, "font-size: 12;". I'll just wait until tomorrow morning to see changes in a Windows pc.
I'd like to thank you all for your helf. I don't know if it works, but it was very useful for me. At least I hope that I've fixed that problem, and I wasn't the only one who experience such kind of problem.