[CSSWG] Minutes Seattle F2F Tue 2014-01-28 PM II: Flexbox,
, Serialization and Shapes from fantasai on 2014-02-04 (www-style@w3.org from February 2014) (original) (raw)

Flexbox

Styling

Serialization of Shapes

====== Full minutes below ======

Flexbox

Scribe: fantasai

TabAtkins: There's an issue in Flexbox where it doesn't interact well with animation in certain cases TabAtkins: e.g. start with inflexible items, then try to animate an item to flex: 1 TabAtkins: the item snaps from inflexible to taking all the free-space immediately TabAtkins: Same thing for shrinking; it's discontinuous between 0 and non-0 TabAtkins: To change it I made a small tweak to flex algorithm, which afaict makes zero difference to all existing cases where sum of flexes is either zero or is 1 or greater TabAtkins: but is continuous between 0 and 1 TabAtkins: dholbert agrees with the problem and the rough solution to the algorithm TabAtkins: If anyone has opinions on that, or have an implementation, please review

TabAtkins: There's another issue, but we don't understand it well yet http://dev.w3.org/csswg/css-flexbox/issues-cr-2012#issue-23 TabAtkins: dholbert thinks Chrome's behavior is more sensible than Firefox's in this case. We haven't quite figured this out yet TabAtkins: So won't bring it up now

TabAtkins: Also have issue of min-size of flex items fantasai: Rossen and I did some interesting testing fantasai: IE does what Alex proposed -- min-size of min-content, except when overflow is scrolling TabAtkins: Ok... I will talk to our implementers TabAtkins: I think we can make the change, because doesn't affect [...]

The
Element (Blast from the Past)

fantasai:
element issue http://dev.w3.org/csswg/css-flexbox/issues-cr-2012.html#issue-28 TabAtkins: Issue comes up when creating anonymous flex items TabAtkins: Flex item creation splits things on element boundaries: each child element becomes a flex item, and runs of text between get wrapped in anonymous flex item TabAtkins: e.g. foo bar creates 3 flex items TabAtkins: However, if you replace with
, then it's all one flex item TabAtkins: In chrome it's because
is treated kindof like text

dbaron: We do this for
, but also for some MathML stuff dbaron: There is a rule for Flexbox that conversions that happen for computed value of display dbaron: Inlines that are children of a flexbox have their computed display changed to block dbaron: So that span there is display: block dbaron: Then code comes over that does this dbaron: It runs over what should go into an anonymous frame dbaron: by using a test of "does this participate in inline layout?" dbaron: span with display : block doesn't dbaron: but
does dbaron: I believe the same is true for some MathML elements

SteveZ: Doesn't
start a new block? TabAtkins:
is weird goo plinss: Logically behaves same as page break, line break, whatever plinss: Like having a line-break-after property on it plinss:
is an element. Should get a box. Should be an element with a line-break-before element SimonSapin: Can we remove the magic from
and spec it? florian: Is it an element? plinss, Tab: yes, it's an element in the DOM dbaron: It gets its own box, it's just an interesting sort of box. :)

TabAtkins: Firefox, for example, will honor 'display: none'. Chrome doesn't. dauwhe: We use display: none on
a lot
to force a line break in one format, set to display: none in other formats.

HTML spec says br { content: '\A'; white-space: pre; } TabAtkins: Ok, we somehow need to figure out that
works in this way... dbaron: I'm not saying our behavior is desirable fantasai: What else do we use inline slurping for? dbaron: block-in-inline splitting, maybe? TabAtkins: I guess, would you want to change so that
becomes a flex item? dbaron: I'd be fine with that if it makes more sense ... dbaron: If in between foo and bar you have a span that is floating or absolutely positioned, it's out-of-flow and doesn't count

TabAtkins: So right now flexbox and reality don't agree TabAtkins: Also, we need to define what
does ... fantasai: what are reasons why HTML's definition doesn't work? plinss: If we make it CSS-defined, then changing display or other properties has to be respected fantasai: Spec for
will require lots of testing.
has lots of weirdness. I don't remember what they all are, just remember it had a lot of weirdness ... TabAtkins:

is describable in CSS. fantasai: No it's not. Next to a float it's not TabAtkins: It's just a BFC fantasai: No, width 50% on
is 50% of the available line width (considering floats), not CB width TabAtkins: Hm, not in Chrome.

TabAtkins: Anyway, are people ok with
becoming a flex item on its own? TabAtkins: Rossen? SimonSapin: Can we agree that we need a spec for
? fantasai: I think we need to investigate why the HTML definition doesn't work dbaron: I'm not sure that it doesn't. But might have some perf implications plinss: Fine to make magic by default, as long as can opt out of magic TabAtkins: Rossen confirms that IE does the same for
TabAtkins: We might need to make it magic

fantasai: display-box: contents; content: '\A'; white-space: pre; TabAtkins: Hm, that might work... [side discussion of interaction with display-box and display: none] [currently display: none won't work on this, but people seem to prefer that it does] dbaron: [something about quirks mode] plinss: We don�t need to define quirks mode. Someone points out the quirks mode spec.

RESOLVED: No change to current behavior for issue 28, work on making
work as described above, no change to Flexbox only to Display


Shapes Serialization

astearns: I had a serialziation proposal. http://lists.w3.org/Archives/Public/www-style/2014Jan/0572.html astearns: fantasai and David looked at it, I made slight adjustments based on feedback. astearns: I'd like to resolve to go with this email's wording, and take Shapes to LC again.

dbaron: You said IE and FF use keywords instead of lengths. dbaron: Were you testing keyword input? dbaron: There's a distinction between preserving what's specified and changing it. dbaron: I don't see anything that converts - in our computed style code we serialize out percentages. astearns: I looked at gCS of a declared style that used keywords. fantasai: No, we looked at declared style.

astearns: My goal is to harmonize what we do with a value in Shapes and bg-position. astearns: The only commonality we saw is that the older version preferred 2-value over 1-value. astearns: Browsers seemed split over keywords vs percentages. astearns: I saw a split, and have a slight preference for lengths, so I used lengths. dbaron: For declared style, we preserve an inputted keyword. dbaron: For computed, we do length/percentages. krit: Should we harmonize that? dbaron: We do two versions of everything.

astearns: I could take this and say it's how to serialize the computed style. astearns: I'd like to normalize the computed output. dbaron: We probably ought to have a larger discussion about serialization between declared and computed. dbaron: I'm fine with this for computed.

dbaron: I feel like we may want slightly better round-tripping for declared values. astearns: So would you be okay with this section noting that it's for computed style, and not defining for specified? dbaron: Yeah. I'd probably be okay with saying it's for declared as well, but I'm not crazy about it. astearns: We'll probably do that in our impl anyway. But I'm fine with normatively defining it to be the computed value. astearns: And nothing else. krit: Computed style is a good start - if we can get farther, that would be great. astearns: I think anything further we do should be a global thing, not just for shape functions.

RESOLVED: Serialize a computed shape value per the email above. RESOLVED: New LC for Shapes with a 3-week period.

krit: Any chance we can specify serialization for all properties? dbaron: What I was clear about when Anne tried it is that it will take research. dbaron: We can't take the lazy-spec approach that requires impls to break interop. krit: We did an interop-breaking change for currentcolor. dbaron: We had good reasons for that, we have a good reason to believe it won't break things, and we'll do experimentation. dbaron: Higher chance of breakage for serialization change, and it's everywhere. krit: What if browsers aren't currently interoperable? dbaron: Then we can do new things. dbaron: We had a problem with Anne's rule [...] dbaron: Where browsers are currently interoperable, we should be explicit about deciding to change it. dbaron: We should also think about the magnitude of the code changes required. dbaron: A spec with a small rule that leads to thousands of lines of code changes is different than a rule that leads to a small amount of code changes. dbaron: Anne's general rule was probably not tested sufficiently given the magnitude of the required changes. florian: Make sure you think about rule serialization too, not just properties.

Received on Tuesday, 4 February 2014 09🔞51 UTC