Re: [CSS3] Flexible Flow Module, proposal.

2009/4/11 Andrew Fedoniouk <news@terrainformatica.com>:
> 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?

I don't know which one the CSSWG adopted as draft, but I know:
- that something along the XUL model is in the charted (see Current Work)
- that the XUL box properties were in the old draft of Advanced Layout

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

It depends on its parent. If its parent has a display of anything but
"box" / "inline-box" (or "flow", or "display-model"), its height and
width are computed as always (box-flex doesn't apply), if its parent
has a display (-model) of "box", its dimensions are computed with the
XUL box model, considering the intrinsic 100px x 100px dimensions.
This means that if there are no siblings and the width / height of
parent is "auto", the <div> is not streched, else it is streched to
fit the whole box (because box-flex is different than "0").
Only one of "width" / "heigth" is changed (the Used Value, not the
Computed), which one depends on the orientation of the parent
("box-orient"). If there are siblings, the box will be streched in a
way that
(new_width - intrinsic_width) : box-flex = (new_width_sibling -
intrinsic_width_sibling) : box-flex_sibling
(assuming that both box-flex are different than "0")

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

Did you forget box-pack and box-align?

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

But David Hyatt noticed that those properties are also in WebKit. So,
if we need a new feature, it probably makes sense to reuse what exists
now (and maybe someone already uses)

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

This doesn't mean that they should used, because they create problems
with tokenization and because alternatives are already present in CSS.
Do you want to have two units (* and fr) for the same purpose?

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

margin-right:1* on its own is margin-right:auto;

but I meant

margin-right:1*;
margin-left:2*;
width:50%

/ equals to /

margin-right:16,67%;
margin-left:33,33%;
width:50%;

Because width must not be auto in order to introduce flexible margins,
with some mathematics you can get it away without flex units (I hope
that width:auto will remain as "margin-box  == parent's width")

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

The problem is...
"Flow" is exactly equal to "display-model". The difference? Probably
just the name.
You wanted to introduce "flow: table". What is the difference with
"display-model:table"?
In addition, with "display-model", you don't need to define the
interaction with "display", that is just a shorthand: that is, you
don't need "flow:default".

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

If I say "block-flow:rl", flow:vertical must become visually
horizontal and right-to-left. So flow:block-progression and
flow:inline-progression; are proably better names (remember that
margins / paddings / borders are rotated when the orientation is
changed, so it doesn't make sense to keep vertical flow, when
flow:vertical)

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

Blocks are inside a line box (they're like inline-block), that is
wrapped according to the appropriate rules (text-wrap, white-space)

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

No it is the same. If you put a block-formatting-context (the only
kind of block that, to me, is not definible by "text flow") inside a
multicolumn block, the former is sized according to the column, it is
splitted if at the end of column (but you can avoid this, with
column-break-inside:avoid), and if there is not enough space, it is
put in the next column.

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

uhm...
<body>
<label>Select:
<select>
<option>...
</select>
</label>
<label>Select multiple:
<select multiple="multiple">
<option>...
</select>
</label>
etc.
<label id="last">Select with h-flow
<select>
<option>...
</select>
</label>
</body>
with

body {
column-count:2;
height:100vh;
}
label {
display:block;
heigth:25%;
}
select {
overflow:auto;
/* appearance:list-menu; */
}
#last {
float:bottom column;
}
#last > select > option {
width:25%;
display:inline-block;
/* appearance:menu-item; */
}
(if instead you wanted less than 4 items per row if space is not
enough, you can use min-width: if 25% is greater than the intrinsic
preferred width then there is more space than needed, else there is
less, and you get the intrinsic width, with blocks wrapped
appropriately)

No flows, no XUL, no flex units. Just multicolumns and plain old percentages.
(the content of <select>s, such as checkboxes and trees, is not relevant now)

>>
>> Giovanni
>>

Received on Sunday, 12 April 2009 16:30:37 UTC