Feb 4 2010

Base CSS Font Sizes Gone Wild (plus bonus CSS reset!)

I’ve been working on my version of a CSS “reset” file lately trying to achieve a gentler reset than the big ones out there. Specifically, I don’t want to reset everything all the way to zero; I’d just like better control over what those defaults end up being (cross-browser of course).

So, I’ve got almost everything done on my reset when I get to the point of wanting to set the base body font size in the CSS. So, as I have done in the past, I looked to the internet for guidance on what the best practice is. So the internet tells me:

  • Set the base body font size to a percentage in the CSS to alleviate Internet Explorer text sizing issues. (yup, knew that already)
  • Always use “em” units for your subsequent font sizing. (of course – been doing that for years)
  • Your base font size percentage should be… (!)

What? There’s no standard out there among the CSS gurus as to what that base font value should be? I was surprised.

So, time to do my own investigating to determine what my base font size should be. Here’s a list of websites that I checked and their base body font sizes:

Curiously, Twitter, Facebook and Yahoo! all use pixels as their base font size:

  • Twitter (0.75em, but overridden to 11px almost everywhere)
  • Facebook (11px)
  • Yahoo! (13px) use px as the base font size.

I’ve seen the 62.5% value often as a means to set the default browser text size to 1em = 10px. Obviously for those who want to set their fonts in pixel sizes, but know they can’t do it directly. Seems that it would work pretty well. For a long time now, I’ve been using the base font size of 76% as based off of this post by Owen Briggs. Strange that there isn’t more of a consensus among the CSS elite, but I think I’ll stick with Owen’s standard. I mean, anyone who took the trouble to take 264 happy little screenshots on the subject of CSS typography deserves some serious recognition.

I still think that the default sizes for the headings could use some tweaking, but I have a CSS reset demo page as well as having the demo pages available in a zip file.

Jan 20 2010

Web Standards. Who Cares?

Web standards, accessibility, WCAG, XHTML, CSS, blah, blah, blah… My web pages look just fine. Why should I care about the so-called “web standards”? Well, do you care that your car was built with and tested for safety standards? Do you care that if you buy a DVD, it will just work in the player you have at home? Does it bug you that you can’t just go buy a replacement battery for your digital camera (or it’s exorbitantly expensive) since it’s proprietary?

Having standards solves lots of problems.

What are web standards?

At a minimum your site will have:

  • Valid HTML/XHTML
  • Valid CSS

Hopefully your site meets some basic accessibility standards:

  • Section 508
  • WCAG priority 1

Even more hopefully, your site will meet the more strict accessibility standards (I usually go up to WCAG priority 2):

  • WCAG priority 2
  • WCAG priority 3

Also, just passing these tests isn’t enough. Seems stupid to say this at this point, but you shouldn’t be using table-based layouts and some thought should be given to how your site will degrade in text-based or unknown browsers. Focus on what matters: the content and usability. Do you really need a bunch of Flash animations and fluff on your site? If you do, then chances are good that people won’t hang around long enough for it to be successful anyway.

Adhering to these standards ensures that your pages can be viewed properly on a wide variety of platforms now and well into the future. You’re pretty much guaranteed that new web browsers will be able to view your pages properly, versus a poorly coded page that will probably fall apart visually. Check out your sites on a wide variety of browsers and devices and see what happens. Check it out on your mobile phone or on your PS3 or Wii browser. If you’ve been coding for IE only (thus making your site proprietary) it will be immediately evident.

Not to mention the fact that coding according to web standards can save money. Pages are more likely to work right “out-of-the-gate” on a greater variety of browsers/devices. Less testing plus increased compatibility = win. Standards-compliant code by definition means that developers new to the project should be able understand and maintain what was written.

Popular Validator Links

For More Info…

Aug 24 2009

Rollover Images – CSS versus JavaScript

I seem to always wrestle with this no matter how many times it comes up. When a website design calls for image-based rollovers on the primary navigation, rollover which method to use? CSS or JavaScript. Accessibility for me in this context is that the navigation must be functional if one or any combination of the following is disabled: JavaScript, CSS, images. It also validate as XHTML Strict, CSS level 2WCAG priority 2, and it (obviously) must work with screen readers. Browser compatibility doesn’t factor in heavily here, but it must work in my standard browser list, which includes IE6. I also consider the actual rollover effect itself to be non-essential.

CSS Benefits

  • [Maintenance] Can use one “sprite” based image for all items (changing background position to show the different items)
  • [Accessibility] Works even if JavaScript is disabled
  • [Accessibility] Shows text if images are disabled (via Ryan Rollovers method)

CSS Cons

  • [Maintenance] Funky HTML/CSS needed for full accessibility (the empty span trick of Ryan Rollovers)
  • [Extras] Will probably look bad if printed (since background images don’t print by default)

JS Pros

  • [Accessibility] Can use forground images with alternate text
  • [Maintenance] Simple, clean inline script using “onmouseover” and “onmouseout”
  • [Accessibility] Shows alt text if images are disabled
  • [Extras] Will print foreground images by default so printout should look better

JS Cons

  • [Maintenance] Will have many images to deal with – 2 for each item. If one image changes width, you need to redo all images and rollover states.

Both methods have a potential issue of when images are disabled, then the foreground or alternate text spacing can be tricky. Result can be that even though the text is displayed, it will be difficult to read.

I think that looking at these items summed up shows the direction I should take. As far as I can tell, the simple JavaScript method provides the most benefits with the least amount of potential problems. So it shall be!

Jul 31 2009

Why Are We Coding for IE6 Again?

Internet Explorer 6 sucks. We all know it. We all hate it. We all Most of us still have to deal with it. This is a problem I had run into before and it took me forever to figure out how to solve it this time. May as well document it here so I (and hopefully anyone else) can find it easily next time.

The problem:
Links styled with a background image are incorrectly tiling that background image. Or to put it another way; IE6 is not properly rendering the background of an inline element has a no-repeat background set. The example below shows the same link style applied in different places on the same page. As you can see, it renders the area for the background image position and dimension correctly, but it repeats the image within the confines of the actual arrow image dimensions (where it should show up). Man, that’s weird to try to explain. Hopefully the image below helps.

The problem shown:

Examples of IE6 background repeat and positioning problem

The CSS code:

.more-link {
 padding-right: 15px;
 font-weight: bold;
 text-transform: uppercase;
 background: url(../images/common/readmore-arrow.gif) 100% 1px no-repeat;

The HTML code:

<a href="#">View more</a>

The solution:
The solution is stupidly simple. I had figured it out before on a previous project, but of course couldn’t remember what the solution was. I just remembered it was something simple to implement. Anyway, as I emphasized above, the problem seems to be that the no-repeat background is set on an inline element. I guess that confuses IE6. Go figure. The browser is coming up on being a decade old.

The solution shown:

IE6 inline background problem - fixed

The updated CSS code:

.more-link {
 display: inline-block; 
 padding-right: 15px;
 font-weight: bold;
 text-transform: uppercase;
 background: url(../images/common/readmore-arrow.gif) 100% 1px no-repeat;

Voila! Tell IE to keep the element inline, but treat it like a block. Plus it shouldn’t adversely affect other browsers. Problem solved.