W3C home > Mailing lists > Public > www-style@w3.org > April 2012

Re: [css3-flexbox] Flexbox Terminology

From: Anton Prowse <prowse@moonhenge.net>
Date: Mon, 16 Apr 2012 23:55:03 +0200
Message-ID: <4F8C9537.1060009@moonhenge.net>
To: Andrew Fedoniouk <news@terrainformatica.com>, "www-style@w3.org" <www-style@w3.org>
CC: "Tab Atkins Jr." <jackalmage@gmail.com>, fantasai <fantasai.lists@inkedblade.net>
On 10/04/2012 08:48, Andrew Fedoniouk wrote:
> On Mon, Apr 9, 2012 at 8:16 PM, Tab Atkins Jr.<jackalmage@gmail.com>  wrote:
>> On Mon, Apr 9, 2012 at 10:56 AM, fantasai<fantasai.lists@inkedblade.net>
>> wrote:
>>> There's an editorial thing that bothers me about Flexbox, which is that
>> the
>>> terminology is a little inconsistent with what we do elsewhere and with
>> the
>>> concepts themselves:
>>> The thing that's a container is called a "flexbox", but the boxes that
>>> actually
>>> flex are called "flexbox items". Usually we call the container box a
>>> "container",
>>> and child boxes are called "boxes", not "items". We don't use "items" to
>>> refer
>>> to boxes anywhere else, and I don't see any reason to start a new
>> convention
>>> here.
>>> So I'd like to propose that the boxes that flex are called "flexboxes",
>> and
>>> the
>>> containing element be called the "flexbox container".
>> I don't like this change.
>> For one, for consistency, it would require us to change the 'display'
>> value to "flexbox-container", which is much longer than it has any
>> right to be.
>> For two, Grid is using the "X as container, X Item as child" pattern
>> as well, and I expect that other new layout modes will do the same,
>> such as in my proposal for Stack Layout.  In Grid (and Stack) the
>> pattern clearly makes sense - the container *is* a grid (or a stack).
>> Letting Flexbox match is convenient, and not harmful.
> Strictly speaking 'display' in the way it is used now has nothing
> common with 'flexbox' and 'flexbox-container'.
> At the moment `display` defines layout behavior of the element
> *itself* but not its children, it defines requirement of the element to its
> container:
> display: inline and inline-block - the element has to be placed inside
> inlines container;
> display: table-cell - it has to be placed inside row container;
> display: block - inside block container;
> and so on.
> 'flexbox' (as a value of the display) is pretty strange creature.
> It is a requirement to *children*.
> And that contradicts with other display values. Suddenly
> table-cell cannot contain flexible elements inside.
> As so list-item and inline-block. I would like to know reasons
> for such limitation.

Yes, the display values which set up complex layout containers are 
generally describing the display-inside, not the display-outside. 
(display:table is one such value from CSS21.)  I don't see why we 
couldn't have something like 
display-outside:table-cell;display-inside:grid in future, though.

Regarding the flexbox terminology change, I'm in favour (as fantasai, 
Tab and I discussed briefly whilst attending the Paris F2F).  The point 
that fantasai is making is that "grid" and "table" are terms which 
clearly describe a layout container, whereas "flexbox" _sounds like_ 
something which /participates/ in a layout container.  The problem is 
that we don't seem to be able to come up with a sensible alternative to 
display:flexbox.  I quite like 'flexgroup', personally.  (Tab: you 
mentioned before that the concept of a flex group already existed with a 
different meaning, but I don't see any mention of that in the 
css3-flexbox draft.)  If we do change the display value name, then I 
think it's fine to refer to the flexbox items as "flexboxes", ie drop 
"item" from the name.

I could live with keeping display:flexbox but I'd strongly prefer to 
rigidly refer to the element on which it is set as a "flexbox 
container".  With that approach, I don't think it's reasonable to refer 
to the items as "flexboxes" since that would be confusing: authors would 
reasonably think that display:flexbox is used to create a flexbox and 
not the container.  So we would have to stick with "flexbox item" or 
come up with something new; how about "flexer"?  (Then, "flexbox" should 
never be used as a technical term anywhere; it would merely be the name 
of a display value, implicitly standing for "flexbox container".)

Personally, I don't much like the use of the word "box" in a display 
value in any case.  ("Box" is an important technical term, so 
ambiguities should be avoided.  It's cumbersome to talk about a "flexbox 
box", and I don't think it's realistic to expect people to use the term 
"flexbox" to consistently refer to the box and not the element.)  So 
this is another point in favour of something like "flexer".

Anton Prowse
Received on Monday, 16 April 2012 21:55:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:57 UTC