W3C home > Mailing lists > Public > www-style@w3.org > February 2014

Re: [css-flexbox] Flex box does not respect inline children/groupings

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Tue, 18 Feb 2014 18:29:56 -0800
Message-ID: <CALRQH78cXKBwD7fWCO+SrP2_ozZ5YechWBn4_XFb1cNpdDe=nw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Eric Eastwood <me@ericeastwood.com>, www-style list <www-style@w3.org>
On Tue, Feb 18, 2014 at 11:14 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Feb 12, 2014 at 1:36 AM, Eric Eastwood <me@ericeastwood.com> wrote:
>> I recently made a chrome
>> issue(https://code.google.com/p/chromium/issues/detail?id=342243) on it and
>> I thought I would bring it here to a more general audience.
>>
>> I think that inline elements should be clumped with "contiguous run[s] of
>> text"(http://www.w3.org/TR/css3-flexbox/#flex-item) to form a single flex
>> item:
>> (text-node)+(inline-element)+(text-node)+(more-inline-elements)=(flex-item)
>>
>> Currently Chrome 32, FF 27, Opera 19 break up inline elements into separate
>> flex items
>>
>> Not breaking up contiguous inline elements + text nodes especially makes
>> sense especially with this use case:
>> HTML:
>> <div class="flex">
>> Heya, <span>nice</span> day isn't it
>> </div>
>>
>> Will be rendered on each line like with `flex-direction: column`.
>> Heya,
>> nice
>> day isn't it
>>
>> See demo: http://jsfiddle.net/MadLittleMods/kSY5t/
>>
>> Of course this effect can easily be mitigated in the current state of things
>> by just wrapping everything you want to actually act inline as one in
>> another element.
>> <div class="flex">
>> <div>
>> Heya, <span>nice</span> day isn't it
>> </div>
>> </div>
>>
>> Renders:
>> Heya, nice day isn't it
>>
>>
>> To quote something I wrote in the chrome issue:
>>
>> "Although it would slightly break the layout of some sites. It is extremely
>> easy to fix and someone using the flex box model at this point in time is
>> probably pretty proactive at getting their site fully functional again. I
>> doubt this will affect many peoples layout as most will not be using inline
>> nodes as flex items.
>>
>> For the flex model's sake I would rather make the change that effects only a
>> tiny portion of early adopters (remember only inline nodes affected)."
>
> This design is intentional.  We originally grouped text and inline
> boxes together as you suggest, but it resulted in very confusing
> behavior when people put <button> or <img> or <input> inside their
> flexboxes, as they are all inline by default.  This can of course be
> "fixed" by explicitly specifying them to be display:block, but it was
> a common enough confusion that it was deemed better to address it
> directly by making everything a flex item.
>

According to this document http://www.w3.org/TR/CSS2/sample.html
(non-normative I believe though) <button> and <input> are
*inline-block* elements. And Eric was asking about purely display:inline
elements that do not generate boxes by themselves.

I think that inline elements should stay inline - flexbox shall not
try to change "boxing nature" of its children.

--
Andrew Fedoniouk.

http://terrainformatca.com
Received on Wednesday, 19 February 2014 02:31:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:19 UTC