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

-----Original Message----- 
From: Mikko Rantalainen 
Sent: Monday, February 28, 2011 12:31 AM 
To: www-style@w3.org 
Cc: Andrew Fedoniouk 
Subject: 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:
>> http://www.terrainformatica.com/w3/flex-layout/flex-layout.htm
>
>I'd prefer "fl" as the unit (instead of "*") and "flex" or "rflex" for
>the "Relative flexes" function (instead of "fx").

'*' for flexes is on par with other existing flex units use cases
in HTML. See multi-length units in HTML.
Here: http://www.w3.org/TR/html4/present/frames.html#h-16.2.1.1
and here: http://www.w3.org/TR/html4/types.html#h-6.6
The concept is already known to web designers, I think it makes sense
to keep them as they (flexes) were all these years.

As of 'fl' - I've mentioned couple of times on the list already: 
'l' is too easy to mix up with '1' - we should avoid use of this letter
in length units abbreviations as they used inline with digits.

In general such special form of flexes: 1*, 2* highlights "relativeness"
of them. In the same way as percentages do: 10%, 20%.

>
>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?
>

In my implementations I am using straightforward 
max(P.pref,N.pref,BS.pref) for computing overlapping margins but 
something tells me that this is not correct. There is no obvious
physical model for the relative flexes so it is tough to say shall
it be min, max or something else.  Still an open question to be short. 

(BS.pref above is a value of 'border-spacing' defined on container) 

>
>> 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 http://www.w3.org/TR/css3-layout/
>will make this specification problematic to integrate with CSS3 layout
>in the future.
>

In fact templates are simpler than e.g. horizontal-wrap. Or at least
not more complex.

As of 'display' versus 'flow'... I believe this horse is rotten no more. 

Consider this: 
span 
{ 
  display: inline-block;
  flow: "1 2"
        "3 3";     
}
or this:
td.complex 
{ 
  display: table-cell;
  flow: "1 2"
        "3 3";     
}
as you see you cannot use template definition in 'display'.

And in general about the display... I've already used following 
metaphor in one of messages on the list:

The 'display' defines topology of DOM elements, 'flow' defines their 
layout/flow. 

E.g. display:block mandates that its next and previous elements in 
rendering tree to be block alike elements also and element itself 
shall establish box. 'Next' and 'previous' are from topology vocabulary
[http://en.wikipedia.org/wiki/Topology]. 

The 'display' does not define how elements are laid out.
And never actually did. Take a look here:
http://www.w3.org/TR/CSS2/visuren.html#display-prop

If still in doubt then consider this:

table.week-view 
{
  display: table;
  flow: horizontal;
}

or even:

table.clock-face 
{
  display: table;
  flow: radial-cw;
}

To be short: 'display' cannot be used for defining layout 
method as it is about conceptually different entity. 

>
>> 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).

Yep, thanks for that. Changed it to MIT license.

>
>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?

vertical and horizontal flexes are orthogonal in mathematical sense.
The algorithm is used for both directions as "it is". 

>
>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.
>

Yep, done this too. Thanks.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Tuesday, 1 March 2011 05:52:42 UTC