18542 2008-04-16 15:25:46 -0700 Quirks: position: relative; top: 50%; should work 2022-07-23 04:32:38 -0700 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) Mac OS X 10.5 NEW P2 Normal --- 1 eric webkit-unassigned ahmad.saleem792 apapirovski ap bfulgham browserbugs2 hyatt rniwa simon.fraser oldest_to_newest 77868 0 eric 2008-04-16 15:25:46 -0700 Quirks: position: relative; top: 50%; should work Hyatt says that 50% would be 0 in standards mode (since the root element has height: auto in standards. However in quirks mode, the root should be as tall as the viewport. So this should work in quirks. http://www.toyota.com.tw/event/200707_service/ depends on this behavior. 77869 1 20605 eric 2008-04-16 15:27:15 -0700 Created attachment 20605 Test case (blue block should be pushed down from top) 77875 2 eric 2008-04-16 17:09:18 -0700 Hyatt mentioned over IRC that he'd found the bug, but that it might not even be worth fixing. 77881 3 apapirovski 2008-04-16 19:00:22 -0700 As far as I'm concerned the spec says something different. In CSS 2.1 (http://www.w3.org/TR/CSS21/visuren.html#position-props) this section was removed: "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'." and there is no loger any mention of special case for height auto resulting in top: 0; which leads me to believe that we should be calculating the content height for the container and then using that as base value. (So not 100% in the case of body, but whatever the content height is.) Have I missed something in the spec? (I've got a patch ready for syncing-up our behavior to Firefox 3, which is only applying percentage top and bottom values if the parent height is either fixed or percentage, not auto.) 144978 4 browserbugs2 2009-09-04 19:20:35 -0700 > Have I missed something in the spec? Yes, I believe so. Bug 14749 comment #14 Bug 26396 has more details. References ---------- * "Percentages: refer to height of containing block" coming from CSS 2.1, Section 9.3.2 Box offsets: 'top', 'right', 'bottom', 'left' http://www.w3.org/TR/CSS21/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/CSS21/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'." coming from CSS 2.1, Section 10.5 Content height: the 'height' property http://www.w3.org/TR/CSS21/visudet.html#the-height-property The decisive factor to consider is a) when the containing block has a specified height or (versus) b) when the containing block does not have a specified height: its height depends on its content (intrinsic height). bugzilla.mozilla.org, bugs.kde.org all have bug reports on this issue. regards, Gérard 1886189 5 ahmad.saleem792 2022-07-23 04:32:27 -0700 I am not sure on what is expected behavior and which browser to align but Safari 15.6 on macOS 12.5 aligns with Chrome Canary 106 and shows the blue box down while Firefox Nightly 104 show the blue box just below the text based on attached test case. Just wanted to share latest testing results. Thanks! 20605 2008-04-16 15:27:15 -0700 2008-04-16 15:27:15 -0700 Test case (blue block should be pushed down from top) test.html text/html 171 eric PHN0eWxlPgpkaXYgewogIHBvc2l0aW9uOiByZWxhdGl2ZTsKICB0b3A6IDUwJTsKICB3aWR0aDog MTAwcHg7CiAgaGVpZ2h0OiAxMDBweDsKICBiYWNrZ3JvdW5kOiBibHVlOwp9Cjwvc3R5bGU+CkJs dWUgYmxvY2sgc2hvdWxkIGJlIHB1c2hlZCBkb3duIGZyb20gdGhlIHRvcC4KPGRpdj4KPC9kaXY+