Closed
Bug 49314
Opened 24 years ago
Closed 24 years ago
Setting a DIV to display: none does not cause re-flow
Categories
(Core :: Layout, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: colin, Assigned: karnaze)
References
()
Details
(Keywords: css1, helpwanted, testcase, Whiteboard: (py8ieh: check 2000-10-07 05:25 comment))
Attachments
(3 files)
When setting a DIV to hidden in JavaScript the page should re-flow to look as if
the element was in fact missing, rather than just hide it.
To re-produce on this page:
1 - Click on the arrow to the left of "Fidonet". The sub menu should appear,
and the arrow change from pointing right to pointing down.
2 - Click on the arrow to the left of "Fidonet" again. The sub menu will
disappear, and the arrow change to point right, however the "Resources" menu
directly underneath will not move up as it should do.
3 - Click on the arrow to the left of "Resources". The whole menu will jump up
to fill the gap as it should have done in the first place!
Found using Build ID: 2000081608
Shouldn't you be setting the display attribute?
Try display: none; .
Reporter | ||
Comment 2•24 years ago
|
||
Sorry I should have checked this first: I am in fact setting the display
attribute to make the div hide/show. I set to none to hide it and block to
display it. I've attached the JS file to make it a bit easier to see what is
going on.
Summary: Setting a DIV to hidden does not cause re-flow → Setting a DIV to display: none does not cause re-flow
Reporter | ||
Comment 3•24 years ago
|
||
if you remove COL#twistycol and COL#contentcol, it works. (there appears to be
a little oddity on my end with the fidonet one because the length of the "How to
get on fidonet" link makes the table resize..)
I'm not sure what the bug is here.. (if there is one, or perhaps I am
overlooking something..)
I tried changing COL#twistycol to col.twistycol and using classes in the html,
but the effect is the same.
Reporter | ||
Comment 5•24 years ago
|
||
I'm still pretty sure that this is a bug. I'm not sure why specifying the width
of the table columns would stop the display: none attribute taking.
This did use to work in Mozilla, but it was sometime ago (M15 to M16) that I
last checked that it worked.
Can this bug be moved to NEW if more than one person can see it happening?
Comment 9•24 years ago
|
||
Comment 10•24 years ago
|
||
I attached a simple, working testcase to start building up: given the
information from previous contributors, this looks like something to do with the
COL anyway so I'll start there when I get the chance.
Comment 11•24 years ago
|
||
Looking for help narrowing this down...
Keywords: helpwanted
Whiteboard: {needs narrowed testcase}
Comment 12•24 years ago
|
||
Comment 13•24 years ago
|
||
Once this is fixed, the following bugs visible on the test case should be
reexamined:
* The table cell is narrower when its contents are displayed than when it
has no child frames.
* When the table re-expands after the contents are redisplayed, the table
border has a small gap in it near the top on both sides (and the cell's
border has a hap on the left side).
* The text is not displayed centered vertically in the cell. (There is too
much space at the top of the DIV.)
* The HTML element is not shrink-wrapping (known, filed, bug)
* If the table is made narrow enough to 'wrap the <br>', it actually does so.
(We should be collapsing trailing whitespace.) This actually removes the
vertical alignment problem, suggesting that the <br> is doing weird things.
This is a filed bug (BR should be a normal element like <span/>, and styled
in ua.css.)
* If the table's containing block is made narrower than the cell's specified
width, the cell is shrunk and the table is sized as a normal block with
width:auto would be. This may or may not be correct behaviour, I forget.
Comment 14•24 years ago
|
||
Chris, can you check this out? setting the DIV to display:none causes a reflow
when not in a table cell, but when in a table no reflow happens (see last two
test cases)
Assignee: attinasi → karnaze
Status: ASSIGNED → NEW
Comment 15•24 years ago
|
||
This URL also seems to have div problems.
http://www.icopyright.com/1.528.000099181
Would this be the same bug ?
(needless to say this URL renders sensibly on NS4.X and IE4+5X.)
Comment 16•24 years ago
|
||
Netscape's standard compliance QA team reorganised itself once again, so taking
remaining non-tables style bugs. Sorry about the spam. I tried to get this done
directly at the database level, but apparently that is "not easy because of the
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
Comment 17•24 years ago
|
||
The URL from this bug is no longer available. The two attachments seem to work
as expected for me on Windows 2000, Mozilla build 2001022605. Fixed?
Comment 18•24 years ago
|
||
Seems to WORKSFORME
Platform: PC
OS: Windows 98
Mozilla Build: 2001022620
![]() |
||
Comment 19•24 years ago
|
||
worksforme, linux build 2001-02-25-21. Hixie's testcase does show some of the
bullet point problems (though not all of them), but the reflow is happening
correctly.
Marking worksforme based on comments.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Updated•24 years ago
|
Whiteboard: (py8ieh: check 2000-10-07 05:25 comment)
You need to log in
before you can comment on or make changes to this bug.
Description
•