Author: Tyler

One of the biggest challenges of web development is making websites that are compatible in all of the major internet browsers. The main browsers are Internet Explorer, Firefox, Safari, Opera and Chrome. It can be extremely difficult to make everything work identically in all browsers, especially as your web design becomes more complicated, but I don’t think it’s impossible or that it always has to consume your entire budget on a web project.

With that said, there have been times where I want to boycott each browser, but with a little focus and research, there’s always a fix!

I see a lot of novice developers just learning how to code tableless designs complain that their website works perfectly in Firefox, but then completely breaks in Internet Explorer.  It’s one thing if your website is totally destroyed in IE6. I get it. It takes a lot of practice to understand why IE6 does what it does, and none of us will ever fully understand what Microsoft was trying to accomplish there. And even though I do always try and support IE6, I don’t expect everyone to do that. It’s a personal call from developer to developer.

With that said, there’s really no reason why a website you develop would work in the latest version of Firefox, but then be totally destroyed in the latest version of Internet Explorer. This just means that there are clearly some things that you don’t understand, and there’s absolutely nothing wrong with that; this is how you learn. Just don’t bitch about it in a forum and curse IE because you don’t understand basic web development concepts work, like the box model, for example.

Oh the box model, you say?

Yeah, I just threw it out there! We’re getting closer to the reveal of the Bobich Law of Browser Compatibility.

For those of you that don’t know, the CSS box model describes the boxes that are formed around elements of content in a Web page. Every element in a Web page is in a box or is a box. The boxes on Web pages are constrained by rules defined by the CSS box model.

Well, I already know about the CSS box model, so what’s your point?

This is all nothing new, right? Many developers know all about the CSS box model, but choose not to think about it until they see a broken website in IE.

I used to have a partner at the Advertising agency I worked at that was so adamant about W3C compliance that he would always say with his nose pointing up to the sky, “I design for W3C standards only. IE comes later.” Then after the site was essentially finished, he’d view his broken site in Internet Explorer and start going through and making changes in a stylesheet called with an IE conditional statement. No offense to him if he ever reads this, but while neatly commented, his HTML/CSS was quite sloppy and he spent way too much time trying to configure this sloppy CSS file for IE.

But would you believe there’s a way for your website to have totally W3C compliant CSS while still having all of your boxes be the same width in both Firefox and Internet Explorer?

So what the hell is it already?

It’s so simple, you’re going to be embarrassed I had to tell you, but this is a rule I’ve developed for myself and I always follow whenever I code anything. And finally, this is what I’ve dubbed the Bobich Law of Browser Compatibility:

Easier said than done, Jason! I need padding and widths on all my divs, how will I ever trudge on?

Don’t worry, friends. I’m not going to just throw out something as mind blowing as the Bobich Law of Browser Compatibility without giving you some helpful information on how to work with it.

Keep in mind that many developers might disagree with the methods I’m about to share because they could be said to add too much cumbersome HTML markup to your site, but I don’t care. If you’ve purchased any of my Theme Forest themes, you’d know that I write extremely clean HTML and CSS that looks almost identical in most browsers.

Basically, on all of my major layout divs that need a width, I also add in a nested div that will have any padding or borders associated with it. Here is an example of a box that will be 300px no matter if it’s viewed in Firefox, Safari, Chrome, Opera or even Internet Explorer.

I am Canadian, so I spell colour funny. It is the UK spelling, the Queen’s English some say.  I am also a Web Designer so in order for CSS and HTML to work colour must be spelled the American way, so I will use that spelling from now on. Anyway… in this posting covers how to “save for Web” in Photoshop and preserve color settings.

Three Steps to Color Perfection.

Step 1: Color Profiles

Color profiles define how Photoshop interprets the raw color data in your files. That’s right: That means they change how you see the colors. This kind of precision is great for photography and print design, but it’s got to go if we’re making a website. With no images open, go to Edit / Color Settings.

Fig. 3 : Changing to Monitor Color.

We’re going to essentially turn off all this profile nonsense by changing the top drop-down to Monitor Color. Let’s uncheck “Ask When Opening” while we’re at it….from now on, when you open an image that has a color profile, Photoshop will give you a brief heads-up that we’re tossing it out.

Step 2: Proof Setup

