Re: [CSS3] Flexible Flow Module, proposal.

Giovanni Campagna wrote:
> I don't like this proposal, because:
> 

Seems like you are trying to compare XUL flex system with
the 'flow' and flexes of our proposal.

XUL flex system is probably good for the XUL but attempt
to marry it "as is" with the CSS is too straightforward in my opinion.

By the way which one of these:
http://damowmow.com/temp/csswg/flexbox.html
http://xulplanet.com/ndeakin/xul/specs/flexbox.html
defines the subject?

In any case I think that having 8 attributes to define all this is too
much. Almost each attribute in mentioned documents is interacting
with the rest of CSS. That creates pretty complex graph of dependencies.

As an example, what exactly is this:

div {
   box-flex:1;
   width:100px;
   height:100px;
}

? What dimensions the block will have? What if I want it to flex
in horizontal direction only? And so on.

In any case the 'flow' and flex length units solve three
problems:
1) block alignment, horizontal and vertical (e.g. margin:1*, padding:1*);
2) introduces extensible list of various layout managers;
3) adds flexes.

And XUL flex system you refer to seems like is aimed for latter two only.


> 1) What you call flows are actually XUL flexes, and thus should be
> handled with the XUL box model.

What exactly is "XUL box model" and how it is related to "CSS box model"?

> Many of those properties are already implemented in Mozilla (with
> -moz- prefix). You can find them at
> <https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions>
> and you can find a proposal for the Flexible Box at
> <http://damowmow.com/temp/csswg/flexbox.html>.

Seems like each of UAs have its own unique set of features for many
reasons. That does not imply that they should go to the common set.
If FF is using XUL based chrome then it is probably makes sense to
wrap XUL flex model into something CSS-ish.

> I'm sure that a more recent version of that is available as
> member-only, since the Flexible Box Model is referenced in the Current
> Work page for CSSWG.
> (It would be great if the draft could be moved at the public cvs)
> 
> 2) * units don't tokenize as DIMENSION, but rather as NUMBER followed
> by DELIM. Use <fraction> and fr units instead (see Values and Units)
> [CSS3SYNTAX] [CSS3VALUES]

'*' units are already used in the CSS Grid module and CSS Template Layout.
http://www.w3.org/TR/css3-layout/
http://www.w3.org/TR/css3-grid/#lsquo

Seems like many people agreed that 'width:1*' or in short form
just 'width:*' means the same thing. They are also known in html
as relative units and widely used in this form (at least in <frameset>)
so I think it makes sense to keep them that way as web developers are 
already familiar with the notation.

> 
> 3) Combining percentages and lengths with calc() makes flexible units
> mostly useless. For example, if width:50%, margin-left:2* (2fr) with
> margin-right:1* (1fr) is equivalent to margin-left:33,33%
> margin-right:16,67%. If width was 500px, you could write:
> margin-left:calc((100% - 500px) * 0.66); and margin-rigth:calc((100% -
> 500px) * 0.33);
> This includes also the case where padding and borders are present.

Sorry but
margin-right:1* is not even close to margin-right:16,67%

margin-right:1* defines how free space is distributed *after*
computation of all required dimensions including percents.

Values given in '*' units do not change intrinsic min/max dimensions
of elements. margin-right:1* means pretty much this: "move element
to the left as much as possible". Compare it with this
"make right margin of the element of 16,67% of width of its
container. No matter what rest of dimensions are".

I thought that was clear. Seems like I need to put more wording
about it.

> 
> 4 The property for deciding how an element lays out its children is
> "display-model". We don't need a new "flow" property for
> that.[CSS3BOX]

We already sang "Sic transit gloria mundi..." to the 'display-model'.
It was integrated with the 'display' long time ago.

I too think that that was wrong but we are here already.

> 
> 5) The properties for deciding in what direction shall elements be
> layed out are "block-flow" and "writing-mode". This means that
> "horizontal" and "vertical" should be replaced by something not
> necessarily top-bottom. [CSS3TEXTLAYOUT]

The 'flow' defines layout manager - principal way of laying out of 
elements. The 'direction' may specify direction for say flow:horizontal.

I was thinking about adding flow:horizontal | horizontal-ltr | 
horizontal-rtl. Latter two should explicitly define the direction.
So far it was not needed, flow:horizontal happened to be enough.

> 
> 6) The property for deciding if a sequence of inline boxes is splitted
> in various line boxes is "text-wrap", so "horizontal" and
> "horizontal-flow" are the same [CSS3TEXT]

I am not sure I understand this. How is text-wrap related to
the way of replacing blocks?

> 
> 7) The properties for deciding if a sequence of block boxes is
> splitted in various column boxes are "column-count" and
> "column-width", so "vertical" and "vertical-flow" are the same
> [CSS3MULTICOL]

Muulti-columns defines text flow rather than block flow.
These are conceptually different things and I wouldn't mix them.

There are many practical cases where you will want to define
exactly block flow. As an example:
http://www.terrainformatica.com/htmlayout/images/selects2.jpg
- various ways to define replacement of list items.

> 
> Giovanni
> 


-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Saturday, 11 April 2009 20:53:54 UTC