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

Re: [css3-flexbox] spec review notes

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 30 Jan 2012 10:13:30 -0800
Message-ID: <CAAWBYDAE1QsBqiPy+3bGcLdXmd53LK098rRjVLK6P-3XeFa_6w@mail.gmail.com>
To: Alex Mogilevsky <alexmog@microsoft.com>
Cc: "www-style@w3.org" <www-style@w3.org>
On Sun, Jan 29, 2012 at 11:31 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> I have reviewed the spec, have some editorial changes that I'll make
> directly; here are some issues that may need a discusion:

Thanks for the detailed review!

> -- 1.1 new values for 'display'
>     # 'column-*' values compute to their initial values
> Why are multicol values singled out here? Are there no other properties that
> don't apply?

I don't *think* so.  I believe that and float multicol are the only
extensions to block layout so far that needs to be shut down like

> Is there a case for actually computing these values differently vs.
> ignoring?

No, either way would work.  I thought it made slightly more sense to
compute them to their initial since they're *required* to have no
effect, but simply ignoring them is fine.  I can switch if you'd like.

> -- 2.2.1. Positioning Absolutely Positioned Flexbox Items
>     # These placeholders are anonymous inline boxes with a width and height
> of ‘0px’
> Are they actually zero height or default line height? Maybe zero height is
> correct, just want to check.

I'm not sure.  They're required to not affect the line height, but
that's all I know.

> -- 3.2. Display Order: the ‘flex-order’ property
> It should have a note on drawing order. Maybe
>     | 'flex-order' property doesn't affect drawing order of flexbox items.

Yeah, I was planning on adding this, but got wrapped up in another
editting task on Friday.  Done.

I added "'flex-order' has no effect on stacking/layering; elements
must still be drawn over/under each other based on document order,
'z-index', and other relevant means.".

> -- 4. Flexibility: the ‘flex()’ notation
> You have deleted "4.2 Resolving Flexible Length" in favor of layut algorithm
> - that's OK, but now this section doesn't say what flexibility means. It
> should at least say that flexbox distributes available space to its children
> proportional to flexibitliy.

Good catch.  I've changed the opening paragraph of the section to:

  | The defining aspect of flexbox layout is the ability to make the
  | <i>flexbox items</i> "flex", altering their width or height to fill the
  | available space.  This is done by using a ''&lt;flex>'' value in the
  | element's 'width' or 'height' property.  A flexbox distributes free space
  | proportionally to its items based on their flexibility.

> -- 5.1. Main Axis Alignment: the ‘flex-pack’ property
>     # A previous revision of this spec allowed margins to flex directly...
> I don't think that note needs to be there. It is more confusing than helpful
> for understanding the spec and it doesn't refer to any specific future
> plans.

Alright, removed the note.

> -- EXAMPLE 7
>     # By using a vertical flexbox and ‘flex-align’, we can emulate the
> functionality of HTML's <center> element:
> Actually not exactly, "flex-align:center" is "true center", right?

Sure, it's not exact, but it's pretty close.

> Alignment
> formulas are missing from layout algorithm btw, so alignment behavior is
> currently undefined

Hm?  The layout algorithm says "For each flexbox line, align the
flexbox items per ‘flex-align’.", and then flex-align describes
precisely how to align them.

> -- 6. Multi-line Flexbox
> Line height: there is no option to stretch line cross size to flexbox (see
> separate email)

Yup, fixed.

> -- 6.1. flex-line-pack property
> I think it should have two more values:
>     'distribute' -- to match flex-pack
>     'stretch' -- to stretch lines in cross direction (and it should be
> default)

Yeah, it makes sense to match 'flex-pack' and add 'distribute'.  Done.
 I've already added stretch.

> -- ISSUE 6
>     # Should flexbox lines be actual boxes in the box-tree, or just a
> theoretical construct to help define things?
> The issue can be removed. There is no need for boxes in box tree, unless
> theoretical boxes would help in the spec (so far it seems ok without them).

I removed this issue on Friday.

> -- Layout Algorithm
> I have a lot of notes on that, will send separately.

Cool, I look forward to them!

Received on Monday, 30 January 2012 18:14:17 UTC

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