Open Bug 260348 Opened 22 years ago Updated 2 years ago

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

Categories

(Core :: Layout: Positioned, defect)

Product:
Core
Component:
Layout: Positioned
Type:
defect

Tracking

()

People

(Reporter: levin, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(2 files)

Minimal Testcase
716 bytes, text/html
Details
Bug 308946 - Testcase #2
1.02 KB, text/html
Details
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.
Attached file Minimal Testcase —
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.
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.
*** This bug has been marked as a duplicate of 259766 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Component: Layout → Browser-General
Resolution: --- → DUPLICATE
Soryy for the bugspam, I hit the wrong tab.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
restoring previous state, sorry
Component: Browser-General → Layout
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?
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
(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.
(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
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
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
(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
(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"
"(...) 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. ***
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.
*** Bug 298052 has been marked as a duplicate of this bug. ***
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'.
> 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.
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.
url of that discussion on www-style mailing list: http://lists.w3.org/Archives/Public/www-style/2007Aug/0139.html
> 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
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.
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.
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
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.
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'.
Any updates? I have already had issues I have to fix with javascript that, by applying this, would solve my contents displaying issues.
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.
Severity: normal → S3

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.

Flags: needinfo?(dholbert)

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.

Flags: needinfo?(dholbert)

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! :)

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

Attachment

General

Creator:
Created:
Updated:
Size: