RE: [css3-flexbox] Changing abspos placeholders to atomic inlines

± From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
± Sent: Monday, May 21, 2012 2:38 PM
± 
± On Sun, May 20, 2012 at 2:36 AM, Anton Prowse <prowse@moonhenge.net> wrote:
± > On 18/05/2012 02:44, Tab Atkins Jr. wrote:
± >> Issue link: 
± >> http://wiki.csswg.org/topics/css3-flexbox-abspos-flex-items

± >>
± >> Previously, the "placeholder" left behind by abspos items was defined 
± >> to be a "0x0 anonymous inline".  Anton raised the issue that setting 
± >> an inline to 0 height doesn't really do anything, and we may instead 
± >> want to set its line-height to 0.  Instead, fantasai and I decided to 
± >> just change them to atomic inlines.  This makes the 0 height actually 
± >> matter.
± >>
± >> This has additional implications, though.  As an atomic inline, the 
± >> placeholder now becomes a flex item, rather than being wrapped in a 
± >> flex item.  This actually seems like slightly better behavior, as it 
± >> means that it responds directly to flex-align.
± >
± > I think that works, but I'm not seeing the connection to 'flex-align'; 
± > would you mind elaborating?
± 
± The effect actually isn't as large as I previously thought.  The effects of 
± 'flex-align' on an anonymous block around the placeholder end up being about the 
± same as applying them the placeholder itself.
± Possibly identical, but I'm not certain off the top of my head.  It may be 
± simply that the only observable effect is to make two abspos elements next to 
± each other still take up two "spots" for the purpose of flex-pack:justify and 
± such.

When we agreed on inline placeholders, which actually affect layout with some values of 'flex-pack' (fairly unusual), we were reasoning that

* This is not an intended use of flexbox
* It doesn't matter all that much what happens
* We just need to define how exactly absolute positioned children are handled

What we had before this switch to atomic inlines was the simplest possible solution, it worked, there was zero or close to zero code in flexbox to deal with it. Why did we have to change?

What our code does currently is

1) Find loose text in flexbox and wrap it in anonymous blocks
2) Size and position the anonymous blocks as part of flex algorithm
3) Anything within the anonymous blocks is handled by normal flow layout, including absolute children

The only special handling that had to happen is that at step (1) absolute positioned children are considered "inline content", they don't break runs of text and they are handled as text when there is no other inline content around.

I am not even sure there had to be any change at all to make it happen.

So if we had a style like this

 b { position:absolute; width:1px; height:1px; background:red; }

each of these would become one anonymous item:

A:
 <b></b>

B:
 <b></b> 
 some text 
 <b></b>

C:
 some 
 <b></b>
 text

Which looks *exactly same* as what will happen if you put same stuff in normal flow.
Further, if you set "display:block" on <b>, behavior will change, and it will still be exactly same as in normal flow. And there is nothing for flexbox layout to do!

Now, "B" and "C" will get 3 anonymous flex items each, right? And BTW in "C" there will be no space between "some" and "text", will it?

I suppose the new solution is not that much harder to do, it is very little code elsewhere, but there is new behavior to define, implement and test... Can somebody explain why it is better?

Alex

Received on Wednesday, 30 May 2012 00:19:17 UTC