<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1400" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Hmmm... most interesting.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Rather than twinking about with the visibility of
each div/row object, (which may leave the borders still showing), I'd suggest
removing the rows completely which you don't want to have appear, and add them
again when the selection criteria so indicates. I've done this on a
production database-lookup utility I wrote a couple of years ago, and it works
slick as snot.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>The only consideration is that if you've got
zillions of rows/columns to repaint, the rebuild of the ordered table may cause
the screen image to sequentially mutate while the column widths change as new
rows are inserted. To beat that problem, I start with a "show everything"
display (much as you do), record the display column widths, and then force the
column width attribute to conform to that initial value. That way the
screen doesn't writhe about as things get repositioned. Believe me, having
all the columns change width on every reselect looks incredibly shabby
(unprofessional, etc. etc.), and this trick lets the original dynamic column
widths define what the subsequent table redraws will use -- the best of both
worlds.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>The other trick which makes for a neater finished
product is to have two layers -- one visible (with a message of the sort "please
wait while we rebuild your table image..."), and a background plane where the
new table is being rebuilt. When the onload event for the back plane
object shows that the new table view is complete, simply change the z-attribute
to bring the back plane to the fore (and vice-versa), and voila! the finished
table reappears. A variation is to leave the original table in view and
use a floating pop-up to alert the user that the new table is being constructed,
and then swap the top table-layer with the bottom just after you trash the
pop-up.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>QED.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>-- Dave Lovering</FONT></DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=paul@dandemutande.org href="mailto:paul@dandemutande.org">Paul
Novitski</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=javascript@LaTech.edu
href="mailto:javascript@LaTech.edu">[JavaScript List]</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, March 26, 2004 3:19
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [Javascript] table collapse
bug in IE6?</DIV>
<DIV><BR></DIV>Thanks for your suggestions, however I had earlier tried
display:none and <BR>found the problem of border ghosts
remains.<BR><BR>Attached is a demonstration of the problem. (Blush: this
is an old <BR>workbench file, not final production code, so please excuse all
the wood <BR>shavings, tools lying about, and old trials commented out in the
mix.)<BR><BR>I imagine that this problem might not SHOW if I use fixed column
widths to <BR>prevent the cell borders from shifting horizontally as rows
appear & <BR>disappear. However, a) I want to solve the problem if I
can, not just work <BR>around it, and b) I balk at pre-determining table
column widths -- I'll do <BR>it if I have to for a specific purpose, such as
matching a table cell with <BR>a contained image of fixed dimensions, but in
general it feels like <BR>intruding on functionality I ought to leave up to
the browser so that I <BR>don't have to try to anticipate future data fill
needs. The looser my <BR>control on rendering niceties, the less I have
to go back and tweak code as <BR>conditions change.<BR><BR>Paul
<P>
<HR>
<P></P>_______________________________________________<BR>Javascript mailing
list<BR>Javascript@LaTech.edu<BR>https://lists.LaTech.edu/mailman/listinfo/javascript<BR></BLOCKQUOTE></BODY></HTML>