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

Re: Relatively positioned box inside an absolutely positioned box

From: Glen Huang <curvedmark@gmail.com>
Date: Sun, 23 Jun 2013 19:37:57 +0800
Cc: "W3C www-style mailing list" <www-style@w3.org>
Message-Id: <E0ADAF89-094B-4509-AF51-02F70E807114@gmail.com>
To: Lev Solntsev <greli@mail.ru>
> I believe the reason is that at the time browser resolves #d1's height for calculating #d2 it isn't known yet.

If that's the reason, why do browsers support the :last-child selector? It has the same problem.

Since you are saying the problem lies within browsers themselves. Can I assume that CSS2.1 does allow centering boxes this way, but all major browsers choose not to comply? Or the spec is vague about this, and thus browsers choose to compute to 0 as you said?

> Actually there is workaround for the case

Wow, didn't think of it. This is a nice trick. Thanks for the heads up. Will apply it in the future. Still, my current goal is to really understand how some strange effects in CSS come in being.

Glen

On Jun 23, 2013, at 6:45 PM, Lev Solntsev <greli@mail.ru> wrote:

> 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 11:38:29 UTC

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