Re: Relatively positioned box inside an absolutely positioned box

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.