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

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.

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.

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.

~fantasai

Received on Monday, 7 May 2012 06:41:41 UTC