[css-d] ie6/7 shrink-wrapping with floated children

[Mike Wilson]

I'm a little rusty on my hack management, but do I remember
correctly that there is no workaround for the following
IE6 and IE7 bug:

  
  
X
  

(the outer DIVs shrink-wrapping is incorrectly defeated by
the floated child so it instead spans the full page width)

Is the only workaround for the wrong size to set an explicit 
width?

Best regards
Mike Wilson

__
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] relative positioning inside absolute positioned element - why not percentage for top?

[Mike Wilson]

Oops, the phrasing should of course be: 

Compliant browsers should now support percentages on relative 
positioning of an element even when the *containing block's* size 
is dependent on the element's size.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Mike Wilson
> Sent: den 29 augusti 2007 09:26
> To: 'CSS-D'
> Cc: 'Philippe Wittenbergh'
> Subject: Re: [css-d] relative positioning inside absolute 
> positioned element - why not percentage for top?
> 
> Just to close this issue off, I can now report that the latest
> working draft of the CSS 2.1 spec has actually solved the problem
> I mentioned.
> 
> Compliant browsers should now support percentages on relative 
> positioning of an element even when the parent's size is dependent
> on the element's size.
> 
> Though, this support is currently only available in IE but at least
> Mozilla has a bug report for it.
> 
> Best regards
> Mike

__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] relative positioning inside absolute positioned element - why not percentage for top?

[Mike Wilson]

Just to close this issue off, I can now report that the latest
working draft of the CSS 2.1 spec has actually solved the problem
I mentioned.

Compliant browsers should now support percentages on relative 
positioning of an element even when the parent's size is dependent
on the element's size.

Though, this support is currently only available in IE but at least
Mozilla has a bug report for it.

Best regards
Mike



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of fantasai
Sent: den 24 augusti 2007 09:11
To: Mike Wilson
Cc: [EMAIL PROTECTED]
Subject: Re: [CSS21] clarification needed for top and bottom property


Mike Wilson wrote:
> Oh, I would be very happy if browsers actually did support the |top|
> property in this scenario, but Gecko, Safari and Opera all behave the
> same in this respect, ie ignoring it, which is striking when being 
> off-spec.
> 
> We also had a discussion over at css-discuss where arguments were
> laid out why it had to be this way, correlating it to the (natural)
> problems of doing the same with |height| property (that leads to
> recursion). 
> 
> Personally I think it would be possible to fix this for the |top| 
> property, but what do all the browser implementor experts out there 
> say?
> And if the spec wants it to be possible, we may need a clarification
> for "that" so there is no chance of misinterpretation :-).

The spec was actually changed so that percentages for top/bottom *do*
work. Behavior in this case was previously explicitly undefined:
   http://www.w3.org/TR/CSS21/changes.html#q53
So that means at some point the browser implementors discussed it and
decided it should be possible. I guess it just hasn't been done yet. :)

~fantasai



-Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Mike Wilson
Sent: den 23 augusti 2007 16:41
To: [EMAIL PROTECTED]
Subject: [CSS21] clarification needed for top and bottom property


Consider the following example:


  
Some
content
  


See also
http://inigent.se/test/test-top-percentage.html
with the two DIVs styled in color as:
div { border: 1px solid green; }
div div { border: 1px dotted red; }

DESCRIPTION OF EXAMPLE

The two DIVs' sizes will both be based on the size of "Some 
content" and as the outer DIV is positioned it establishes a
positioning context. Following the spec, expectation is that
the inner DIV will be positioned down and right of the outer 
DIV according to the specified percentages. 

OUTCOME

In standard browsers only the right shift happens and the
|top| percentage setting is ignored.
(Notably, IE performs the shift in both directions).

CURRENT SPEC

There are probably good reasons why UAs have chosen to do like 
this, but it cannot be deciphered from the current spec, see
text for |top| property in 9.3.2:
http://www.w3.org/TR/CSS21/visuren.html#propdef-top
Percentages: refer to height of containing block
...
The values for the four properties have the following 
meanings:
...
 
