15405 - :root element stretches vertically to fit viewport [BG] (grows)

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Hixie (not reading bugmail)]

The root element is stretching to fit the viewport if its contents are smaller
than the height of the viewport. It should not.

According to CSS2, section 9.1.2:
# The height of the initial containing block may be specified with the
# 'height' property for the root element. If this property has the value
# 'auto', the containing block height will grow to accommodate the document's
# content.

The initial value is 'auto', and so the height of the root element should
shrinkwrap the contents. Currently we are using the maximum of either the
content height or the viewport height.

There is an HTML test page for this:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/background/17.html
...and an XML version:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/background/18.xml

[cc'ing David. David, I'm only 99% sure that about this; I found it by
accident. Section 14.2¶3 (see bug 7656, bug 13473) would tend to suggest that
this is indeed a bug, though. Do you agree?]

Comment 1

[troy]

No, I don't agree. We used to do what you describe, but that broke backwards
compatibility for HTML documents because then the background wasn't
being displayed.

So the solution, which I don't think you agree with _how_ this was done, was to
make sure that the document element's frame is sized to cover the canvas

Comment 2

[Hixie (not reading bugmail)]

Right, but according to section 14.2 paragraph 3 of CSS2, the root
element's *background* (and not its *box*) covers the canvas anyway:

# The background of the box generated by the root element covers the
# entire canvas.

Note that it says _background_ not box! The box is sized as per 9.1.2, and then
the background -- in this special case -- is spilt straight out of the box and
covers the canvas. (Note that this does NOT mean that you just paint over the
margins of the root element as the bottom margin won't reach the bottom of the
viewport, and the margins won't cover anything sticking out of the left/right of
the viewport.)

So the spec-compliant solution is to follow both these rules -- section 9.1.2
and section 14.2 -- and then you get full backwards compatability to boot.

Comment 3

[troy]

What you suggest may be more correct (although I'm dubious), but we're not doing
it. It's reasonable the way it is now, and it's way too late for version 1.0 to
be making changes to how the viewport model works

Comment 4

[Hixie (not reading bugmail)]

Ok. I'm going to mark this LATER, we can reargue it once 1.0 is out.

David: When the WaSP review Mozilla, this may have to be the one thing we
complain about... ;-)

Comment 5

[troy]

I think that part of the CSS2 spec needs to be reconsidered. It's horrible to
have so many exceptions to the normal rules. We have to reverse propagate the
BODY's background up to the HTML element which is bad enough, and to to have to
special case the document element's background is even worse

It sure looks like the CSS authors spent all of about 5 seconds writing that
part of the spec...

Comment 6

[Hixie (not reading bugmail)]

Actually, we currently have as many special cases as we would if we changed to
the spec way -- currently, we special case the height of the root element, which
the spec way doesn't do (the root element acts as a simple block box). The only
special case in the spec is the fact that the root element bg spills into its
containing block, the canvas. So we would just be exchanging one special case
for another. A spec compliant one... :-)

Comment 7

[troy]

The document element's box isn't necessarily a block. It could be an inline, a
table, a list item, or anything for that matter. At least I don't think the spec
precludes it

Yes, what we're doing today probably isn't what the spec wants, but it's easy
and clean to implement. All we do have the root frame (that corresponds to the
'canvas') make sure it's child frame covers the canvas

Then the rendering just works.

The problem with not doing it this way is that the document element's box is
small, and _somehow_ we need to make sure that when it renders it paints over
the entire canvas

I say _somehow_ because that certainly isn't the normal CSS behavior. Normally
a box paints the background over its content and padding areas only, and not
outside of its box.

Because the document element isn't necessarily a 'block' that means this quirky
behavior isn't limited to just one occurence, and each and every frame class
that could be used for the document element's box needs to be able to do this.

What about the case where the document element has a fixed height and 'overflow'
set to 'scroll' or 'auto'. How does the background render in that case? Does it
behave like a 'fixed' background attachment, or does the background change as
the document element is scrolled? If so, then does the background that's
splattered out onto the canvas need to repaint as well, or does it get out of
sync?

If they want it to cover the canvas then I think I would prefer if they said
that the 'canvas' should render the background. Much like they've done with the
BODY's background being moved to the HTML element and it renders it

And what if the document element is positioned? I think the spec currently
forbids that, but I seem to remember that you would like that. If it's
positioned should it still paint over the entire canvas? That seems kind of odd
as well

That's just the beginning of the woes with this approach. From an implementation
perspective we currently have all sorts of other issues:

- how does the document element's frame even know how much to paint? When we
paint we intersect the dirty rect with the frame's box and tell it that's what
it needs to paint. In this case that won't be true, because it needs to paint
the canvas as well

