W3C home > Mailing lists > Public > www-style@w3.org > June 2013

Re: Relatively positioned box inside an absolutely positioned box

From: Lev Solntsev <greli@mail.ru>
Date: Sun, 23 Jun 2013 14:45:53 +0400
To: "Glen Huang" <curvedmark@gmail.com>
Cc: "W3C www-style mailing list" <www-style@w3.org>
Message-ID: <op.wy4n6reg39dhqv@lev-pc>
Glen Huang <curvedmark@gmail.com> wrote Sun, 23 Jun 2013 13:07:04 +0400:

> 1. Since "left: -50%" for #d2 works, and the property "left" is  
> calculated exactly the same as property "top", IIRC, only relative to  
> >different values (both of which have a computed value 'auto' in the  
> example), why does one work the other doesn't?
>
> 2. I can understand the rational behind 'max-height' is to avoid  
> self-dependence, but the 'top' value of a relatively positioned box can  
> >not possibly change the height of the box, thus it will never have the  
> self-dependence problem as 'max-height' does. So if the spec were >to  
> specify that when a relatively positioned box's containing-block height  
> depend on content height, its percentage top should be 0, it >wouldn't  
> have made sense.
I believe the reason is that at the time browser resolves #d1's height for  
calculating #d2 it isn't known yet. There could be next sibling elements  
which add height and weren't calculated yet. Since the height cannot be  
truly resolved it computes to 0. Browsers need to work very fast to  
achieve reasonable rendering time, so they do only things which could be  
done quickly.

Actually there is workaround for the case. Instead of ‘position: relative’  
you can use modern alternative – transform (what ‘position: relative’ is  
really should be) which behaves in the desirable way:

     #d2 {
         transform: translate(-50%, -50%);
     }

Within transforms percentage values refer to the bounding box of the  
element itself, so there is no problem with computing a value. CSS  
Transforms module is still working draft but it's mature enough. Every  
browser has implemented it and prefixes where dropped a year ago.
Received on Sunday, 23 June 2013 10:46:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC