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

RESOLVED FIXED

Status

()

Core
Layout
RESOLVED FIXED
18 years ago
13 years ago

People

(Reporter: Hixie (not reading bugmail), Unassigned)

Tracking

(Blocks: 1 bug, {css1, testcase})

Trunk
css1, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-P1], URL)

(Reporter)

Description

18 years ago
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

18 years ago
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
(Reporter)

Comment 2

18 years ago
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.

Updated

18 years ago
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WONTFIX

Comment 3

18 years ago
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
(Reporter)

Updated

18 years ago
Status: RESOLVED → REOPENED
Summary: Root element is stretching to fit the viewport → {css1} Root element is stretching to fit the viewport
(Reporter)

Comment 4

18 years ago
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... ;-)
(Reporter)

Updated

18 years ago
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: WONTFIX → LATER

Comment 5

18 years ago
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...
(Reporter)

Comment 6

18 years ago
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

18 years ago
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.
(Reporter)

Comment 8

18 years ago
> 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

18 years ago
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

Updated

18 years ago
QA Contact: petersen → chrisd
(Reporter)

Updated

18 years ago
QA Contact: chrisd → petersen
(Reporter)

Updated

18 years ago
QA Contact: petersen → chrisd
(Reporter)

Comment 10

18 years ago
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

18 years ago
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
(Reporter)

Comment 12

18 years ago
Agreed, that's why I marked it LATER.

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 13

18 years ago
Verified bug LATER.
(Reporter)

Updated

18 years ago
Keywords: css1
(Reporter)

Comment 14

18 years ago
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

17 years ago
Reopening bug
Status: VERIFIED → REOPENED
Resolution: LATER → ---

Updated

17 years ago
Status: REOPENED → ASSIGNED

Comment 16

17 years ago
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

17 years ago
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.
Assignee: troy → evaughan
Status: ASSIGNED → NEW
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

17 years ago
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
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

17 years ago

*** This bug has been marked as a duplicate of 35681 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → DUPLICATE
(Reporter)

Updated

17 years ago
Summary: {css1} Root element is stretching to fit the viewport → Root element is stretching to fit the viewport
Whiteboard: (py8ieh:verify when dup is fixed)
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(Reporter)

Comment 23

17 years ago
As per meeting with ChrisD today, taking QA.
QA Contact: chrisd → py8ieh=bugzilla
(Reporter)

Updated

17 years ago
Keywords: correctness, nsbeta3, testcase

Comment 24

17 years ago
nsbeta3-, don't see dire need to hold ns6 for this bug.
Whiteboard: (py8ieh:verify when dup is fixed) → [nsbeta3-](py8ieh:verify when dup is fixed)
Target Milestone: --- → Future
(Reporter)

Comment 25

17 years ago
Note: MacIE5 does this right.
Keywords: 4xp
(Reporter)

Updated

17 years ago
Whiteboard: [nsbeta3-](py8ieh:verify when dup is fixed) → [nsbeta3-] hit during nsbeta2 standards compliance testing
(Reporter)

Updated

17 years ago
Summary: Root element is stretching to fit the viewport → Root element is stretching to fit the viewport [BG]
(Reporter)

Updated

17 years ago
Blocks: 54661
(Reporter)

Updated

17 years ago
Summary: Root element is stretching to fit the viewport [BG] → Root element is stretching vertically to fit the viewport [BG]
(Reporter)

Comment 26

17 years ago
Bug 57906 is now tracking the horizontal issues.
(Reporter)

Comment 27

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

Updated

17 years ago
Target Milestone: Future → mozilla0.9
(Reporter)

Updated

17 years ago
Keywords: nsbeta3 → nsbeta1
Whiteboard: [nsbeta3-] hit during nsbeta2 standards compliance testing → hit during nsbeta2 standards compliance testing

Comment 28

17 years ago
->moz1.0
Target Milestone: mozilla0.9 → mozilla1.0
(Reporter)

Updated

16 years ago
Whiteboard: hit during nsbeta2 standards compliance testing → [Hixie-P2] hit during nsbeta2 standards compliance testing

Updated

16 years ago
Blocks: 104166
(Reporter)

Updated

16 years ago
Blocks: 103709

Comment 29

16 years ago
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)
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 30

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

Target Milestone: mozilla1.0.1 → mozilla1.0
Blocks: 105286

Comment 31

15 years ago
The behavior Ian describes is also observed using FizzillaCFM/2002070913.
Setting All/All.
OS: Windows 98 → All
Hardware: PC → All
See bug 157698 for a somewhat interesting testcase (although quite confused by
other issues as well).
(Reporter)

Updated

15 years ago
Severity: minor → normal
Summary: Root element is stretching vertically to fit the viewport [BG] → :root element stretches vertically to fit viewport [BG] (grows)
(Reporter)

Comment 33

15 years ago
->boris for fun
Assignee: eric → bzbarsky
Status: REOPENED → NEW
Target Milestone: mozilla1.0 → Future
css1->css2, since CSS2 section 14.2 has been cited throughout the bug...
Keywords: css1 → css2
(Reporter)

Comment 35

15 years ago
It's still a CSS1 bug, even if we refer to CSS2.
Keywords: css2 → css1

Comment 36

15 years ago
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).

> 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

15 years ago
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;

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).
(Reporter)

Comment 40

15 years ago
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

15 years ago
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

15 years ago
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.
(Reporter)

Comment 43

14 years ago
Please refer to CSS2.1, not CSS2, when examining containing block issues.
Priority: P3 → P4
(Reporter)

Updated

14 years ago
Whiteboard: [Hixie-P2] hit during nsbeta2 standards compliance testing → [Hixie-P1]

Updated

14 years ago
Blocks: 228942
No plans to work on this any time in the foreseeable future, so to default owner.
Assignee: bz-vacation → nobody
QA Contact: ian → core.layout
Priority: P4 → --
Target Milestone: Future → ---
*** Bug 234039 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Depends on: 241694
Fixed by checkin for bug 241694.
Status: NEW → RESOLVED
Last Resolved: 17 years ago13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.