The offset is a percentage of the containing block's width 
(for 'left' or 'right') or height (for 'top' and 'bottom').

As can be seen there is no mention that percentage-based 
positioning is ignored when the containing block's size is 
dependent on the current element.

Contrast this with the |height| property which is also ignored
when assigned a percentage with a dependent containing block
in 10.5 (important part marked with *):
http://www.w3.org/TR/CSS21/visudet.html#the-height-property
Percentages: see prose
...
Values have the following meanings:
...
 
Specifies a percentage height. The percentage is calculated 
with respect to the height of the generated box's 
*   containing block. 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, the 
*   value computes to 'auto'. 

CLARIFICATION

So, if UAs are correct in honoring the |left| property but not 
the |top| property in this example, this could be clarified in
9.3.2 by adding something like the following text to the 
"prose" section:
 
The offset is a percentage of the containing block's width 
(for 'left' or 'right') or height (for 'top' and 'bottom').
*   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, the value for 'top'
*   and 'bottom' computes to 'auto'.

Best regards
Mike Wilson

__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] relative positioning inside absolute positionedelement-why not percentage for top?

[Mike Wilson]

Thanks again for your input and for helping me understand this! 

> > But extending this reasoning to the offset properties, like 
> > left and top, seems unfair as they cannot cause any layout 
> > recursion. The child height and width may cause recursion 
> > as the parent element may base its own size on the child 
> > size, but the parent element will never base its own size 
> > on a child's offset.
> 
> But the % offset for 'top' cannot be computed in your case, as 
> it depends on the height of the containing block, which is 
> _basically_ unknown (it is 'auto').

The algorithm for calculating the actual height (when set to 
'auto') is described in:
  10.6.7 'Auto' heights for block formatting context roots.
where I find the following description:
  "If it has block-level children, the height is the distance 
  between the top margin-edge of the topmost block-level child 
  box and the bottom margin-edge of the bottommost block-level 
  child box. 
  Absolutely positioned children are ignored, and relatively 
  positioned boxes are considered without their offset."

Reading this, especially the phrasing "considered without their
offsets", leads me to think that the rendering is thought to
take place in two phases something like this:
1) Calculate sizes and lay out elements in normal flow
2) Lay out pos:absolute children and shift pos:relative children
   to their final destination.

If this maps well to what implementations can do, then there
wouldn't be a problem using a percentage in (2) as the actual
height was calculated in (1).

Please get me right, I sense that you have a very deep 
understanding of the mechanisms at work here and I primarily
want to have a deeper understanding myself. At my current level
I still cannot deduce from the spec why top offset needs to be 
handled with the same limitations as height. Maybe there are
things I need to know about how UAs normally go about rendering
a page?

(I'm sure there is something solid that forces this, as all
standard browsers do this, but I still fail to see it.)

> I agree that the spec is a little under-defined in this case. Maybe  
> you should take this up with the CSS WG? They might still include a  
> clarification [1].

I'm actually already a subscriber of this list so I'll try and do 
that (though, not being a "regular" on the list I expect to be 
ignored as seems to be the custom for w3c mailing lists ;-).

> For 'left' or 'right' offset, it is based ultimately on the 
> shrink-to-fit algorithm for width
> For 'top' (and 'bottom'), height has no shrink-to-fit possibilities,  
> and hence your top: 50% computes to '0'.

For a casual reader like myself, the shrink-to-fit algo doesn't
appear conceptually different from the "auto height" algo in 10.6.7
I mention above. I would expect these two to create symmetry between
how width and height are handled, albeit with somewhat different
rules as the page flow goes up to down, block elements fill to
available width but not height, etc.

> [2] see towards the end of 10.3.7
> 

Yes, and the corresponding behaviour for height is described in
10.6.4 and our case applies to rule number (3), which makes the
reference to 10.6.7.

Best regards
Mike

__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] relative positioning inside absolute positionedelement- why not percentage for top?

[Mike Wilson]

Thanks for your insights Philippe!

