Abs pos frames on reflow branch

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Abs pos frames on reflow branch

Boris Zbarsky
So the reflow branch code for reflowing an abs pos frame (in
nsAbsoluteContainingBlock::ReflowAbsoluteFrame) uses

   nsSize(aReflowState.mComputedWidth, NS_UNCONSTRAINEDSIZE)

for the child reflow state.  Two questions:

1)  If the abs pos container is a positioned inline, aReflowState.mComputedWidth
     will be NS_INTRINSICSIZE.  This doesn't look right to me.
2)  Shouldn't the available width be the containing block width if available, in
     this case?  And if not available, then mComputedWidth +
     mComputedPadding.LeftRight() ?

-Boris
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Abs pos frames on reflow branch

L. David Baron
On Thursday 2006-04-27 16:23 -0500, Boris Zbarsky wrote:

> So the reflow branch code for reflowing an abs pos frame (in
> nsAbsoluteContainingBlock::ReflowAbsoluteFrame) uses
>
>   nsSize(aReflowState.mComputedWidth, NS_UNCONSTRAINEDSIZE)
>
> for the child reflow state.  Two questions:
>
> 1)  If the abs pos container is a positioned inline,
> aReflowState.mComputedWidth
>     will be NS_INTRINSICSIZE.  This doesn't look right to me.
> 2)  Shouldn't the available width be the containing block width if
> available, in
>     this case?  And if not available, then mComputedWidth +
>     mComputedPadding.LeftRight() ?
I agree that this seems wrong for inlines, and that it should include
padding for blocks.  But for inlines, according to CSS2.1, it *should*
actually be based on the position of the inlines, not the blocks.

http://www.w3.org/TR/CSS21/visudet.html#containing-block-details

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Abs pos frames on reflow branch

Boris Zbarsky
In reply to this post by Boris Zbarsky
L. David Baron wrote:
> I agree that this seems wrong for inlines, and that it should include
> padding for blocks.  But for inlines, according to CSS2.1, it *should*
> actually be based on the position of the inlines, not the blocks.
>
> http://www.w3.org/TR/CSS21/visudet.html#containing-block-details

Right.  For an inline, we pass in aContainingBlockWidth -- see
<http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsInlineFrame.cpp&rev=3.247.2.2&mark=1202-1205,1212#1200>.
  So I'd say maybe do something like:

   nscoord availWidth = aContainingBlockWidth;
   if (availWidth == -1) {
     NS_ASSERTION(aReflowState.mComputedWidth != NS_UNCONSTRAINEDSIZE,
                  "Must have a useful width _somewhere_");
     availWidth =
       aReflowState.mComputedWidth + aReflowState.mComputedPadding.LeftRight();
   }

and use that as the available width.  Seem reasonable?
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Abs pos frames on reflow branch

L. David Baron
On Thursday 2006-04-27 18:39 -0500, Boris Zbarsky wrote:

> L. David Baron wrote:
> >I agree that this seems wrong for inlines, and that it should include
> >padding for blocks.  But for inlines, according to CSS2.1, it *should*
> >actually be based on the position of the inlines, not the blocks.
> >
> >http://www.w3.org/TR/CSS21/visudet.html#containing-block-details
>
> Right.  For an inline, we pass in aContainingBlockWidth -- see
> <http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/generic/nsInlineFrame.cpp&rev=3.247.2.2&mark=1202-1205,1212#1200>.
>  So I'd say maybe do something like:
>
>   nscoord availWidth = aContainingBlockWidth;
>   if (availWidth == -1) {
>     NS_ASSERTION(aReflowState.mComputedWidth != NS_UNCONSTRAINEDSIZE,
>                  "Must have a useful width _somewhere_");
>     availWidth =
>       aReflowState.mComputedWidth +
>       aReflowState.mComputedPadding.LeftRight();
>   }
>
> and use that as the available width.  Seem reasonable?
Yep.

Although, given the two extra parameters this code passes to the reflow
state constructor, does this even matter?

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Abs pos frames on reflow branch

Boris Zbarsky
In reply to this post by Boris Zbarsky
L. David Baron wrote:
> Although, given the two extra parameters this code passes to the reflow
> state constructor, does this even matter?

Without that change, exercising this code leads to:

175       NS_ASSERTION(availableWidth != NS_UNCONSTRAINEDSIZE,
176                    "shouldn't use unconstrained widths anymore");

being hit at the top of nsHTMLReflowState::Init.  I think that assert is correct....

-Boris
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|

Re: Abs pos frames on reflow branch

Boris Zbarsky
In reply to this post by Boris Zbarsky
L. David Baron wrote:
>> and use that as the available width.  Seem reasonable?
>
> Yep.

I've gone ahead and done that:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/layout/generic&command=DIFF_FRAMESET&file=nsAbsoluteContainingBlock.cpp&rev1=1.69.6.2&rev2=1.69.6.3&root=/cvsroot

-Boris
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout