Re: Fw: RE: [css-flexbox] Summary of planned changes to Flexbox Module

--------------------------------------------------
From: "Tab Atkins Jr." <jackalmage@gmail.com>
Sent: Thursday, May 20, 2010 9:27 AM
To: "Andrew Fedoniouk" <news@terrainformatica.com>
Cc: <robert@ocallahan.org>; "Alex Mogilevsky" <alexmog@microsoft.com>; "Adam 
Del Vecchio" <adam.delvecchio@go-techo.com>; <www-style@w3.org>
Subject: Re: Fw: RE: [css-flexbox] Summary of planned changes to Flexbox 
Module

> 4On Wed, May 19, 2010 at 11:58 PM, Andrew Fedoniouk
> <news@terrainformatica.com> wrote:
>> --------------------------------------------------
>> From: "Tab Atkins Jr." <jackalmage@gmail.com>
>> Sent: Tuesday, May 18, 2010 6:08 PM
>> To: "Andrew Fedoniouk" <news@terrainformatica.com>
>> Cc: <robert@ocallahan.org>; "Alex Mogilevsky" <alexmog@microsoft.com>; 
>> "Adam
>> Del Vecchio" <adam.delvecchio@go-techo.com>; <www-style@w3.org>
>> Subject: Re: Fw: RE: [css-flexbox] Summary of planned changes to Flexbox
>> Module
>>
>>> I have put up a first draft of the new flexbox module on my website,
>>> at http://www.xanthir.com/:wih.
>>>
>>> The flex distribution algorithm turned out to have somewhat more
>>> corner cases than I'd thought, especially once you figure multiple
>>> lines.  Give it a read through and tell me if I missed anything
>>> obvious.  My head hurts at this point.  ^_^
>>>
>>
>> === Comments to section #2 "Creating a flexbox" ===
>>
>> There is no existing "display-inside" property in
>> any of existing proposals so
>> "property" and "new value" should be replaced by
>> "new property" and "value" I think.
>
> I'm running with the assumption that the display split will happen
> separately.  It wouldn't make sense for me to define it as a new
> property here, because then I'd have to define the entire thing.  This
> is not the appropriate spec to do that.
>
> In the worst case, that can be pulled out and I'll just add some extra
> display values.
>

Without seeing that split of the display any discussion
of your document is not quite productive I think.

E.g. I simply do not understand what should be rendered/used
in this case:

display: table flexbox;

It may or may not be useful.

display: inline flexbox;

is also questionable.

I do understand that here

  display:inline;
  flow: horizontal;

'flow' will be just ignored, but here:

  display:inline-block;
  flow: horizontal;

it makes sense and will be used.

So  'display: inline flexbox;' raises questions.
Is it disallowed configuration or is it
display: inline-block;  with flexbox LM inside?

>
>> About "Alternately, you may use 'flex' in the 'display' property,
>> which is equivalent to declaring 'block flex'."
>>
>> In your interpretation 'display' is shorthand property for
>> some 'display-inside' and 'display-outside'.
>> I hope that they will be <s>formalized</s> defined
>> anywhere. Without them it is hard to get your idea.
>>
>> Anyway.... Since CSS1 'display' property has initial
>> value 'inline'. Therefore your intention to see
>> 'display: flex'  as a  'display: block flex' is not correct.
>> It is 'display: inline flex' if to follow existing practice
>> when shorthand attribute resets all non-defined attributes
>> to their initial values.
>
> Single values in "display" are not setting a particular subproperty.
> That would be impossible, since some current display values are
> setting display-outside, some display-inside, and some both.  Single
> keywords in display are valid values all by themselves, and map to
> specific pairs of values.
>

Could you name values of the 'display' that
are setting only display-outside and only display-inside?

>
>> And 'display: inline flex' makes no sense at all.
>>
>> There are other 'outside's that are non-compatible
>> with the flex. E.g. almost all 'table-***'
>> That is why I think splitting 'display' on parts
>> makes no sense at this point. It has to be just separate
>> property.
>
> These issues are both dealt with, or will be dealt with, by the spec
> that covers split display.
>

Ok, let's wait for the spec then.

>> It would be very surprising if you will declare
>> li { display:flex; } and it will stop e.g. drawing bullets.
>
> li { display:block; } makes it stop drawing bullets.  I fail to see
> why this is any more confusing.  If you need bullets and flexes, you
> can set "display: list-item flex" and it will work as expected.
>

I mean that the safest way of defining flexbox LM will be to
use 'display-inside' to make intentions clear and safe.

An yet the display is used for showing/hiding elements by this
'display: none' and 'display:block'.  Either one of
these will drop your flexbox as far as I understand.

