NetTalk Central

Author Topic: IE and the <pre> Tag  (Read 4654 times)

mpetitjean

  • Newbie
  • *
  • Posts: 18
    • View Profile
    • Nola Ridge
    • Email
IE and the <pre> Tag
« on: November 12, 2007, 04:58:56 AM »
     We have an online scheduler in beta which displays reservations for a twelve hour period, a twenty-four hour period, a week or a month.  The twelve hour view breaks each hour into fifteen minute time slots.  The header for the table extends across the width of four columns and displays the hour of the day.  Since the header is four columns wide and the time display only requires the center two columns, we used the <pre> tag to insert spaces in the leftmost and rightmost columns of the header.  The column width for the table is set to 15 for each column.

     Everything works correctly in both IE and Firefox when the page is opened from the menu choice.  On the page is a set of radio buttons to select what to display (aircraft schedules, instructor schedule or both).  When a radio button is selected the page refreshes and displays correctly in Firefox.  In IE, however, it suddenly makes the first header column (and the table columns under it) extend the width of the viewable area on the page.  No scroll bar is created so the customer cannot scroll to see the vastly widened table.

     We created a text file and stored the HTML created in the SendPacket routine.  We then used Beyond Compare to compare the generated HTML sent to IE with that sent to Firefox.  with the exception of the session number the HTML is identical.

     If we remove the <pre> tags and substitute two dashes (--) in the blank header columns IE is happy and displays the page properly even when the radio button is reselected.  However the page looks very bad with the dashes instead of spaces.  This has been tested with the original version of IE 6 (no patches) and the current patched version of IE7.  Both give the same result.

     Does IE not support the <pre> tag?  Is there some other way, acceptable to IE, to insert these spaces?  Can anyone recommend a book concerning the inner workings of IE that might help us resolve continuing display issues with IE?

     Thanks!

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: IE and the <pre> Tag
« Reply #1 on: November 13, 2007, 01:54:58 AM »
IE6 or IE7?
IE6 seems to have some problems with the horizontal scroll bar if the div style has a float: left; setting. This is in the adiv class which is uses as a default div class all over the place.

There is however an alternate fdiv class which doesn't have this setting. So try changing the page (netwebform, but included browse) to use fdiv instead of adiv. See Css Styles tab for both.

cheers
Bruce

mpetitjean

  • Newbie
  • *
  • Posts: 18
    • View Profile
    • Nola Ridge
    • Email
Re: IE and the <pre> Tag
« Reply #2 on: November 14, 2007, 05:20:30 AM »
     Thank you, the fdiv class fixed the IE6 scroll bar problem.

     The second IE problem, the expansion of the column size is a refreshed browse page, persists however.  This problem occurs in both IE6 and IE7 but not in Firefox.  In one browse page we have twelve hours in the header but four columns under that header for each hour.  We created classes to control the border on the header columns, since there are actually four header columns in the one hour slot.  The hour is shown in the third and forth header columns.  The first and fourth header columns should be blank for an hour.  If we leave the columns blank both browsers help us by shrinking the size of the column.  I tried using the width property in the CSS to fix this, without success.

    Each header column is populated from a data variable.  In the first and fourth columns of each hour we set these variables to be
<pre>  </pre> to insert two spaces in the header to maintain the width.  When the form page, in which the browse page is embedded, is called (from a menu choice or a button) the form and the browse display properly in both browser types.  If a radio button selection is used on the page to set a new filter for the browse, the form is not refreshed but we specified that the browses must be in the client-side tab.  Firefox refreshes the browse correctly with the new filter and the column spacing is maintained.  IE6 and IE7 both mis-display the first and fourth columns of each hour by making them excessively wide.

    I temporarily corrected this by changing from radio buttons to regular buttons to reset the three browse filter changes.  This forces the entire form page to refresh and IE handles everything properly.  Unfortunately now the customer wants a date selection control on the page to select the date to view (rather than just using the forward and back date buttons we already have).  Since this control only refreshes the browse, not the form we are back to the same problem.

   Internet Explorer seems to give us lots of trouble (originally we built a .jpg file with Draw to display data but IE would not refresh it when it changed but retained the same file name).  Ideally I wish everyone would switch to Firefox but I know this isn't going to happen with the average web user.  Microsoft's tech support site has proven fairly useless in resolving these problems.  Is there a book anyone can recommend that will tell me how IE handles web pages internally?

   In the mean time does anyone have any suggestions on how we solve this display problem in a way that makes IE happy?

Mike Petitjean
Lodi Computer Services, Inc.

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: IE and the <pre> Tag
« Reply #3 on: November 16, 2007, 04:48:56 AM »
Hi Mike,

sounds like you have columns inside columns etc, and getting the html just right (and specifically the css just right) can take some time.

you can set the width of a column specifically using css, but you need to get it "all" right.

incidentally instead of <pre>  </pre> for hard-coding spaces, you can use

&#160;
which displays as a blank space.
(ie it's a "space" character that doesn't "contract".

Cheers
Bruce