- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 21 Sep 2011 17:04:37 -0700
- 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 UTC