297445 - text elements interact strangely with XUL flex

Status: RESOLVED INVALID

(Core :: XUL, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

In the attached test case, there are two vboxes.  Both have three vboxes in
them, with flex of "60", "100", "140".  In the first column, the boxes have
labels as children; in the second column, they do not.

I'd expect the boxes to be exactly the same size, but the <label>'s seem to be
screwing up the flex computations.  Not sure what's going on..

(Cc'ing shaver and pav as this is blocking some calendar view design)

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: flex test case

Comment 2

[Boris Zbarsky [:bzbarsky]]

Flex affects how _extra_ space is allocated.  In your testcase, both vboxes are
300px tall.  So the one without labels takes the space needed by the child
vboxes (0, since they have no content), and allocates the remaining space
(300px) according to the flex attributes (in a 3:5:7 ratio, so the vboxes end up
60, 100, and 140 px tall respectively).  The one _with_ labels takes the space
needed by the child vboxes (space enough for 3 lines of text; let's assume that
the text is 20px tall for ease of computation) and allocates the remaining space
(240px) in a 3:5:7 ratio.  That would make the boxes 20px plus the flex tall
(68, 100, and 132 px, to be exact).

For what you seem to want (allocation of total space, not available space), you
probably want to use percentage heights instead of flex.

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #2)
> Flex affects how _extra_ space is allocated.

Hmm, ok, that sort of makes sense to me, though I'm not sure if it's all that
intuitive.

> For what you seem to want (allocation of total space, not available space), you
> probably want to use percentage heights instead of flex.

You're right, I do -- except that percentages don't seem to work/be supported
for XUL width/height. =/

Comment 4

[Boris Zbarsky [:bzbarsky]]

> though I'm not sure if it's all that intuitive.

Complaints to hyatt/evaughan/etc, please.  ;)

> except that percentages don't seem to work/be supported for XUL width/height. =/

Looks like we treat percentages as the same as pixels or something...  XUL and
presentational attributes is such a mess.  :(  You could use style="height:
nn%"; that should work.

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #4)
> > except that percentages don't seem to work/be supported for XUL width/height. =/
> 
> Looks like we treat percentages as the same as pixels or something...  XUL and
> presentational attributes is such a mess.  :(  You could use style="height:
> nn%"; that should work.

Nope.. CSS height/width seem to be completely ignored if they're specified as
percentages.  Looking at the box object/box layout interfaces I don't even think
that percentages can be supported without changing all sorts of things.  I've
moved to using a <stack> and positioning things myself, but now I get to deal
with very laggy behaviour as my layout code doesn't directly participate in
reflow, but can only react when a resize event is posted or similar.  (Not to
mention that a <stack> currently can't ever shrink smaller than its biggest
element, so if you have an element where one dimension is supposed to match the
stack, but you want the stack size to be flexible, you currently lose.)  It's
all terribly exciting.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Mike, Neil, is there a way to do what vlad is trying to do here?

Comment 7

[[e-mail]]

(In reply to comment #6)
>Neil, is there a way to do what vlad is trying to do here?
Well, to solve the display issue as shown I would just switch to a grid ;-)
I tried all sorts of things that I thought might alter the box model, but only
one worked, and that was to set a CSS height of 1px on each label. By my reading
of nsBox.cpp a CSS height of 0% should work, but I had no luck with that :-/