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

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.

> /* Initial value. Main-axis is inline, no wrap. */

"no wrap" -> "no wrap means it will overflow along the main-axis"

> 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.


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

will receives => will receive | receives

> ending up 100px wide.

possibly "each ending up"

> 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.

> 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.

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

so => is so

> 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

> 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?

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

> 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 ?

> 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...

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.

> 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.


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.

> >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 `,`

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


> 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)


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]


> 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"?

> 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


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=394984
[2] Please fill in a bug url

Received on Friday, 5 June 2015 19:01:39 UTC