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
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
