W3C home > Mailing lists > Public > www-style@w3.org > September 2011

[CSSWG] Minutes and Resolutions 2011-09-21

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 21 Sep 2011 17:04:37 -0700
Message-ID: <4E7A7B95.8020703@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:
   - Anton Prowse joins WG as Invited Expert
   - View Mode spec is blocked on Media Queries which is blocked on implementations.
   - Discussed column-span and margin collapsing again
   - RESOLVED: Make flexbox do "safe centering"; add control for overflowing
               to allow switch to "true centering"
   - RESOLVED: Adopt 'flex-flow' proposal with logical values only

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

Present:
   Tab Atkins
   David Baron
   Bert Bos
   Cathy Chan
   Elika Etemad
   Simon Fraser
   Arno Gourdol
   John Jansen
   Håkon Wium Lie
   Peter Linss
   Divya Manian
   Alex Mogilevsky
   Anton Prowse (Invited Expert)
   Florian Rivoal
   Alan Stearns
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2011/09/21-css-irc
Scribe: TabAtkins

Media Queries Status
--------------------

   plinss: Last minute addition - View Mode Media spec is at PR, and is
           blocked on MQ.
   plinss: They want to know our status.
   howcome: Is it blocking that MQ is not a Rec?
   plinss: Yes, we're at CR.  They can only refer to specs one level down
           from them.

   howcome: For MQ, annevk is not here right now.
   fantasai: My understanding is that we're blocked on impls passing the
             test suite.
   howcome: It may be that some of the deficit in impl is due to the more
            "exotic" features, like color-index.
   fantasai: No, IIRC it's actually just parsing issues.
   dbaron: Arron pointed out some problems at the last F2F, which I fixed.
   howcome: I suggest we ask annevk to be in here next week for this.
   plinss: Sounds like we just need to get impls, then.
   dbaron: Sounds like we should publish a new test suite snapshot, since
           it fixed some issues.
   <dbaron> johnjansen, do you happen to know if Arron had any other bug
            reports with the MQ test suite?
   <johnjansen> dbaron, I'm following up today on that.

Administrative
--------------

   <florian> http://lists.w3.org/Archives/Public/www-style/2011Sep/0182.html
   florian: If we have time, there was a mail about css-conditional we could
            discuss.

   plinss: Also, we have a new member now, Anton Prowse.
   antonp: Thanks, glad to be here.
   <dbaron> welcome!
   <antonp> thanks!

