Re: [css-flexbox] LCWD: Notifier call for review

On 06/05/2015 09:01 PM, timeless wrote:
> http://www.w3.org/TR/2015/WD-css-flexbox-1-20150514/
>
> btw, the fact that Firefox (38.0.1 -- turns out the updater code is
> broken [1]) can't search for and can't select "example 5" etc. is
> really frustrating. I don't
> care if it's a UA bug [2] or a "feature" of your specification, please
> consider not using features that make it hard for people to read your
> specification/send feedback.

Filed at
   https://github.com/tabatkins/bikeshed/issues/474

>> /* Initial value. Main-axis is inline, no wrap. */
>
> "no wrap" -> "no wrap means it will overflow along the main-axis"

Well, this isn't necessarily true. It might overflow, or it might
shrink to fit. Expanded comment, in any case.

>> Example 8
>> This example shows four buttons that do not fit horizontally.
> ^ this could benefit from "and thus wraps and grows along the
> cross-axis" or something.

Okay.

>> so each of the three items on that line will receives 20px of extra width,
>
> will receives => will receive | receives

Fixed.

>> ending up 100px wide.
>
> possibly "each ending up"

A bit redundant since we have an each already, but added as requested.

>> The remaining item is on a line of its own and will stretch to the entire width of the line, or 300px
>
> or => i.e.

Fixed.

>> A flex container distributes free space to its items proportional to their flex grow factor,
>> or shrinks them to prevent overflow proportional to their flex shrink factor.
>
> I'm not sure what this means, but I suspect you want:
>
> or shrinks them (proportional to their flex shrink factor) to prevent overflow.
>
> the parentheses are optional, but the placement there is less ambiguous.

Fair enough. Rewrote as
   # A flex container distributes free space to its items
   # (proportional to their <a>flex grow factor</a>) to
   # fill the container, or shrinks them (proportional to
   # their <a>flex shrink factor</a>) to prevent overflow.
to maintain parallel structure.

>> This so that the flex shorthand can better accommodate the most common cases.
>
> so => is so

Fixed.

>> The equivalent effect can be had by using auto together with a main size (width or height) of auto.
>
> can be had => can be achieved

Fixed.

>> These properties apply only to flex layout until CSS Box Alignment Level 3 is finished and defines their effect for other layout modes.
>
> Does that mean that the definition for these properties are to be
> considered obsolete/superseded once CSS Box Alignment Level 3 is REC?

Yes. Well, CR really.

> The "for other layout modes" sort of indicates that it might not
> define them for this mode, or that it might...

It might or might not. Not really sure at this point. :)
Likely the specs will work in conjunction. But in any case,
this spec will not define them for other layout modes.

>> Note: Note that, if free space is distributed to auto margins, the alignment properties will have no effect in that dimension because the margins will have stolen all the free space left over after flexing.
>
> Note-Note ?

Fixed. (We started auto-generating "Note:".)

>> 1.If any of the flex items on the flex container’s first line ry in baseline alignment, the flex container’s main-axis baseline is the baseline of those flex items.
>
> There's a space missing after `1.`
>
>> 1. Otherwise, if the flex container has at least one flex item, and its first flex item has a baseline parallel to the flex container’s main axis, the flex container’s main-axis baseline is that baseline.
>
> This feels like a `2.`, but...

Looks like there was some kind of processing error.
Should be fixed now.

> I'm wondering if an empty box has a baseline, because if it didn't,
> i'd half hope that the first flex item with a baseline parallel to the
> flex container's main axis would be chosen -- instead of only
> consulting only the first flex item.

A fair criticism. I'm not sure if it's necessary to do this search,
though, because in such cases you're likely to have chosen baseline
alignment for at least one of the items (and we'd use that baseline
over any arbitrary information from the first cell).

However, I'll raise that as a separate issue...
   https://lists.w3.org/Archives/Public/www-style/2015Aug/0345.html

>> The flex items with the lowest (most negative) order values are first in the ordering.
>> If multiple flex items share an order value, they’re ordered by document order.
>
> I know what this is trying to say, but I wonder if it's ambiguous --
> the goal is that flex items sharing an order value are themselves
> ordered in document order, but that they collectively are ordered
> relative to other flex items according to their common order property.
>
> What it actually says, might possibly be interpreted such that the
> presence of two flex nodes with a common order value is essentially an
> error and takes them out of the general order property ordering and
> just orders them globally based on document order.

Mmm, I'm not sure it's that ambiguous. What you say wouldn't make
terribly much sense, for one, and for two, it says that *they* are
ordered by document order, not that the flex items as a whole are
ordered by document order.

> Example 12
>
> For example, the available space to a flex item in a floated
> auto-sized flex container is:
>
>> the width of the flex container’s containing block minus the flex container’s margin, border, and padding in the horizontal dimension
>> infinite in the vertical dimension
>
> ... this doesn't feel like an example, there's no sample code, there's
> no picture. `width` is used instead of `horizontal [size|dimension]`
> or something (width and vertical dimension aren't well related, and
> nothing in the "example" has established main/cross axes afaict.

Examples don't need to have code and pictures to be examples.

>>> If the flex item has ...
>> an intrinsic aspect ratio,
>> a used flex basis of content, and
>> a definite cross size
>
> I think this is missing a trailing `,`

Okay, added.

>> then the flex base size is calculated from its inner cross size
>> and the flex item’s intrinsic aspect ratio.

Not sure what you meant to comment on here.

>> Resolve the flexible lengths of all the flex items to find their used main size (see section 9.7.).
>
> You can probably drop the `.` after `7`
> Also, perhaps include a section symbol as in:
>> (or until a forced break is encountered, see §10 Fragmenting Flex Layout)

Fixed.

> http://www.w3.org/TR/2015/WD-css-flexbox-1-20150514/#algo-visibility
> The CSS for the Paragraph marker in `¶ 10` causes the first digit in a
> two digit number to become invisible when hovered, this is
> frustrating. [Firefox 38.0.1]

I think this has been fixed. Let me know if not.

>> This is a Last Call Working Draft of CSS FlexBox.
>> Flexbox has several additional cases where a length can be considered definite:
>
> Is it "FlexBox" or "Flexbox"?

Flexbox, or more formally, Flexible Box Layout.

>> Likewise, order does not affect the default traversal order of sequential navigation modes (such as cycling through links, see e.g. tabindex [HTML40]).
>> [HTML40] Dave Raggett; Arnaud Le Hors; Ian Jacobs. HTML 4.0 Recommendation. 24 April 1998. REC. URL: http://www.w3.org/TR/html40
>
> Is there a reason to reference HTML40? Isn't there a requirement to
> reference the latest version of W3 REC specs?
>
> I believe that'd be this:
> http://www.w3.org/TR/html5/editing.html#sequential-focus-navigation-and-the-tabindex-attribute

Updated.

Thanks again for the comments. I appreciate the close review.

~fantasai

Received on Monday, 31 August 2015 22:47:21 UTC