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

On 18/05/2012 04:37, Kang-Hao (Kenny) Lu wrote:
> (12/05/17 10:41), fantasai wrote:
>> On 05/16/2012 07:25 PM, Boris Zbarsky wrote:
>>> On 5/16/12 7:22 PM, Boris Zbarsky wrote:
>>>> On 5/16/12 5:01 PM, fantasai wrote:
>>>>> 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.
>>
>> [snip]
>>
>> I think it *is* weird. But so's putting a list of special-cased HTML
>> elements into a CSS spec. So the question is, what's likely to cause
>> fewer problems down the line?
>
> Another option is that we define an anchor here (say, "flex item
> elements") and put that list in the HTML spec. We could have used 'any
> element that is "intended to be" a replaced element', but the HTML spec
> uses a hypothetical technology so-called "Behavior CSS" to describe the
> form elements so it's not clear if the term "replaced element" is still
> appropriate. To answer that, we need to ask a hypothetical question,
> which is "For the form elements that have 'binding: none;', do they
> generate flexbox items?"

I quite like this option.  Seems to me that similar issues with these 
elements might crop up again in future layout models.  Which 
incidentally would mean that "flex item" elements probably isn't the 
best choice of term, since it's a very biased term.

Actually, that bias is something I'm a little uncomfortable with in 
fantasai's proposal to make these elements display:flex-item in the 
ua.css. Perhaps we could make them display:special-weird-things (with 
the same computed value behaviour) instead.  Perhaps that's abstracting 
a bit too far...

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

Received on Tuesday, 22 May 2012 21:36:44 UTC