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

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

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.

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.

It would be very surprising if you will declare
li { display:flex; } and it will stop e.g. drawing bullets.


=== 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?
And to limit 'flex-begin' by just logical directions?

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.

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

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

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

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Thursday, 20 May 2010 06:59:03 UTC