> > Or are you saying that the height of the containing block used for
> > positioning will be different from the calculated size of the actual
> > element? This doesn't seem to be the case as the other, absolutely
> > pos'd, child DIV finds bottom:0 nicely.
> 
> Yes. The height of the parent div (containing block in this case) is  
> 'auto'.
> 'height' refers to a declared value.
> The computed size is a different matter in this case (actual,  
> calculated height).
> The other child div behaves differently because it is _absolute_  
> positioned. Because for absolute positioned elements height can  
> always be resolved.
> Percentage values for height and by extension offset ('top') are a  
> complicated matter. Basically, only absolute positioned element know  
> their 'height' based on the intrinsic values (computed).
> 10.5 states this quite clearly
> 

Ok, looking at 10.5 (and 10.2) I find that when we have
  parent.height = auto
  parent.width = auto
  relativechild.height = nn%
  relativechild.width = nn%
then the CSS rules say that the child height should be reset to auto:
  relativechild.height = auto
and the child width is undefined:
  relativechild.width = 

I can clearly understand why, as a layout calculation would otherwise
easily lead to an endless recursion in the UA.

But extending this reasoning to the offset properties, like left and 
top, seems unfair as they cannot cause any layout recursion. The child
height and width may cause recursion as the parent element may base its
own size on the child size, but the parent element will never base its
own size on a child's offset.

The specification is very clearly written for height percentages (10.5):
  "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, the value computes to 'auto'."
but I lack the corresponding text for top percentages (9.3.2) which
are only specified as "refer to height of containing block".

So, could you comment if my reasoning below is plausible? :

1) The spec doesn't mention special handling of percentage offsets when 
   the parent's size is dependent on child size.
2) Standard browser makers have made an educated guess that the spec's
   reasoning behind height/width should be extended to the offset
   properties (which is not implied by the spec).
3) When I set a top percentage the standard browser resets top to auto
   which is why I see no "upwards shift".
4) When I set a left percentage the standard browser is free to do what
   it prefers as this is undefined and, as they probably reason the 
   way I do above, can calculate the correct widths without risk of 
   recursion and then use a percentage based on that, which is why I do 
   see a "left shift".

> And if you use any other unit of measure (px, em, ex, ...) the  
> relative positioned element will move upwards, because that doesn't  
> depend on the height of the parent element.

Yes, I have noticed this also. Too bad it is 50% of an unknown height
I need ;-).

Best regards
Mike

__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] relative positioning inside absolute positioned element- why not percentage for top?

[Mike Wilson]

