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

On 18/05/2012 02:30, fantasai wrote:
> On 05/17/2012 12:47 PM, Anton Prowse wrote:
>> On 17/05/2012 19:16, fantasai wrote:
>>>
>>>>> 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.
>>>>
>> 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?
>
> No, which is why I stated in the "Corollary", that if we add a 'flex-item'
> value, any element with display-inside: block that became a flex item would
> also compute its 'display' value to 'flex-item'. :)
>
> (Essentially, 'display: flex-item' means 'display-outside: flex-item',
> 'display-inside: block'.)

Ah right; I missed that because I chopped it off when quoting you!  Sorry.

Yes, that seems better...

>> 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.
>
> Indeed, we can do that as well. This just happens to solve both the
> replaced items case as well as the "we're going to change the computed
> value of 'display' in the future" problem.

...although there will be plenty of things that can't compute to 
flex-item, including table, grid, flexbox.  So the problem will still 
exist for those.

I guess I'm just not sure whether half doing something is better than 
not doing it at all.

Either way, I think I would like to see a note in the spec explaining 
that the computed 'display' of table, grid etc when these types are flex 
items will change from being 'table', 'grid' to being 'flex-item table', 
'flex-item grid' in future.  (And hence it's best not to code anything 
that relies on those values.)  Hmm, perhaps introducing 'flex-item', 
albeit partially, would underline that point.

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

Received on Tuesday, 22 May 2012 21:10:03 UTC