W3C home > Mailing lists > Public > www-style@w3.org > February 2015

Re: [css-flexbox] few change/addition prepositions

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 12 Feb 2015 08:29:58 +1100
Message-ID: <CAAWBYDCjCLAGBuZcGGBvSPsh74jQi1ZEUX+=YWtfyAobvm07AQ@mail.gmail.com>
To: Robert Koritnik <robert.koritnik@gmail.com>
Cc: www-style list <www-style@w3.org>
On Tue, Feb 10, 2015 at 11:30 PM, Robert Koritnik
<robert.koritnik@gmail.com> wrote:
> Dear sirs.

And ma'ams. ^_^

> Let me propose a few changes/additions of the flexbox specification.
>
> 1. Value change preposition for flow-direction property
> I would like flow-direction values to change from row to horizontal and
> column to vertical because they way they're defined now is rather confusing.

flex-direction is defined with "logical" axis names (as opposed to
"physical" ones) on purpose; generally, if you want a "row" flexbox
you want it to flow in the same direction as text.  That's horizontal
on English pages, but vertical on, for example, Japanese pages.

The direction within the axis is also relative to the language of the
page (more precisely, to the 'writing-mode' of the flex container) -
in English "row" causes items to flow left-to-right, same as text, but
in an Arabic page the same value flows right-to-left, same as Arabic
text.

> Let me give you a simple example.
> We define flow-direction as column. And if we keep other flexbox properties
> as defaults then we actually end up with rows of items that stretch the
> whole line. If we'd use vertical instead of column it would be unambiguous
> in which way items will flow.

I'm unsure what you're referring to with this example.

> 2. Additional value for justify-content property
> I'm missing an additional value of stretch, to make individual unwrapped set
> of item fill the whole main-axis width without any space between them.

This is what the 'flex' property is for.

> 3. Confusing non-self-explanatory property names
> I find it hard not to confuse these flexbox related properties
> align-content, align-items, justify-content. They should have more directly
> meaningful names, so their usage wouldn't be as confusing as it is at the
> moment. Maybe they should include words main, cross and line so it would be
> obvious what they relate to.

I agree that, taken by themselves, the Flexbox alignment properties
are not super-obvious.  It'll get easier as the full set of alignment
properties defined in <http://dev.w3.org/csswg/css-align/#overview>
become usable in more display types, such as Grid, Block, or
position:absolute.

> 4. Add flex groups or add flex-break property
> Suppose we have a flexbox container with several items. It's currently
> impossible to force a main-axis wrap after a certain item unless we define
> certain main-axis dimension to items. This is not flexible enough if we want
> flexbox specification to cover layout design needs. I propose two different
> solutions:
>
> flex-break property than can be defined on items and allows following
> values:
>
> none - no wrapping even if item exceeds main axis margin; in this case
> wrapping should occur either before previous sibling flex item - useful with
> orphan control so we never end up with a single item at the end
>
> item:last-child { flex-break: none; }
> item can be any CSS selector which matches a flex item; defining this
> selector as item:last-child::after would make it possible to create such
> design elements as flush-space effect of which can be seen on this image
> where a fleuron is added to the end of the last paragraph with a flush space
> in between so fleuron is aligned to the right margin;
>
> auto - this is current default, where item wraps as required by other
> properties or main axis dimension
> before - forced wrap before this item
> after - forced wrap after this item
> both - forced wrap before and after, leaving this item as the only one of
> its main axis set
>
> a more complex specification for flex groups to group individual flex items
> as if they'd be wrapped in an additional element; all settings provided on
> flex container would therefore relate to flex groups defined within and any
> items not contained in any of the defined flex groups; these flex groups
> could be generalised and not relate only to flexbox spec, but could be
> defined as a pseudo element :wrapper(n) on container where n could be a
> number or a string name that would be more self-explanatory to developers;
> defining these wrappers would have to go along with an additional CSS
> selector property i.e. wrap-within: n that would allow developers to add
> elements of the container to previously defined wrapper pseudo element; this
> would have to work along with DOM - if only two elements would be added to a
> certain wrapper all sibling elements between them would therefore be
> automatically added to it as well; in flexbox specification this would also
> obey to order rules;
>
> It would be best to see both added to the CSS specification as they serve a
> different purpose although when working with flexboxes similar results can
> be achieved with both. The second one is definitely more flexible. As well
> as more complex.

Better control of flex wrapping is planned, and will show up in either
the CSS Break specification or Flexbox Level 2.

~TJ
Received on Wednesday, 11 February 2015 21:30:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:01 UTC