Re: [css3-flexbox] Editorial comments on ED 2012-04-20

Any issues without a response were accepted, and we tried to make the
obvious edits.

On Mon, Apr 23, 2012 at 2:36 AM, Anton Prowse <prowse@moonhenge.net> wrote:
> Issue 6:
>
> Regarding the above paragraph from Section 4, is there narrowing of a
> flexbox next to floats, similar to narrowing of BFC roots?

We tried to clarify this.  If you still have any concern, please
suggest some wording.

> Issue 11:
>
> Section 4 (Flexbox Items) says:
>
>  # Example 2
>  #
>  # [...]
>  #
>  # <!-- flexbox item: anonymous table wrapped around table-cell -->
>  # <div id="item4" style="display:table-cell">table-cell</div>
>
> Actually, the flexbox item in this case is the anonymous table /wrapper/
> that's wrapped around the anonymous table that's wrapped around the
> anonymous table-row etc etc.

This is an example, and should be clear enough.  I'm already omitting
the table-row detail; authors don't need to know about table wrappers
unless they're relevant.

> Issue 14:
>
> 4.1 (Absolutely Positioned Flexbox Children) says:
>
>  # Absolutely positioned children of a flexbox are not flexbox items,
>  # but they leave behind "placeholders" in their normal position in
>  # the box tree. These placeholders are anonymous inline boxes with a
>  # width and height of ‘0px’, and they interact normally with the
>  # flexbox layout algorithm. In particular, they'll trigger the
>  # creation an anonymous flexbox item wrapper boxes, or join
>  # neighboring inline elements in their anonymous flexbox item wrapper
>  # boxes.
>
> A height of 0px on the placeholder is meaningless because 'height' doesn't
> apply to non-replaced inline boxes.  I think you mean 'line-height:0'.
>
> [I believe that Alex questioned the use of 'height:0px' too, on the mailing
> list somewhere; but I can't find it now :-/.  No conclusion was reached.]

Corrected it to say they generate atomic inlines.  We'll start a new
thread on the slight change in layout that this causes.

> Issue 15:
>
> Observation: I dislike that abspos children leave placeholders behind; but I
> sympathize that it's really hard to spec static position accurately without
> them.

Hopefully making them atomic inlines makes this behavior more
sensible, as the placeholders themselves become individual items.

> Issue 16:
>
> Section 5 (Multi-line Flexbox) says:
>
>  # A flexbox can be either single-line or multi-line, depending on the
>  #  ‘flex-wrap’ property. A single-line flexbox lays out all of its
>  # children in a single line, even if that would cause the flexbox to
>  # overflow its bounds. A multi-line flexbox breaks its flexbox items
>  # across multiple lines to avoid overflowing, similar to how text is
>  # broken onto a new line when it gets too wide to fit on the existing
>  # line. Every line contains at least one flexbox item, unless the
>  # flexbox itself is completely empty.
>
> Does "bounds" mean "containing block"?  Actually, it's not explicit how
> overflow works for flexbox.

Changed the wording.

> In a single-line flexbox, does the line
> overflow the flexbox, or does the flexbox overflow its containing box?

This is well-defined in the layout algorithm.

> Also, s/avoid/attempt to avoid/ since overflow can still happen in some
> situations (eg if there is a single wide flexbox item).

"avoid" doesn't necessarily imply that it can't possible happen, just
that you're trying to make it not happen.  "attempt to avoid" would be
redundant here.

> Does an empty flexbox contain a line?

Yes (the layout algorithm says so), but there's no difference in
behavior either way.

> Issue 18:
>
> Example 3 in Section 5 discusses an example involving buttons with borders.
>  Unfortunately the border widths aren't taken into account in the
> calculations given.  This is largely because it's tedious and distracting to
> do so, but still...

There are no borders specified in the example, and buttons size their
border-box by default anyway, so there's no mistake here.

> Issue 21:
>
> Example 5 in Section 6.4 (Display Order: the ‘flex-order’ property)
> describes a tabbed interface in which tab three has been moved to become the
> leftmost of four tabs.  This is a strange example!  For me, the typical
> author expectation is that tab three is brought forward visually but doesn't
> change position.  Perhaps there exists a more natural use case that could be
> presented instead.

This is actually a pretty common UI behavior.

> Issue 23:
>
> Section 7 (Flexibility: the ‘flex’ property) says:
>
>  # The defining aspect of flexbox layout is the ability to make the
>  # flexbox items "flex", altering their width or height to fill the
>  # available space. This is done by using a ‘flex’ property. A flexbox
>  # distributes free space to its items proportional to their positive
>  # flexibility, or shrinks them to prevent overflow proportional to
>  # their negative flexibility.
>
> I'm not sure about "defining aspect"; after all, flexbox can be used quite
> productively without flex.

Given that the spec is called "flexible box layout", I'd say it's the
"defining aspect". ^_^

~TJ and fantasai

Received on Friday, 18 May 2012 00:01:25 UTC