[CSSWG] Minutes Seattle F2F Tue 2014-01-28 PM II: Flexbox, <br>, Serialization and Shapes

• From: fantasai <fantasai.lists@inkedblade.net>
• Date: Tue, 04 Feb 2014 01:18:22 -0800
• To: "www-style@w3.org" <www-style@w3.org>
• Message-ID: <52F0B05E.9070600@inkedblade.net>

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).
       https://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
   https://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
   https://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> https://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