Saturday, April 26, 2008

Cloning your Corporate UI with HTML DB - Part VI (Re-Post)

The following is a re-post of the "Cloning your Corporate UI with HTML DB" series that I blogged about back in 2005 on the now-defunct Orablogs site. Most of the content and advise is still the same today, and has been reposted here exactly as it was on the old site.

July 12, 2005

What's the best way to ensure that you have more work to do? Use a statement like "That about wraps up this series" in your "final" posting in a series!

As Earl Lewis pointed out, things are not 100% correct when using MSIE. Now, there's a very simple cut-and-dry solution to this problem: Don't use MSIE. However, for those who have not yet made the switch to Firefox yet (which, according to traffic on HTML DB Studio is still about 80% of you), you will also see this error. Thus, it is critical that you test your site in both - if not more - browsers. This is something which I simply forgot to do.

It's as simple as this: the same HTML can and often will look different in MSIE & FireFox (and other browsers). It is time very well spent running through each and every page in each browser which you expect your users to use, in order to ensure that all pages render correctly. Nothing infuriates me more than a site which only renders correctly on MSIE!

The core problem here is some abandoned JavaScript calls & references, left over from when I gave up on the Dynamic OTN Menus. I took a few minutes to remove all of them, and MSIE is once again, quite happy. Ironically, I had to the use the JavaScript debugger in FireFox to determine which reference was still hiding in the source, as the messages generated by MSIE are very vague. I encourage you to check out the FireFox JavaScript debugger - it's quite nice for a browser add-in.

Looking around some more, I noticed that the titles on the Application Detail pages are not rendering correctly in MSIE either:

Let's take a look at the Report Template to see what HTML is being generated. Here is the relevant snippet:

<table width="100%" class="bodycopy">
<tr>
<td colspan="3" class="OTNHeadline">#NAME#</td>
</tr>

Looks like the table has a class called bodycopy associated with it, and the title has a class called OTNHeadline associated with it. The class bodycopy will be applied to all items in the table, as it is defined at the table level. When the #NAME# token is rendered, it will first have the bodycopy class associated with it, but it will override any directive set by bodycopy with those set in OTNHeadline. Those attributes not mentioned in OTNHeadline will retain their values as per their definition in bodycopy.

Let's take a look at bodycopy first, as that is what gets applied to the text first:

.bodycopy { color: #000000; font-size: 12px; font-family: Arial, Helvetica, sans-serif; line-height: 14px; text-decoration: none; visited: #000000 }

Looks like quite a few things are set here: color, font size, font, link style & color, and something called line-height. According to htmldog.com, line-height "Specifies the height of a line of text." So if it is set to 14px as per the above class, and then apply the OTNHeadline class:

.OTNHeadline { font-family: Arial Narrow, Arial; font-weight: bold; font-size: 30px; }

Since there is no definition for line-height, the value of 14px set by bodycopy is retained. This causes something to get chopped off at the top & bottom, as we're trying to render a 30px font in a 14px space. Thus, all I have to do to fix this is change the class definition of OTNHeadline to this:

.OTNHeadline { font-family: Arial Narrow, Arial; font-weight: bold; font-size: 30px; line-height: 30px; }

Reload in MSIE, and things look much better now:

This is just one of many examples of how different browsers render the same HTML. I can assure you that this is the norm, not an exception.

Once again (knocking on wood), that about wraps up this series...

No comments: