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

[css-flexbox] few change/addition prepositions

From: Robert Koritnik <robert.koritnik@gmail.com>
Date: Tue, 10 Feb 2015 12:30:02 +0000
Message-ID: <CABJN8dfYKFmj_+QmnjFc6ycfTYz6FGe26yhkdTohPVZyNpfDzw@mail.gmail.com> (sfid-20150210_123007_476791_15E89769)
To: www-style@w3.org
Dear sirs.

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

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.

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.

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:

   1. *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
         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
   2. 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.

Kind regards,
Robert Koritnik
*Pleiado d.o.o.*
Developer/consultant on Microsoft platforms and technologies
*mobile* +386 41 322 735
*skype* robert.koritnik
*twitter* @robertkoritnik <http://twitter.com/robertkoritnik>
*google+* Robert Koritnik <https://plus.google.com/116164717430356367649>
*linkedin* Robert Koritnik <http://www.linkedin.com/in/robertkoritnik>
*blog* Erratic software development <http://erraticdev.blogspot.com>
Received on Wednesday, 11 February 2015 19:53:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:51 UTC