Closed
Bug 15405
Opened 25 years ago
Closed 21 years ago
:root element stretches vertically to fit viewport [BG] (grows)
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
People
(Reporter: ian, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: css1, testcase, Whiteboard: [Hixie-P1])
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?]
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•25 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.
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•25 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•25 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•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: WONTFIX → LATER
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•25 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... :-)
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•25 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.
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•25 years ago
|
QA Contact: petersen → chrisd
Reporter | ||
Updated•25 years ago
|
QA Contact: chrisd → petersen
Reporter | ||
Updated•25 years ago
|
QA Contact: petersen → chrisd
Reporter | ||
Comment 10•25 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•25 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•25 years ago
|
||
Agreed, that's why I marked it LATER.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 13•25 years ago
|
||
Verified bug LATER.
Reporter | ||
Comment 14•25 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 16•25 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•25 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
Comment 18•25 years ago
|
||
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•25 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
Comment 20•25 years ago
|
||
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•25 years ago
|
||
*** This bug has been marked as a duplicate of 35681 ***
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Updated•25 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)
Comment 22•24 years ago
|
||
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•24 years ago
|
||
As per meeting with ChrisD today, taking QA.
QA Contact: chrisd → py8ieh=bugzilla
Reporter | ||
Updated•24 years ago
|
Comment 24•24 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 | ||
Updated•24 years ago
|
Whiteboard: [nsbeta3-](py8ieh:verify when dup is fixed) → [nsbeta3-] hit during nsbeta2 standards compliance testing
Reporter | ||
Updated•24 years ago
|
Summary: Root element is stretching to fit the viewport → Root element is stretching to fit the viewport [BG]
Reporter | ||
Updated•24 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•24 years ago
|
||
Bug 57906 is now tracking the horizontal issues.
Reporter | ||
Comment 27•24 years ago
|
||
*** Bug 57682 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Target Milestone: Future → mozilla0.9
Reporter | ||
Updated•24 years ago
|
Reporter | ||
Updated•24 years ago
|
Whiteboard: hit during nsbeta2 standards compliance testing → [Hixie-P2] hit during nsbeta2 standards compliance testing
Comment 29•23 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•23 years ago
|
||
don't move bugs that are in the 1.0 dependency tree. sorry.
Target Milestone: mozilla1.0.1 → mozilla1.0
Comment 31•22 years ago
|
||
The behavior Ian describes is also observed using FizzillaCFM/2002070913.
Setting All/All.
OS: Windows 98 → All
Hardware: PC → All
Comment 32•22 years ago
|
||
See bug 157698 for a somewhat interesting testcase (although quite confused by
other issues as well).
Reporter | ||
Updated•22 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•22 years ago
|
||
->boris for fun
Assignee: eric → bzbarsky
Status: REOPENED → NEW
Target Milestone: mozilla1.0 → Future
Comment 34•22 years ago
|
||
css1->css2, since CSS2 section 14.2 has been cited throughout the bug...
Reporter | ||
Comment 35•22 years ago
|
||
It's still a CSS1 bug, even if we refer to CSS2.
Comment 36•22 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).
Comment 37•22 years ago
|
||
> 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•22 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;
Comment 39•22 years ago
|
||
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•22 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•22 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•22 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•22 years ago
|
||
Please refer to CSS2.1, not CSS2, when examining containing block issues.
Updated•22 years ago
|
Priority: P3 → P4
Reporter | ||
Updated•21 years ago
|
Whiteboard: [Hixie-P2] hit during nsbeta2 standards compliance testing → [Hixie-P1]
Comment 44•21 years ago
|
||
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
Updated•21 years ago
|
Priority: P4 → --
Target Milestone: Future → ---
Comment 45•21 years ago
|
||
*** Bug 234039 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
QA Contact: core.layout → ian
Comment 46•21 years ago
|
||
Fixed by checkin for bug 241694.
Status: NEW → RESOLVED
Closed: 25 years ago → 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•