Last Comment Bug 260348 - Relative positioning with percentages inside auto-height containing block does not work
: Relative positioning with percentages inside auto-height containing block doe...
Status: NEW
:
Product: Core
Classification: Components
Component: Layout: R & A Pos (show other bugs)
: Trunk
: All All
: -- normal with 9 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
http://levin.grundeis.net/files/20040...
: 298052 308946 391528 939641 (view as bug list)
Depends on:
Blocks: 909667
  Show dependency treegraph
 
Reported: 2004-09-19 06:59 PDT by Levin Alexander
Modified: 2016-08-19 07:11 PDT (History)
17 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Minimal Testcase (716 bytes, text/html)
2004-09-19 07:24 PDT, Levin Alexander
no flags Details
Bug 308946 - Testcase #2 (1.02 KB, text/html)
2005-09-18 13:16 PDT, Mats Palmgren (:mats)
no flags Details

Description Levin Alexander 2004-09-19 06:59:28 PDT
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 2004-09-19 07:24:38 PDT
Created attachment 159394 [details]
Minimal Testcase
Comment 2 Bill Mason 2004-09-19 08:54:17 PDT
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 2004-09-19 09:17:41 PDT
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 2004-09-19 09:40:07 PDT

*** This bug has been marked as a duplicate of 259766 ***
Comment 5 Hermann Schwab 2004-09-19 09:44:56 PDT
Soryy for the bugspam, I hit the wrong tab.
Comment 6 Hermann Schwab 2004-09-19 09:46:16 PDT
restoring previous state, sorry
Comment 7 Gérard Talbot 2004-09-19 10:41:53 PDT
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 2004-09-19 10:59:34 PDT
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 2004-09-19 11:00:33 PDT
(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 2004-09-19 11:08:06 PDT
(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 2004-09-19 11:40:30 PDT
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 2004-09-19 12:12:16 PDT
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 2004-09-19 12:59:18 PDT
(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 [:bz] (still a bit busy) 2004-09-21 12:04:27 PDT
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 2004-09-21 13:42:54 PDT
(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 2005-09-17 17:08:24 PDT
"(...) 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 (:mats) 2005-09-18 13:16:21 PDT
*** Bug 308946 has been marked as a duplicate of this bug. ***
Comment 18 Mats Palmgren (:mats) 2005-09-18 13:16:30 PDT
Created attachment 196583 [details]
Bug 308946 - Testcase #2
Comment 19 Gérard Talbot 2006-04-24 19:07:23 PDT
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 2006-09-28 15:15:41 PDT
*** Bug 298052 has been marked as a duplicate of this bug. ***
Comment 21 Mike Wilson 2007-09-02 13:43:52 PDT
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 2007-09-03 09:41:57 PDT
> 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 2007-09-03 09:49:44 PDT
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 2007-09-03 13:16:30 PDT
url of that discussion on www-style mailing list:
http://lists.w3.org/Archives/Public/www-style/2007Aug/0139.html
Comment 25 Mike Wilson 2007-09-04 02:50:31 PDT
> 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 2008-03-05 13:10:44 PST
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 2008-03-06 12:09:43 PST
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 2008-07-30 16:24:29 PDT
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 29 David Baron :dbaron: ⌚️UTC-10 2013-08-26 22:56:47 PDT
*** Bug 391528 has been marked as a duplicate of this bug. ***
Comment 30 David Baron :dbaron: ⌚️UTC-10 2013-08-26 23:00:17 PDT
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 2013-11-18 02:29:17 PST
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 32 Boris Zbarsky [:bz] (still a bit busy) 2014-05-18 18:16:57 PDT
*** Bug 939641 has been marked as a duplicate of this bug. ***
Comment 33 brunoais 2014-06-09 06:00:05 PDT
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 2014-06-22 08:32:15 PDT
Is anything blocking this bug other than a lack of volunteers?
Comment 35 David Baron :dbaron: ⌚️UTC-10 2014-06-22 08:45:49 PDT
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.

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