Relative positioning with percentages inside auto-height containing block does not work

NEW
Unassigned

Status

()

Core
Layout: R & A Pos
13 years ago
9 months ago

People

(Reporter: Levin Alexander, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
User-Agent:       Opera/7.54 (Windows NT 5.1; U)  [en]
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10

(Not sure if this is a Bug in Mozilla or a misunderstanding of the CSS-Spec)

Relative positioning with "top:-50%" does not work as expected if the containing 
Block has a height of "auto"

In the Testcase the Blocks should be centered vertically.




Reproducible: Always
Steps to Reproduce:
1. Open <http://levin.grundeis.net/files/20040918/center.html>

Actual Results:  
<http://levin.grundeis.net/files/20040918/safari_1.2.jpg>
(Looks identical in Opera 7.54, Firefox 1.0, Safari 1.2, IE5.2/mac)

Expected Results:  
<http://levin.grundeis.net/files/20040918/ie_6_win.jpg>
(Looks as expected in IE5/win, IE5.5/win, IE6/win)

The DOM-Inspector reports Computed Style of "#wrap div p" (correctly) as "-36px" 
this is different from the actual rendered result.
(Reporter)

Comment 1

13 years ago
Created attachment 159394 [details]
Minimal Testcase

Comment 2

13 years ago
I am not getting after viewing your testcase why you expect div#one to be
visible.  You can strip everything out your CSS but the background colors and
get the same result as the testcase already gives, btw.

Also, the CSS in your testcase doesn't match the CSS that you state is a problem
in the description.

Comment 3

13 years ago
The Problem is about relative positioned elements with percentages given for
top, bottom, left or right.

div#one should be visible, because div#two should move down by 100% of it's
parents height.

Comment 4

13 years ago

*** This bug has been marked as a duplicate of 259766 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Component: Layout → Browser-General
Resolution: --- → DUPLICATE

Comment 5

13 years ago
Soryy for the bugspam, I hit the wrong tab.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

Comment 6

13 years ago
restoring previous state, sorry
Component: Browser-General → Layout

Comment 7

13 years ago
Your testcase works when div#one has a defined height value (eg, say, height:
56px;). height: auto (I think) means to use as much height as such div requires,
demands. Since div#two is relatively positioned, then div#one does not need any
height: there is no anonymous node for div#one.
So, I'm not sure there is a bug here.

Your 20040918/center.html page has another issue: 
#wrap div has float:left and position:relative;. Why float:left if that div is
relatively positioned?

Comment 8

13 years ago
http://www10.brinkster.com/doctorunclear/HTMLJavascriptCSS/Positioning.html

- Blue Div: Position: relative; Click OK
- Yellow Div: Position: relative; Top: 100; length unit:%; Click OK

Blue and Yellow divs have defined width and height values.
WORKSFORME
(Reporter)

Comment 9

