Re: [css3-flexbox] open issues in spec

On 02/23/2012 10:39 AM, Alex Mogilevsky wrote:
> *Issue 1:* Add "Canonical Order" fields to all the propdef tables, per
> What is it? I would do it but not sure what it means…

Anne requested it, to define the order of serialization when multiple
reorderable values are present.

> -----
> *Issue 2:*Although the term "flexbox formatting context" is defined here, it is not used anywhere else. BFC is the commonly
> used term for what it means here. Perhaps this could say that flexbox formatting context *is* a block formatting context, with
> different rules for how blocks are formatted but same protection from external floats etc. Then the terms can be used
> interchangeably, as they will be anyway...
> I put the issue there, in place of previous one. I don’t care all that much, can just remove it. The term is not very useful
> though, would be good if there was a generic term…
> == How about we call it “formatting context” – just like BFC but not a block flow?

It's not a block formatting context. I think flexbox formatting context is the
correct term to use here; I don't really see a problem with the wording in this

> -----
> *Issue 3: *Add a ‘|display:flexbox-item|’ value, so I can do flexbox-fixup (wrapping an anonymous flexbox around children that
> have declared themselves to be items).
> I am not too excited about creating yet another kind of fixup. Anonymous flexboxes don’t seem too useful either.
> == Move to bugzilla for tracking?

Sure. Could defer to L2.

> -----
> *Issue 4: *For consistency with ‘|white-space|’, we should use ‘|nowrap|’. For consistency with ‘|text-wrap|’, we should use
> ‘none <>’. ‘none <>’
> is the less dumb of these. Can we switch both this and ‘|text-wrap|’ to ‘|no-wrap|’
> == I like ‘nowrap’. Change and resolve?

I'd prefer to keep it consistent with text-wrap, so we should change both to
nowrap or have both as 'none'.

> *Issue 7: *Currently there are no separate properties for pos-flex, neg-flex or preferred size. If it doesn't change, there
> needs to be at least CSS OM access to the separate values. Parsing space-separated list is easier than functional notation,
> but figuring out the used value for preferred size is still far from trivial.
> Issue from me. Not essential for LC.
> == To Bugzilla

This is a CSSOM issue: it applies to every property that takes multiple values.

> *Issue 8: *Finalize and define what happens to auto margin (main axis and cross axis).
> This is important, we really want to resolve one way or another and settle. I see positive feedback for auto margins on main
> axis. Can live with any resolution.
> == propose: Cross-axis -- safe align, Main-axis -- distribute extra space (if positive) after flex, before pack

Your proposal works for me. :)

> *Issue 13: *[Change or remove the following CR exit criteria if the spec is not a module, but, e.g., a Note or a profile. This
> text was decided on 2008-06-04. <>]
> == remove the issue.



Received on Thursday, 23 February 2012 17:43:44 UTC