Re: Positioned Layout proposal

> ?--------------------------------------------------
> From: "Shelby Moore" <shelby@coolpage.com>
> Sent: Friday, October 22, 2010 5:05 AM
> To: "Boris Zbarsky" <bzbarsky@MIT.EDU>
> Cc: "www-style list" <www-style@w3.org>
> Subject: Re: Positioned Layout proposal
>
>>> On 10/21/10 3:35 PM, Shelby Moore wrote:
>>>> Those 1000s of elems on page are mostly inline content.
>>>
>>> In the cases that worry me, they're mostly absolutely positioned,
>>> floated, table cells, blocks, etc.
>>
>> Well if they are absolutely positioned, then there is much less of a
>> constraint to solve. Tables cells is a repeating structure with a
>> defined
>> semantics.
>>
>> I am also skeptical as to whether we can generalize, maintain
>> performance
>> and avoid nasty circularity errors. So I wouldn't dare propose something
>> for implementation which wasn't well understood by that time. So please
>> do
>> not be concerned that I am trying to shove some insane thing down the
>> implementor's throats (I couldn't any way obviously).
>>
>> Perhaps I can allocate more time thinking about this at some point,
>> because CSS as it is now really frustrates me. The tsuris seems mostly
>> to
>> revolve around the fact that CSS is not designed to support the new Web
>> applications which want to keep all their content inside the viewport
>> and
>> create overflowed scrolled sub-areas instead of overflowing the
>> viewport.
>>
>> Am I missing some easy way to do the following example?
>>
>> For example, I current have a need to do something like this for my
>> social
>> network site:
>>
>> <div>some header content, even has a float:right so it fills the width
>> of
>> viewport</div>
>> <table>
>>   <tr>
>>      <td><div id='leftPane' style='width:50em; height:?;
>> overflow:auto'></div>
>>      <td><div id='rightPane' style='width:?; height:?; overflow:auto'>
>>                <textarea...><textarea>
>>                <div id='ChatText' style='width:30em; height:?;
>> overflow:auto'></div>
>>             </div>
>> </table>
>>
>> What I want is for those height:? to fill up the viewport from their
>> inline locations to the bottom of the viewport. Ditto the width:? for
>> the
>> viewport width. So I never want the viewport to scroll, I just want my
>> overflow:auto to absorb all the overflow.
>
> As far as I understand you will need flex units with template layout here.
>
> With flex units and the flow this layout can be defined as
>
> <style>
> body
> {
>    flow: "1 1"  // header (first child) spans two columns
>          "2 3"; // leftPane, rightPane
>    width:*;
>    height:*; // spans whole viewport
> }
> </style>

Note I could not obtain the layout I want using <table> because see the
single '?' in following example:

<body style='margin:0'>
  <table style='margin:0; width:100%; height:100%'>
    <tr>
      <td colspan='2'>
        <div>some header content, even has a float:right so it fills the
width of viewport</div>
    <tr>
      <td>
        <div id='leftPane' style='width:50em; height:100%;
overflow:auto'></div>
      <td>
        <div id='rightPane' style='width:100%; height:100%; overflow:auto'>
          <textarea...><textarea>
          <div id='ChatText' style='width:30em; height:?;
overflow:auto'></div>
        </div>
  </table>
</body>

In the above <table> example, is it correct that the contained 100%
settings refer to the computed values of their parent and not to the
viewport? I hope so. But still I have the problem of the height of the
ChatText above.

below...

> <body>
>   <div>
>      some header content, even has
>      a float:right so it fills the width of viewport</div>
>   </div>
>   <div id='leftPane' style='width:50em; height:*;
>                                   overflow:auto'>
>   </div>
>   <div id='rightPane' style='width:*; height:*; overflow:auto'>
>       <div id='ChatText' style='width:30em; height:*;
> overflow:auto'></div>
>       <textarea...><textarea>
>   </div>
> </body>
>
> '*' above is '1*' - one unit of free space left in container.

Afaics that doesn't work, because of the same reason that <table> doesn't
work above, as the height of the ChatText is wrong. I want the ChatText to
extend from the bottom of the <textarea...> to the bottom of the viewport.

Note I see you moved my <textarea...> below the ChatText, but that is
irrelevant.

I think we can fix it though, using one more nesting of rows for the right
pane?

So then yes, Flexbox will solve it (because it supports the concept of
filling up the unused space of an intrinsically sized element), where
<table> can not.

> div#ChatText will expand to the height of 'rightPane' pane minus
> height of the textarea so textarea will be at the very bottom of
> rightPane.

Oh it will?  I thought you would need to specify another column of rows in
the Flexbox syntax.  In any case, I think we agree that Flexbox would
enable the semantics I want to express in the above example.

However, as Tab Atkins pointed out, Flexbox won't express all the possible
semantics or relative layout. Flexbox is suited to minimizing unused space
within a container.  Flexbox does nothing for generalized relative
placement of elements.

> Obviously you do not need any artificial DOM elements here.
>
> See: "3.5. flow:"template"" in
> http://www.terrainformatica.com/w3/flex-layout/flex-layout.htm

Oh I see, you were using Flex-Layout syntax, not Flexbox.  Any way, I
think Flexbox can handle it too, just need another column of rows within
the right pane.

> To calculate flex units you will not need generic constraint solver.
> The algorithm of flex computations is not more complex than for tables.

Agreed.  Flexbox is only just a relative width property for tables.  It is
a very simple conceptuation extension of tables and will be very helpful.
We should do that first, before any attempt at a more generalized relative
positioning constraint solution.

> Or did I miss something in your messages?

You got it. Thanks.

>> What I am forced to do now is use JavaScript on a viewport load and
>> resize
>> events, to calculate those. It is very messy and obfuscates the
>> semantics
>> of my layout.
>>
>> With the generalized edge based layout proposed in this thread, I could
>> easily achieve the above example.

Received on Saturday, 23 October 2010 14:39:20 UTC