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

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!

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

~fantasai

Received on Thursday, 17 May 2012 17:17:25 UTC