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

On 17/05/2012 19:16, fantasai wrote:
> On 05/16/2012 11:19 PM, Anton Prowse wrote:
>> 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.
>
> The elements Tab listed.
>
>> (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.)
>
> You can't, because you can't select in ua.css on "children of a flexbox".
> That depends on what the author sets the elements' display type to!

D'oh, of course!  In a moment of madness I was thinking there was a 
<flexbox> element or something... >_<

OK, so back to your proposal... does it make sense that these special 
elements become display:flex-item yet non-inline elements remain/become 
display:block, display:table etc?

I don't feel very happy about that, although I applaud the attempt to 
get a flex-item display type in through the back door!

For now I prefer Tab's approach, and in future when there really is a 
display-outside:flex-item, /then/ we can replace Tab's approach with 
your one.

>> 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.
>
> Last time I brought up the issue, Tab and Alex felt there wasn't
> a really good use case for that. Which is probably true; you'd
> want to be able to set properties on that flexbox, e.g. whether
> it's rows or columns, etc. so you'd need an element.

Hmm, yes that seems that seems about right.

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

Received on Thursday, 17 May 2012 19:48:20 UTC