W3C home > Mailing lists > Public > www-style@w3.org > February 2012

[CSSWG] Minutes and Resolutions Paris F2F 2012-02-08 PM I: Flexbox, Line Layout

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 13 Feb 2012 18:29:57 +0100
Message-ID: <4F394895.90904@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Flexbox
-------

   - Discussed switching 'flex()' notation back to a 'flex' property
   - Discussed using margins for alignment in place of or in conjunction
     with flex-item-align

CSS3 Line Layout
----------------

   Steve Zilles presented a proposal for the scoping of the CSS3 Line Layout
   module (which needs significant rewriting since the previous publication).
   Scope would include
   - line processing model
   - defining line layout from 2.1 with more precision
   - choosing baselines to use for alignment
   - line grid proposal from Kyoto F2F
   - possibly other stuff

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

Flexbox
-------

Scribe: fantasai
   Tab: We have a few issues that are not big or controversial, just
        Alex and I disagree.
   <alexmog> http://wiki.csswg.org/spec/css3-flexbox#open-issues
   Tab: Two open issues: 18 and 19, and a third one raised by fantasai
   Tab: Issue 18
   Tab: Right now, in current flexbox as written, auto margins resolve to zero
   Tab: if you want to align things, you use flex-pack or flex-align
   Tab: In my old proposal auto margins flexed
   Tab: Alex prefers having margins flex in cross axis
   Tab: And alignment property is fallback
   Tab: If both are auto, center it. If one is auto, align to other side
   Alex: flex-item-align is somewhat redundant with aligning with margins
   Alex: Most things that can be done with alignment can be done with
         flexible margins
   Tab: Right. I dropped that idea because of baseline alignment
   Alex: If choice is between margin alignment and a separate property,
         separate property is better because it easier to understand,
         and it does support baseline alignment, which margins wouldn't
   Alex: The concern I have for not doing margin alignment is that in
         situations where margin alignment works, it is already a
         well-understood way to align things.
   Alex: if you take normal block flow and change to vertical flexbox,
         you will get the same behavior: won't get surprises
   Alex: There is also not really any contradiction in using margins
   Alex: Flexbox can insist that auto margins resolve to zero, but it
         doesn't have to.
   Alex: So if both flexbox code and margin code, no special code added,
         it will just work.
   Alex: Setting auto margins to zero seems artificial: no good reason
         to do it.
   Tab: So, auto margins being flexible or zero.
   fantasai: Note that zero is the default, so you have to explicitly ask
             for auto to get the flex behavior.
   dbaron: I tend to prefer flexible, though I think auto is confusing a
           keyword
   fantasai: I prefer flex over zero as well
   Alex: There was another option that we briefly discussed, that centering
         and aligning things using flexbox alignment properties does true
         center and does start-end alignment regardless of overflow
   Alex: overflow will still be end alignment
   Alex: Margin alignment however should be do what margins do in normal
         flow: If overflow happens, margin: auto should not result in true
         centering, should just set those margins to zero and apply
         whatever alignment
   Tab: Basically, use auto-resolution rules from block
   Alex: I kindof like that approach even though we have three ways to
         align an item. They're all consistent. Margins are consistent
         with margins everywhere, and box properties consistent with each
         other, and there are no conflicts in flexbox algorithm.
   Tab: So we have 2 people for flexible auto margins. Anybody think auto
        margins should resolve to zero?
   Rossen: Why do you want them to be zero?
   Tab: Simpler, don't have another way of doing alignment.
   Tab: It's not problematic, it's just an extra thing.
   dbaron: Is there an existing mechanism that acts on the item individually?
   Tab: flex-item-align property
   dbaron: I guess I'd lean towards making auto margins zero.
   Bert: This looks a lot like vertical-align, so why not use vertical align?
   Tab: The name is confusing.
   Alex: There is more to it including grid consistency.
   Bert: This is specific to flex, but in grid we also have alignment.
   Bert: And then we have table alignment.
   Bert: If they all use different properties, it might be too much.
   fantasai: flex-item-align exists because of baseline alignment, right? ...
             I think we can get away with not having a separate property.
   fantasai: need to think about it
   Alex: baseline alignment per item isn't particularly useful
   Alex: You can set flex-align to baseline, and then use margins to change
         anything you want not baseline-aligned
   Tab: You can't mix stretch and baseline then
   ... some confusing discussion ...
   Alex: I think the situation of some items being baseline-aligned and
         others being stretched is kindof rare.
   Alex: So if that's the only reason to have an extra property, it's not
         worth it.
   * fantasai agrees with Alex
   Tab: If we use margins for alignment, still have issue of consistency
        with blocks vs. true centering
   fantasai: If you have flex-align, you can do true centering. Just can't
             mix it with baseline.
   Tab: But I want that for [toolbar example?]
   fantasai: I think the three of us should get in a room and figure it out.
   Tab: Response so far seems to indicate that group has no opinion.

   Tab: Next topic. Flex function
   Tab: Right now you set flex() on either 'width' or 'height'.
   Tab: This has the downside that flex() is only valid width or height,
        depending on orientation of the flexbox.
   Alex: Before I would start describing why flex() is bad, I would say
         that it doesn't have to be a function to begin with.
   Tab: Getting to that.
   Tab: If you, for whatever reason, change the orientation, you have to
        switch which property you set it on.
   Alex: And you have to store it on both properties.
   Tab: Alex instead suggests a separate property that indicates the flex
        in whichever dimension is appropriate
   Alex: I would be fine with either flex property with same value, or flex
         property that just gives flexibility and use width/height as
         preferred size
   fantasai: Ahhh, I can see that there's a problem either way you go there.
   fantasai: If you want preferred width as zero, because you want just flex,
             then you don't want that stored in 'width' because when you
             remove flexibility you get something nonsensical
   fantasai: But if you set preferred width to your actual preferred width,
             then you do want that stored in 'width' because when you remove
             flexibility you want to get that size.
   Alex: Other problem with flex function is you can't set flex separately
         from width or height.
   Alex: Seems to be a completely reasonable thing to do
   Alex: Everywhere else this would have been a separate property
   Alex: Hard to work with the functional notation.
   Alex: And you cannot cascade flex separately from preferred size
   Alex: And animations would be really difficult to apply to flex function
   fantasai: animate from flex 1 to flex 2?
   Tab: No problem. But animating from no flex to flex is a problem. But a
        separate issue than this.
   Alex: my preferred solution would be to have a flex property with three
         values. Fine with having preferred size there.
   Alex: For implementation it is redundant.
   fantasai: But then you don't get your separate cascading.
   Alex: Have sub-properties.
   fantasai: I don't think positive and negative flex need to cascade separately.
             Do you?
   Tab: No...
   fantasai: I think they should stay one property. If the issue is ease of OM
             access, that's a separate issue that we need to solve globally.
   fantasai: I think the only thing you need is one property with positive and
             negative flex and a switch for using 'width'/'height' as preferred
             size or using zero.
   nobody else seem to care

   discussion of stabilizing spec
   Alex: fantasai's condition for moving to LC was that dbaron reviews and
         approves the spec
   dbaron: Would prefer if feature design would stabilize before moving to LC
   Alex: These issues are coming up as a result of me implementing the spec.

   Bert: Have a question.
   Bert: Flex seems very similar to fr unit in Grid. Can't you use one or the
         other?
   Tab: I think grid is planning to move to flex()
   Tab: Can't use fr unit because we need a triplet for flex: preferred size,
        positive flex, and negative flex.
   Tab: fr unit only provides one of those.
   Alex: We had that as a unit at some point in Flexbox
   Tab: But replaced it with e.g. flex(1)
   Tab: So Grid was planning to move to flex() function. But we no longer have
        a flex() function anymore.
   Alex: Would be weird to remove fr in favor of flex()
   Tab: Primary need of flex() function was to establish minimum for flexing
   Tab: For grid. You needed a minimum size for columns. But you have the
        minmax() function
   Alex: ...
   Tab: Using just the fr unit is too weak, because I want to say this column
        is ... with minmax() a lot of function of flex() is subsumed
   Tab: So fr unit is okay. probably don't need flex function there.
   Bert: Does the flex property apply to tables, too? To <col> element for example?
   fantasai: what happened to the multi-length unit for tables? I remember
             it was implemented, because I wrote tests for it.
   dbaron: I removed it at some point.
   dbaron: What the spec said it was supposed to do was same as percentages
   Tab: When someone defines table layout, we can figure it out at that point.
   [discussion of how undefined table layout is]

   Tab: Anyone else have any comments on flexbox?
   fantasai: Process is, the three of us get to the point where we can't find
             any more issues. Then we give it to dbaron. If he can't find any
             issues, then we go to LC.

   Bert: Are you replacing flex() with one or two properties?
   Alex: Only one. Because there's only flex in one dimension.
   Bert: What about grid?
   Alex: ...
   Bert: I'm specifically thinking about andrew fedoniouk made
   Bert: He did grid and flex together, and came up with a 2D flex model
   Tab: You can do a flex grid. But it's not the same thing as the grid layout
        module that we're talking about.
   Alex: Flexbox has a lot of details not applicable to grid.
   fantasai: Should think about 2D flexible layout, if we do that we'd need
             flex in 2 dimensions.
   Tab: Can you link to Andrew's model?
   <Bert> -> http://www.terrainformatica.com/w3/flex-layout/flex-layout.htm
          documentation of Andrew Fedoniouk's grid/flex combo (see last
          para of section 3.5)

   fantasai: Anton and I were suggesting that instead of calling the container
             a "flexbox" and the children "flexbox items", we should call the
             the boxes that actually flex "flexboxes" and call the container a
             "flex container" to be consistent with how we use terminology
             elsewhere, like blocks and block containers.
   fantasai: To make the 'display' value consistent with this, we suggest
             "display: flex" and "display: inline-flex"
   Anton: I'm not won over by 'display: flex', but can't think of anything better.
   dbaron: I think making display:flex make something a flexbox container is
           confusing
   Alex: This is the first I hear about this, so let's discuss this first.
   * sylvaing renaming -> www-bikeshed mailing list

