Closed
Bug 105286
Opened 23 years ago
Closed 20 years ago
viewport used as containing block for absolutely positioned elements instead of root (percentage height, %, bottom)
Categories
(Core :: Layout: Positioned, defect)
Core
Layout: Positioned
Tracking
()
VERIFIED
INVALID
People
(Reporter: gabriele_fava, Unassigned)
References
Details
Attachments
(4 files, 3 obsolete files)
The "background-image" property associated with "repeat: repeat" should renders
a background image in the whole region under the control of the selector that is
referred to. Mozilla instead (and ie 5.5 too, and I don't know what ie6 does)
renders only the part that is visible on the screen at the rendering moment, the
part that needs to be scrolled to be visible haven't a background.
Comment 1•23 years ago
|
||
->ImageLib
Assignee: dbaron → pavlov
Component: Style System → ImageLib
QA Contact: ian → tpreston
Comment 2•23 years ago
|
||
Do you have an example page that shows the problem?
Reporter | ||
Comment 3•23 years ago
|
||
Reporter | ||
Comment 4•23 years ago
|
||
Reporter | ||
Comment 5•23 years ago
|
||
Reporter | ||
Comment 6•23 years ago
|
||
I'm sorry for the delay, I tried to reproduce the bug in other documents, but I
wasn't able. So I posted the original document.
What I see on "repeat" property (that is background-repeat) don't deal with the
problem, because the "repeat" value is the default value.
The problem is that only a part of the lateral background is rendered, exactly
the part visible on the screen at the rendering moment. It seems that the
height's percentage refers to the screen, non to the page.
Comment 7•23 years ago
|
||
Attachment #54351 -
Attachment is obsolete: true
Attachment #54352 -
Attachment is obsolete: true
Comment 8•23 years ago
|
||
Comment 9•23 years ago
|
||
The page has a div that's absolutely positioned with height:100%. That means
its containing block is _not_ the body, which is statically positioned. Thus
it's sized based on the viewport size.
Making the body positioned makes the <div> size based on the body size, again
correctly.
Marking invalid; the behavior here is correct.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Comment 10•23 years ago
|
||
Are you sure it should be based on the viewport size?
Comment 11•23 years ago
|
||
Hmm. "If there is no such ancestor, the content edge of the root element's box
establishes the containing block." So what is the root element in our case?
<html>? How should we treat "position:absolute; bottom: 0"? Should it be at
the very bottom of the page or at the bottom of the viewport when the page first
loads?
Reopening and to layout to decide all this.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Comment 12•23 years ago
|
||
--> layout
Assignee: pavlov → attinasi
Status: UNCONFIRMED → NEW
Component: ImageLib → Layout
Ever confirmed: true
OS: Windows ME → All
QA Contact: tpreston → petersen
Hardware: PC → All
Summary: css "background-image" property: the images are not totally rendered → absolutely positioned 100% height div has height of viewport, not root element?
Reporter | ||
Comment 13•23 years ago
|
||
It's invalid to make the initial containing block positioned <
http://www.w3.org/TR/REC-CSS2/visuren.html#containing-block >; but it could be
that the initial containing block is <HTML>, not <BODY>; yes, it must be like
that. Anyway,
" 1. If the element has 'position: absolute', the containing block is
established by the nearest ancestor with a 'position' other than 'static',
If there is no such ancestor, the content edge of the root element's box
establishes the containing block. " <
http://www.w3.org/TR/REC-CSS2/visudet.html#containing-block-details >.
That content edge is the document's edge, not the viewport.
In your way it works, but it should works also leaving BODY static. It's an
interpretation error, I think, but I'll ask to w3c's editors.
Component: Layout → ImageLib
OS: All → Windows ME
QA Contact: petersen → tpreston
Hardware: All → PC
Summary: absolutely positioned 100% height div has height of viewport, not root element? → css "background-image" property: the images are not totally rendered
Comment 14•23 years ago
|
||
The second URL you give says that the containing block is established by the
root element, which in this case is HTML. I think Boris Zbarsky has established
that this is either a layout bug or is not a bug.
Component: ImageLib → Layout
Comment 15•23 years ago
|
||
fixing QA, summary, OS/Platform.
OS: Windows ME → All
QA Contact: tpreston → petersen
Hardware: PC → All
Summary: css "background-image" property: the images are not totally rendered → absolutely positioned 100% height div has height of viewport, not root element?
Comment 16•23 years ago
|
||
Starting at the <div> and walking up to the nearest frame that IsPercentageBase
does _not_ give us the <html> frame. Not exactly surprising...
Reporter | ||
Comment 17•23 years ago
|
||
"Starting at the <div> and walking up to the nearest frame that IsPercentageBase
does _not_ give us the <html> frame. Not exactly surprising..."
I'm sorry, I don't understand you. Are you talking about Mozilla source?
Comment 18•23 years ago
|
||
Yes. The frame corresponding to the div (the frame is the object that actually
gets laid out and drawn) does not have the <html> frame as its containing block,
basically. This feels like a layout bug to me.
Reporter | ||
Comment 19•23 years ago
|
||
Yes, I concur with you. By the way, I had the confirmation that "the content
edge of the root element's box" must be the entire document edge, not the edge
of the browser window. So this is a confirmed bug. Who takes it?
Updated•23 years ago
|
Target Milestone: --- → Future
Comment 20•23 years ago
|
||
*** Bug 126476 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Summary: absolutely positioned 100% height div has height of viewport, not root element? → absolutely positioned 100% height div has height of viewport, not root element? [containing block]
Comment 21•23 years ago
|
||
If this is indeed a bug, does this also mean the only way to create an element
which has, say, 90% the height of the viewport is with using "position: fixed"
(since it's impossible to refer to the viewport in another way)?
Comment 22•23 years ago
|
||
So I suspect that the issue here is simply that the computed height of the
<html> and the rendered height of the <html> do not match. Try setting "height:
100px" on the <html> and note that the positioned div is now 100px tall but the
<html> block itself sizes based on the content...
Depends on: 15405
Comment 23•23 years ago
|
||
Comment 24•22 years ago
|
||
Hi, we've recently come across this bug. It seems that IE 6 is doing this
correctly (but not doing other stuff though). Is this currently being work on
or is there an estimated time that a fix might be landing?
Comment 25•22 years ago
|
||
*** Bug 157287 has been marked as a duplicate of this bug. ***
Comment 26•22 years ago
|
||
Ok. I'm a dunce when it comes to all the CSS talk. Just tell me, is this the
correct bug for the following problem:
<html style="height:100%">
<body style="height:100%">
<div><img height="125"...></div>
<div style="height:100%;background:#FF"></div>
</body>
</html>
The problem is that the 100% height div is rendered exactly as 100% + 125px
(because it's under the image), and so we get 125px of scrolling on a blank
document. This happens in standards, and quirks mode. Shouldn't 100% mean 100%
of the viewport when the page isn't as tall as the viewport?
Comment 27•22 years ago
|
||
This is counter-intuitive to me. 100% equals more than 100%.
Comment 28•22 years ago
|
||
Actually, from a strict CSS point of view, the behavior of the testcase in
comment 27 makes perfect sense. You've set the 'html' element to be the height
of the viewport (okay, that part doesn't necessarily make sense, but it's what
we do). Then you've set the 'body' element to be the height of its parent,
which is 'html', which is the height of the viewport. Then you've set the
height of the 'div' to equal the height of its parent, the 'body', so the 'div'
is also the height of the viewport. To the pixel. You've placed content before
it, so the 'div' gets shoved down that distance, but it's still as tall as the
viewport-- which can be seen if you scroll down to the end of the document.
100% doesn't mean "fill in the remaining space," it means "make me as tall as my
parent element," unless said parent has 'auto' height, in which case 100% means
'auto' for the sized element as well. See
http://www.w3.org/TR/CSS2/visudet.html#propdef-height for details.
I don't really think this is the same bug, although I could be wrong; I only
glanced over the other discussion.
Comment 29•22 years ago
|
||
That testcase has nothing to do with this bug. Start with lack of an absolutely
positioned element in the testcase (this bug is _only_ about absolutely
positioned elements) and go from there.
Comment 30•22 years ago
|
||
Ok. I didn't know that the code that calculated heights for absolutely
positioned DIVs was different than the code that calculated the height of other
DIVs. Sorry to have bothered this bug.
Comment 31•22 years ago
|
||
*** Bug 172823 has been marked as a duplicate of this bug. ***
Comment 32•22 years ago
|
||
* The testcase titled 'testcase showing the height issue....' performs
correctly. The content in garbage text overflow html element, as html has
(implicitly) overflow: auto. Additional Comment #22 is not a correct analysis of
the behavior.
Additional Comment #28 From Eric A. Meyer
It does make sense, Eric. Cascading Style Sheets, level 2 revision 1 states:
"A UA may compute a percentage height on the root element relative to the
viewport."
http://www.w3.org/TR/CSS21/visudet.html#the-height-property
But then you said, "I don't really think this is the same bug, although I could
be wrong; I only
glanced over the other discussion." You are correct. It is not the same bug. As
your analysis states, it is not a bug at all, but a distraction. For more info
on this, please see my testcase: http://dhtmlkitchen.com/experiment/height/
So what is supposed to happen?
The div should have height: auto because
"...
The percentage is calculated with respect to the height of the generated box's
containing block. If the height of the containing block is not specified
explicitly (i.e., it depends on content height), and this element is not
positioned, the value is interpreted like 'auto'..."
Please make Mozilla do this exactly.
Comment 33•22 years ago
|
||
A few thoughts, although I only had a chance so far to skim your comment:
* the containing block for absolutely positioned elements may be the initial
containing block, which is not the root element (despite a contradiction in one
part of CSS2) See CSS2 10.1.
* We have hacks to make percentage heights work in a backwards compatible way
in quirks mode, but they shouldn't be present in standards mode. See
http://mozilla.org/docs/web-developer/quirks/
Comment 34•22 years ago
|
||
A third thought:
* The scrollbars present on a window by default are not associated with
'overflow' on the root element, rather they are the scrolling mechanism required
by CSS2 9.1.1: http://www.w3.org/TR/CSS21/visuren.html#q2
Comment 35•22 years ago
|
||
The horizontal scrollbar is not desirable at all. It can't be gotten rid of. I
haven't given this much thought, though. How can one use right: 0; border-width:
1px and not have a horz scrollbar?
"The containing block (called the initial containing block) in which the root
element lives is chosen by the user agent."
In Mozilla and IE, this is HTML.
Look down below at the chart:
For box generated by C.B. is established by
body initial C.B. (UA-dependent)
div1 body
p1 div1
p2 div1
em1 p2
strong1 p2
So the initial C.B. in Mozilla is HTML, by choice, not rule.
Comment 36•22 years ago
|
||
Comment #33 We have hacks to make percentage heights work in a backwards
compatible way
in quirks mode, but they shouldn't be present in standards mode.
I thought so at first, too. As I previously quoted, the css2.1 spec says,
"A UA may compute a percentage height on the root element relative to the viewport."
http://www.w3.org/TR/CSS21/visudet.html#the-height-property
Comment 37•22 years ago
|
||
The chart in comment 35 is wrong. The containing block for the <body> box is
the <html> box. The UA-dependent part is what the containing block of the
<html> box is. This is the case in IE6/Win in standards mode and in Mozilla.
IE5.x/Win and IE6/Win in quirks mode treat <body> as the root element and the
chart does apply to them as listed in comment 35.
Comment 38•22 years ago
|
||
That chart comes from section 10.1 of css2. It's just the same in revision 2.1.
Am I to believe that the specification is wrong?
http://www.w3.org/TR/CSS21/visudet.html
Comment 39•22 years ago
|
||
Yes. That text is clearly wrong. David, want to bring this up in the WG?
Comment 40•22 years ago
|
||
Oh, and note the mention of a "contradiction" in comment 33. That chart
directly contradicts the earlier text in that same section.... The spec has
been self-contradictory on this for a while now; I'm hoping the issues get
ironed out before 1.2.1 exits CR...
Comment 41•22 years ago
|
||
Thanks for the clarification.
Chart showing containment heirarchy:
+---initial containing block---+
|+----------------------------+|
|| root (html) ||
|| +------------------------+ ||
|| | body | ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|| | | ||
|| +------------------------+ ||
|+----------------------------+|
+------------------------------+
The initial containing block is UA-dependent.
HTML is the root
Body is a containing block.
Comment 42•22 years ago
|
||
But now I am reading this:
"...
The root of the document tree generates a box that serves as the initial
containing block for subsequent layout.
..."
http://www.w3.org/TR/CSS21/visuren.html#initial-containing-block
Comment 43•22 years ago
|
||
WHat the fuck is the initial containing block? Is it a secret? Is it the
document root? is it UA-dependent? Is it a secret? What's all this
contradiction? Who's the expert here?
Comment 44•22 years ago
|
||
That part you just quoted is the second part of the contradiction David (who
_is_ the expert here) referred to. As I understand, that prose will be cleaned
up (read: edited to match section 10.1) in the next edition of the CSS 2.1 spec.
The initial containing block is UA-dependant. The spec clearly says so in
section 10.1 and that will continue to stand (again, this is based on what I've
seen in the discussion on www-style@w3.org). In Mozilla it's the viewport,
basically. It is not the document root. The document root is a DOM concept
and is the root node of the DOM tree (<html> in HTML documents unless you're
using a really broken browser like IE5.x/Win or IE6/Win in quirks mode (same
thing); for those, the <body> is the root node of the DOM tree, as far as I can
tell). The contradiction is between the normative definitions in section 10.1,
the non-normative table you cited from the same section, and the normative text
you cited in comment 42.
The www-style@w3.org have some discussion on this, iirc... See the list
archives (http://lists.w3.org/Archives/Public/).
All of which is not relevant to this bug. What _is_ relevant is that whether
it's a bug or not depends on what CSS 2.1 ends up saying when it's done.
Trying to implement anything on the basis of a preliminary self-contradictory
draft is silly.
Comment 45•22 years ago
|
||
So my diagram _is_ correct, right, Boris? (I'll accept your silence as
affirmative). I'm going to email you and ask you to send me some resources that
prove this, though. Not that I think you're lying, but I want to see proof. The
documentation from css2 and css2.1 a total joke; its author a sadist.
Comment 46•22 years ago
|
||
The paragraph quoted in comment 42 is the inconsistency I mentioned in comment
33, and should be corrected in the next release of CSS 2.1 (by removal of a
significant chunk of 9.1.2, I think).
Comment 47•22 years ago
|
||
The chart mentioned in comment 35 / comment 38 / comment 39 has already been
corrected in internal CSS2.1 drafts:
Comment 48•22 years ago
|
||
http://www.people.fas.harvard.edu/~dbaron/css/test/sec090102
Shows that html element will stretch to fill the viewport vertically , even with
html { height: 500px; } Not in quirks mode, the DTD is:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/strict.dtd">
It is possibly related to this bug because the html element is automatically
assuming the height of the viewport.
I think what happened here is that somewhere, somebody filed a bug about "xxx
element does not have n% height, instead it is as tall as possible" I further
suppose that said bug was not marked invalid, as it should have been, and was
incorrectly fixed. Tell me, is it so far fetched?
Comment 49•22 years ago
|
||
Comment 48 is bug 15405. It's a fundamental issue with the way the root of the
and its immediate children are constructed and is not a result of a particular
bugfix.
Comment 50•22 years ago
|
||
*** Bug 190063 has been marked as a duplicate of this bug. ***
Comment 51•22 years ago
|
||
.
Assignee: attinasi → position
Component: Layout → Layout: R & A Pos
QA Contact: cpetersen0953 → ian
Target Milestone: Future → ---
Comment 52•21 years ago
|
||
*** Bug 216342 has been marked as a duplicate of this bug. ***
Updated•21 years ago
|
Summary: absolutely positioned 100% height div has height of viewport, not root element? [containing block] → viewport used as containing block for absolutely positioned elements instead of root (percentage height, %, bottom)
Updated•21 years ago
|
Attachment #100836 -
Attachment is obsolete: true
Comment 53•21 years ago
|
||
I don't see any of the test cases showing something that we do incorrectly. We
seem to be consistent with the CSS specification, correct?
Comment 54•21 years ago
|
||
"which spec"? What we do is sorta wrong per CSS2.0, and maybe almost right per
CSS2.1. Once bug 243519 is fixed, this bug should be revisited (hence the
dependency).
Comment 55•20 years ago
|
||
*** Bug 253135 has been marked as a duplicate of this bug. ***
Comment 56•20 years ago
|
||
Just to carry this over from the dup. bug report (sorry, managed to miss this one on searching), now
that the 2.1 spec is out (candidate recommendation), it only says the initial cb 'could' be the viewport.
However, although this makes perfect sense for fixed position elements, it would be much more
sensible to consider the canvas (that being the total area required to render the entire content) as the
icb for absolutely positioned elements. If the viewport is used for both, absolute elements do not
behave as expected, leading to interesting rendering effects and it becomes much harder (to the point
of systematically having to 'patch' a page to behave sensibly) to specify an element that covers an area
relative to the canvas but which grows with it's content. (Sorry if I have miss-used the term canvas).
Comment 57•20 years ago
|
||
Robert, the canvas is by definition infinite in the CSS spec.... As for the
rest, using something that depends on the size of the content for the initial
containing block leads to circular definitions (consider setting the height of
the root element to 150% -- then it should be 150% the height of the initial
containing block, and there is no way to make that consistent with your proposal).
So the initial containing block needs to have an intrinsic size completely
independent of the contents of the document. As things stand, Mozilla and Opera
are working on interoperably implementing the viewport as the initial containing
block, simply because there is nothing else reasonable to use.
Comment 58•20 years ago
|
||
This is INVALID per CSS2.1. CSS2.1 section 10.1 clearly says that the containing
block of absolutely positioned elements that don't have a positioned ancestor is
the initial containing block, which the working group agrees is, for desktop
browsers, the viewport. (The spec doesn't actually say it is the viewport
because there are theoretical cases where it wouldn't be, sigh.)
Status: NEW → RESOLVED
Closed: 23 years ago → 20 years ago
Resolution: --- → INVALID
Comment 59•20 years ago
|
||
I don't care what the elements are initially calculated against. All I care is that my css behaves as I
expect it to. As such, when I specify that an element has a bottom attribute of 20px, I expect to see
that element stretch all the way down to the bottom of whatever it is that controls how much the
viewport needs to scroll, with a 20px space at the end. I can understand the argument about circular
calculations and stuff but, well, quite simply, it can be done because I've seen it being done by Safari
(and the source is available so maybe you should go take a peak...).
Let me put this another way. The Safari behaviour seems to be completely css compliant and a sensible
interpretation of the spec. In comparison, mozilla's interpretation reduces the capability of an html/css
coder to control the layout of the page and causes unexpected and unnecessary 'visual effects' which
require deep knowledge of how everything works to understand correctly. Now, you may argue that
Safari is not CSS2.1 compliant (although I still hold that, in this respect, it is) but even if you argued
that, then I would argue that the 2.1 spec is a backwards step and should be revisited.
As it stands, and I have played with this a lot, with mozilla there is no way to create a div that has:
1) A height always at least that of the viewport minus some explicit offset
2) grows to accommodate content
3) has not had it's width and height explicitly coded (which breaks in all manner of ways and should be
strongly discouraged for any major content holding element)
Even if you consider Safari's method of rending to be wrong for some reason, this does not negate the
fact that Mozilla's rendering is undeniably incorrect - allowing an element's content either to overflow
or grow it's dimensions without redrawing it to show this growing visually. Also note that this behaviour
is unique to absolutely positioned objects with no non-static ancestor meaning that the behaviour is
radically different depending on the hierarchy and for no apparent reason.
And what is the name for the area defined by the scroll bars? Not the canvas or the page so how about
the View? After all, the window is termed the viewport.
Comment 60•20 years ago
|
||
I'll contact the Safari people to get their browser fixed.
You can get the behaviour you describe using nested elements and min-height.
I'm not sure what you mean by the drawing error, which testcase shows that?
The box marked out by the scrollbars is the viewport.
Comment 61•20 years ago
|
||
nested elements and min-height will not work when the viewport is vertically larger than the min-
height but the content of the element renders to less than the min-height. As you increase the height
of the viewport further, the element in question does not grow with it but stays where it is, leaving an
expanding patch of nothingness below itself.
The two attachments linked to the dup. bug show a screen capture of one of the fuller pages of
www.far-blue.co.uk. The Safari screenshot shows how things should be, with the translucent grey div
coming all the way down to the bottom and leaving a 20px gap as specified in the style sheet. The
mozilla screen shot shows that the same div is rendered with a gap from the bottom of the original
viewport and is not re-rendered to accommodate the content which spills over it and continues down
the *insert appropriate name e.g. canvas, page or view*. I am not even sure whether the grey div is
actually resized or not to contain it's content but it certainly is not re-rendered if that is the case. I can
re-post the attachments to this bug entry if people wish.
The box marked out by the scroll bars is, indeed the viewport. I was referring to the space within which
scrolling the scroll bars will move the viewport. I wish to know the name of the thing that totally
encompasses the rendered content of all html (maybe even that specified to be 150% or another sily
value) and which is used to calculate how much scrolling the viewport will need to do to allow the user
to view it's entirety. It is this 'thing' (maybe described as the minimal canvas area required to hold
rendered content?) that I argue should be the final reference for right and bottom attributes to
absolutely positioned elements.
Comment 62•20 years ago
|
||
Robert, absolutely positioned elements affect the area you are talking about (if
you position something "off the bottom of the page", the user can scroll to it.
So you're suggesting a circular dependence again. Consider setting "bottom:
-20px". With your proposal that would mean that the bottom of the element
should be 20px below where you can scroll to. At the same time, you can scroll
to the bottom of the element, per above. Which is impossible.
The effect you want is easy to produce by setting "position: relative" on the
root element, as I already told you to do in bug 253135.
Comment 63•20 years ago
|
||
And so then, bottom: 20px will be 20px *above* where you can scroll to? It's the
natural converse of your statement, but it seems bizarre.
Comment 64•20 years ago
|
||
So should I reopen this one or file a different one on the issue where a window
resize does not cause elements with viewport-based sizings to resize (in aviary)?
Comment 65•20 years ago
|
||
for a start, no, you can't gain the same results using position:relative on the root (or an ancestor)
object. Because this object is only high enough to contain it's content, if the viewport is larger than the
content the element we are talking about only expands to contain it's content, not all the way down to
the bottom of the viewport.
As for whether it is possible or not, I can only say it has to be possible because Safari (ad
konqouror 3.2) does it. I cannot think of a better proof. Anyhow, if any negative value is specified for
the bottom attribute, it should not grow the depth of the container (in this case root) element but
overflow it. This is exactly what does happen with elements with a real ancestor so why do anything
different with an element which is a child of the icb? As the scroll bars track the size of the root element
(or whatever you wish to tall it), a negative value such as the one you describe should guarantee that
the bottom of the affected element is not visible and you cannot scroll to it. Sounds sensible if slightly
pointless.
I don't see what the fundamental problem is with wishing to be able to specify that an element has it's
bottom a known number of pixels (or whatever) from the bottom of the area viewable by the user. If
there are no scroll bars, this should be the bottom of the viewport. If there are scroll bars, this should
be the bottom of the viewport when the viewport is scrolled down as far as it will go.
Comment 66•20 years ago
|
||
I think I see the point. Since positioned elements aren't included in the block
size, there isn't any circular dependency.
The decision here appears to be that positions relative to the BODY element are
viewport-relative. That's fine. I can get content-relative by wrapping my page
in a DIV. If the same background is placed on the BODY and the DIV, then
Robert's request is satisfied, no?
Comment 67•20 years ago
|
||
> And so then, bottom: 20px will be 20px *above* where you can scroll to?
No. It will be 20px above the end of the root element (so 20px above where the
in-flow content ends).
> So should I reopen this one or file a different one on the issue where a
> window resize does not cause elements with viewport-based sizings to resize
> (in aviary)?
First check whether it happens on trunk (I can't reproduce with a current trunk
SeaMonkey build an a simple "bottom: 20px" testcase). If it does, please file a
new bug, cc me.
> As for whether it is possible or not, I can only say it has to be possible
> because Safari (ad konqouror 3.2) does it.
Really? What does it do for the "bottom: -20px" case?
> I cannot think of a better proof
You have yet to present evidence that it "does it" as opposed to "does something
like it in a limited set of circumstances".
> Anyhow, if any negative value is specified for the bottom attribute, it should
> not grow the depth of the container
Why not? A positive value for "top" _does_ grow the scrollable area, no? How
is a negative bottom any different?
What if a positive value is specified and the absolutely positioned element
itself overflows, such that its overflow overflows the root too?
> As the scroll bars track the size of the root element
Except they don't.
> I don't see what the fundamental problem is with wishing to be able to specify
> that an element has it's bottom a known number of pixels (or whatever) from
> the bottom of the area viewable by the user.
Nothing, except CSS has no concept of "the bottom of the area viewable by the
user". Please do feel free to take that up with the CSS working group.
Comment 68•20 years ago
|
||
The comments about backgrounds are from a while back while my bug report came in yesterday and
was dup'd to this one so is prob a little confusing if you just read from the top :)
To try and clarify (and there are two example screen shots showing the Safari and Mozilla versions of
the rendering attached to my original bug report) this is what I tried to do:
I have a div which is absolutely positioned. It has top, left, bottom and right attributes which, being an
absolutely positioned element, I thought were relative to the total render area of the html, not the
viewport. The div has a grey translucent background and variable content.
The effect I wanted was that if the content was shorter than the viewport, the grey div would come
down to a few pixels above the bottom of the viewport while if the content was longer, it would come
down to a few pixels above the bottom of the viewport when the user has scrolled to the bottom of the
rendered html.
This is exactly what Safari does. (see the safari jpeg attachment in my original bug report)
Mozilla, on the other hand, only renders down to the slight offset from the bottom of the viewport - no
matter what the content of the div is doing. As a result, the content overflows the div and continues
down. As you scroll, you can see the grey div has stopped in 'mid air' rather than carrying on down. I
honestly don't think this is a valid behaviour however you look at it.
Now, if the div was fixed, it seems very sensible that it has it's attributes relative to the viewport but
then, it should also scroll with the viewport.
If you try the trick of making the div have a relative ancestor, this works fine for any content longer
than the viewport but fails to allow the div to extend down to near the bottom of the viewport when the
content is shorter than the viewport.
It would be a 30 second task to knock up a couple of example pages to show the various behaviours
and some screen shots to show how mozilla vs Safari renders everything. Would that help? You can also
see the problem by going to http://www.far-blue.co.uk, clicking on the 'RioVista' link (with an initially
quite small mozilla window or with your text size at 200% to force the text to require scrolling).
My suggestion is that calculating the right and bottom attributes of an absolute element with no
ancestor should be relative to the final rendered size of the html, not the initial viewport.
Comment 69•20 years ago
|
||
a negative value on a top attribute does not push everything else down - right? so why should a
negative value on bottom increase the scroll depth?
Comment 70•20 years ago
|
||
Robert, take such suggestions to the CSS working group, please. At the moment
Mozilla implements what the spec says, so you're asking for us to break the spec
or for the spec to change.
Status: RESOLVED → VERIFIED
Comment 71•20 years ago
|
||
> a negative value on a top attribute does not push everything else down - right?
That's a bug. Bug 6976, in fact.
Comment 72•20 years ago
|
||
I'll take it up with the css committee :)
Comment 73•20 years ago
|
||
Nevermind on the resize issue.
I note that the icb is the viewport size before application of scrollbars. Is
that correct? Would it be possible to adjust the viewport when the scrollbars
are added?
Comment 74•20 years ago
|
||
That's probably bug 243519
You need to log in
before you can comment on or make changes to this bug.
Description
•