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)

Product:
Core
Component:
Layout: Block and Inline
Platform:
x86
Linux
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: Jos.vandenOever, Unassigned)

References

(
URL
)

Details

(Keywords: compat)

Attachments

(4 files)

Simple testcase showing the issue
500 bytes, text/html
Details
Same with larger font-size to show that the red space is font-size-dependent
500 bytes, text/html
Details
Same, but with "vertical-align:bottom" on the image
531 bytes, text/html
Details
quirks mode variant of original testcase
835 bytes, text/html
Details
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.
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
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.
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...
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.
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.
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).
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.
This shows that it's indeed the line box that's the issue. Again, use a window at least 500px tall.
So in summary, I believe that the observed rendering is correct (modulo the placement of the bottom border of <html>).
So should this be WFM ?
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.
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.
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.
dupe of bug 133352 ?
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)
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.
(And that ignores the interaction between the bug 5821/bug 22274 issues and the issues in bug 15405.)
Severity: normal → minor
Status: RESOLVED → UNCONFIRMED
Priority: -- → P4
Resolution: INVALID → ---
Target Milestone: --- → Future
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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(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.)
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
Component: Layout → Layout: Block & Inline
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
if the first attachment is exposing it ... and its rendering in standard compliance mode ... it aint quirks then !?
Michael Gabriel, see comment 18. The rendering of the first attachment is in fact correct.
QA Contact: chrispetersen → layout.block-and-inline
Assignee: dbaron → nobody
Status: ASSIGNED → NEW
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: