[Javascript] table collapse bug in IE6?

[David Lovering]

I'd have to say I suspect that the phantom border effect is (at least in
part) a Microsoft artifact.  I was running the absolute latest IE, with the
patches posted as of yesterday, and still saw the borders issues.
Apparently the cell borders are separate objects from the cell contents
(which I've heard is consistant with W3C standards), so this makes some kind
of sense.

If you REALLY want to hide the cells, and not merely nuke/rebuild the rows,
I'd suggest building into your routine a number of CSS attribute calls which
set the border width to 0 on each of the affected cells/rows, making sure
that you still preserve one top/bottom border to "join" the rows which
remain undeleted above and below the one you're taking out.
Correspondingly, when you render the row visible again, you'll have to
restore the border widths to their original values.

Personally, nuking the rows makes sense in another way as well -- every
screen refresh still exercises the "hidden" objects, taking longer than
necessary to paint the window.  I've seen an appreciable speed up when I
trash the unwanted rows, rebuilding them only when necessary.

-- Dave Lovering


----- Original Message ----- 
From: "Paul Novitski" <paul at dandemutande.org>
To: "[JavaScript List]" <javascript at LaTech.edu>
Sent: Saturday, March 27, 2004 9:49 AM
Subject: Re: [Javascript] table collapse bug in IE6?


> 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
>
>
> _______________________________________________
> Javascript mailing list
> Javascript at LaTech.edu
> https://lists.LaTech.edu/mailman/listinfo/javascript
>
>