- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 04 Feb 2014 01:18:22 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Flexbox ------- - Tab explained that the flex distribution algorithm is changing for flex totals between zero and one (non-inclusive). Intent is to make this range continuous (rather than discontinuous, as currently). Reviews on recent changes to Flex Distribution Algo are welcomed. - Discussed problem of implied minimum size of flex items, which has gone back and forth a couple times as various cases come up for consideration (and was left open since Eliott's post on it last year). http://dev.w3.org/csswg/css-flexbox/issues-cr-2012.html#issue-23 - RESOLVED: No change to Flexbox spec for handling <br> (but see below). Styling <br> ------------ - RESOLVED: In Display Module, define br { display-box: contents; content: '\A'; white-space: pre; } to work. (This should result in change to handling of 'display: none', and change to HTML spec once published.) Serialization of Shapes ----------------------- - RESOLVED: Serialize a computed shape value per the email above. - RESOLVED: New LC for Shapes with a 3-week period. ====== 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 <br> Element (Blast from the Past) -------------------------------------- fantasai: <br> 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. <flexbox>foo <em></em> bar</flexbox> creates 3 flex items TabAtkins: However, if you replace <em> with <br>, then it's all one flex item TabAtkins: In chrome it's because <br> is treated kindof like text dbaron: We do this for <br>, 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 <br> does dbaron: I believe the same is true for some MathML elements SteveZ: Doesn't <br> start a new block? TabAtkins: <br> is weird goo plinss: Logically behaves same as page break, line break, whatever plinss: Like having a line-break-after property on it plinss: <br> is an element. Should get a box. Should be an element with a line-break-before element SimonSapin: Can we remove the magic from <br> 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 <br> a lot <dauwhe> <br class="large-print-edition"/> to force a line break in one format, set to display: none in other formats. <SimonSapin> HTML spec says br { content: '\A'; white-space: pre; } TabAtkins: Ok, we somehow need to figure out that <br> 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 <br> 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 <br> 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 <br> will require lots of testing. <br> has lots of weirdness. I don't remember what they all are, just remember it had a lot of weirdness ... TabAtkins: <hr> 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 <hr> is 50% of the available line width (considering floats), not CB width TabAtkins: Hm, not in Chrome. TabAtkins: Anyway, are people ok with <br> becoming a flex item on its own? TabAtkins: Rossen? SimonSapin: Can we agree that we need a spec for <br>? 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 <br> 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 <br> work as described above, no change to Flexbox only to Display <br type=coffee> Shapes Serialization -------------------- astearns: I had a serialziation proposal. <astearns> 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 <position> 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:18:51 UTC