Now, let’s go up to View / Proof Setup / Monitor RGB. This is to make sure Photoshop won’t be showing you skewed colors on your nice new profile-less images. A note, though: If you’re on a Mac/PC and want to see how an image is going to look on the other’s default gamma setting, you can come back here and test using “Windows RGB” or “Macintosh RGB.” Just remember to switch it back, or you could accidentally be designing in (shudder) PC mode.

Fig. 4 : Make sure you’re not viewing the wrong proof colors.

Step 3:

After all this hard work, Photoshop still wants to sneak color profiles into your images. Most web browsers ignore them, but new Safari and Firefox builds DON’T, and IE can be set to work with them too. This can result in the weirdest cross-browser headache yet, so we need to make sure the colors we save out are sans profile.

Fig. 5 : Convert to sRGB is an evil setting.

Thankfully, it’s an easy fix: Open up any image on your machine and File / Save For Web. Next to the Preset option, there’s a sneaky little arrow…click it and uncheck “Convert to sRGB.” (Note: From what I can tell, this is only the default setting in CS3)

Congratulations

Your color woes are over! Or maybe not. If you followed these steps and your color accuracy test failed, leave a comment with your results.

em vs. px vs. pt vs. %

One of the most confusing aspects of Cascading Style Sheets (CSS) is the application of the font-size attribute for text size and scaling. In CSS you’re given four different units by which you can measure the size of text as it’s displayed in the web browser. Which of these four units is best suited for the web? It’s a question that’s spawned a diverse variety of debate and criticism. Finding a definitive answer can be difficult, most likely because the question, itself, is so difficult to answer.

Meet the Units

1. “Ems” (em): The “em” is a scalable unit that is used in web document media. An em is equal to the current font-size, for instance, if the font-size of the document is 12pt, 1em is equal to 12pt. Ems are scalable in nature, so 2em would equal 24pt, .5em would equal 6pt, etc. Ems are becoming increasingly popular in web documents due to scalability and their mobile-device-friendly nature.
2. Pixels (px): Pixels are fixed-size units that are used in screen media (i.e. to be read on the computer screen). One pixel is equal to one dot on the computer screen (the smallest division of your screen’s resolution). Many web designers use pixel units in web documents in order to produce a pixel-perfect representation of their site as it is rendered in the browser. One problem with the pixel unit is that it does not scale upward for visually-impaired readers or downward to fit mobile devices.
3. Points (pt): Points are traditionally used in print media (anything that is to be printed on paper, etc.). One point is equal to 1/72 of an inch. Points are much like pixels, in that they are fixed-size units and cannot scale in size.
4. Percent (%): The percent unit is much like the “em” unit, save for a few fundamental differences. First and foremost, the current font-size is equal to 100% (i.e. 12pt = 100%). While using the percent unit, your text remains fully scalable for mobile devices and for accessibility.

So, What’s the Difference?

It’s easy to understand the difference between font-size units when you see them in action. Generally, 1em = 12pt = 16px = 100%. When using these font-sizes, let’s see what happens when you increase the base font size (using the body CSS selector) from 100% to 120%.

As you can see, both the em and percent units get larger as the base font-size increases, but pixels and points do not. It can be easy to set an absolute size for your text, but it’s much easier on your visitors to use scalable text that can display on any device or any machine. For this reason, the em and percent units are preferred for web document text.

Em vs. Percent

We’ve decided that point and pixel units are not necessarily best suited for web documents, which leaves us with the em and percent units. In theory, both the em and the percent units are identical, but in application, they actually have a few minor differences that are important to consider.

In the example above, we used the percent unit as our base font-size (on the body tag). If you change your base font-size from percent to ems (i.e. body { font-size: 1em; }), you probably won’t notice a difference. Let’s see what happens when “1em” is our body font-size, and when the client alters the “Text Size” setting of their browser (this is available in some browsers, such as Internet Explorer).

When the client’s browser text size is set to “medium,” there is no difference between ems and percent. When the setting is altered, however, the difference is quite large. On the “Smallest” setting, ems are much smaller than percent, and when on the “Largest” setting, it’s quite the opposite, with ems displaying much larger than percent. While some could argue that the em units are scaling as they are truly intended, in practical application, the em text scales too abruptly, with the smallest text becoming hardly legible on some client machines.

Conversion from Points to Pixels (and Ems and %)
Here’s a chart that converts points to pixels (and ems and %). It’s an approximation, which will depend on font, browser and OS, but it’s a good starting point.