- From: L. David Baron <dbaron@dbaron.org>
- Date: Wed, 4 Jun 2008 22:24:10 -0700
- To: Andrew Fedoniouk <news@terrainformatica.com>
- Cc: www-style@w3.org
On Wednesday 2008-06-04 20:09 -0700, Andrew Fedoniouk wrote: > L. David Baron wrote: >> On Wednesday 2008-06-04 17:50 -0700, Andrew Fedoniouk wrote: >>> Consider following markup: >>> >>> <body> >>> <div>On the top</div> >>> <div>On the bottom</div> >>> </body> >>> >>> and we would like to "stick" second div to the bottom and first one >>> to the top of the view. How would you >>> accomplish that with XUL flexes? Probably I have missed something but >>> that is impossible with XUL flexes. >> >> <body style="display:box; box-orient:vertical"> >> <div>On the top</div> >> <div style="box-flex: 1"></div> <!-- maybe needs 'display: box' ? --> >> <div>On the bottom</div> >> </body> > > David, I think you already know why this is bad. > div in the middle is not a solution if we speak about CSS. I think you're stretching the example, though. The normal reason to want one thing at the top edge and another at the bottom edge is because you have something else that you want to fill the space between them. That said, there are always going to be presentations that authors want that require boxes that don't have a corresponding element in the markup. I agree that we need better mechanisms for generated content. >>> Flexibility is really a length unit rather than some property. >> >> No, since some layout models (traditional document layout) use one >> dimension as input and the other as output; you can only flex in a >> dimension that is input to the algorithm. In the existing CSS >> model, in many cases, there is no sensible height that is input to >> the algorithm (or, depending on how you look at it, multiple heights >> that might be of interest). >> > > I am not sure I understand this: > "you can *only* flex in a dimension that is input to the algorithm" > > This > <body><table width=100% height=100%></table></body> > works perfectly well in Gecko as in other engines. And tables are a separate layout model from block layout, and can (optionally) use the viewport height, or the height of the closest containing block with a fixed height, or maybe something else depending on quirks mode, as input. You can always add more complications to an existing model if you want. So I suppose that point wasn't particularly relevant. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Received on Thursday, 5 June 2008 05:24:48 UTC