HomeSearchMerchandiseAboutMichael HorowitzMy CNET Blog

HTML

HTML is the language used to construct web pages

Fonts Across a Table 

The page headers and footers on this site reside in tables. The font used by the headers and footer is specified outside the table as shown here: 

<font face="Arial, Helvetica">
<table border="1" width="100%">
<tr><td><small>Computer Gripes<a href="index.htm">Home Page</a></small></td></tr>
</table>
</font>

With IE5, the gripe is the need for the <SMALL> tag. Specify a font size in the font tag is ignored within the table. An example of such a FONT tag is:
   <font face="Arial, Helvetica" size=-1>

IE5 is not consistent, the font face is honored within the table but the font size is not. 

Netscape Navigator 4.77 does not honor the FONT tag at all in this situation. The page headers and footers are displayed in the browsers default font rather than Arial or Helvetica.  (March 7, 2002) 

Fonts are also not honored within a table row. That is, in a table with a single row and multiple cells, a FONT tag specified just after the beginning of the row (TR tag) is ignored within each cell, even though the closing FONT tag is after the close of the final cell (TD tag). This is true for both IE 5.5 and Navigator 4.77. (March 13, 2002)  

Frames 

In developing the Table of Contents frame for this site, I ran into some issues with frames. 

As documented on the help page for the Table of Contents frame, you can adjust the width of the frames on this site. For IE 5 users, it seemed at first as if this did not work, because the mouse pointer did not change to indicate that the scrollbar is movable (at least not in IE 5.5). In contrast, Netscape Navigator 4.77 users did see the mouse pointer change to the normal window resize indicator. This was due to having coded 
            FRAMESPACING="0" 
in the <FRAMESET> tag. Removing the frame spacing, removed the quirk in IE5. 

If you resize the frames on this site, you can easily restore them to the original size with IE 5.5 by refreshing the page. However, Navigator 4.77 can not restore the original frame width by reloading the page. 

An interesting problem occurred when I loaded the home page of this site into the main right hand frame. For some reason, it caused all links in the Table of Contents frame to thereafter open new browser windows rather than their normal effect of replacing the page in the main frame. I don't know why this happens, so I worked around it, but making all links to the home page break out of the frameset (target="_top" for HTML coders). The links in the Table of Contents frame all specify "target=gripeframe" to force the page to load in the right hand frame. Sometimes this problem could be corrected in IE5 by refreshing the page. Sometimes not. Nothing fixed it with Navigator 4.77. 

If anyone knows why this happens, please email me. I suspect it has something to do with the following JavaScript code that is executed only on the home page:        window.name = "GripeMainWin" 

This was done so that form output can be directed to the correct window after doing a search from a standalone browser window. I suspect the window name specified here is interfering somehow with the frame name specified in the frameset definition. (March 7, 2002) 

A similar issue arises when searching this site. The results of the search are sent to a specific window called "GripeMainWin". However, when using frames, the main frame will not be assigned this name because the home page was never loaded into it. As a result, the search results page always opens as a new page when called from the framed environment.  

Another problem with frames has to do with tracking the usage of the web pages in the frames. My web hosting company provides web server statistics using a program called Analog. The statistics show usage for the web page that contains the frameset definition. However, the initial web pages that are loaded into each frame do not appear in the stats at all. Research done at the Analog web site turned up no documentation on how pages inside frames are reported on. This may vary based on the web server. 

Cascading Style Sheets 

Cascading Style Sheets can be used to control the font on an entire web site. I tried using it on this site and found a problem. The pages on this site reference a style sheet that resides in a file other than the individual HTML files that make up the site. The style sheet can include a body section that can specify a font and font size. When I tried this with IE 5.5, it worked. However, because the style sheet now specifies the exact font size, the page no longer responds to the Size button in IE which can normally make the font Largest, Larger, Medium, Smaller, or Smallest. I could leave off the font size and just specify the font, but that defaults to a font size that I find too large. I would like to start out the page at the font size I prefer, but still let users change the font size should they so desire.  March 22, 2002. 

Turns out there are other CSS options. For now, the font is set to 80% of the default size. This has the advantage of responding to user requests for larger and smaller font sizes. 

However, the cascading is not working consistently. Some <FONT> tags are being over-ridden by the style sheet and some are not. I think that <FONT> tags in the body are being over-ridden while those in headings and inside tables are not. March 23, 2002. 

My Home Page Gripes 

In playing with assorted designs for my home page, I ran across a few HTML gripes. 

As it now stands (March 2002), Netscape Navigator 4.77 does not display the main table across the full width of the screen, even though the table definition says the width should be 100 percent. This was tested on a 1024x768 screen under Windows 2000 SP2. 

In the summer of 2000, this was the way the table in the middle of my Home Page was supposed to look: 

The main part of the page was a table with two columns (still is). The left hand column was supposed to be exactly 460 pixels wide. This was just enough to allow the display of each of the gripes such that each one fit on one line. The right hand column did not have a fixed width, meaning the width can vary based on the size of your web browser window. In a browser window 600 pixels wide, the two columns would have been about the same height. In a browser window less than 600 pixels wide, then the right hand column would have been taller than the left hand column, and in a window more than 600 pixels wide, the right hand column would have been shorter than the left hand column. 

That was the theory anyway.

It worked this way with Internet Explorer version 5. Netscape Navigator v4.72 did not however, correctly render this table. It made the left hand column less than 460 pixels wide which resulted in many of the gripes taking two lines. Below is a picture of how Netscape mangled the table display. 

IE version 4 also renders the table correctly. Navigator v4.61 also renders the table incorrectly.  

You can specify an exact width for the right hand column too, and Netscape would have rendered this correctly. But this is poor design. It would require anyone viewing the web page in a window narrower than the hard coded width to scroll horizontally. Also, people using wider screen widths, would not get the benefit of their extra screen real estate. 

Below is a simplified version of the HTML to illustrate this problem: 

<table border="1"> <tr>
 <td width="460">I should be 460 pixels wide</td>
 <td>I have no set width, but I am...</td></tr>
</table>

The above HTML results in a table that looks like the below: 

I tried adding an option to the table definition to force the table to be 100% of the page width, but this had no noticeable, visible effect. 

The final solution to this was to replace the fixed width specification with the cell-based option "nowrap" in the left hand table cell that has the list of all the gripes. After all, the visible problem is that the gripes were wrapping, causing the longer ones to take up two lines instead of one. Bingo! Netscape Navigator honored the "nowrap" directive and the page now renders well. 

This brings up an interesting conflict. If you specify that a cell in a table should be a specific width at the same time that you say the text can not wrap around, the browser has to chose which instruction to honor when there is too much text. Of course, Netscape is incapable of honoring a specific width, even when it conflicts with nothing. To test this conflict of interest, I created the examples below. All specify a fixed width of 460 pixels for the left hand cell. 

A simple one cell table that is 460 pixels wide (for comparison purposes):

Short text again, fixed with of 460 pixels, without the nowrap directive  (for comparison purposes) : 

The lesson learned? Navigator needs a nowrap directive to help nudge it into doing what it should do anyway, honor the request for a fixed cell width. 
This section was originally written in August 2000.