13 years ago
(In reply to comment #7)
> height: auto (I think) means to use as much height as 
> such div requires, demands. 

Yes.  Spec:
<http://www.w3.org/TR/CSS21/visudet.html#root-height>

The relevant part:
| Absolutely positioned children are ignored, and relatively
| positioned boxes are considered without their offset.

So the height of div#one can (and should) be determined before "top" 
is calculated.  I believe this is be the problem.

> Since div#two is relatively positioned, then 
> div#one does not need any height: there is no anonymous node for div#one.
> So, I'm not sure there is a bug here.

Not sure either.  But the Spec does not restrict the use of percentage values 
for "top" to cases where the parent height is defined explicitly.

If you look with the DOM-Inspector you will see that it reports the Computed 
Value of "top" as being "100px" so there is definitely _some_ problem. 

> Your 20040918/center.html page has another issue: 
> #wrap div has float:left and position:relative;. Why float:left if that div is
> relatively positioned?

The position:relative bit makes it the containing block for "#wrap div p"
But you're right "position:relative" is not needed.
(Reporter)

Comment 10

13 years ago
(In reply to comment #8)
> Blue and Yellow divs have defined width and height values.
> WORKSFORME

But it does not work if height of the blue div is "auto"

Still UNCONFIRMED

Comment 11

13 years ago
I'm not going to confirm this bug. One thing you can do to help is to add this
declaration to your div#one rule:
border:2px solid red;
It outlines the div#one and its content... and div#one is not empty (also
confirmed by DOM inspector).

-> Layout: R & A Pos

for further triaging
Component: Layout → Layout: R & A Pos

Comment 12

13 years ago
I'm not saying there is not a bug here: I just don't know, I am not the best
person to decide that.
The closest I could find was
the 2nd "div.contain p.two" example involved in the page
http://dbaron.org/css/test/sec090302a
which is your testcase and which "should be in its normal position within the
div" according to D. Baron.

-> core.layout.r-and-a-pos@bugs

Assignee: nobody → core.layout.r-and-a-pos
(Reporter)

Comment 13

13 years ago
(In reply to comment #12)

> http://dbaron.org/css/test/sec090302a
> which is your testcase and which "should be in its normal position within the
> div" according to D. Baron.

He refers to Section 9.3.2 of CSS 2
<http://www.w3.org/TR/REC-CSS2/visuren.html#position-props>

which states:

| <percentage> 
|  The offset is a percentage of the containing block's width 
|  (for 'left' or 'right') or height (for 'top' and 'bottom'). 
|  For 'top' and 'bottom', if the height of the containing block 
|  is not specified explicitly (i.e., it depends on content 
|  height), the percentage value is interpreted like 'auto'.

This Paragraph has changed in CSS 2.1 to:

| <percentage>
|  The offset is a percentage of the containing block's width 
|  (for 'left' or 'right') or height (for 'top' and 'bottom').
|  Negative values are allowed.
<http://www.w3.org/TR/CSS21/visuren.html#position-props>
Confirming.  Daniel, please do read the specs more carefully...

At the moment, Mozilla implements the CSS2 behavior (see
nsHTMLReflowState::ComputeRelativeOffsets).  The main problem with fixing this
is that ComputeRelativeOffsets is called in InitConstraints(), which means it's
done before the parent's final size is known... It'd need to be moved to
somewhere else; not quite sure where.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 15

13 years ago
(In reply to comment #14)
> The main problem with fixing this
> is that ComputeRelativeOffsets is called in InitConstraints(), which means it's
> done before the parent's final size is known... It'd need to be moved to
> somewhere else; not quite sure where.

That's strange, for the DOM Inspector shows the correct value in "computed Style"

Comment 16

12 years ago
"(...) percentage heights are only supposed to mean something when the parent
has a fixed height"
https://bugzilla.mozilla.org/show_bug.cgi?id=216847#c5

I wish I could be better informed on all this because there are now several bugs
which could be resolved either way (dup or invalid) or confirmed. E.g. bug 308946
*** Bug 308946 has been marked as a duplicate of this bug. ***
Created attachment 196583 [details]
Bug 308946 - Testcase #2

Comment 19

11 years ago
I still think this bug should not have been confirmed. If height is auto or resolved as auto, then, according to previous and/or current CSS 2.1 spec., what is supposed to be calculated when top: 50% is declared? It's 50% of what? It still has to be the containing block.

The spec was clear and is still clear, albeit a few sentences have changed place.

    *  "Percentages: refer to height of containing block" CSS 2.1, Section 9.3.2 Box offsets: 'top', 'right', 'bottom', 'left'
http://www.w3.org/TR/2006/WD-CSS21-20060411/visuren.html#position-props

    * Percentage values for the 'top' property are relative to the containing block.
      "if the element's position is 'relative' or 'static', the containing block is formed by the content edge of the nearest block-level, table cell or inline-block ancestor box." coming from CSS 2.1, Section 10.1 Definition of "containing block"
http://www.w3.org/TR/2006/WD-CSS21-20060411/visudet.html#containing-block-details

    * "If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, [then] the [height] value computes to 'auto'." CSS 2.1, Section 10.5 Content height: the 'height' property
http://www.w3.org/TR/2006/WD-CSS21-20060411/visudet.html#the-height-property
The same was said in the previous CSS 2.1 WD.

So, whether the height of div#one can (and should) be determined before "top" 
is calculated is a matter outside the spec.

And FWIW, all other good compliant CSS 2.x browsers (Konqueror 3.3, Opera 8.50, Opera 9, Safari 2.0) resolve top: <percentage> of an relatively positioned element inside an auto-height container as top: auto.

Comment 20

11 years ago
*** Bug 298052 has been marked as a duplicate of this bug. ***

Comment 21

10 years ago
Interesting for this bug is discussion on www-style mailing list as of August 24, 2007. It was mentioned that the latest CSS spec has actually been changed so that percentages for top/bottom *should* work:
  http://www.w3.org/TR/2007/CR-CSS21-20070719/changes.html#q53

The change done to the spec is that the following text has been removed from the explanation of "9.3.2 Box offsets" percentages:
  For 'top' and 'bottom', if the height of the containing 
  block is not specified explicitly (i.e., it depends on 
  content height), the percentage value is interpreted like 
  'auto'.

Comment 22

10 years ago
> Interesting for this bug is discussion on www-style mailing list as of August
> 24, 2007. It was mentioned that the latest CSS spec has actually been changed
> so that percentages for top/bottom *should* work:
>   http://www.w3.org/TR/2007/CR-CSS21-20070719/changes.html#q53

Can you provide the url of that discussion please?

As far as I can read the current CR (CR-CSS21-20070719), nothing has changed. Section 9.3.2 says percentage refers to height of its containing block. 
Section 10.1 defines what is the containing block for relatively positioned elements. 
Section 10.5 indicates how should be resolved and interpreted an auto-height containing block element. It should be resolved as auto: "If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, the value computes to 'auto'."
http://www.w3.org/TR/2007/CR-CSS21-20070719/visudet.html#the-height-property
That's tic-tac-toe to me.

"Percentage offsets are no longer undefined for containing blocks without an explicit height." does not say much: it just says it's not unspecified, it's not undefined, not indetermined. It can and should be resolved, interpreted as auto: that's what I was and still am reading.

Comment 23

10 years ago
One last thing. Resolving as auto in strict mode does not mean it's not parsed, it's not resolved, it does not work or that it does not follow the spec... but it may give that impression to web authors, furthermore if IE 6+ does not resolve it as auto.

Comment 24

10 years ago
url of that discussion on www-style mailing list:
http://lists.w3.org/Archives/Public/www-style/2007Aug/0139.html

Comment 25

10 years ago
> As far as I can read the current CR (CR-CSS21-20070719), 
> nothing has changed.

Sorry, I was not making myself very clear. What is new in CR-CSS21-20070719 is that the change is actually mentioned in the "changes" appendix. The change regarding this example from CSS2 to CSS2.1 has been in the WD for a long time and I realize now that Levin Alexander mentioned just that in comment #13 back in 2004.

I do not agree with you that the current CSS spec makes it clear that Mozilla exhibits the desired behaviour, rather I would at its best say it is unclear. I also think that you are correlating specification text for the |top| and |height| properties in a way that is not natural.

As the only activity on this bug report for its entire lifetime of three years has been about how to interpret the CSS 2.1 spec, I suggest that we move this discussion to the W3C's mailing list to sort this out. As far as I can see there are only two alternatives to have Mozilla in sync with the spec:

1) Keep the current Mozilla behaviour and persuade the CSS working group to put back the '98 CSS2 phrasing for 9.3.2 back in the spec ("For 'top' and 'bottom', if the height of the containing block is not specified explicitly (i.e., it depends on content height), the percentage value is interpreted like 'auto'.").

-or-

2) Keep the current CSS2.1 phrasing for 9.3.2 and update Mozilla to handle the case as outlined in this bug report.

Note that I personally can think of both alternatives, what is important is to have Mozilla in sync with the spec. I welcome your response on the mailing list, preferrably as a disagreement to 
http://lists.w3.org/Archives/Public/www-style/2007Aug/0152.html

Comment 26

9 years ago
Microsoft and IE 8 beta 1 (build 17184) render this testcase

http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/PercentualRelativePositioning.html

just like Firefox 2 (and Konqueror 3.3+, Opera 8.50+,
Opera 9.x, Safari 2+) and, IMO, just according to the reading of the spec I gave in comment #19 and comment #22. As far as I understand this bug and unless something new comes up, there is no bug here IMO. If height of containing block is auto or resolved as auto, then top: 50% applied to a relatively positioned child should be resolved as top: auto. 

Bug 391528 should be resolved with the same status as for bug 260348. IMO, bug 391528 is a duplicate of bug 260348.

Comment 27

9 years ago
It was extremely clear from the discussion on www-style in August 2007 (referred to in my comment #25) that the CSS working group has a different opinion from yours. Doesn't that bother you?

WG member fantasai said this:
"The spec was actually changed so that percentages for top/bottom *do* work. Behavior in this case was previously explicitly undefined: http://www.w3.org/TR/CSS21/changes.html#q53"
[See http://lists.w3.org/Archives/Public/www-style/2007Aug/0152.html]

In my last post I urged you to enter this discussion and get agreement with the CSS WG on your differing opinion. Why haven't you? 
IMO, as long as you don't do this I suggest your opinion should be ignored for this bug.

Comment 28

9 years ago
I would like to see mozilla follow the CSS spec (http://www.w3.org/TR/CSS21/changes.html#q53 as cited in comment #27 above by Mike Wilson.  If this happens, it will be possible to center automatically sized content at a given point without Javascript (by using top: -50%; left: -50%), which will simplify and speed up our whiteboarding app (and I would imagine many other apps out there can take advantage of this).
Assignee: layout.r-and-a-pos → nobody
QA Contact: layout → layout.r-and-a-pos
Duplicate of this bug: 391528
Bug 391528 has a good bit more of the history here with links to recent CSS WG decisions.

Bug 157681 also made our behavior inconsistent in the case of dynamic changes (so that this bug is fixed in certain animation cases).  That's actually rather bad, since we're now inconsistent under dynamic changes.
Blocks: 909667

Comment 31

4 years ago
Looks like I duplicated this bug here:

https://bugzilla.mozilla.org/show_bug.cgi?id=939641

I was specifially searching for 'min-height' before submitting mine, not 'auto'.
Duplicate of this bug: 939641

Comment 33

3 years ago
Any updates? I have already had issues I have to fix with javascript that, by applying this, would solve my contents displaying issues.

Comment 34

3 years ago
Is anything blocking this bug other than a lack of volunteers?
I don't think so, although it's a good bit of work to fix, since relative positioning has to happen much later in the layout process than it currently does in at least some cases.

Does this work across other browsers these days?  That would increase the priority.
You need to log in before you can comment on or make changes to this bug.