Re: [CSS3] Flexible Flow Module, proposal.

Giovanni Campagna wrote:
> 2009/4/12 Andrew Fedoniouk <news@terrainformatica.com>:
>> Giovanni Campagna wrote:
>>> 2009/4/11 Andrew Fedoniouk <news@terrainformatica.com>:
>>>> Giovanni Campagna wrote:
...
>> I think that XUL by itself can
>> benefit from adopting proposed flow and flex units.
>>
>> Flexible Flow Module introduces just two entities: the 'flow' attribute
>> and flex units but it is functional *superset* of XUL flex model.
>>
>> I mean that XUL flex DOM attributes can be mapped to the 'flow' and flex
>> units without any limitations.
> 
> Ok. But if we can do that without forgetting existing and implemented
> properties, everybody will benefit.
> 

Which "existing and implemented properties" you are talking about?

>>>>> 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.
> 
> They cannot be used anymore in conforming HTML(5) documents.

I am not sure I understand why HTML5 is relevant to this discussion.

> 
>>> 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?
>> I am not aware of any problems with tokenization of flex units.
>>
>> In the same way as lexical scanner can recognize '2%' it will also
>> recognize '2*'. Not a problem at all.
>>
>> Consider this:
>> http://www.w3.org/TR/CSS21/grammar.html#scanner
>>
>> {num}{E}{M}             {return EMS;}
>> {num}{E}{X}             {return EXS;}
>> ...
>> {num}{H}{Z}             {return FREQ;}
>> {num}{K}{H}{Z}          {return FREQ;}
>> {num}{ident}            {return DIMENSION;}
>>
>> {num}%                  {return PERCENTAGE;}
>> {num}*                  {return FLEX;}
>> {num}                   {return NUMBER;}
>>
>> I have added this line above:
>> {num}*                  {return FLEX;}
>>
>> And it does not conflict with anything in CSS grammar.
>>
> 
> That is the second grammar. I meant the core grammar, at
> <http://www.w3.org/TR/CSS21/syndata.html#tokenization> and
> <http://www.w3.org/TR/css3-syntax/#tokenization>, and the core grammar
> cannot be changed.

Could you remind me where "the core grammar
cannot be changed" is stated?

Or at least what exactly fuels your feeling that extending length units
by flexes in '{num}*' form is impossible?

> 
>>>>> 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%;
>> You have missed one point. Flowed elements with default
>> value of the 'overflow' (visible) cannot have
>> width less than their intrinsic min width set. Flowed elements
>> behave as table cells in this respect - they never overflow
>> (if they have overflow:visible)
>>
>>
>> See: http://www.terrainformatica.com/w3/flex-layout/flex-layout.htm
>> Chapter #2.
>>
>> So this:
>>
>>  margin-right:1*;
>>  margin-left:2*;
>>  width:50%
>>
>> is in fact:
>>
>>  margin-right:1*;
>>  margin-left:2*;
>>  width:50%;
>>  min-width:min-intrinsic;
>>
>> And this case is in principle not reproducible by the calc().
> 
> I don't like this (boxes should wrap or overflow), but it is anyway a feature.

So you have a feeling that this:
http://www.terrainformatica.com/w3/w3c-fp.jpg
is how people should see that pages on small screens?

> 
>>> 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")
>> Flex units are implicitly used in <table> layout in HTML.
>> So far <table> layout is not reproducible by CSS means. Even
>> with display:table and friends. Flex as an entity is what that make
>> <table> impossible to be defined in CSS. Our proposal makes this
>> possible - you will have layout mechanism that is even more powerful
>> than tables - it provides more layout options.
> 
> What in <table>s is not reproducible in CSS, with the automatic table layout?

Table in the "Example" section here:
http://www.terrainformatica.com/htmlayout/fspu.whtm
is not reproducible by the CSS means.

If you think it is then I would like to see concrete implementation
of this layout by using CSS.


> 
>> And all this by just using two additional entities.
>>
>>>>> 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.
>> As a name 'flow' is better as it defines more precisely what this attribute
>> is for. Let 'display' be 'display' as it is now - it specifies requirements
>> of the element to its container. E.g. by defining display:inline the element
>> is asking to place itself in text container.
>>
>>
>>> You wanted to introduce "flow: table". What is the difference with
>>> "display-model:table"?
>> Table can be display:inline-block and and can be display:block
>> as any other block element. Table per se is a way of laying out its
>> children.
> 
> That is "display-model": a way of laying out children. And that is
> "display-role": how the element is used inside its parent.
> Tables can have any value of "display-role" (block, inline, card,
> table-cell, run-in, compact, table-caption...).
> Compare
> 
> -- my proposal --
> role => "display-role"
> layout algorithm => "display-model"
> "display" => shorthand
> -- your proposal --
> role => "display"
> layout algorithm => "flow"
> 
> Advantages of my proposal: you reuse "display" as a shorthand, so
> you're still backward compatible with CSS using "display:table" (that
> becomes "display-model:table; display-role:block"). If "display" also
> sets "flow" for some values, I will accept it (although I don't like
> the name, I'd rather "layout-model" or "layout-manager" or "layout").

So you propose to introduce two new attributes:
'display-role' and 'display-model', correct?

>> For example you may want to say:
>>
>> ul > table
>> {
>>  display: list-item;
>> }
>>
>> and this *must* not affect the way how table is replacing its children.
> 
> There are styles out there assuming that declaring "display:list-item"
> affects the layout manager chosen (and I'm not sure it is correct to
> blame them). If on the contrary you set "display-role:list-item", you
> get the desider result of a table with an automatic ::marker
> 
>> That is why I think all table-** values are better to be removed from the
>> 'display'. And single flow:table should be added instead.
> 
> We cannot do that. They're crafted in the stone of CSS21.

Yes, it is possible that there are documents published already that use
display:table. I haven't seen sites yet that rely on 'display:table' 
existence. *I think* that at the moment it is pretty safe to deprecate them.


> 
>> With the wording "flow:table manages layout of contained tr,td,th and
>> caption elements by using rules defined in HTML".
>>
>> And that is it.
> 
> AFAIK, neither the latest version of HTML (that is HTML5) nor that of
> XHTML (that is XHTML2) define a rendering algorithm for tables.
> 
>> If someone want to define table alike layout for other DOM elements
>> like list items then he/she may use any other method from the flow
>> palette.
>>
>> As simple as that.
>>
>>
>>> 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".
>> I've lost you here, sorry.
> 
> You don't need "flow:default" because you have
> "display-model:inline-inside" and because anytime you set the
> "display" you set also the "display-model".

Sorry but there are no such things as display-model, display-role.
They sparkled once but are dead since then.

We can discuss their reincarnation of course.

> 
>>>>> 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)
>> Why such simple things have to be so complex?
> 
> Because Chinese are billions and they look at their monitors from the
> wrong side.
> 

Beg my pardon?


-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Monday, 13 April 2009 00:12:22 UTC