Bug 18542 - Quirks: position: relative; top: 50%; should work
Summary: Quirks: position: relative; top: 50%; should work
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-16 15:25 PDT by Eric Seidel (no email)
Modified: 2022-07-23 04:32 PDT (History)
8 users (show)

See Also:


Attachments
Test case (blue block should be pushed down from top) (171 bytes, text/html)
2008-04-16 15:27 PDT, Eric Seidel (no email)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2008-04-16 15:25:46 PDT
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.
Comment 1 Eric Seidel (no email) 2008-04-16 15:27:15 PDT
Created attachment 20605 [details]
Test case (blue block should be pushed down from top)
Comment 2 Eric Seidel (no email) 2008-04-16 17:09:18 PDT
Hyatt mentioned over IRC that he'd found the bug, but that it might not even be worth fixing.
Comment 3 Anatoli Papirovski 2008-04-16 19:00:22 PDT
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.)
Comment 4 Gérard Talbot 2009-09-04 19:20:35 PDT
> 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
Comment 5 Ahmad Saleem 2022-07-23 04:32:27 PDT
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!