Re: Relatively positioned box inside an absolutely positioned box

Oops, I accidentally messed up the example, here is new url: http://jsbin.com/unupum/1/edit

On Jul 4, 2013, at 9:37 AM, Glen Huang <curvedmark@gmail.com> wrote:

> Sorry for the late reply.
> 
> Thank you for bearing with me so far. I know what you were saying are all conjectures, but they are very reasonable  and I thought that must be the reason, until I come up with this new example: http://jsbin.com/odubaw/1/edit
> 
> Now #d2 is an in-flow element that engages in an inline formatting context, and #d1 doesn't have an explicit width. This should replicate the situation in the previous example only with the horizontal dimension now runs the risk of having circular reference, and the left property should stop working, but somehow all major browsers work as intended this time.
> 
> I'm not sure what to take of it.
> 
> I also went ahead and opened an issue in the w3 issue tracker, but no much has been going on: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22474
> 
> On Jun 25, 2013, at 7:07 PM, Lev Solntsev <greli@mail.ru> wrote:
> 
>> Glen Huang <curvedmark@gmail.com> wrote Tue, 25 Jun 2013 08:57:25 +0400:
>> 
>> I know you said below that out of flow children are exceptions. but the point here is that browsers are able to calc the height of elements that depends on content height before the elements are closed, even though it's very expensive like you said.
>> I don't think it's expensive in this case. Since they are out of the flow and have no impact on the document and no circular references, they can be just rescheduled for computing later when the height is already known.
>> 
>> I must state that all what I'm saying is just my thinking, based on my knowledge of specification, how browsers work in general, and programming basics. I never had a look into a real browser engine, and a real engine can have own implementation peculiarities.
>> 
>> This explains a lot, but where do you get that conclusion? The CSS spec doesn't seem to have stated that. Or did you inferred it from the definitions of height, min-height and alike properties?
>> In your case I think it's
>> “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
>> as Gérard Talbot stated it in his answer. Chapter “10 Visual formatting model details” contains all that complex topic about computing styles.
>> Generally, I'm basing on my experienced, read articles and discussions in this mailing list. There where a lot about CSS 2 couple years ago. BTW, CSS 2.1 specification was written with taking in account browser vendor considerations. Subjects that are difficult to implement, very complex or have lack of implementation were punted (like text-shadow) or undefined (like relative positioning or min/max-width on tables). That's why I'm telling about browser point of view.
>> 
>> I can understand the rational behind the conclusion is to avoid self-dependence, for a in-flow child needs to know the height of its containing block, it's very likely to change it's own height, and thus in turn changes the containing block's height.
>> Like I said, it's a complex topic. There a lot of possibilities circular references, even non-obvious like appearing scrollbars in the viewport or element with ‘overflow: auto’.
>