WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
18542
Quirks: position: relative; top: 50%; should work
https://bugs.webkit.org/show_bug.cgi?id=18542
Summary
Quirks: position: relative; top: 50%; should work
Eric Seidel (no email)
Reported
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.
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
View All
Add attachment
proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1
2008-04-16 15:27:15 PDT
Created
attachment 20605
[details]
Test case (blue block should be pushed down from top)
Eric Seidel (no email)
Comment 2
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.
Anatoli Papirovski
Comment 3
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.)
Gérard Talbot (no longer involved)
Comment 4
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
Ahmad Saleem
Comment 5
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!
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug