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

On Wed, May 16, 2012 at 5:01 PM, fantasai <fantasai.lists@inkedblade.net>wrote:

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


I support this. I think it's more clear what's going on if the computed
display type changes.