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

Re: [css3-flexbox] Fixing the "replaced elements may or may not be inline" issue

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 16 May 2012 17:01:59 -0700
Message-ID: <4FB43FF7.80702@inkedblade.net>
To: www-style@w3.org
On 05/16/2012 04:10 PM, Tab Atkins Jr. wrote:
> This issue was discussed at the F2F.  You can skip the next paragraph
> if you don't need a refresher on the issue.
> The Flexbox spec declares any child of a flexbox that is a block or
> inline-block (more or less - I won't get into the details) to be a
> flexbox item, while inline elements instead get wrapped into an
> anonymous item.  Unfortunately, replaced elements are display:inline,
> and may not even be replaced at all in some circumstances (Firefox
> renders<img>  as a non-replaced inline when the image fails to load).
> However, we'd like layout to be consistent and based only on
> computed-time or earlier values.
> The discussion during the F2F ended with a proposal that we hardcode a
> list of replaced elements that should just always become flexbox
> items.  I've now made the relevant change to the spec, and the WG just
> needs to either OK it or discuss changes.
> The list of elements that always become flexbox items is:<img>,
> <canvas>,<svg>,<math>,<audio>,<video>,<iframe>,<object>,
> <embed>,<input>,<button>,<select>, or<textarea>.
> Any issues with this proposal?

I think it's okay.

An alternative would be to define a 'flex-item' value for 'display',
and make it compute to 'inline' except on children of a flex container.
Then you can assign 'display: flex-item' to those elements in ua.css.

(As an additional benefit, you could make the computed 'display' of
block container flex items start returning 'flex-item' now, instead
of changing it in the future.)

Received on Thursday, 17 May 2012 00:02:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:16 UTC