NS_INTRINSICSIZE on reflow branch

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

NS_INTRINSICSIZE on reflow branch

Boris Zbarsky
On reflow branch, is it still possible for the mComputedWidth of a reflow state
to be NS_INTRINSICSIZE?

-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: NS_INTRINSICSIZE on reflow branch

L. David Baron
On Monday 2006-04-24 22:42 -0500, Boris Zbarsky wrote:
> On reflow branch, is it still possible for the mComputedWidth of a reflow
> state to be NS_INTRINSICSIZE?

Not for non-replaced blocks.  I put an assertion in the reflow state
Init method, but it's still not quite right.  (It fires for every
bullet.)

And probably it shouldn't ever be NS_INTRINSICSIZE for form controls
either, since they have block-like stuff on the inside.

-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
Reply | Threaded
Open this post in threaded view
|

Re: NS_INTRINSICSIZE on reflow branch

Boris Zbarsky
In reply to this post by Boris Zbarsky
L. David Baron wrote:
> And probably it shouldn't ever be NS_INTRINSICSIZE for form controls
> either, since they have block-like stuff on the inside.

Right, that's what I ran into.  Right now what I'm doing for buttons is in their
Reflow method I do:

   nsHTMLReflowState reflowState(aReflowState);
   if (reflowState.mComputedWidth == NS_INTRINSICSIZE) {
     nscoord prefWidth = GetPrefWidth(aReflowState.rendContext);
     nscoord availWidth = reflowState.availableWidth -
       reflowState.mComputedBorderPadding.LeftRight() -
       reflowState.mComputedMargin.LeftRight();
     availWidth = PR_MAX(0, availWidth);
     reflowState.mComputedWidth = PR_MIN(prefWidth, availWidth);
   }

and then use that reflowState thereafter.  This does lead to slightly weird
results when a button with a bunch of text comes at the end of a line, but no
weirder than what we do now, and using the CB computed width instead of
availableWidth wouldn't play nice with floats, as far as I can tell.

I just realized I should probably take PR_MAX(GetMinWidth, the stuff above),
actually, which makes it look awfully like shrink-wrap width for blocks.  I
guess that makes sense.

I guess I could try to push that logic up into the reflow state; something along
those lines should be relevant for buttons, text inputs, and textareas, right?

-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: NS_INTRINSICSIZE on reflow branch

L. David Baron
On Tuesday 2006-04-25 10:31 -0500, Boris Zbarsky wrote:

> L. David Baron wrote:
> >And probably it shouldn't ever be NS_INTRINSICSIZE for form controls
> >either, since they have block-like stuff on the inside.
>
> Right, that's what I ran into.  Right now what I'm doing for buttons is in
> their Reflow method I do:
>
>   nsHTMLReflowState reflowState(aReflowState);
>   if (reflowState.mComputedWidth == NS_INTRINSICSIZE) {
>     nscoord prefWidth = GetPrefWidth(aReflowState.rendContext);
>     nscoord availWidth = reflowState.availableWidth -
>       reflowState.mComputedBorderPadding.LeftRight() -
>       reflowState.mComputedMargin.LeftRight();
>     availWidth = PR_MAX(0, availWidth);
>     reflowState.mComputedWidth = PR_MIN(prefWidth, availWidth);
>   }
>
> and then use that reflowState thereafter.  This does lead to slightly weird
> results when a button with a bunch of text comes at the end of a line, but
> no weirder than what we do now, and using the CB computed width instead of
> availableWidth wouldn't play nice with floats, as far as I can tell.
>
> I just realized I should probably take PR_MAX(GetMinWidth, the stuff
> above), actually, which makes it look awfully like shrink-wrap width for
> blocks.  I guess that makes sense.

Yep.

> I guess I could try to push that logic up into the reflow state; something
> along those lines should be relevant for buttons, text inputs, and
> textareas, right?

Yes, although it's a little less interesting for other form controls
where min-width == pref-width (at least in the absence of percentage
widths).

-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