[Javascript] table collapse bug in IE6?

[Paul Novitski]

Thanks for your solid comments, Dave.

>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.

I agree completely.  I will tweak my code accordingly.

I have, by the way, rewritten the script to destroy & rebuild the display 
table on each re-select, and of course the phantom borders are no longer a 
problem.  But I'm still curious to know whether they were caused by bad 
coding by me or by Microsoft.  I've haven't seen this bug mentioned on the net.

One clue to the nature of the problem might be that the most persistent 
phantom borders appear to originate in the initial rendering of the 
table.  When I return to the all-records view, none of the phantoms are 
visible (they've either disappeared or they're in alignment with the 
intended cell borders).

Has anyone coded or run across a successful use of this technique, 
modifying a table on the fly by hiding & showing selected rows?  If there's 
a working example I could look at, I'd be grateful.

Paul




At 05:51 AM 3/27/2004, you wrote:
>Hmmm... most interesting.
>
>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.
>
>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.
>
>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.
>
>QED.
>
>-- Dave Lovering
>----- Original Message -----
>From: <mailto:paul at dandemutande.org>Paul Novitski
>To: <mailto:javascript at LaTech.edu>[JavaScript List]
>Sent: Friday, March 26, 2004 3:19 PM
>Subject: Re: [Javascript] table collapse bug in IE6?
>
>Thanks for your suggestions, however I had earlier tried display:none and
>found the problem of border ghosts remains.
>
>Attached is a demonstration of the problem.  (Blush: this is an old
>workbench file, not final production code, so please excuse all the wood
>shavings, tools lying about, and old trials commented out in the mix.)
>
>I imagine that this problem might not SHOW if I use fixed column widths to
>prevent the cell borders from shifting horizontally as rows appear &
>disappear.  However, a) I want to solve the problem if I can, not just work
>around it, and b) I balk at pre-determining table column widths -- I'll do
>it if I have to for a specific purpose, such as matching a table cell with
>a contained image of fixed dimensions, but in general it feels like
>intruding on functionality I ought to leave up to the browser so that I
>don't have to try to anticipate future data fill needs.  The looser my
>control on rendering niceties, the less I have to go back and tweak code as
>conditions change.
>
>Paul
>
>
>----------
>_______________________________________________
>Javascript mailing list
>Javascript at LaTech.edu
>https://lists.LaTech.edu/mailman/listinfo/javascript
>
>_______________________________________________
>Javascript mailing list
>Javascript at LaTech.edu
>https://lists.LaTech.edu/mailman/listinfo/javascript