Closed
Bug 59837
Opened 25 years ago
Closed 18 years ago
{ib} body { display: inline } causes contents to dissapear
Categories
(Core :: Layout: Block and Inline, defect, P1)
Core
Layout: Block and Inline
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: ppmozilla, Unassigned)
References
()
Details
(Keywords: css1, testcase, Whiteboard: [CSS1-5.6.1])
Attachments
(6 files, 1 obsolete file)
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (Win98; U)
BuildID: 2000110904 (or 20001102?? or M18 or M17)
Will not render the page (except bgcolor), but it pass all tests at W3C org (
http://validator.w3.org/ ). And it works for Communicator 4.75 and IE 5.
Documented as png's at:
http://tberg.net/MOZILLA/tbergMozilla.png and
http://tberg.net/MOZILLA/tbergNavigator.png and
http://tberg.net/MOZILLA/tbergValidator.png and
http://tberg.net/MOZILLA/tbergValidator2.png and
http://tberg.net/MOZILLA/tbergValidator3.png
%Referer:
|
||
Comment 1•25 years ago
|
||
The problem seems to be that the display attribute of body is set to inline.
Commenting out that one line in the stylesheet fixes the problem.
What should our behavior be when we run into BODY { display: inline }?
Assignee: asa → pierre
Component: Browser-General → Style System
QA Contact: doronr → chrisd
|
|
Reporter | |
Comment 2•25 years ago
|
||
Sorry, some of the png addresses are wrong, where ...Validator.. is there should
be:
http://tberg.net/MOZILLA/w3cValidation.png and
http://tberg.net/MOZILLA/w3cValidation2.png and
http://tberg.net/MOZILLA/w3cValidation3.png
Thomas
|
|
Reporter | |
Comment 3•25 years ago
|
||
I have removed BODY { display: inline } from the stylesheet now (Thank you
Boris!). Thomas
|
||
Comment 4•25 years ago
|
||
Confirming, though I don't really get what display:inline would do in a BODY.
|
|
||
Updated•25 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Could someone please attach a testcase?
Hixie: so what should that css do?
Clarifying summary.
Severity: major → normal
Keywords: qawanted
QA Contact: chrisd → ian
Summary: Will not render the page (except color). → Page content w/ css[BODY { display: inline }] does not render
|
|
||
Comment 6•25 years ago
|
||
|
|
||
Comment 7•25 years ago
|
||
|
|
||
Comment 8•25 years ago
|
||
In testcase #2, the body tag only contains inline children and is rendered
correctly.
Also changing OS -> ALL, since I see this on Linux.
OS: Windows 98 → All
|
||
Updated•25 years ago
|
Hardware: PC → All
|
|
||
Comment 9•25 years ago
|
||
Setting <body> to display:inline is perfectly valid and should do the same as
setting a <div> to display:inline. Testcase and ref rendering coming up.
Assignee: pierre → buster
Summary: Page content w/ css[BODY { display: inline }] does not render → body { display: inline } causes contents to dissapear [INLINE]
|
|
||
Comment 10•25 years ago
|
||
|
|
||
Comment 11•25 years ago
|
||
|
|
||
Updated•23 years ago
|
Whiteboard: [CSS1-5.6.1]
|
|
||
Comment 14•23 years ago
|
||
So.. Here is what's up. We create the <body> frame quite early, apparently. So
early that at that point the body nsIContent children. This means that
ProcessInlineChildren will say that all the children (of which there are none)
are inline. Thus the body does not get marked as "special", and appending
blocks to it doesn't do any of the magic fixup that should happen.
So one solution (the one that seems correct) is to have ContentInserted() and
ContentAppended() for a non-special inline frame check whether the frames that
are being inserted are blocks and if so mark the frame special and reframe the
whole thing.... Does that seem reasonable?
|
|
||
Comment 15•23 years ago
|
||
Will this fix bug 15462 too?
|
|
||
Comment 16•23 years ago
|
||
Most likely, yes.
By the way, Comment 14 meant to say "the body nsIContent has no children", not
"the body nsIContent children."
|
|
||
Comment 17•23 years ago
|
||
Ugh. So even if the <body> frame is special things don't work... We call
ReframeContainingBlock() on the body frame, which looks for the body's
containing block, and reframes it. Do do this it gets the containing block's
nsIContent, gets that nsIContent's parent and "oops", there is no parent. So it
can't pull its ContentReplaced(aPresContext, parentContainer, blockContent,
blockContent, index) trick because there is no parentContainer -- the
blockContent is the <html> element in this case. Needless to say, bug 15462
will break one step earlier in this sequence of events....
|
|
||
Comment 18•23 years ago
|
||
Heh. And if we have no parent block we do:
return RecreateEntireFrameTree(aPresContext);
and here is the gem:
nsresult
nsCSSFrameConstructor::RecreateEntireFrameTree(nsIPresContext* aPresContext)
{
// XXX write me some day
return NS_OK;
}
|
|
||
Comment 19•23 years ago
|
||
This fixes ReframeContainingBlock() to use the right thing to blow away the
whole frame tree and fixes the code in ContentAppended() to check _all_ the
appended content.
If I now force the <body> frame to be marked special the testcase renders
correctly. We don't always want it to be special, however.... so that's not a
very good approach.
|
|
||
Comment 20•23 years ago
|
||
might as well take this..
Assignee: attinasi → bzbarsky
Priority: P3 → P4
Target Milestone: mozilla1.1alpha → Future
|
|
||
Comment 21•23 years ago
|
||
If I add display:inline; to the CSS "*" tag, the page breaks up and the contents
of the CSS file are displayed!
Take the line out and the layout is perfect.
I'm on Mozilla 1.2, PC, Win98.
Here is the code. Check in IE6 to see what it should look like. (Sorry, can't
upload this as an attachment on this computer.)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<nolayer>
<style>
* {font-family:verdana;
font-size:12px;
display:inline;}
body {
margin: 10px 10px 0px 10px;
background-color: #fff;}
td {border: solid 1px #999;
vertical-align:top;}
td, th {background-color: #eee;}
a {font-family:verdana;
font-size:12px;
font-weight:bold;
color:#039;
line-height:16px;
text-decoration:none;}
a:hover {color:#08f;}
img {vertical-align:top;}
.heading {font-weight:bold;
color:#636;
text-decoration:none;
text-align:center;
border-bottom:1px solid #aab;}
</style>
</nolayer>
</head>
<body>
<table align="left" cellpadding="8" border="0">
<tr><td><div style="width:140px; height:300px">
<div class="heading">SECTION 1</div>
<p><a href="http://www.mozilla.org">Link 1</a></p>
<p><a href="http://www.mozilla.org">Link 2</a></p>
<p><a href="http://www.mozilla.org">Link 3</a></p>
</div>
</div></td>
<td><div style="width:140px; height:300px">
<div class="heading">SECTION 2</div>
<p><a href="http://www.mozilla.org">Link 1</a></p>
</div>
</div></td>
<td><div style="width:140px; height:300px;">
<div class="heading">SECTION 3</div>
<p><a href="http://www.mozilla.org">Link 1</a></p>
</div>
</div></td>
</tr>
<tr><td colspan="2">
<b>SECTION 4</b>
<br />Text that goes here
</td>
<td colspan="2"> </td>
</tr>
</table>
</body>
</html>
|
|
||
Comment 22•23 years ago
|
||
> Check in IE6 to see what it should look like.
IE's rendering is wrong here. By default, in Mozilla, <head>, and <style> have
display:none, so they are not shown. You set them to display:inline so we show
them. Nothing wrong with that -- those elements are not in any way special as
far as a CSS browser (Mozilla) is concerned.
Further, that testcase has nothing at all to do with this bug. This bug is
about having something with display:block inside a body that has display:inline.
In your testcase, all the elements are display:inline, so this bug cannot arise.
(Oh, and if IE is not rendering that _exactly_ like Mozilla for the stuff inside
<body> then IE is just plain buggy; our rendering of that part is exactly
correct per CSS spec).
|
|
||
Comment 23•23 years ago
|
||
Originally the effect occured when I added display:inline; to the body tag. I
see that now works okay in Moz 1.2. I wasn't aware that <head> and <style> were
elements that could be displayed though. I thought they were only for the
browser to know about internally (and the actual page content existing only in
the <body> section.)
It now looks like IE *isn't* making the cells inline. The text is correctly
displayed. I guess making everything inline was overkill on my part!
|
|
||
Comment 24•22 years ago
|
||
*** Bug 226606 has been marked as a duplicate of this bug. ***
|
|
||
Updated•22 years ago
|
Summary: body { display: inline } causes contents to dissapear [INLINE] → {ib}body { display: inline } causes contents to dissapear [INLINE]
|
|
||
Comment 25•21 years ago
|
||
No plans to work on this any time in the foreseeable future, so to default owner.
Assignee: bz-vacation → dbaron
|
|
||
Updated•21 years ago
|
Priority: P4 → --
Target Milestone: Future → ---
|
||
Updated•21 years ago
|
Summary: {ib}body { display: inline } causes contents to dissapear [INLINE] → {ib} body { display: inline } causes contents to dissapear
|
||
Comment 26•21 years ago
|
||
This is essentially the same as the first testcase, but it enables stylesheet
switching. The word "test" does not initially display, but it does display when
switching to Basic Theme and back to the default Display Inline theme.
Attachment #19117 -
Attachment is obsolete: true
|
||
Comment 27•21 years ago
|
||
*** Bug 266453 has been marked as a duplicate of this bug. ***
|
|
||
Comment 28•20 years ago
|
||
*** Bug 280040 has been marked as a duplicate of this bug. ***
Assignee: dbaron → nobody
Severity: normal → major
Component: Style System (CSS) → Layout: Block and Inline
Priority: -- → P1
QA Contact: ian → layout.block-and-inline
|
|
||
Comment 29•20 years ago
|
||
|
|
||
Comment 30•18 years ago
|
||
Seems to work fine in FF 2.0 and on trunk
Status: NEW → RESOLVED
Closed: 18 years ago
Flags: in-testsuite?
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•