And yet...  'display:none' is which display-*** actually?
inside or outside? It could be both I suspect.

>
>> === Comments to section #3 and #4,
>> "Flexbox Direction" and "Display Ordering" ===
>>
>> Any changes in direction and order of elements
>> make selection of text as plain nightmare to the user.
>> E.g. reversing display order of elements from their
>> DOM order will make text selection almost not usable
>> in all UA that are in use at the moment.
>>
>> And yet I see almost no value for the 'flex-index'
>> in combination with automatic row wrapping
>> that is proposed - very hard to predict what you will
>> get.
>>
>> Could you consider to remove 'flex-index' at all?
>
> My own experience as a web author suggests that reordering elements is
> absolutely necessary to achieve sufficient layout flexibility.  The
> selection issue will need to be solved at some future point anyway;
> this may draw the problem into starker contrast, but won't add any
> fundamentally new problems.
>

Our experiences are obviously different.

We are designing UI of mostly desktop applications.
Personally I do not remember any case when I needed
to change order of elements in flow:horizontal for example.
100% sure - not in flow:vertical/horizontal-wrap;

Usually if you do need reordering then you need it
in both directions at the same time - table alike layouts.

In any case it is just a matter to say
   flow: "2 1";
if you want to replace elements horizontally with
second child on the left of first one.

Vertical flows with wrapping are really helpful when
items are in natural order and in direction natural
to the user:
http://www.terrainformatica.com/w3/flows.png

I suspect that with lack of templates people will try
to use non trivial flex-indexes with crazy wrappings.
But I think we already got all this fun with floats.

>
>> And to limit 'flex-begin' by just logical directions?
>
> Given the selection issues you are talking about, presumably you mean
> to limit it to just "start" and "before"?  No, that is far too weak.
> Doing that would just mean that authors would jump through hoops to
> hack around it, like setting an dir=rtl on the flexbox and then
> dir=ltr back on the children.

If the "template" will be a part of flow/flex mechanism then
there is no need for any hacks like that.

BTW: are you considering to unify "template" with flexbox somehow?

I think that it is sufficiently better to provide one but powerful
solution than two partial ones with overlapping feature sets.

>
>> === Comments to section #5 "Flexibility" ===
>>
>> Example that you have there:
>>
>> <div style="display: flex; width: 200px;">
>>  <span style="padding: 0 1fl; width: 2fl;">
>>   foo
>>  </span>
>> </div>
>>
>> will not render what you expect.
>>
>> 1) I said above about  'display: flex' already
>> (it is display: inline flex; in fact).
>> and
>> 2) According to section #2 of your spec that <span>,
>> as display:inline element by default,
>> will be wrapped into anonymous box so flexes
>> declared in its style will simply not work.
>
> Ah, you're very right.  Thanks for catching that.  Hmm, then.  I
> suppose that I could, rather than wrapping them in anonymous blocks,
> just have their display-outside compute to "block".  Same effect, but
> less surprises for authors.
>

Statement "just have their display-outside compute to "block""
is not clear.

Are you saying that li's here

<ul style="display: flex; width: 200px;">
    <li style="padding: 0 1fl; width: 2fl;">...

will get display:block?

In any case I don’t think that implicitly changing 'display' values
is  a productive idea.

>
>> === Comments to section #6 "Multiple Lines" ===
>>
>> It is not clear what will be in effect if two
>> siblings will have:
>>
>> flex-break-after: avoid;
>> flex-break-before: always;
>>
>> correspondingly. Which one will win?
>
> "If either value is 'avoid', then the boxes must always remain on the
> same line together, even if this would cause the elements to overflow
> the flexbox."

So to ensure that some block will wrap on next row you will
need to define flex-break-before: always; for it and to do
flex-break-after: always; on its previous sibling? Just to be safe
from the developer in next cubicle...

And what about that non-trivial orderings?
What does flex-break-before mean when you have say
reversed order of elements? To define proper breaks would
be very challenging.

Say you have elements in flow  3,1,2; and you would want
to place break between 3 and 1 how it will look like?

With templates it will be just
flow: "3 3"
         "1 2";
without any ambiguity.

>
>> "Person having pair of watches cannot be sure about
>> exact time".
>>
>> I think that logic 'clear' property is using at the
>> moment is reasonably good. And why not to use the
>> 'clear' as it is?
>
> The abilities offered by flex-break-* are a useful superset of what
> you get with clear, but are only a tiny bit more complex.
>

Probably, but I suspect that benefits will not overcome costs of defining
new property (size of code, CPU cycles for processing additional property, 
etc).
Especially if to keep in mind that we already have property with exact
semantics.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Friday, 21 May 2010 03:28:41 UTC