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)

Product:
Core
Component:
Layout: Positioned
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: gabriele_fava, Unassigned)

References

Details

Attachments

(4 files, 3 obsolete files)

The image required by Exercise.HTM
40.37 KB, image/jpeg
Details
reduced testcase from the HTML
2.79 KB, text/html
Details
same but with positioned <body>
2.81 KB, text/html
Details
testcase showing the height issue....
1.52 KB, text/html
Details 
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.
->ImageLib
Assignee: dbaron → pavlov
Component: Style System → ImageLib
QA Contact: ian → tpreston
Do you have an example page that shows the problem?
Attached file The html page where the bug occurs (obsolete) — 

    
    

    
  

      
      
      
      

        Attached file
          
        The style document for Exercise.HTM (obsolete)
        — 
      

    


  

    
    

    
  


  

    
    

    
  
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.

    
    

    
  


  

        Attachment #54351 -
        Attachment is obsolete: true

        Attachment #54352 -
        Attachment is obsolete: true

    
    

    
  
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

    
    

    
  
Are you sure it should be based on the viewport size?

    
    

    
  
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 → ---

    
    

    
  
--> 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?

    
    

    
  
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

    
    

    
  
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

    
    

    
  
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?

    
    

    
  
Starting at the <div> and walking up to the nearest frame that IsPercentageBase
does _not_ give us the <html> frame.  Not exactly surprising...

    
    

    
  
"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?

    
    

    
  
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.

    
    

    
  
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?
Target Milestone: --- → Future

    
    

    
  
*** Bug 126476 has been marked as a duplicate of this bug. ***
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]

    
    

    
  
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)?

    
    

    
  
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

    
    

    
  
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?

    
    

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

    
    

    
  
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?

    
    

    
  

      
      
      
      

        Attached file
          
        Like this (obsolete)
        — 
      

    


  
This is counter-intuitive to me. 100% equals more than 100%.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

    
  
* 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.

    
    

    
  
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/

    
    

    
  
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

    
    

    
  
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 #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




    
    

    
  
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.

    
    

    
  
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

    
    

    
  
Yes.  That text is clearly wrong.  David, want to bring this up in the WG?

    
    

    
  
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...

    
    

    
  
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.


    
    

    
  
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    

    
    

    
  
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?

    
    

    
  
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.

    
    

    
  
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. 



    
    

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

    
    

    
  
The chart mentioned in comment 35 / comment 38 / comment 39 has already been
corrected in internal CSS2.1 drafts:

    
    

    
  
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 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.

    
    

    
  
*** Bug 190063 has been marked as a duplicate of this bug. ***
Blocks: 196937

    
    

    
  
.
Assignee: attinasi → position
Component: Layout → Layout: R & A Pos
QA Contact: cpetersen0953 → ian
Target Milestone: Future → ---

    
    

    
  
*** Bug 216342 has been marked as a duplicate of this bug. ***
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)
Depends on: 243519

    
  

        Attachment #100836 -
        Attachment is obsolete: true

    
    

    
  
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?

    
    

    
  
"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).

    
    

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

    
    

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

    
    

    
  
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.

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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)?

    
    

    
  
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.

    
    

    
  
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? 

    
    

    
  
> 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.

    
    

    
  
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.

    
    

    
  
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?

    
    

    
  
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

    
    

    
  
> a negative value on a top attribute does not push everything else down - right?

That's a bug.  Bug 6976, in fact.

    
    

    
  
I'll take it up with the css committee :)

    
    

    
  
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?

    
    

    
  
That's probably bug 243519

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: