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: