- From: Alex Mogilevsky <alexmog@microsoft.com>
- Date: Tue, 28 Feb 2012 04:32:15 +0000
- To: 'fantasai' <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Made changes to ED: > From: fantasai [mailto:fantasai.lists@inkedblade.net] > Sent: Thursday, February 23, 2012 9:43 AM > > On 02/23/2012 10:39 AM, Alex Mogilevsky wrote: > > > > *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... > > Anne requested it, to define the order of serialization when multiple reorderable > values are present. Moved to Bugzilla https://www.w3.org/Bugs/Public/show_bug.cgi?id=16141 > > *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 > paragraph. OK, removed issue > > *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 removed. Bug opened: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16143 > > *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? > > I'd prefer to keep it consistent with text-wrap, so we should change both to > nowrap or have both as 'none'. 'none' looks weird in the shorthand 'flex-flow': flex-flow:row none; makes way less sense than flex-flow:row nowrap; I don't hear strong preference either way, renaming to 'nowrap'. If > > > *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. > https://www.w3.org/Bugs/Public/show_bug.cgi?id=16145 > > *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. :) Done > > > *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. > > Yes. removed
Received on Tuesday, 28 February 2012 04:32:54 UTC