- if the document element's frame has a view, e.g., it has opacity, it's
positioned, ..., then the view code won't let it paint outside of its view. That
means we will need to size the view to be the same size as the canvas in order
for it to paint outside its view

There are all sort of issues that this quirk exposes.

Comment 8

[Hixie (not reading bugmail)]

> The document element's box isn't necessarily a block. It could be an
> inline, a table, a list item, or anything for that matter. At least
> I don't think the spec precludes it.

No, nothing does preclude it, AFAICT (David?). And we don't support
it. Oops. This issue is now covered by bug 15462.


> I say _somehow_ because that certainly isn't the normal CSS
> behavior. Normally a box paints the background over its content and
> padding areas only, and not outside of its box.

True. But then normally a CSS box does not size it self to the size of
the viewport either, and yet we are doing that.


> Because the document element isn't necessarily a 'block' that means
> this quirky behavior isn't limited to just one occurence, and each
> and every frame class that could be used for the document element's
> box needs to be able to do this.

Hmm. Surely (hah!) what you could do is just make the canvas paint
itself with the background offset so that its start position is the
same (in window coordinates) as the start of the root element's
position. That way the root element doesn't have to paint outside
itself, it only has to inform the canvas that it has changed.


> What about the case where the document element has a fixed height
> and 'overflow' set to 'scroll' or 'auto'. How does the background
> render in that case?

Interesting point. It is not covered by the spec. I would say that the
canvas would have to move its background too, to keep it in sync with
the root element's. That, though, is no bigger a deal than dynamically
changing the value of 'background-position' in the same scenario:
background of root is rerendered, so notify the canvas.


> If they want it to cover the canvas then I think I would prefer if
> they said that the 'canvas' should render the background. Much like
> they've done with the BODY's background being moved to the HTML
> element and it renders it.

That would have exactly the same effect, which is fine by me. So long
as in the BODY->HTML case, the _specified_ background values are
`inherited', while with the canvas the _actual_ values are
`inherited'. And making sure that the root element is not made
transparent, like the BODY element is. (Because otherwise you are open
to weirdness with 'z-index'.)


> And what if the document element is positioned? I think the spec
> currently forbids that, but I seem to remember that you would like
> that. If it's positioned should it still paint over the entire
> canvas? That seems kind of odd as well.

