[css3-flexbox] options for breaks in multiilne flexboxes

± From: fantasai [mailto:fantasai@inkedblade.net] 
± Sent: Tuesday, February 14, 2012 6:25 AM
± 

Fantasai, thanks a lot for notes from f2f discussion 
(notes sent privately, but it seems any further discussion should be here...)

I updated the draft with what I remember and what I thought about later. It is different in a few issues from what you seem to like... let me explain (If you want to discuss further that should probably be documented at www-style)

± Application of 'break-before' / 'break-after'
± ---------------------------------------------
± 
±    - Applies to flex item when main axis matches block axis
±    - Propagates to flex line when cross axis matches block axis
±      (css3-break explains what propagation means and how to merge
±       multiple break types)

I came up with something a little different:

	FORCED BREAKS ON FLEXBOX ITEMS
	
	1.	In a row-direction single-line flexbox, breaks 
		before and after items apply to the flexbox 

	2.	In column-directon single-line flexbox and all multi-line flexboxes 
		1.	Forced break before the first item is applied to the flexbox 
		2.	Forced break after the last item is applied to the flexbox 
		3.	Forced break before or after any other item terminates the 
			set of items to be laid out on this page 

(1) Is a special case of yours. There I can't think of any useful per-item handling, the choices are really ignore the break or promote to box. 

Oh, hmm... actually I just thought of another choice for (1): make single-line behave exactly as multiline with one line (except (a) it adds a line per break and (b) there is no automatic line wrap)... What do you think?

(2) I still prefer to apply breaks per item. 

Your point of horizontal flexbox being like lines is interesting, but I think you should reconsider. Flexbox is dealing with blocks, its algorithms don't change at all with orientation switch. If it makes sense to apply page break in the middle of a line in multi-line vertical, it makes even more sense in multi-line horizontal. And the meaning of "break before" is "I don't want to be on the same page at previous item" - that seems to mean exactly same in either orientation...

A good use case for (2) is multi-screen UI with icons, iPhone style. It could very well be a multi-line flexbox in paged view, with forced breaks on some items. 

± Breaking multiline flexbox with main axis parallel to block axis
± ----------------------------------------------------------------
± 
± Option A: Simple Pagination
± 
± | 3  1 |
± | 4  2 |
± +------+
± +------+
± | 5  2 |
± | 5  2 |
± 
±    Pros: Best preservation of layout
±    Cons: Ridiculously complicated due to impact of pagination
±          on size of box
± 
± Option B: Multi-column Model
± 
± | 2  2  1 |
± | 3  2  2 |
± +---------+
± 
± +---------+
± | 7  5  3 |
± | 8  6  4 |
± 
±    Pros: Relatively straightforward
±    Cons: Scrambles layout compared to unpaginated
± 

It has to be option "B". It doesn't make any sense to layout items out of order. If somebody wants specific line breaks, they can just use a grid...

± Option C: Overlapping Broken Boxes
± ----------------------------------
± 
± | 5  3  1 |
± | 6  4  2 |
± +---------+
± +---------+
± |      67 |  <-- I think this drawing is wrong...
± |       8 |      but idea was a box that didn't fit
±                   on the first page would behave as
±                   overflow: visible onto the second
± 
±    Pros: ?
±    Cons: Overlapping elements, which looks broken and often
±          results in dataloss

I think you meant this (it is extension of "B" either way):

| 5  3  1 |
| 6  4  2 |
+---------+
+---------+
|      27 |  <-- "6" is the last item on the page, 
|       8 |      	it should be broken if it doesn't fit;
			but "2" has nowhere to continue, so it
			overflows and overlaps 7.

It looks sad, but:

    *	We will first put flexbox at top of the page, so to get 
	this overlap we really have to have a vertical flexbox
	with huge items.
    * The result is consistent with what overflow:visible
	is anywhere: if it is unfortunate to be overflow, 
	it shows, but it won't affect layout of anything else.
		
± 
± Option D: Last Option
± 
± I can't find the drawing. :( I remember that there was no overlap, and 
± it involved boxes that overflowed the first page pushing down content 
± on the second page instead of overlapping it.

The idea for the last option was that overflow from vertical lines would take some space on the next page, then normal layout would resume. Or overflow would be alone on the next page(s). Either way, it would be overflow displacing surrounding layout - not what overflow should do...

So my preference is option "B" (and "C" for overflow from columns other than last column). 

--Alex

Received on Friday, 17 February 2012 04:08:25 UTC