W3C home > Mailing lists > Public > www-style@w3.org > May 2012

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

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Tue, 8 May 2012 03:40:35 +0000
To: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <2C86A15F63CD734EB1D846A0BA4E0FC81A3EDFE9@CH1PRD0310MB381.namprd03.prod.outlook.com>
 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 
 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">

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

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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:14 UTC