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.


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


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

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


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


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


> Practice shows that when you really need non-trivial
> order then "template" way of defining it is the most
> adequate.
>
> One of practical examples of the template:
>
> flow: "1 . 4"
>         "2 3 5"
>         "6 6 6";
>
> For the markup:
>
>  <caption for="available"><u>A</u>vailable</caption>
>  <widget type="select" multiple id="available" accesskey="a">...</widget>
>  <div id="buttons">...</div>
>  <caption for="selected"><u>S</u>elected</label></caption>
>  <widget type="select" multiple id="selected" accesskey="s"></widget>
>  <div class="button-bar">
>   <button name="ok">Ok</button>
>   <button name="cancel">Cancel</button>
>  </div>
>
> and we will get this:
> http://terrainformatica.com/w3/flex-template.png
>
> I mean that as soon as you will need to change order
> then it will be far from that trivial schemes that
> indexes and global direction can provide.

In general, you're correct.  To do a full page layout, or complex
widget layout, you need more power than what flexbox grants you.  But
the limited power that you get from flexbox is still pretty useful,
and further is simple to use, which is the important part.


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


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

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

~TJ

Received on Thursday, 20 May 2010 16:27:58 UTC