column-span and margin-collapsing
---------------------------------

   florian: Last week we got to the point where we needed feedback from impls,
            and that's been sent.
   howcome: It seems there's consensus to have collapsing when the column-spans
            have identical values, except for MS.
   alexmog: I talked to our team, and it seems the use-cases that benefit from
            collapsing are kinda rare and you can do it in other ways.
   alexmog: Last week we came up with several complicated scenarios, and I'd
            like to avoid complicating it more.
   alexmog: Say you're writing a document with a variable number of columns.
            When the element shrinks to a single column, does a column-span:all
            element collapse with surrounding elements?
   alexmog: The idea of column-span is something that *can* span multiple
            columns, but you don't actually have a "separation" from the rest
            of the document, given the single-column case above.  It's kinda
            more like floats.
   fantasai: In response to the "single column col-spanning element", we
             already had a very specific proposal last week.
   fantasai: It was that you only collapse columns if the specified value of
             column-span is the same.  A column-span:all doesn't collapse with
             column-span:1 when the element is single-column.
   fantasai: The question I had was about collapsing colspan element children's
             margins with the colspan's own margins.
   fantasai: We were discussing whether the children's margins collapse with
             margins outside the colspan, but a related question is about
             whether they collapse with things inside of it.
   howcome: In today's email, I included the children.
   alexmog: Can't it be the same as floats?
   fantasai: If they're block formatting roots, the margins don't collapse
             with anything.
   florian: Conceptually, these aren't really related to floats.
   alexmog: If you use column-span with a number, like originally specified,
            these are very similar to floats.
   howcome: Agreed that they become more float-like with explicit span values.
   howcome: I think we're in a gray area here.  So I won't insist very hard
            on my solution, even if I support it.
   florian: Another point - as long as we don't have css-conditional, if
            they want the equivalent of multicol without collapsing, they
            have to simulate it themselves.
   howcome: That's a good argument.  But I'd rather have MS pass the testsuite
            eventually than have this feature be slightly more perfect.
   alexmog: We're not really concerned with how difficult this may be (it
            might be more difficult to *not* collapse).
   alexmog: Our concern is that colspan may evolve into something more powerful,
            and if we make the behavior more complicated we can get into a very
            complicated situation with collapsing.  And I think the use-cases
           aren't particularly convincing.
   <fantasai> The two proposals are: 1) each column-spanning element is a BFC
              2) each consecutive sequence of elements with the same
              'column-span' value is wrapped in an anonymous BFC
   <dbaron> fantasai, thanks, that's useful :-)
   howcome: The situation on the table is the natural fallout from two
            implementations (Opera and FF).
   howcome: If you're saying it's impossible to change the implementation,
            we can probably more easily change our impl.
   howcome: But if we're talking about what we want, I want collapsing.
   fantasai: The two proposals, really, are that (1) each colspan element is
             a BFC, and (2) each consecutive sequence of elements with the
             same column-span is wrapped in an anonymous BFC.
   fantasai: Given that we have code to do this for tables, I don't think
             #2 is particularly difficult.
   fantasai: It could be more difficult in some ways based on implementation
             [gives example in FF], but it's doable and not absurdly complicated.
   fantasai: [further explains the implications of the two models]
   howcome: Agreed, and I think both are achievable.

   florian: I think it's difficult to say which way authors would want, but
            I personally think I would want collapsing.
   florian: [brings up backwards-compat argument]
   fantasai: [brings up example with <h1 column-span:all>..</h1><p>...</p>,
             where the paragraph still won't collapse.)
   alexmog: Do we want multiple consecutive elements with columns-span:all
            to act like they're in a single-column block?
   TabAtkins: That's basically the effect, yeah.
   alexmog: Do we want to say that column-span floats collapse with sibling
            col-spans?  And do margins collapse through colspans?
   alexmog: I'm hearing that if there are multiple consecutive column-spans,
            they should act like a normal single-column flow.
   alexmog: And if that's a layout mechanism that's *kinda like* normal flow,
            but only looks like it at first glance, I think that's a confusing
            model.
   fantasai: It's not creating something "kinda like" normal flow - you'd be
             creating a BFC wrapper, within which it's perfectly normal block
             layout.
   alexmog: So with margin-collapsing enabled, the column-span is no longer a
            BFC itself.
   florian: Right.  A group of them is, but not each one individually.
   alexmog: So margins do collapse through empty colspans, and floats within
            one colspan will affect other colspans.
   fantasai: If the two colspans are in the same group, yeah.
   alexmog: Okay.  I'm not sure when we're going to implement that.  Is that
            what Opera does (with floats affecting across colspans)?
   howcome: I don't know.
   florian: In theory it sounds reasonable, but I don't know what our
            implementation does.
   alexmog: So I'm not sure we're coming to a consensus yet.
   fantasai: I think we need an action item to poke around in Opera and Webkit
             and see what they actually do.
   fantasai: Also, asking authors what they actually think about this problem
             may be useful.
   fantasai: Is Divya here?
   johnjansen: I'm trying to figure out scenarios where I use colspans and
               wanting margin-collapsing.
   johnjansen: I don't think I want it.
   <nimbupani> fantasai: i am here
   howcome: If you're in a situation without multicol at all, the margins will
            collapse in old browsers but not in new.
   johnjansen: Yeah, but there are significant other issues with colspanning.
   <fantasai> The columnspanning element still won't collapse with
              non-columnspanning elements, though
   alexmog: Should howcome take an action to describe exactly what should happen?
   florian: fantasai already described that.  I think we should instead
            investigate to see what Opera actually does, and if it's different,
            we can decide whether we should change or the proposal should.
   ACTION howcome: Investigate Opera's precise behavior around consecutive
                   colspans, to see if they match fantasai's "they're just
                   wrapped in an anonymous BFC" proposal is accurate.
   <trackbot> Created ACTION-364
   ACTION tabatkins: Investigate WebKit's precise behavior around consecutive
                     colspans, to see if they match fantasai's "they're just
                     wrapped in an anonymous BFC" proposal is accurate.
   <trackbot> Created ACTION-365
   plinss: Should we gather author's opinions on this?
   florian: I think authors are confused enough about margin-collapsing, so
            asking about corner cases in more complicated scenarios is unlikely
            to result in much useful.
   <nimbupani> agree with florian
   plinss: Okay, we'll revisit next week
.
Flexbox
-------

   alexmog: I like the idea of the centering control being separate from Flexbox.
   alexmog: Like 'overflow-position' or something.
   TabAtkins: Okay, so I recommend going with true centering, as I think that's
              what authors would expect, and then we'll solve the rest of this
              later.
   alexmog: I disagree.  Other layout models use "safe centering", and I think
            we should be consistent for now.
   TabAtkins: In that case, I think I'd like to pursue this quickly, to allow
              true centering quickly.
   alexmog: This only makes a difference during overflow, so we can address it
            as a feature of overflow, not a featur eof flexbox.
ScribeNick: fantasai
   TabAtkins: Ok, that seems fine. I'd want to go ahead and address that fairly
              quickly, because I think true centering is something ppl will
              expect when using flexbox to center stuff.
   TabAtkins: Using 1-element flexbox for vertica/horizontal centering is very
              useful.
   TabAtkins: Would we be ok defining this overflow property within flexbox
              spec?
   fantasai: My suggestion is to define it in flexbox for now, and if we find
             a better place later, we can move it.
   TabAtkins: Ok, I will do that. Change spec back to safe centering, put
              together first draft of overflow control and put on list for
              discussion.
   RESOLVED: Make flexbox do "safe centering", add control for overflowing
             to allow switch to "true centering"

   TabAtkins: Next issue was 'flex-flow' values.
   TabAtkins: During the F2F, me, fantasai, and Alex got together and put
              together suggestion for how to address virtually every use case
              of how you want flex-box direction to respond to things
   TabAtkins: You have pure physical,
   TabAtkins: Physical axis, but responding to 'direction'
   TabAtkins: And pure logical, responding to writing-mode
   TabAtkins: This created many values for flex-flow
   TabAtkins: That did what it needed to do, but it was pretty complex both to
              read and understand
   TabAtkins: e.g. deciding between 'row', 'horizontal', 'horizontal-ltr'.
   TabAtkins: I suggest simplifying it down by using :ltr/:rtl
   TabAtkins: And :ttb/etc.
   fantasai: You can't key off of computed style, so that won't work.
   TabAtkins: Let's pretend we only have ltr and rtl.
   TabAtkins: You don't need physical then
   TabAtkins: ..????
   * scribe gots confused
   TabAtkins: Whenever you're specifying the direction of writing mode,
              that's pretty major, you can at the same time switch flexbox.
   TabAtkins: Grid, which we're trying to maintain similarity with is
              completely logical based.
   TabAtkins: If you're in an rtl context, first column is on right side.
              In vertical context, first "column" is a row.
   TabAtkins: My proposal is to drop down to pure logical directions.
   TabAtkins: That puts us in a similar situation to grid and loses us little
              power
   alexmog: So you're proposing pure logical?
   TabAtkins: Yes.
   alexmog: I think that's ok.
   alexmog: I've looked at .. spec authors .. they all appeared to use
            horizontal and vertical, for the wrong reasons
   alexmog: Not switchable ...
   alexmog: In most cases more intuitive for ppl to use horizontal/vertical
   alexmog: What they mean is rows and columns
   alexmog: If your plan is top-level layout, you have a control there,
            you're applying .... can be anywhere, you can just put
            writing-mode on itself and it will be in whatever direction
            you want.
   alexmog: I think it'll be fine.
   TabAtkins: This is a decent bit easier for us to implement, since WebKit
              operates in logical mode
   alexmog: I'm not buying implementation complexity argument.
   TabAtkins: That change was made a little bit earlier.
   TabAtkins: Any other flexbox issues?
   fantasai: Any concerns with having logical values only?
   <silence>
   RESOLVED: Adopt 'flex-flow' with logical values only
Received on Thursday, 22 September 2011 00:05:14 GMT

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