[css-flexbox] floats, white space, and box-generation from fantasai on 2014-03-07 (www-style@w3.org from March 2014) (original) (raw)

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 flex container is the box generated by an element with a | computed 'display' of 'flex' or 'inline-flex'. | A flex item is a child of a flex container, | other than an absolutely positioned child.

and removing the 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 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 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.

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.

Right.

 That brings us to the simpler question:

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