Line Module
-----------

   Steve posts slides
   "CSS Line Module Processing Model"
   Steve: Sent a message to the mailing list
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2012Feb/0238.html
   Steve: Basically talking about a processing model for line module
   Steve: At November F2F we agreed jdaggett and I would edit Line module
   Steve: And to incorporate line grid material into it
   Steve: Because line module talks about alignment
   Steve: To begin that process, wanted to get agreement on what the processing
          model is for the line module
   Steve: Then have a slide about next steps.
   Steve: So this is not quite the model I put out in the message to the
          list because dbaron looked at it and commented, so I tried to
          incorporate dbaron's comments.

   Steve: Basically, what happens is that with one small exception, you can
          largely do line breaking and justification prior to doing alignment
   Steve: It's presumed that's what the Text module is describing.
   Steve: This is describing alignment within that.
   Steve: So once I've got a line, then I have to adjust each component of
          the line relative to its parent
   Steve: based on alignment points, leading, and other things don't want
          to get into.
   Steve: Having done that, then compute height of line, size of line box.

   Steve: Two ways of taking that line box and putting it on to the current
          flow in the block direction.
   Steve: If there is no line grid, no alignment to the line grid, then we
          just stack the top of the new line box at bottom of previous.
   Steve: Relatively straightforward.
   Steve: If there is a line grid, then some baseline in the line box is
          aligned to some baseline in the line grid.
   howcome thinks the word 'table' in there is confusing
   Steve: After I define the line height, I might have things that collide
          with floats.
   Alan: That will require you to recalculate the width
   dbaron: If you're laying out lines within a space like this
           *draws two lines denoting sides of containing block*
   dbaron: If you have floats like this
           *draws narrow float and fat float below it*
   dbaron: If the height of the line or its position winds up with the
           bottom of the line here, you're fine.
   dbaron: But if the bottom of the line ends up here
           *draws line adjacent to fat float*
           then you have to shorten the line and redo line breaking
   dbaron: We should stick to rule that once you shorten it, you don't
           lengthen it again.
   dbaron draws "this is some <big>TEXT</big>"
   dbaron draws "this is some" onto the line, and "TEXT" onto a next line.
   dbaron: It would fit horizontally, but it would make the line tall
           enough to intersect the fat float, which would make it no
           longer fit.
   http://lists.w3.org/Archives/Public/www-archive/2012Feb/att-0012/dsc03591-dbaron-drawing-on-linebox.jpg
   dbaron: Not sure we define what happens in this case.
   <Bert> (Re the <big>TEXT</big> example: You might instead make an
           earlier line a little longer or shorter.)

   "Baseline Tables"
   Steve: It basically notes that you have different alignment points
          for different scripts. Latin typically alphabetically. Some
          northern Indic scripts to hanging baseline. Ideographic to
          ideographic baseline, which is usually the text-after-edge
   Steve: So the current vertical-align property doesn't really deal
          with that, so one of the other tasks the line module took
          was to come up with a reasonable set of properties that give
          you control over vertical-align, allowing for different
          baseline tables.
   Steve: Few complications to it. In particular, there's a notion
          called 'dominant baseline', e.g. if you put Latin text in
          Japanese document, the dominant baseline would be ideographic.
          But Chinese text in English document, dominant baseline is
          alphabetic.
   Steve: Matters because baseline tables are different by font
   Steve: The last complication is that I define what alignment is for
          a given font size and dominant baseline, but there are certain
          baseliens you can align to that don't come from the font.
   Steve: text-top and text-bottom, which come from leading,
   Steve: and bottom and top, which are even messier.
   Steve: algorithm in 2.1
   Steve: Collection of alignment points I have to deal with, some computed
          as a result of laying out the lines.

   howcome: Statement of different baselines having different baseline
            tables doesn't make sense to me.
   some explanation of baseline tables
   most fonts have one baseline table
   but some fonts have multiple baseline tables: you choose a different
   one depending on your dominant baseline
   howcome: CSS shouldn't have to say what the dominant script is
   Steve: there are defaults, and it is automatically specified
   jdaggett: That's a detail we don't need to depend on right now.
   howcome: If we have to deal with it we have to deal with multiple baselines.
   howcome: we use the term 'baseline' in vertical-align, but don't specify
            which one.
   fantasai explains dominant baselines and how they're used for alignment
      See http://www.w3.org/TR/css3-writing-modes/#baseline-alignment
   dbaron: based on what Steve was saying, this is what I imagine is an example
   dbaron: You were talking about different sets of baseline tables, I was
           imagining perhaps Chinese text within English aligning different
           from English text within Chinese.
   dbaron: Here, ideographic baseline matches alphabetic, because alphabetic
           is dominant
   dbaron: Whereas here the Latin is centered between the top and bottom of
           the ideographic characters because Chinese is dominant and you
           want to fit everything within the embox
   Steve: That's somewhat exaggerated, but yes.
   http://lists.w3.org/Archives/Public/www-archive/2012Feb/att-0012/dsc03592-dbaron-drawing-on-multiple-baseline-tables.jpg

   howcome: I'd like to add my use case
   howcome: In a multicol element...
   Steve: Haven't gotten to line grids yet.
   Steve: So that's what baseline tables are about.
   Steve: Concerns I have --
   Steve: determining top and bottom of baselines. It is in 2.1 except 2.1
          is underspecified intentionally
   Steve: I see as a goal of this effort is trying to come up with a reasonable
          definition, because if we don't, we will never be able to do the
          line grid
   jdaggett: It would be good to interact with type design community to [...]
             to get a consistent platform. Right now we cannot, for a given
             font, which of several different metrics are given, we currently
             specified one or the other because there's disagreement about
             which one should be used.
   ChrisL: Platforms disagree on which set of metrics to use.
   Steve: Ascenders and descenders are an example

   Steve: Last point is, it's been noted that good typography doesn't put
          half-leading at the top of the box.
   fantasai: or the bottom, if there's a border or anything you can see
   jdaggett: So having some way of being able to say you'd like that behavior
             seems desirable
   fantasai: This is complicated by the fact that two paragraphs after each
             other, if you turn off half leading at the top (and/or bottom)
             you will have not enough space between the two
   dbaron explains this situation further
   dbaron: It's in the minutes from the Kyoto meeting.
   <dbaron> Basically, that CSS lacks a distinction between blocks that
            establish frames and blocks that just have line breaks
   <dbaron> and we need the interline spacing at block boundaries for things
            that aren't frames (with the half-leading at the edges of each
            of the blocks)
   <dbaron> but that when we're in a block that happens to be at the edge
            of a frame we don't want that interline spacing
   Steve: So, I treat that as a goal.
   Florian: I think we should deal with the more critical things first.
   Steve: That's why I treat it as a goal.

   Steve: Okay, line grids
   Steve: This example is taken from the line grid spec
   Steve: Points out what the key goal of the line grid spec is
   Steve: If you have, as seen in this multicol, you'd like to ensure that
          the body text lines up across the columns.
   Steve: So you could get interrupted by a figure
   Steve: or text in a different size
   Steve: But it should resynchronize at the next point
   jdaggett: We're using line grids in a couple different contexts.
   jdaggett: In this case seems you're really arguing for line boxes are
             spaced at integral...
   howcome: It's a discrete unit.
   jdaggett: There's a concept of aligning this thing with other thing.
   jdaggett: Multi-column case is different, because you want integral amount
             of space.
   Alan: In the multicol case it's still a grid, it's just something achievable
         if you can control the other line heights (points at images, headings)
   chrisL: The heading, e.g. , is not snapped to the grid.
   Steve: Key thing is within the line grid spec, talks about a constant rhythm.
   jdaggett: There are cases where the metrics of the font will tell you that
             the line box has grown
   jdaggett: Want to achieve where things like subscripts leaking out of the
             line box but not colliding with anything don't interrupt the rhythm
   Steve: Similarly to my topics of concern of alignment, some concerns for line
          grid
   Steve: Idea is that for a container, typically a page, I would define a
          current font font-size and line-height, and that would determine
          spacing used for that container
   Steve: Question is, to what do I align in that?
   Steve: I need a table of baselines for each of the slots that I needed
   Steve: I can have for example columns where the left column is in English,
          right column is in Hindi
   Steve: They want to align up to the rhythm, but the alignment points are
          different for each of them
   fantasai notes this is already covered by line-grid proposal
   ...
   Florian: Are you discussing what fantasai proposed in Kyoto? something
            else? the problem space? how that proposal fits into the problem
            space?
   Steve: Hopefully.

   Steve: So, I left this as a question...
   Steve: Can I always just align the dominant baseline in the line, because
          all other lines are aligned to dominant baseline
   Steve: That depends on computing dominant baseline in the line, which you
          can't do today
   Steve: Then, if I go back, if I look at these headings and images (image
          taken from line-grid)
   Steve: If there are chunks that don't align to grid, but want to placed
          within an integral number of line units
   Steve: Question is what do I do with the extra space?
   Steve: Could top bottom or center it
   Steve: Bert pointed out TeX has a nice feature called glue, similar to
          flex, which can determine space left above/below
   Steve: So certain analogy to flex
   howcome: Makes sense, but simple alignment seems like a good idea.
   discussion of aligning blocks inside integral number of lines

   Steve: Last point is issue of top-line leading, you might want to define
          an offset of the line grid from the top of the container
   Steve: So in general, might want to say 'line grid starts here"
   Steve: Shift the line grid, though grid is infinite in either direction

   Steve: proposed plan
   Steve: We have a draft that is seriously out of date
   Steve: First step is to take what's there and
   Steve: a) update to current template
   Steve: b) drop things that are out-of-scope
   Steve: e.g. defer drop-caps
   ChrisL: If you can do integral number of line grid units, you've solved
           quite a bit of the drop-caps problem
   Steve: Next thing is redo the introduction based on the processing model
          I just outlined
   Steve: Then implement resolution of moving the Line Grid description
          into this spec
   Steve: And then have something to discuss at Hamburg F2F.
   discussion of publishing strategy
   Steve explains that he tried to send the presentation to the mailing list
         twice and failed, and that's why it's not there.
   Florian: I'm happy this is being worked on.
   [ discussion of slide format conversion and avoiding [?] ]

   ChrisL: SVG 1 already has the concept of aligning baselines, and it's a
           little handwavy. If we can point to this in SVG2 that would be
           preferable.
   dbaron: speaking of SVG and other formats
   dbaron: I'm going to attempt to describe what happened, and Chris will
           correct me where I'm wrong
   dbaron: I think XSL1.0 took the CSS vertical-align property and turned
           it into a shorthand for 3-4 other properties
   dbaron: SVG then took a subset of those properties, but didn't reflect
           vertical-align as a shorthand
   dbaron: I think what we want to wind up with is vertical-align as a shorthand.
   ChrisL: That's correct except XSL didn't really have shorthands. It had
           a way of expanding a property into traits, which is not quite
           the same as our shorthand.
   dbaron: If we introduce these properties back from svg, would prefer not
           to have multiple properties with same set of values not shorthand
           of each other
   dbaron: beware there's a bit of hornets nest with some of these properties
   dbaron: we'll probably talk about it again in the future.
   <glenn> see http://www.w3.org/TR/2006/REC-xsl11-20061205/#shortexpan
           for more info on XSL shorthands

   Alan: On the www-style mailing list, there were an argument that went over
         and over again about what a line box is
   Alan: One person said that box that contains glyphs but not the half-leading,
         and other ...
   dbaron: Sure this isn't about inline box? Because if this is about line box,
           these people had no idea what they were talking about
   Alan: What's a line box?
   Steve: A box that ocntains the line. Complex rules that define its top and
          bottom.
   ChrisL: do glyphs always fit in line box?
   No.
   smfr: ever a gap between line boxes?
   No (except for floats and clearance)
   <dbaron> My previous research into the messy set of properties that might
            be a shorthand is https://bugzilla.mozilla.org/show_bug.cgi?id=308338#c21
            and my opinion on the way to proceed is
            https://bugzilla.mozilla.org/show_bug.cgi?id=308338#c28
   ChrisL: Does clearance realign to line-grid?
   fantasai: My conclusion from last time I looked was that vertical-align
             should not be a shorthand.
   fantasai: vertical-align: baseline should use dominant baseline
   <glenn> believes vertical-align should be a shorthand
   fantasai: Most cases can just use the dominant-baseline of the parent
             to choose the appropriate alignment baseline.
   dbaron: We might not want dominant-baseline to be part of vertical-align,
           but if we have alignment-shift and alignment-?, those should
           probably be part of vertical-align
   dbaron: I think alignment-adjust and baseline-shift should definitely be
           subproperties of a vertical-align shorthand if they're included.
           I don't have a strong opinion on whether dominant-baseline should
           be in the vertical-align shorthand.
   Bert: What happened with vertical aligning of image?
   SteveZ: At minimum, we'll add top, bottom, center, and we'll consider
           adding glue/flex.

<br duration="calc(15 * 60s)" />
Received on Monday, 13 February 2012 17:30:31 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:50 GMT