Open
Bug 157698
Opened 22 years ago
Updated 2 years ago
[QUIRKS] whitespace trailing image leads to space at end of root element
Categories
(Core :: Layout: Block and Inline, defect, P4)
Tracking
()
NEW
Future
People
(Reporter: Jos.vandenOever, Unassigned)
References
()
Details
(Keywords: compat)
Attachments
(4 files)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529
BuildID: 2002052918
A <html> element with height=100% and margins and paddings of 0 is visible, even
though a body element, also with height=100% and margins and paddings of 0 is
inside it.
The <html> should not be visible. The <html> element has a red background, the
body element has a blue background, the other elements have other colours here.
The body element is not visible.
The big picture in the page also has height=100%, but this should be 100% of the
containing box, which is a <p> element. This element should be smaller than the
<html> element, but the image is scaled to 100% of the viewport/html element.
Reproducible: Always
Steps to Reproduce:
1.visit mentioned page
2.scroll down (strange that this is necessary: height=100%)
3.a red line is visible: this is the <html>
Actual Results: The <html> element is visible as red at the bottom of the page.
This element should not be visible, since the margin and padding of it and the
<body> element it contains are zero.
Expected Results: The <html> should not be visible.
Comment 1•22 years ago
|
||
This looks like bug 22274 to me -- the page is in strict mode, the <img> has
height 100% of its containing block, the linebox hence overflows said containing
block (since the line box includes space for descenders) and overflows the
<body> too. It can't oveflow the root element (is this correct?) so we get the red.
Assignee: attinasi → dbaron
Reporter | ||
Comment 2•22 years ago
|
||
This, similar, page also fails.
http://www.fenk.wageningen-ur.nl/~oever/veenendaal/test4.html
It's just one image that should be as big as the viewport. It actually is, but
there's still a scrollbar, because the <html> is bigger.
Comment 3•22 years ago
|
||
No, this isn't bug 22274, since the P background is smaller than the BODY
background. I'm not sure why it isn't larger, since the BODY should be limited
to only 100%, I'd think...
Comment 4•22 years ago
|
||
Invalid, I think: a <P> includes a blank line after the last line. Therefore,
since the image is height=100%, the paragraph has overflow because it must be
taller than the image. Therefore, it flows out of the <BODY> tag. The red area
at the bottom is the overflow of the <P>. If you set the <P> to overflow:hidden
it works as you expected.
<P> tags are meant to contain _paragraphs_. <DIV> is the general container tag,
and you don't need the overflow style if you use it.
Comment 5•22 years ago
|
||
No, because the testcases in question turn off margins on the <p>. So comment 4
is bogus. Attaching a few testcases that show what's going on.
Comment 6•22 years ago
|
||
The white border is on the <div>, the blue one is on the <body>, the yellow one
on <html>. <html>, <body>, <div> all have margins and padding set to 0. Note
that the <div> and the <body> are both limited to 100% of the height of the
parent. The image is 100% of the height of the parent as well, but the
_line_box_ containing the image is taller than that (bug 22274). So the line
box overflows the <div> and the <body> and makes the <html> be bigger than the
<body> (not sure what the correct border position is for the bottom border of
the <html> here, but the red space below the image is correct).
Comment 7•22 years ago
|
||
Make sure to view this in a window that's at least 500 px tall; otherwise you
may get space for ascenders at the top.
Comment 8•22 years ago
|
||
This shows that it's indeed the line box that's the issue. Again, use a window
at least 500px tall.
Comment 9•22 years ago
|
||
So in summary, I believe that the observed rendering is correct (modulo the
placement of the bottom border of <html>).
Comment 10•22 years ago
|
||
So should this be WFM ?
Reporter | ||
Comment 11•22 years ago
|
||
A new example: I've replaced the <p> by a <div> and removed the height=100%
attibute for the image.
http://www.fenk.wageningen-ur.nl/~oever/veenendaal/test5.html
http://www.fenk.wageningen-ur.nl/~oever/veenendaal/foto5.css
The image is still 100% of the viewport, but now the height of the image is
inferred from the other elements. <html>, <body> and <div> are all set to 100%.
Still, the red line at the bottom is visible. This means the height of the image
is not correct. It should be adapted to make sure the <div> does not overflow
it's parent.
What else would be the proper way to have an image the height of the viewport.
Surely the specs should allow for something like this.
Comment 12•22 years ago
|
||
The test5.html testcase sets the image height to "100%". That's what we set it
to. The space is _not_ part of the image, and hence should not affect the image
height.
> What else would be the proper way to have an image the height of the viewport.
Make the image a block (instead of an inline), since you want it to act as a
block. Or see the third testcase I attached (which is not as effective a
method, as the comments about 500px show). Also, see bug 22274, which I keep
mentioning -- that explains the issues in great detail.
Reporter | ||
Comment 13•22 years ago
|
||
Thanks for your comments, Boris.
Now I understand and agree with you explanation. I've also managed to change the
test5.html to do what I want.
Sorry for sumitting a duplicate bug. Well, I guess CSS is tough stuff.
Comment 14•22 years ago
|
||
dupe of bug 133352 ?
Comment 15•22 years ago
|
||
http://www.w3.org/TR/REC-CSS2/visuren.html#q5
Inline-level elements are those elements of the source document that
do not form new blocks of content; the content is distributed in
lines (e.g., emphasized pieces of text within a paragraph, inline
images, etc.). Several values of the 'display' property make an
element inline: 'inline', 'inline-table', 'compact' and 'run-in'
(part of the time; see compact and run-in boxes). Inline-level
elements generate inline boxes.
Inline boxes may participate in several formatting contexts:
- Within a block box, an inline boxes participate in an
*inline formatting* context.
- A compact inline box is given a position in the margin of a block
box.
- Marker boxes are also given positions outside of a block box.
http://www.w3.org/TR/REC-CSS2/visuren.html#inline-formatting
9.4.2 Inline formatting context
In an inline formatting context, boxes are laid out horizontally,
one after the other, beginning at the top of a containing block.
Horizontal margins, borders, and padding are respected between
these boxes. The boxes may be aligned vertically in different
ways: their bottoms or tops may be aligned, or the baselines of
text within them may be aligned. The rectangular area that contains
the boxes that form a line is called a line box.
The width of a line box is determined by a containing block.
*The height of a line box is determined by the rules given in the
section on line height calculations*. A line box is always tall
enough for all of the boxes it contains. However, it may be taller
than the tallest box it contains (if, for example, boxes are
aligned so that baselines line up). When the height of a box B is
less than the height of the line box containing it, the vertical
alignment of B within the line box is determined by the
'vertical-align' property.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Summary: height=100% is ignored for html element → image (img) css height=100% is ignored (incorrect height) (inline vs block element)
Comment 16•22 years ago
|
||
I agree, after another look, that the bug is invalid -- the height: 100% plus a
5px border on each element makes its border-edge the same size as the
border-edge of its parent, which means its bottom border should be below the
bottom border of its parent.
There are, however, one, and possibly two bugs shown by the testcase:
* the first is that borders on the root element expand based on the
children of the root element rather than being drawn on the correct box.
This is bug 15405. Note that the fix to this bug would change the
position of the border but not the background, since the background of
the root element is drawn on the canvas.
* The second is that there may be some incompatibilites in the handling of
final whitespace between Mozilla and other browsers. However, I'm not one
to start investigating compatibility issues presented by an obscure
theoretical testcase.
Comment 17•22 years ago
|
||
Updated•22 years ago
|
Severity: normal → minor
Status: RESOLVED → UNCONFIRMED
Priority: -- → P4
Resolution: INVALID → ---
Target Milestone: --- → Future
Comment 18•22 years ago
|
||
Actually, when I was writing comment 16, I was thinking that the first
attachment was associated with the reporter's description, when I should have
been looking at the URL field, so my comments about borders don't make sense.
That said, this is a pretty obscure issue, since the normal authoring practice,
and one that mostly avoids this issue, is to specify the background only on the
BODY.
However, I actually think there is a remaining issue -- whether we should be
expanding the scrollbars for the empty (i.e., all-whitespace) text frame at the
end of the image in quirks mode (which is what's causing the whitespace to
appear), and I think that issue is valid, although low-priority.
(Note that the default margins of P have nothing to do with it since the
stylesheet on the page in question overrides them.)
Reopening -> P4/minor/Future.
Comment 19•22 years ago
|
||
Updated•22 years ago
|
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Comment 20•22 years ago
|
||
(One reason that I actually care about that quirks-mode code in this case is
that we'll probably be using it to implement the CSS3 line-box-contain or
line-box-policy or whatever version ends up in the final version of css3-box.)
Updated•22 years ago
|
Summary: image (img) css height=100% is ignored (incorrect height) (inline vs block element) → whitespace trailing image leads to space at end of root element
Updated•22 years ago
|
Component: Layout → Layout: Block & Inline
Comment 21•21 years ago
|
||
This is a quirks mode bug right?
Keywords: compat
Summary: whitespace trailing image leads to space at end of root element → [QUIRKS] whitespace trailing image leads to space at end of root element
Comment 22•21 years ago
|
||
if the first attachment is exposing it ... and its rendering in standard
compliance mode ... it aint quirks then !?
Comment 23•21 years ago
|
||
Michael Gabriel, see comment 18. The rendering of the first attachment is in
fact correct.
Updated•15 years ago
|
QA Contact: chrispetersen → layout.block-and-inline
Updated•4 years ago
|
Assignee: dbaron → nobody
Status: ASSIGNED → NEW
Updated•2 years ago
|
Severity: minor → S4
You need to log in
before you can comment on or make changes to this bug.
Description
•