Well, if we implement it as the canvas drawing the background in sync
with the root element, then there is no big problem here. (And yes,
the canvas would still use the root element's background.)


> - how does the document element's frame even know how much to paint?
> When we paint we intersect the dirty rect with the frame's box and
> tell it that's what it needs to paint. In this case that won't be
> true, because it needs to paint the canvas as well.

Well, if you let the canvas paint itself in sync with the root
element, you could `just' trigger an event when the root element
paints it's background.


> - if the document element's frame has a view, e.g., it has opacity,
> it's positioned, ..., then the view code won't let it paint outside
> of its view. That means we will need to size the view to be the same
> size as the canvas in order for it to paint outside its view.

Not if you just get the canvas to paint in sync; then you just need to
make sure the canvas is notified.

Comment 9

[troy]

My main point was to emphasize that the way the spec is defined now it seems
like they expect the document element's box to splat its background over the
cancas, and that opens up a whole can of worms

Comment 10

[Hixie (not reading bugmail)]

I don't disagree, but I believe you can get exactly the same effect by simply
deferring the painting to the canvas itself, and just keeping the background
positions in sync. The effect is identical, but the implementation is a lot
easier (relatively speaking, anyway). Right?

Comment 11

[troy]

Maybe. I would be more comfortable implementing this if the spec were clearer
and address cases like where the document element is scrollable.

Otherwise, these kind of changes tend to consume a lot of time and often require
several iterations to get it right

Comment 12

[Hixie (not reading bugmail)]

Agreed, that's why I marked it LATER.

Comment 13

[Christine Hoffman]

Verified bug LATER.

Comment 14

[Hixie (not reading bugmail)]

Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 15

[troy]

Reopening bug

Comment 16

[troy]

Part of the bug has been fixed. I changed the frame construction code to 
propagate the document element's backgroun to the canvas so that the background 
is rendered to cover the entire canvas

Comment 17

[troy]

Eric, the remaining problem is that the document element is getting sized to 
large. The problem is because when the canvas frame is reflowed it is given a 
constrained computed width instead of NS_AUTOHEIGHT like it should get

What seems to be happening is that the gfx scrollbar code which does get 
reflowed with a constrained computed height is passing that constrained height 
along to the canvas frame instead of giving it NS_AUITOHEIGHT like it should 
get.

Comment 18

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is the CanvasFrame the same as the root element?  If you've just started
propagating the background color of the root element to the canvas, I'd think
not...  But if that's the case, what should happen is that the canvas should
fill the viewport, and the root element shouldn't.

If the only changes you (troy) made today were in the background-color
propogation, then I think the current behavior is 100% correct.  I'll have to
check tomorrow's build against
http://www.people.fas.harvard.edu/~dbaron/css/test/rootbox

Comment 19

[troy]

Yes, RootFrame has now been renamed CanvasFrame. The old name made sense when it 
really was the root frame (i.e., the top-most frame that had no parent), but 
that hasn't been true for ages since we added the viewport and viewport scroller

And yes, now we reverse propagate the document element's background to the 
canvas. That way we can satisfy section 14.2 of the CSS2 spec that says that the 
document element's background should cover the entire canvas.

And yes again, I agree that the document element's box should not fill the 
entire canvas. That was what I had attempted to do a long time ago in order to 
have the document element's background cover the canvas

But you and Ian convinced me that was wrong. Unfortunately, the gfx scrollframe 
code is causing the document element's frame to be sized to the viewport size 
which is bad and that's why the bug is now assigned to Eric. So the remaining 
problemn can be fixed

Comment 20

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Oops - never mind.  Somehow I was convinced that Mozilla displayed the test I
mentioned in my previous comment differently from the way it really does...

Comment 21

[Eric Vaughan]

*** This bug has been marked as a duplicate of 35681 ***

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This one isn't fixed completely.  Reopening from duplicate.  Bug 35681 covered 
horizontal issues, which are now fixed.   I'm reopening this bug, which was 
really about vertical issues to begin with.

Comment 23

[Hixie (not reading bugmail)]

As per meeting with ChrisD today, taking QA.

Comment 24

[Peter Trudelle]

nsbeta3-, don't see dire need to hold ns6 for this bug.

Comment 25

[Hixie (not reading bugmail)]

Note: MacIE5 does this right.

Comment 26

[Hixie (not reading bugmail)]

Bug 57906 is now tracking the horizontal issues.

Comment 27

[Hixie (not reading bugmail)]

*** Bug 57682 has been marked as a duplicate of this bug. ***

Comment 28

[Peter Trudelle]

->moz1.0

Comment 29

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 30

[Asa Dotzler [:asa]]

don't move bugs that are in the 1.0 dependency tree. sorry.

Comment 31

[Greg K.]

The behavior Ian describes is also observed using FizzillaCFM/2002070913.
Setting All/All.

Comment 32

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

See bug 157698 for a somewhat interesting testcase (although quite confused by
other issues as well).

Comment 33

[Hixie (not reading bugmail)]

->boris for fun

Comment 34

[Christopher Hoess (gone)]

css1->css2, since CSS2 section 14.2 has been cited throughout the bug...

Comment 35

[Hixie (not reading bugmail)]

It's still a CSS1 bug, even if we refer to CSS2.

Comment 36

[Garrett Smith]

comment 7 The document element's box isn't necessarily a block.

Block level elements can't be contained by inline elements. That means body must
be inline, too. It is not something that really needs to be done. It does not
seem that it will be of any practical use.

It is conceiveable that html could be block-table, body could be table-row, and
a div inside the body could be table cell. Stupid idea, though.


In addition to background-color, all other background properties should be
propagated to the canvas.

background
 - background-color
 - background-image
 - background-repeat
 - background-attachment
 - background-position
 - background-positionX
 - background-positionY


comment 7
What about the case where the document element has a fixed height and 'overflow'
set to 'scroll' or 'auto'. How does the background render in that case? Does it
behave like a 'fixed' background attachment, or does the background change as
the document element is scrolled?

It is fixed to the canvas. The background of the box generated by the root
element covers the entire canvas. 

If the value of the 'background' property for the HTML element is different from
'transparent' then use it, else use the value of the 'background' property for
the BODY element.. Let body override this. See 14.2 The background:
http://www.w3.org/TR/REC-CSS2/colors.html#q2

Comment 8 "making sure that the root element is not made
transparent, like the BODY element is. (Because otherwise you are open
to weirdness with 'z-index'.)"

I don't see what could go wrong. body inherits stacking order from root. What's
the problem? 


> - if the document element's frame has a view, e.g., it has opacity,
> it's positioned, ..., then the view code won't let it paint outside
> of its view. That means we will need to size the view to be the same
> size as the canvas in order for it to paint outside its view.

The initial containing block cannot be positioned or floated (i.e., user agents
ignore the 'position' and 'float' properties for the root element).
http://www.w3.org/TR/REC-CSS2/visuren.html#q2

"initial containing block" is defined as the root. Given the fact that this
definition is incorrect, it is up to the mystics (David Baron, Ian Hickson, et
c.) to determine what the above statement means. It would be impossible to
position the initial containing block, but it would not be impossible to
position the root element, although this may be illegal. The question is: What
is meant by "initial containing block" in the above referenced statement?

Before getting too caught up in "all kinds of issues," lets get our terms
straight (as opposed to CSS 2 spec, which is not).

Comment 37

[Boris Zbarsky [:bzbarsky]]

> Block level elements can't be contained by inline elements. 

This is a statement about HTML, not CSS.  The concepts of "block and inline" 
are subtly different in HTML and CSS; this is one of the really major 
differences.  A CSS inline can most certainly contain a CSS block.

> The background of the box generated by the root element covers the entire
> canvas. 

It should not.  That's precisely what this bug is about.

The positioning issue is a side issue; the root element can certainly have 
opacity set and that will lead to the same problem with painting...

Comment 38

[Garrett Smith]

14.2 The background

"The background of the box generated by the root element covers the entire canvas."
 
--------------------

Test:
1) go to: http://www.people.fas.harvard.edu/~dbaron/css/test/rootbox
2) maximize window
3) choose view -> Text Zoom -> 50%

Actual Result: html's height is stretched so that it's content area is expanded.
The border is always at the edge of the initial containing block.

Expected Result: html's height should be the distance from the top border-edge
of the body, to the bottom border-edge of the body. 
http://www.w3.org/TR/REC-CSS2/visudet.html#the-height-property

-----------------

From initial report 
"The initial value is 'auto', and so the height of the root element should
shrinkwrap the contents."

Correct.

-----------

comment 37
"A CSS inline can most certainly contain a CSS block."

"unless the element is absolutely positioned, the containing block is formed by
the content edge of the nearest block-level ancestor box."
 (10.1 http://www.w3.org/TR/REC-CSS2/visudet.html#containing-block-details )

body{display: block} 
html{background: #eee;display:inline }
body should appear outside of the HTML element. 
The canvas should have a background color of #eee;

Comment 39

[Boris Zbarsky [:bzbarsky]]

Please don't confused "contained in" and "containing block".... The body would 
appear in between two of the line boxes of <html> in your example (and the 
canvas background would be #eee).  None of which addresses the original concern 
Troy expressed, as far as I can see (though the concern may have been specious).

Comment 40

[Hixie (not reading bugmail)]

The ICB is a box the size of the viewport anchored at the origin. The root
element is just a normal block box anchored at 0,0 in the ICB.

Anyway, this bug is still valid, and unambiguous, just as it was over three
years ago when I filed it...

Comment 41

[Garrett Smith]

Regarding Comment 40,
The root has a few other properties that make it special. The CSS 2 spec is very
ambiguous about this whole area. This is also evidenced in some of the comments
that were made. 

The bug is absolutely valid; no doubt about it. My additional comments and the 
replies they prompted are important because they show how much misunderstanding
there is about this. 


10.1
"If there is no such ancestor, the content edge of the root element's box
establishes the containing block."

So absolutely positioned elements that have no containing block will use the
root as a containing block. This is evidenced in
http://dbaron.org/css/test/sec090102
If the root were "just a box in normal flow," then the absolutely positioned
divs would have to use the ICB, unless the root had absolute positioning. It is
my opinion that the root should be in normal flow and that user agents should
allow such behavior. User-Agents should also use position: absolute in the
default stylesheet, so that stuff would work just like it does in the
aforementioned test case.

Comment 42

[Garrett Smith]

Regarding Comment 40,
The root has a few other properties that make it special. The CSS 2 spec is very
ambiguous about this whole area. This is also evidenced in some of the comments
that were made. 

The bug is absolutely valid; no doubt about it. My additional comments and the 
replies they prompted are important because they show how much misunderstanding
there is about this. 


10.1
"If there is no such ancestor, the content edge of the root element's box
establishes the containing block."

So absolutely positioned elements that have no containing block will use the
root as a containing block. This is evidenced in
http://dbaron.org/css/test/sec090102

If the root were "just a box in normal flow," then the absolutely positioned
divs would have to use the ICB, unless the root had absolute positioning. It is
my opinion that the root should be in normal flow and that user agents should
allow such behavior. User-Agents should also use html{position: absolute;} in
the default stylesheet, so that stuff would work just like it does in the
aforementioned test case.

You can try typing this into the location bar of the test case:
javascript:void(document.documentElement.style.position='static'); It has no effect.

Comment 43

[Hixie (not reading bugmail)]

Please refer to CSS2.1, not CSS2, when examining containing block issues.

Comment 44

[Boris Zbarsky [:bzbarsky]]

No plans to work on this any time in the foreseeable future, so to default owner.

Comment 45

[Boris Zbarsky [:bzbarsky]]

*** Bug 234039 has been marked as a duplicate of this bug. ***

Comment 46

[Boris Zbarsky [:bzbarsky]]

Fixed by checkin for bug 241694.