W3C home > Mailing lists > Public > www-style@w3.org > April 2012

Re: [css3-flexbox] spec nits

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 19 Apr 2012 17:25:48 -0700
Message-ID: <CAAWBYDBKKsBFAOOGkOz7p1oED_cxWyXtfNe+3cT=1W0kZQ_pTg@mail.gmail.com>
To: Daniel Holbert <dholbert@mozilla.com>
Cc: www-style list <www-style@w3.org>, Alex Mogilevsky <alexmog@microsoft.com>
On Tue, Apr 17, 2012 at 3:58 PM, Daniel Holbert <dholbert@mozilla.com> wrote:
>> Section 2. The Flexbox Box Model
>> In the cross axis, flexbox items can either "flex" to fill the available
>> space or be aligned within the space with the ‘flex-align’ property.
> It's confusing that we use the term "flex" to refer to cross-axis sizing
> here, since we otherwise only use that term for *main*-axis sizing.
> Could we replace "flex" with "stretch" in this sentence? (since that's
> the flex-align value that gives the behavior being described, anyway)


>> Section 3. New values for ‘display’ property
>> ...this specification will refer to the former kind of flexbox as a
>> block flexbox and the latter type as an inline flexbox.
> Despite what this quoted statement promises, the spec never actually
> uses those terms ("block flexbox" or "inline flexbox") at all, outside
> of this sentence. Maybe this sentence can just be dropped?

I really *should* be using this term in the sizing algorithm, as
"inline flexboxes" are "sized by their contents".  I'll figure out a
way to bring this up in the algo.

>> ... each of the flexbox items establish a new formatting context for
>> its contents.
> Nit: s/establish/establishes/
> ('each' is singular -- e.g. "each person establishes", not "each person
> establish".)

Done.  This catches me a lot, due to the proximity of the plural that
"each" is operating over.

>> 4.1. Absolutely Positioned Flexbox Children
>> Note: In most cases, this means that absolutely positioned items will
>> have no effect[...] The only exception is when the flexbox has
>> ‘flex-pack:justify’
> That's no longer "the only exception".  This should mention "flex-pack:
> distribute" as well.


>> 6. Ordering and Orientation
>> This functionality is exposed through the ‘flex-flow’ and ‘flex-order’
>> properties.
> Perhaps this should refer to 'flex-direction' and 'flex-wrap', instead
> of their shorthand version 'flex-flow'...?  It seems odd to mention a
> shorthand as the way in which a particular behavior "is exposed".  Maybe
> that's just me, though.


>> 6.1. Flexbox Flow Direction: the ‘flex-direction’ property
>> * row: The flexbox's main axis has the same orientation as the inline
>> axis of the current writing mode (the direction that text is laid out in)
> Perhaps "writing mode" here (and in the rest of this section) should be
> linkified to the CSS3-writing-modes spec? (perhaps to the writing-mode
> property itself[1] in that spec?)


>> 8.3. Resolving 'auto' margins
>> *  Immediately before pack and align steps...
> Nit: there's a stray '&nbsp;' in the source here, making this
> bullet-point's text indented further than its neighbors.


>> 9. Flexbox Layout Algorithm, chunk on resolving 'auto' margins:
>>   1. If leftover free-space is positive...
>>   2. If leftover free-space is negative...
> Nit: this doesn't say what to do with these margins if leftover
> free-space is 0. (neither positive nor negative)  I think (2) there
> should just say "Otherwise, ..." in place of "If leftover free-space is
> negative".


>> If a flexbox item has ‘flex-item-align:stretch'' and its [...]
> The quotes here are broken (‘ vs ''), and there's also a <code
> class="css"> tag that gets closed way too late, resulting in nearly this
> entire paragraph being colored blue.

Fixed all the stray occurrences of &#39; in the source.

>> Property index
> The entries under the "Percentages" heading in this table seem to
> actually be describing "Computed Value" -- they don't appear to have
> anything to do with percentages.
> (I'm not sure the table even needs a "Percentages" column, in fact,
> unless it's just standard to provide one.  Note that for 'flex', the
> only property here for which percentages could come into play, the
> computed value explicitly doesn't resolve percentages.)

The script that generates the index is kinda broken. I don't know what
exactly it looks for when generating that index. :/

Received on Friday, 20 April 2012 00:26:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:14 UTC