[Forwarding Philippe's reply to the list]

On May 10, 2007, at 4:57 PM, Mike Wilson wrote:

> Or are you saying that the height of the containing block used for
> positioning will be different from the calculated size of the actual
> element? This doesn't seem to be the case as the other, absolutely
> pos'd, child DIV finds bottom:0 nicely.

Yes. The height of the parent div (containing block in this case) is  
'auto'.
'height' refers to a declared value.
The computed size is a different matter in this case (actual,  
calculated height).
The other child div behaves differently because it is _absolute_  
positioned. Because for absolute positioned elements height can  
always be resolved.
Percentage values for height and by extension offset ('top') are a  
complicated matter. Basically, only absolute positioned element know  
their 'height' based on the intrinsic values (computed).
10.5 states this quite clearly
<http://www.w3.org/TR/CSS21/visudet.html#the-height-property>

Similarly as with your 'top' offset, your relative positioned element  
won't be able to calculate a height in percentage.

Width is different as it can always be resolved.
(although you might run into problems, depending on how various UA  
will understand the shrinkwrapping of absolute positioned elements.  
Your basic testcase works in current versions of most UA. If it  
becomes more complicated - type of nested elements in your absolute  
positioned div, you'll probably notice differences).

And if you use any other unit of measure (px, em, ex, ...) the  
relative positioned element will move upwards, because that doesn't  
depend on the height of the parent element.



IE Windows is a separate case, there you have the concept of  
'hasLayout' rearing its ugly head.
<http://www.satzansatz.de/cssd/onhavinglayout.html>



> BTW: Just joining the list on Monday it seems my posts are not
> getting through to everybody (can't see my posts in the public
> archive). Is this normal?
That I can't help. Your messages make it to the list.
Maybe you'll need to ask the list admin directly (the email address  
should be listed in the welcoming email you received when you signed up.


Philippe
---
Philippe Wittenbergh
<http://emps.l-c-n.com>





__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

Re: [css-d] relative positioning inside absolute positioned element- why not percentage for top?

[Mike Wilson]

Hi Philippe,

I have put a new test file on 
http://lahall.se/test/test-top-percentage.html

> How much offset for top do you actually expect ?

Half (50%) of the DIV's height (both DIVs have the same height as the
outer DIV adapts to the inner DIV's size).

> CSS 2.1, 9.3.2 Box offsets
> For 'top'
> 
> Percentages:  refer to height of containing block
> 
> But the height of the containing block [1] in this case depends on  
> the element itself (the height is auto), which makes the whole thing  
> pretty much undefined.

The height of the outer DIV is calculated using the rules in 10.6.4
and 10.6.7 so it gets a size adapted to fitting its children. Looking
at the green border indicates that this works correctly.

Or are you saying that the height of the containing block used for
positioning will be different from the calculated size of the actual
element? This doesn't seem to be the case as the other, absolutely 
pos'd, child DIV finds bottom:0 nicely.

Also, what is strange is that standard browsers do use the calculated
width for the "left: -50%" shift. I would have been less surprised if
none of the shifts had worked...

> Then, regarding the computed values for relative positioned boxes,  
> 9.3.2 makes an explicit reference to 9.4.3 [2].
> Result: unless the absolute positioned has a height explicitly  
> declared, the rel. pos. box won't move.

9.4.3 mainly concerns the case when top hasn't been assigned a value
("auto"), right? The relative child has been assigned a top value 
(-50%) so the browser shouldn't have to find out a computed value
in that sense? (Sorry if misunderstanding this)

Anyway, I don't find how top and left are handled differently here
either, so why left gives an effect, but not top, is still a mystery
to me...

> of course, you could make the rel.pos. box an absolute positioned  
> box, and solve the issue.

Unfortunately not, as I need the inner DIV stay relative to have it 
control the size of the parent. The content presented inside the
inner DIV could be of different sizes, and I want it to move halfway
up and left. Then the outer DIV / containing block needs to be of 
the same (unknown) size which is accomplished by using a static or
relative child.

Many thanks for your input. I really hope we can make some sense out
of this!
Best regards
Mike

BTW: Just joining the list on Monday it seems my posts are not 
getting through to everybody (can't see my posts in the public
archive). Is this normal?

__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/

[css-d] relative positioning inside absolute positioned element - why not percentage for top?

[Mike Wilson]

I have a problem with relative positioning, containing block,
and percentages.

I have an absolutely positioned outer DIV, and a relatively 
positioned inner DIV. My goal is to shift the inner DIV 
halfway to the left and up, using percentages. See code 
below:

http://www.w3.org/TR/html4/strict.dtd";>

  

title

  body { margin: 50px; }
  div { border: 1px solid green; }
  div div { border: 1px dotted red; }

  
  

  
Some multi-
line content
  

  


My expectation is to see the text with the red border
shifted both up and left from the green (outer) box. In
standard browsers like Firefox and Opera I only get a shift
sideways and not upwards, though in IE I get both 
directions.

I have been trying to find support for the standard browsers'
behaviour in the CSS spec, but have failed. Sections 9.3.2,
10.6.4 and 10.6.7 suggest, at least to me, that I should be
getting the upwards shift with my layout.

Can anybody point to something that explains this? Did I miss
something in the spec or are both Firefox and Opera wrong
(not likely) ?

Best regards
Mike

__
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
IE7 information -- http://css-discuss.incutio.com/?page=IE7
List wiki/FAQ -- http://css-discuss.incutio.com/
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/