- 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