W3C home > Mailing lists > Public > www-style@w3.org > June 2008

Re: Publishing the flexible box model

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Thu, 05 Jun 2008 00:32:51 -0700
Message-ID: <484796A3.60507@terrainformatica.com>
To: "L. David Baron" <dbaron@dbaron.org>, www-style@w3.org

L. David Baron wrote:
> On Wednesday 2008-06-04 17:50 -0700, Andrew Fedoniouk wrote:
>>   flow:horizontal; /* all children form single row */
> 
> I've been thinking about this a little more.  I think my main
> problem with what you're proposing is this:
> 
> You're proposing that we take the CSS box model, with all its
> complexity -- things like margin collapsing, flow around floats,
> doing intrinsic width calculation in the presence of floats and
> containers that establish new block formatting contexts, and make
> this whole complicated thing work in both horizontal and vertical
> orientation (and mixing orientations).  I don't think all of these
> pieces are needed for user interface layout, and I worry that this
> whole mess put together will collapse under the weight of its own
> complexity.

My solution (@flow + flex units) solve multiple existing problems:
1) vertical alignment and positioning
2) flex layouts.
3) real sidebar/statusbar/toolbar layouts.

And your solution appears as a foreign entity for CSS. Here is an 
example from document you have provided:
   button
   {
       box-flex: 1.0;
       width: 100px;
   }

So what is the width of the button? Is it defined by @box-flex or
by the @width? And how all this plays with min/max-widths?

To avoid any logical conflicts it should be just:

   button
   {
       width: 1*;
   }

with optional min/max-widths.


I've implemented flex units in the engine that supports CSS2.1 pretty 
much in full. flex units implementation is around 2500 lines in total 
(C++). Flex units can be added in *any* existing CSS engine.
Particular mileage for particular engine may vary but magnitude is as such.


> 
> I'd rather start with something simpler that doesn't have these
> complications, where maybe we have a chance of defining sensible
> intrinsic dimensions in the presence of switches between horizontal
> and vertical layout (which is complicated enough already).
> 

David, I have an impression that time to *start with* flexes passed
years ago. And yet I do not think that CSS as a public standard has
such luxury to "start with something simpler". Either flexes are there 
either not.

> 
> I think your solution does solve a pretty similar set of problems.
> But I disagree with your claim that it's simpler.  I think by
> reusing the existing, complicated model, it's actually more complex
> than a cleaner break that introduces more new properties.  (I'd even
> agree that there are advantages to reusing the same model; I just
> don't think simplicity is one of them.)
> 

My solution (@flow + flex units) solve multiple existing problems:
1) vertical alignment and positioning,
2) flex layouts,
3) real sidebar/statusbar/toolbar layouts.

My solution is simpler in the following sense:

Each new attribute added to CSS potentially adds new dimension
to the CSS space. Each attribute may affect others.

For example: by adding 'box-direction' you effectively create
construction orthogonal to say 'direction' attribute. You need
to spec and implement full matrix of intersection of their values.
The same is about all other attributes you propose.

That is why I wouldn't say that your solution is less complex
than mine.

-- 
Andrew Fedoniouk.

http://terrainformatica.com
Received on Thursday, 5 June 2008 07:33:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:07 GMT