Re: [css-flexbox] floats, white space, and box-generation

On 02/13/2014 03:29 AM, Peter Moulder wrote:
> Here are my remaining comments on your much welcomed element/box fixup commit.
>
>
> Coming back to that paragraph in §3 that mentions adding a row to table 9.7:
>
>    # If a box’s specified display is inline-flex and the box is floated or
>    # absolutely positioned, the computed value of display is flex.
>    # The table in CSS 2.1 Chapter 9.7 is thus amended to contain an additional
>    # row, with inline-flex in the "Specified Value" column and flex in the
>    # "Computed Value" column.
>
> I think the table amendment can stay as is, we just need to change the
> description of that in the first two lines.  It's actually a bit awkward
> to give in a single sentence the exact conditions in which that table
> is applied (e.g. the existing description leaves out the root case and the
> parent-flex-container case); I suggest a different approach, e.g.
>
>    | If the specified value of 'display' is 'inline-flex', then the computed
>    | value becomes 'flex' in certain circumstances:
>    | the table in CSS 2.1 section 9.7 is amended to contain ...
>
> (i.e. removing the word "thus", and incidentally also changing "Chapter 9.7" to
> "section 9.7").

Fixed.

> There are misleading indications of how floats are handled: section 4 says that
> only in-flow children are flex items, which I would take to mean that
> float:something elements simply don't generate flex items (and are instead
> handled much like abspos elements are).  Alternatively, one could say that
> the issue is that "in-flow box" isn't a well defined concept.  (CSS 2.1 defines
> only whether an element is in-flow, and does so in terms of whether the element
> is "floated", which itself isn't very clearly defined in this case.)
>
> We'll come back to how floats are handled, but for now we'll get the section 2
> definitions out of the way, while avoiding using the phrase "in-flow".
>
> In section 2 (Terminology), the second sentence needs to be qualified with
> "that are not absolutely positioned" to avoid conflicting with what section 4
> ‘Flex Items’ says about abspos children not being flex items.
>
> As noted in another thread, I also believe there needs to be a clear definition
> of "flex item", and that this can be accomplished by changing these sentences
> in section 2 to
>
>    | A <dfn>flex container</dfn> is the box generated by an element with a
>    | computed 'display' of 'flex' or 'inline-flex'.
>    | A <dfn>flex item</dfn> is a child of a flex container,
>    | other than an absolutely positioned child.
>
> and removing the <dfn> markup from the section 4 sentence.  (The "are called"
> construct could be interpreted as merely giving an example of flex items rather
> than a definition, as does the "becomes" approach in section 4.)

Ok, I've shuffled around <dfn>s and made judicious use of the word "in-flow".
See if it all works for you now.

> A related problem is that the text at the start of section 4 (before the first
> colon) isn't true considering the abspos case (assuming that we consider abspos
> boxes to still be among the contents of its parent).
>
> As section 2 already has a definition (if the above change is accepted), then I
> suggest that section 4 start with a non-normative description of the situation
> from the point of elements, to give an intuitive feel for how things happen.
> E.g. [...]

Ok, we've adjusted the introductory sentence in Section 4.

> Regarding text nodes:
>
>    - I'm not sure of the intended behaviour for whitespace text nodes: should
>      white-space-only text nodes behave any different from if not present?
>      If not, then I suggest that it not become a flex item at all.  (That
>      reduces the risk of it unintentionally interacting with other bits of
>      the spec that talk about flex items.)

I think the behavior should be clear from

   # an anonymous flex item that contains only white space
   # (i.e. characters that can be affected by the white-space
   # property) is not rendered, as if it were display:none.

Is there really a problem in understanding the implications here?
This is exactly analogous to how anonymous white space is handled
in table fixup.

>    - I'm not sure that I understand the whitespace provision: the "can be
>      affected by the 'white-space' property" formulation looks like it's
>      trying to do something different from CSS 2.1 section 9.2.1's
>      "collapsible whitespace" provision (and section 9.2.2.1's "white space

It's different from collapsible white space because collapsible
white space must have 'white-space: normal | pre-wrap', whereas
this applies equally to 'white-space: pre'.

I think the text here is fine.

>    - What should happen to consecutive elements whose specified 'display' is
>      'table-cell' and whose specified 'float' is not 'none' (and whose
>      specified 'position' is static), and whose parent element has a 'display'
>      of '(inline-)flex' ?  Per the existing spec, part of the answer is that
>      the table fixup provisions in the flexbox spec don't occur until boxes
>      have already been generated; to decide what boxes get generated, we first
>      apply CSS 2.1 table 9.7, and find that the computed 'display' of these
>      cell elements is 'block', and computed 'float' is the specified
>      non-'none' value, so the behaviour should be the same as for
>      display:block float:something elements, with no applicable table fixup.

Right.

>      That brings us to the simpler question:
>
>    - What should be the behaviour for an element with display:block
>      float:something (and position:static) and whose parent element has
>      display:(inline-)flex ?  I'll assume that the intent is that it
>      generate a flex item and not float, but there's also the question
>      of what the computed value of 'float' for the element is
>      (as is relevant for corner cases such as display:inherit).

The computed value is not affected by becoming a flex item.

> I tried testing how chromium answers these questions, but it looks like my
> installed version of chromium doesn't even apply the normal table-fixup rule
> (if I've correctly written the test case at
> http://bowman.infotech.monash.edu.au/~pmoulder/html-tests/flexbox-floated-cells.html).
>
> Still, I do get one interesting result from that test case, namely that
> in the one implementation I tested, an element with float:something specified
> and a display:flex parent element has a computed 'float' of none (as tested by
> a child with float:inherit).

Tab says this is an implementation bug.

> Without giving too much thought, I'm guessing that all of this float-related
> behaviour (especially float:inherit) is something without much author
> preference, and on that basis I suggest specifying whatever behaviour a
> majority of existing implementations have.  What do other implementations do?
> For now, I'll go with making the computed value of 'float' for the element be
> 'none'.  I would do this by having css-flexbox specify that CSS 2.1 section 9.7
> is amended to say that elements with a display:(inline-)flex parent have a
> computed value of 'float' of none.

I think it's simpler just to have the computed value of 'float' not
be affected and have the 'float' property simply have no layout
effect on flex items. But will double-check with the WG.

Wrt comments about the 9.7 table, we rewrote the bit about computed
'display' to reference 'display-outside' instead. That clears up
pretty much all the problems, we think.

Let us know if that all works.

~fantasai (and TJ)

Received on Friday, 7 March 2014 21:57:59 UTC