RE: [css3-flexbox] implied flex-itemness of inline replaced elements

± From: fantasai [mailto:fantasai.lists@inkedblade.net] 
± Sent: Sunday, May 06, 2012 11:41 PM
± 
± The current spec says that an anonymous flex item is wrapped 
± around all non-atomic inline content; and that atomic inlines 
± become flex items on their own. This means that 'display: inline'
± elements are flex items when they are replaced, and not when they 
± are non-replaced.
± 
± IIRC from what I've heard in side-conversations here and there, 
± Gecko doesn't know whether a 'display: inline' element is inline 
± non-replaced or inline replaced at computed value time, which 
± means that we don't know whether an element is a flex item or not 
± at computed value time.

I can't comment on Gecko code, but any implementation must at some point make a decision to render an element as "display-outside:inline-block" (which is what "display:inline" replaced element really is) and it has to happen somewhere between object fallback and layout. Not sure what kind of optimizations could make it a problem but it doesn't seem that this is a major change in logic.

± This has some implications for how precise our computed values 
± can be, e.g. the flex basis cannot be accurately computed, and 
± can only return its specified value. If we ever have a
± 'display-outside: flex-item' value, this magic will also interact 
± poorly with that: the property cannot compute to 'flex-item' on 
± implied flex items.

Why not? It is exactly what we do. The internal equivalent of 'display-outside' computes to 'flex-item' on whatever is a flex item, block, inline-block or anonymous
 
± Without the magic on replaced 'display: inline' elements, you 
± could tell solely from an element's 'display' and its parent's 
± 'display' whether it was going to be a flex item, and hence 
± computed values could reflect more closely the values used in 
± layout.
± 
± Even if that isn't considered an important consideration, though, 
± I think the following is:
± 
± Consider a toolbar consisting of <img> (or <object>) elements.
±    * if the images load, each <img> is a flex item.
±    * if the images don't load, the alt texts are all glommed
±      together into one large flex item
± 
± This is rather unexpected behavior, if the author is expecting 
± each <img> element to be a single flexbox item.
± 
± I find this rather disconcerting, and I'm not sure the extra 
± convenience of magically turning replaced elements with
± 'display: inline' into flexbox items is such a good idea, given 
± its complications and consequences.

This is not a convenience, this rule addressed the most common mistake we've seen from users of early implementations in IE. 

In this *very common* case

<div style="display:flex">
	<button>abort</button>
	<button>retry</button>
	<button>fail</button>
</div>

, if buttons are not automatically flexbox items, the visual result is exactly same as in normal flow -- all three buttons are side to side in one line (assuming they fit). The buttons are actually wrapped into an anonymous item, but the author doesn't realize that. 

For the author it looks like flexibility doesn't work. They read and re-read the chapter on flexibility, verify in debugger or script that flexbox display type is set correctly, then they file a bug or post in a forum. Eventually somebody explains that you have to make you buttons "display:block" for flexibility to work.

That's not an imaginary scenario, I've seen it multiple times. Of any usability issues with flexbox that was fixed by a spec change it is the top one.

I am not all that thrilled by having a special case for replaced either. But if we remove the rule, we will reintroduce a major usability issue without improving anything. Inline content shouldn't really be in a flexbox after all, it is pretty much always a mistake or bad design.

Alex

Received on Tuesday, 8 May 2012 03:41:26 UTC