[css3-flexbox] open issues in spec

There is a number of open issues in the spec, some editorial. I would like to resolve as many as possible and update WD, ideally to get in shape for LC.

I have proposed resolutions marked as "==". Can we agree on what we can agree and discuss the rest ASAP?

Thanks
Alex

-----
Issue 1: Add "Canonical Order" fields to all the propdef tables, per http://wiki.csswg.org/spec/format-update.

What is it? I would do it but not sure what it means...

== Ok to move the issue to Bugzilla?

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

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

-----

Issue 4: For consistency with 'white-space', we should use 'nowrap'. For consistency with 'text-wrap', we should use 'none<http://dev.w3.org/csswg/css3-flexbox/#flex-flow-none>'. 'none<http://dev.w3.org/csswg/css3-flexbox/#flex-flow-none>' is the less dumb of these. Can we switch both this and 'text-wrap' to 'no-wrap'

== I like 'nowrap'. Change and resolve?

-----
Issue 5: Transitioning to/from a <length> (or to/from a <flex> with 0 flexibility) doesn't work well if it's the only flexible item in the flexbox. Rather than smoothly transitioning, it suddenly jumps in size when the flexibility becomes non-zero. Can we fix this, perhaps with a value that represents a percentage of the free space or something?

== To Bugzilla?

-----
Issue 6: Illustrate this example.

== TODO

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

-----

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

-----
Issue 9: TODO: examples

== TODO

-----
Issue 10: shrink-to-fit definition

Fantasai says it is 'max-content' defined in [css3-writing-modes]. That's a dependency but I don't see why it would be a problem at this stage.

== change text to say 'max-content', add normative reference to writing modes

-----
Issue 11: archived previous algorithm.

I think mine is simpler and guaranteed to finish.

== remove (or keep for reference until WD)

-----
Issue 12: forced breaks

I have some new ideas, will propose separately. I don't think this needs to be fixed before LC.

== keep

-----
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.<http://www.w3.org/Style/CSS/Tracker/actions/44>]

== remove the issue.