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

Status: NEW

(Core :: Layout: Positioned, defect)

Description

[Levin Alexander]

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.

Comment 1

[Levin Alexander]

Attachment: Minimal Testcase

Comment 2

[Bill Mason]

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

[Christian Fersch]

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

[Hermann Schwab]

*** This bug has been marked as a duplicate of 259766 ***

Comment 5

[Hermann Schwab]

Soryy for the bugspam, I hit the wrong tab.

Comment 6

[Hermann Schwab]

restoring previous state, sorry

Comment 7

[Gérard Talbot]

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

[Gérard Talbot]

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

Comment 9

[Levin Alexander]

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

Comment 10

[Levin Alexander]

(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

[Gérard Talbot]

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

Comment 12

[Gérard Talbot]

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

Comment 13

[Levin Alexander]

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

Comment 14

[Boris Zbarsky [:bzbarsky]]

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.

Comment 15

[Christian Fersch]

(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

[Gérard Talbot]

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

Comment 17

[Mats Palmgren (inactive)]

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

Comment 18

[Mats Palmgren (inactive)]

Attachment: Bug 308946 - Testcase #2

Comment 19

[Gérard Talbot]

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

[Gérard Talbot]

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

Comment 21

[Mike Wilson]

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

[Gérard Talbot]

> 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

[Gérard Talbot]

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

[Gérard Talbot]

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

Comment 25

[Mike Wilson]

> 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

[Gérard Talbot]

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

[Mike Wilson]

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

[Bill Burdick]

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

Comment 30

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 31

[Louis Lazaris]

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

Comment 33

[brunoais]

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

[Roman]

Is anything blocking this bug other than a lack of volunteers?

Comment 35

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 36

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 37

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 38

[Eevee (Evelyn Woods) [:eevee]]

I just ran into this (not for anything important, but for explaining the box model) and realized that the CSS spec does seem to imply that this should work — or, at least, it doesn't say this /shouldn't/ work, so I don't see any reason why it wouldn't.

But I'm bumping this bug because I've discovered a truly delightful quirk:

If a relatively-positioned block in an auto-height parent has a percentage top/bottom when it's added to the document, the top/bottom is ignored. No surprise.

If I use devtools (or, I would assume, regular JS) to /give/ a block relative positioning and a percentage top/bottom... nothing happens. Again, no surprise.

If I then /change/ the percentage top/bottom to any other valid percentage... NOW it works as expected.

A change to the containing block's size causes the inset to be ignored once again.

So this is at least sort of supported already! :)