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

On 17/05/2012 02:01, fantasai 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.

By "those", do you mean the HTML elements that Tab listed, or the 
general children that you mentioned in the previous sentence?  Only the 
former makes sense to me.

(For that matter, I suppose you could do the same in the ua.css without 
introducing a new display type; just set such children of flexbox to 
have display:inline-block.)

It would be cool to introduce display:flex-item, but then we'd need to 
think about whether a stand-alone flex-item should generate an anonymous 
flexbox to wrap it (analogously to table fix-up) rather than computing 
to inline.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Thursday, 17 May 2012 06:19:47 UTC