- From: Peter Moulder <pjrm@mail.internode.on.net>
- Date: Thu, 13 Feb 2014 22:29:24 +1100
- To: www-style@w3.org
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"). 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.) 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. | Loosely speaking, the flex items of a flex container are the boxes | generated from the children (and text nodes and pseudo-element children) | of the element that generated the flex container, other than absolutely | positioned children. It might also mention | Box generation proceeds as usual inside elements whose 'display' | is 'flex' or 'inline-flex', except [something about floats and possibly | text nodes, see below]. The section needs to say something about floats and text nodes, but there are a couple of behavioural questions that need to be decided first. 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'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 that would subsequently be collapsed away" provision). For example, my understanding of the mention of the word "property" in the existing text in css-flexbox is that it's talking about the white-space property generally rather than talking about the particular value of this property effective for the element that contains that white space, i.e. I'd expect from this text that an all-white-space text node in a display:flex element would behave the same regardless of that element's value of 'white-space'. Whereas I think that the more natural thing to specify is that box generation for child nodes of a display:flex element procedes pretty much as usual (other than computed 'float' being none), such that a box (and hence displayed flex item) gets generated for all-white-space if the parent's 'white-space' is 'pre' but not if 'normal'. Regarding floats: - 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. 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). 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). 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. The other arbitrary choice to make is what to do with adjacent elements with display:table-* float:something and a display:(inline-)flex parent element. Again, without giving much thought, this sounds like a truly bizarre combination so seems like it doesn't matter much what we specify (e.g. whether we leave the existing CSS 2.1 9.7 mechanism to apply first, resulting in two display:block flex items, or whether we insert something before the relevant "Otherwise" rule that does that, so that that rule doesn't fire, and we end up with a single anonymous-table flex item). CSS 2.1 section 9.7 is the best place to specify the computed value of 'float', so let's first skip forward to the part of css-flexbox section 4 that deals with this section: # The computed 'display' of a flex item is determined by applying the table # in CSS 2.1 Chapter 9.7 This has the same box-tree / computed-'display' circularity as the reference to section 9.7 mentioned in my previous message in this thread. We can fix this and specify the 'float' stuff at the same time as follows: | CSS 2.1 section 9.7 is amended to insert the following additional rule | after the existing rule 2: | | 2b. Otherwise, if the parent element has a computed 'display' of 'flex' | or 'inline-flex', then the computed value of 'float' is 'none', | and the computed value of 'display' is the specified value if | the specified value is an internal table value (i.e. is one of | ...), or set according to the table below if the specified value | is not an internal table value. (In particular, the inserted rule shouldn't mention "flex item", because not all of these elements will generate flex item boxes.) [Note that both the above and the element-to-box transformation description in section 4 must somewhat go out of their way to have table fixup occur (i.e. for adjacent internal table things to be merged to a single table flex item rather than a number of display:block flex items), and that the one implementation I tested happens not to implement table fixup (if I'm correctly interpreting what I see). So you might consider whether the table coalescing is something you want for authors or whether you were just guessing that that would be the easiest. (I'd guess that you do want it and that it wouldn't be too hard for implementations to honour, I'm just checking here.)] The immediately following text in the flexbox spec # (except that internal table # [<del>elements</del>] boxes # are instead handled by anonymous box fixup, see below). can and should now be removed (because it's no longer an exception). Elements whose specified 'display' is an internal table thing (i.e. table-*) continue to get "as specified", and anonymous table object generation will proceed as normal with no changes needed. (The outermost anonymous table box will be display:table by the existing rules in CSS 2.1, because the parent element's 'display' is not 'inline' but '(inline-)flex'.) Incidentally, once CSS has a normative description of box generation, I think the near-following text about table fixup can become a non-normative note. It almost can already, except that the CSS 2.1 text for table fixup is currently written in terms of making *changes* to a box tree [without even mentioning how those initial boxes relate to elements], rather than describing a single box tree that the rest of CSS (such as this bit of the flexbox spec) wants. You might even consider adding a comment along the lines | <!-- Should be made non-normative once CSS has a description of | anonymous table object generation that generates a single box tree | rather than making changes to a box tree. --> The above is all the difficult bits. Sorry if I've made a mistake, but it's getting late. The remaining comments are pretty straightforward. §5.4: # exactly as if the flex items were reordered in the source document. If talking about behaving as if reordering the source document, then I think it worthwhile to clarify that 'order' has no effect on counter values, e.g.: | However, 'order' has no effect on counter values. (Other places where one might consider mentioning counter values are sections 9.1 and 5.4.1. My own conclusion was not to in each of these two cases.) §8.3: # A value of auto for 'align-self' # computes to the value of 'align-items' on - # the element's parent, + # the flex item’s parent, # or <a value for=align-self>stretch</a> if - # the element + # the flex item # has no parent. This change should be reverted: the text in question is defining the computed value of the 'align-self' property, which needs to be done whether or not the element ultimately generates a flex-item box. (E.g. because "all properties defined in this specification also accept the inherit keyword as their property value.") One other change included in this commit is changing a prose condition for the over-constrained-aspect-ratio case to the form of an unordered list (and, incidentally, changing the behaviour for that condition). In that unordered list ("If the flex item has ..."), may I suggest adding semicolon after the first item and "; and" after the second ? This just saves a bit of time working out whether "and" or "or" is intended. That's all I noticed. Thanks for taking the time to fix these box generation things; we're slowly working our way towards having the box tree being defined in a way likely to be implemented interoperably. pjrm.
Received on Thursday, 13 February 2014 11:29:44 UTC