In case anyone hasn't seen this problem, just sharing the info....
I created a dotnet 1.1 page with a literal control. I used a
streamreader to open a text file to fill the control. I filled the
control on page load.
When viewing the page in IE 6.0, sometimes the literal control did not
display all of the text. Refreshing the page (via browser refresh
button) would cause random results; sometimes more text, sometimes less
(whole paragraphs missing), sometimes partial height lines, etc.
At first, I thought this was some kind of buffering problem, or a
timing issue with the streamreader. Then I tested with Netscape 7.1 and
Mozilla 1.75 - same pages displayed perfectly with no problem.
The true problem was the old and well-known IE positioning bug.
Essentially, as I understand it, it boils down to a "div" element that
doesn't have a fixed size (height/width); IE has trouble displaying
them. The Literal Text control renders as a "div" element. When I
applied the "Hollyhack" fix
(http://www.positioniseverything.net/...ollyhack.html), the
problem VANISHED.
In case the above link breaks, here is the relevant section from the
Hollyhack page:
*******************************************
"....The following code is an instance of the Holly hack. Primarily,
the Holly hack consists of a set of hiding methods wrapped around that
1% height, which is the key to the hack. Remember, the whole idea is to
let IE/Win and only IE/Win see that height and apply it to the buggy
box.
/* Hides from IE5-mac \*/
* html .buggybox {height: 1%;}
/* End hide from IE5-mac */
Code Block 1
Two Hacks in One: The first line of code is a CSS comment with an
"escape" (colored red) just before the comment closing tag. The
presence of that escape character causes IE5/Mac to ignore the closing
tag of the comment, and think that the comment is still active. Thus,
it ignores everything until it sees what it thinks is a correct CSS
comment closing tag. The last line of the hack is a normal CSS comment,
and its closing tag is what lets IE5/Mac begin parsing code again. We
generally refer to these two lines (the top and bottom in the above
code box) as the "Mac-hack," but it is also referred to as a
"comment-backslash hack."
The second, or middle line, has, in this example, three items separated
by descendant combinators, which are the spaces you can see, and then
the height property within curly brackets. First item is a universal
selector or star, * , which selects any element, followed by html
(both also in red), followed by the element suspected to have the bug.
The above code selects an element with the class attribute of buggybox
that is a descendant of an html element, (which will always be
true), when html itself is a descendant of any element (*), and
applies a {height: 1%} to that element, in this case, .buggybox.
It so happens that all IE browsers, both Win and Mac, recognize an
invisible and mysterious wrapper element around <html> . The use of
the universal selector preceding html , also known as the Tan Hack (or
Star HTML Selector Bug), works in IE browsers and nowhere else. Thus,
the reason for using the "Mac-hack" is to prevent IE5/Mac from seeing
this height just as other browsers are, because it does not wrongly
enlarge the box like IE/Win, but it does read the Tan hack.
Note that the element to be given the height need not be classed. Any
valid selector may be inserted instead of .buggybox, and even entire
strings using descendant combinators may be used there. What really
matters is that * html must always precede whatever target element is
to be fixed, and that the * and html have a space between them,
followed by another space, and then the target element. ...."
****************************************
Hope this saves someone the 2 hours it took me to find the solution.
Thanks to the folks who created the Hollyhack, and who wrote google
articles pointing me to it.
Nancy Steinmann
MCSD .NET