Re: [css] the 'flow' and flex units

2011-02-26 21:38 EEST: Andrew Fedoniouk:
> I've updated my proposal for flex units and the 'flow' in CSS:

I'd prefer "fl" as the unit (instead of "*") and "flex" or "rflex" for
the "Relative flexes" function (instead of "fx").

About "3.1.1. Margin collapsing in flow:vertical containers":
How does one compute the margins if relative flexes are used in one or
more element?

> Just two additions:
> 1) "template" flow can use ordinals of child elements now. So if you
> have this markup:

I think templates are a nice feature but I'd prefer keeping the flex
units and flow attribute as simple as possible. Therefore, I'd suggest
dropping the "template" feature from the first version to keep it easier
to implement. In addition, putting the template in "flow" property
instead of "display" property as in
will make this specification problematic to integrate with CSS3 layout
in the future.

> 2) The Flex Algorithm.
> The document contains link to the implementation of algorithm
> used for computation of sets of flexible and non-flexible values.
> It is in C++ but code is straightforward - core of the calc() function
> is about 50 lines of code. The implementation is using only integer
> arithmetic so pretty stable and can be used effectively on low-end
> devices.
> In fact this algorithm is used in many places in HTML/CSS even without
> flex units per se, for example:
> 1) computation of 'auto' widths and margins in blocks,
> 2) tables - computation of column/rows distributions,
> 3) frameset layouts, etc.
> At the moment the algorithm is BSD-licensed - please let me know if
> this not permissive enough. I am not that good in "legaleze".

You're using the older 4-clause BSD license variant that has the
advertisement clause. In particular, this part:

	"All advertising materials mentioning features or use
	of this software must display the following
	acknowledgement: This product includes software
	developed by the Terra Informatica Software, Inc".

I believe that this will cause problems for open source implementors
such as Mozilla/Gecko (this causes a conflict with GPL license and as a
result the same code cannot be used as a part of GPL licensed software).

I'd suggest MIT license instead (it's practically the same with the
advertisement clause removed).

About the algorithm:

It seems that the algorithm speaks about width everywhere. Is this
algorithm suitable computing height also? Does it implement all flow
variants? (The required flow variants are "vertical", "horizontal",
"horizontal-flow" and "vertical-flow".) How the caller is expected to
switch to another flow variant?

The struct "engine" should have some comments to explain the usage of
members (e.g. ptotal, vtotalmin, autos). It's hard to guess the real
intent of these members without documentation.


Received on Monday, 28 February 2011 08:32:32 UTC