IRC log of css on 2011-09-21

Timestamps are in UTC.

15:54:01 [RRSAgent]
RRSAgent has joined #css
15:54:01 [RRSAgent]
logging to
15:54:10 [plinss]
rrsagent, make logs public
15:54:18 [plinss]
zakim, this will be style
15:54:18 [Zakim]
ok, plinss; I see Style_CSS FP()12:00PM scheduled to start in 6 minutes
15:54:21 [Zakim]
Style_CSS FP()12:00PM has now started
15:54:28 [Zakim]
15:54:39 [florian]
Zakim, I am ??P1
15:54:39 [Zakim]
+florian; got it
15:55:01 [Zakim]
15:56:08 [Martijnc]
Martijnc has joined #css
15:56:16 [Zakim]
15:56:39 [Zakim]
+ +1.206.552.aaaa
15:56:49 [stearns]
stearns has joined #css
15:56:52 [nimbupani]
Zakim, aaaa is me
15:56:52 [Zakim]
+nimbupani; got it
15:57:35 [antonp]
antonp has joined #css
15:58:11 [johnjansen]
johnjansen has joined #css
15:59:12 [jarek]
jarek has joined #css
15:59:48 [Zakim]
+ +34.93.329.aabb
16:00:00 [Zakim]
16:00:29 [Zakim]
16:00:37 [Zakim]
16:00:40 [johnjansen]
zakim, microsoft has johnjansen
16:00:40 [Zakim]
+johnjansen; got it
16:00:43 [Zakim]
16:01:04 [dbaron]
Zakim, ??P19 is fantasai
16:01:04 [Zakim]
+fantasai; got it
16:01:11 [smfr]
smfr has joined #css
16:01:58 [Zakim]
16:02:05 [smfr]
Zakim, Apple has smfr
16:02:06 [Zakim]
+smfr; got it
16:02:08 [Zakim]
+ +1.415.832.aacc
16:02:15 [antonp]
Hi everyone, I'm one of those on the call
16:02:23 [arno]
Zakim, aacc is arno
16:02:25 [Zakim]
+arno; got it
16:02:50 [antonp]
I guess I would be +34.93...
16:03:02 [Zakim]
16:03:10 [plinss]
zakim, aabb is antonp
16:03:10 [Zakim]
sorry, plinss, I do not recognize a party named 'aabb'
16:03:22 [howcome]
howcome has joined #css
16:04:00 [dsinger]
dsinger has joined #css
16:04:26 [Cathy]
Cathy has joined #css
16:04:30 [johnjansen]
Bert, you can always say something :-)
16:04:43 [smfr]
is anyone else getting a nasty whine, or is it my phone?
16:04:50 [dbaron]
smfr, just you, I think
16:05:09 [smfr]
my phone whines when on mute! go figga
16:05:14 [Zakim]
16:05:18 [johnjansen]
smfr, I had it for about 3 seconds, then it stopped
16:05:23 [TabAtkins_]
TabAtkins_ has joined #css
16:05:26 [Zakim]
16:06:24 [Zakim]
+ +1.281.305.aadd
16:06:29 [TabAtkins_]
Zakim, aadd is me
16:06:32 [stearns]
16:06:33 [Zakim]
+TabAtkins_; got it
16:06:33 [szilles]
szilles has joined #css
16:07:29 [smfr]
plinss: you were very faint
16:07:42 [smfr]
still faint
16:07:50 [smfr]
Zakim, who's noisy?
16:08:01 [Zakim]
smfr, listening for 10 seconds I heard sound from the following: plinss (15%), [Apple] (38%), Bert (32%)
16:08:17 [TabAtkins_]
ScribeNick: TabAtkins_
16:08:31 [Bert]
zakim, mute me
16:08:31 [Zakim]
Bert should now be muted
16:08:54 [TabAtkins_]
plinss: Last minute addition - View Mode Media spec is at PR, and is blocked on MQ.
16:08:58 [TabAtkins_]
plinss: They want to know our status.
16:09:06 [TabAtkins_]
howcome: Is it blocking that MQ is not a Rec?
16:09:18 [Zakim]
16:09:18 [TabAtkins_]
plinss: Yes, we're at CR. They can only refer to specs one level down from them.
16:10:03 [florian]
16:10:06 [TabAtkins_]
florian: If we have time, there was a mail about css-conditional we could discuss.
16:10:30 [TabAtkins_]
howcome: For MQ, annevk is not here right now.
16:10:40 [TabAtkins_]
fantasai: My understanding is that we're blocked on impls passing the test suite.
16:11:04 [TabAtkins_]
howcome: It may be that some of the deficit in impl is due to the more "exotic" features, like color-index.
16:11:17 [TabAtkins_]
fantasai: No, it's actually parsing issues. More serious.
16:11:33 [TabAtkins_]
dbaron: Arron pointed out some problems at the last F2F, which I fixed.
16:12:13 [TabAtkins_]
howcome: I suggest we ask annevk to be in here next week for this.
16:12:24 [TabAtkins_]
plinss: Sounds like we just need to get impls, then.
16:12:36 [TabAtkins_]
dbaron: Sounds like we should publish a new snapshot, since it fixed some issues.
16:12:52 [TabAtkins_]
plinss: Also, we have a new member now, Anton Prowse.
16:12:57 [TabAtkins_]
antonp: Thanks, glad to be here.
16:12:59 [dbaron]
16:13:10 [TabAtkins_]
Topic: column-span and margin-collapsing
16:13:15 [antonp]
16:13:37 [TabAtkins_]
florian: Last week we got to the point where we needed feedback from impls, and that's been sent.
16:13:54 [TabAtkins_]
howcome: It seems there's consensus to have collapsing when the column-spans have identical values, except for MS.
16:14:29 [TabAtkins_]
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.
16:15:03 [TabAtkins_]
alexmog: Last week we came up with several complicated scenarios, and I'd like to avoid complicating it more.
16:15:26 [dbaron]
johnjansen, do you happen to know if Arron had any other bug reports with the MQ test suite?
16:16:29 [johnjansen]
dbaron, I'm following up today on that.
16:16:52 [TabAtkins_]
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?
16:18:01 [TabAtkins_]
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.
16:18:43 [TabAtkins_]
fantasai: In response to the "single column col-spanning element", we already had a very specific proposal last week.
16:19:24 [TabAtkins_]
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.
16:19:53 [TabAtkins_]
fantasai: The question I had was about collapsing colspan element children's margins with the colspan's own margins.
16:20:17 [TabAtkins_]
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 outside of it.
16:20:25 [TabAtkins_]
howcome: In today's email, I included the children.
16:20:34 [TabAtkins_]
alexmog: Can't it be the same as floats?
16:20:54 [TabAtkins_]
fantasai: If they're block formatting roots, the margins don't collapse with anything.
16:21:07 [TabAtkins_]
florian: Conceptually, these aren't really related to floats.
16:21:29 [TabAtkins_]
alexmog: If you use column-span with a number, like originally specified, these are very similar to floats.
16:21:44 [TabAtkins_]
howcome: Agreed that they become more float-like with explicit span values.
16:22:09 [TabAtkins_]
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.
16:23:13 [TabAtkins_]
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.
16:23:32 [TabAtkins_]
howcome: That's a good argument. But I'd rather have MS pass the testsuite eventually than have this feature be slightly more perfect.
16:24:02 [TabAtkins_]
alexmog: We're not really concerned with how difficult this may be (it might be more difficult to *not* collapse).
16:24:08 [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
16:24:35 [TabAtkins_]
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.
16:24:41 [dbaron]
fantasai, thanks, that's useful :-)
16:25:18 [TabAtkins_]
howcome: The situation on the table is the natural fallout from two implementations (Opera and FF).
16:25:52 [TabAtkins_]
howcome: If you're saying it's impossible to change the implementation, we can probably more easily change our impl.
16:26:09 [TabAtkins_]
howcome: But if we're talking about what we want, I want collapsing.
16:26:42 [TabAtkins_]
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.
16:26:55 [TabAtkins_]
fantasai: Given that we have code to do this for tables, I don't think #2 is particularly difficult.
16:27:21 [TabAtkins_]
fantasai: It could be more difficult in some ways based on implementation [gives example in FF], but it's doable and not absurdly complicated.
16:27:54 [TabAtkins_]
fantasai: [further explains the implications of the two models]
16:28:16 [TabAtkins_]
howcome: Agreed, and I think both are achievable.
16:29:02 [TabAtkins_]
florian: I think it's difficult to say which way authors would want, but I personally think I would want collapsing.
16:29:26 [TabAtkins_]
fantasai: [brings up example with <h1 column-span:all>..</h1><p>...</p>, where the paragraph still wont' collapse.)
16:29:56 [TabAtkins_]
alexmog: Do we want multiple consecutive elements with columns-span:all to act like they're in a single-column block?
16:30:02 [TabAtkins_]
TabAtkins_: That's basically the effect, yeah.
16:30:41 [TabAtkins_]
alexmog: Do we want to say that column-span floats collapse with sibling col-spans? And do margins collapse through colspans?
16:31:05 [TabAtkins_]
zakim, who is noisy?
16:31:17 [Zakim]
TabAtkins_, listening for 11 seconds I heard sound from the following: florian (56%)
16:32:17 [TabAtkins_]
alexmog: I'm hearing that if there are multiple consecutive column-spans, they should act like a normal single-column flow.
16:32:45 [TabAtkins_]
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.
16:34:10 [TabAtkins_]
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.
16:34:51 [TabAtkins_]
alexmog: So with margin-collapsing enabled, the column-span is no longer a BFC itself.
16:34:59 [TabAtkins_]
florian: Right. A group of them is, but not each one individually.
16:35:40 [TabAtkins_]
alexmog: So margins do collapse through empty colspans, and floats within one colspan will affect other colspans.
16:35:54 [TabAtkins_]
fantasai: If the two colspans are in the same group, yeah.
16:36:21 [TabAtkins_]
alexmog: Okay. I'm not sure when we're going to implement that. Is that what Opera does (with floats affecting across colspans)?
16:37:16 [TabAtkins_]
howcome: I don't know.
16:37:26 [TabAtkins_]
florian: In theory it sounds reasonable, but I don't know what our implementation does.
16:37:48 [TabAtkins_]
alexmog: So I'm not sure we're coming to a consensus yet.
16:38:16 [TabAtkins_]
fantasai: I think we need an action item to poke around in FF and Webkit and see what they actually do.
16:38:26 [TabAtkins_]
fantasai: Also, asking authors what they actually think about this problem may be useful.
16:38:41 [TabAtkins_]
johnjansen: I'm trying to figure out scenarios where I use colspans and wanting margin-collapsing.
16:38:49 [TabAtkins_]
johnjansen: I don't think I want it.
16:38:53 [nimbupani]
fantasai: i am here
16:39:26 [TabAtkins_]
howcome: If you're in a situation without multicol at all, the margins will collapse in old browsers but not in new.
16:39:44 [TabAtkins_]
johnjansen: Yeah, but there are significant other issues with colspanning.
16:40:00 [fantasai]
The columnspanning element still won't collapse with non-columnspanning elements
16:40:29 [TabAtkins_]
alexmog: Should howcome take an action to describe exactly what should happen?
16:41:00 [TabAtkins_]
florian: Elika 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.
16:41:33 [TabAtkins_]
ACTION howcome: Investigate Opera's precise behavior around consecutive colspans, to see if they match Elika's "they're just wrapped in an anonymous BFC" proposal is accurate.
16:41:33 [trackbot]
Created ACTION-364 - Investigate Opera's precise behavior around consecutive colspans, to see if they match Elika's "they're just wrapped in an anonymous BFC" proposal is accurate. [on HÃ¥kon Wium Lie - due 2011-09-28].
16:41:57 [TabAtkins_]
ACTION tabatkins: Investigate WebKit's precise behavior around consecutive colspans, to see if they match Elika's "they're just wrapped in an anonymous BFC" proposal is accurate.
16:41:58 [trackbot]
Sorry, couldn't find user - tabatkins
16:42:05 [TabAtkins_]
ACTION tab: Investigate WebKit's precise behavior around consecutive colspans, to see if they match Elika's "they're just wrapped in an anonymous BFC" proposal is accurate.
16:42:05 [trackbot]
Created ACTION-365 - Investigate WebKit's precise behavior around consecutive colspans, to see if they match Elika's "they're just wrapped in an anonymous BFC" proposal is accurate. [on Tab Atkins Jr. - due 2011-09-28].
16:42:29 [TabAtkins_]
plinss: Should we gather author's opinions on this?
16:43:06 [nimbupani]
agree with florian
16:43:24 [TabAtkins_]
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.
16:43:29 [TabAtkins_]
plinss: Okay, we'll revisit next week.
16:43:33 [TabAtkins_]
Topic: Flexbox
16:43:45 [szilles]
szilles has joined #css
16:44:37 [TabAtkins_]
alexmog: I like the idea of the centering control being separate from Flexbox.
16:44:48 [TabAtkins_]
alexmog: Like 'overflow-position' or something.
16:46:19 [TabAtkins_]
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.
16:46:40 [TabAtkins_]
alexmog: I disagree. Other layout models use "safe centering", and I think we should be consistent for now.
16:47:08 [TabAtkins_]
TabAtkins_: In that case, I think I'd like to pursue this quickly, to allow true centering quickly.
16:47:53 [TabAtkins_]
alexmog: This only makes a difference during overflow, so we can address it as a feature of overflow, not a featur eof flexbox.
16:47:59 [fantasai]
ScribeNick: fantasai
16:48:20 [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.
16:48:30 [fantasai]
TabAtkins_: Using 1-element flexbox for vertica/horizontal centering is very useful.
16:48:42 [fantasai]
TabAtkins_: Would we be ok defining this overflow property within flexbox spec?
16:49:07 [fantasai]
fantasai: My suggestion is to define it in flexbox for now, and if we find a better place later, we can move it.
16:49:27 [fantasai]
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.
16:49:49 [fantasai]
TabAtkins_: Next issue was 'flex-flow' values.
16:50:29 [fantasai]
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
16:50:33 [fantasai]
TabAtkins_: You have pure physical,
16:50:41 [fantasai]
TabAtkins_: Physical axis, but responding to 'direction'
16:50:47 [fantasai]
TabAtkins_: And pure logical, responding to writing-mode
16:50:54 [fantasai]
TabAtkins_: This created many values for flex-flow
16:51:12 [fantasai]
TabAtkins_: That did what it needed to do, but it was pretty complex both to read and understand
16:51:26 [fantasai]
TabAtkins_: e.g. deciding between 'row', 'horizontal', 'horizontal-ltr'.
16:51:52 [fantasai]
TabAtkins_: I suggest simplifying it down by using :ltr/:rtl
16:52:30 [fantasai]
TabAtkins_: And :ttb/etc.
16:52:49 [fantasai]
fantasai: You can't key off of computed style, so that won't work.
16:53:18 [fantasai]
TabAtkins_: Let's pretend we only have ltr and rtl.
16:53:25 [fantasai]
TabAtkins_: You don't need physical then
16:53:34 [fantasai]
TabAtkins_: ..????
16:54:01 [fantasai]
TabAtkins_: Whenever you're specifying the direction of writing mode, that's pretty major, you can at the same time switch flexbox.
16:54:17 [fantasai]
TabAtkins_: Grid, which we're trying to maintain similarity with is completely logical based.
16:54:32 [fantasai]
TabAtkins_: If you're in an rtl context, first column is on right side. In vertical context, first "column" is a row.
16:54:39 [fantasai]
TabAtkins_: My proposal is to drop down to pure logical directions.
16:54:48 [fantasai]
TabAtkins_: That puts us in a similar situation to grid and loses us little power
16:55:02 [fantasai]
alexmog: So you're proposing pure logical?
16:55:08 [fantasai]
TabAtkins_: Yes.
16:55:12 [fantasai]
alexmog: I think that's ok.
16:55:31 [fantasai]
alexmog: I've looked at .. spec authors .. they all appeared to use horizontal and vertical, for the wrong reasons
16:55:42 [fantasai]
alexmog: Not switchable ...
16:55:52 [fantasai]
alexmog: In most cases more intuitive for ppl to use horizontal/vertical
16:55:57 [fantasai]
alexmog: What they mean is rows and columns
16:56:25 [fantasai]
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 directio nyou want.
16:56:31 [fantasai]
alexmog: I think it'll be fine.
16:56:50 [fantasai]
TabAtkins_: This is a decent bit easier for us to implement, since WebKit operates in logical mode
16:56:58 [fantasai]
alexmog: I'm not buying implementation complexity argument.
16:57:06 [fantasai]
TabAtkins_: That change was made a little bit earlier.
16:57:18 [fantasai]
TabAtkins_: Any other flexbox issues?
16:57:21 [Zakim]
16:57:51 [fantasai]
fantasai: Any concerns with having logical values only?
16:57:53 [fantasai]
16:58:05 [Zakim]
16:58:20 [fantasai]
RESOLVED: Adopt 'flex-flow' with logical values only
16:58:33 [TabAtkins_]
RESOLVED: Make flexbox do "safe centering", add control for overflowing to allow switch to "true centering"
16:59:02 [Zakim]
16:59:03 [Zakim]
16:59:05 [Zakim]
16:59:07 [Zakim]
16:59:08 [Zakim]
16:59:10 [Zakim]
16:59:10 [Zakim]
16:59:10 [Zakim]
16:59:12 [Zakim]
16:59:19 [Bert]
zakim, unmute mu
16:59:19 [Zakim]
sorry, Bert, I do not know which phone connection belongs to mu
16:59:35 [Zakim]
16:59:35 [Ms2ger]
Zakim, unmute Bert
16:59:36 [Zakim]
Bert should no longer be muted
16:59:41 [florian]
florian has left #css
17:01:56 [Bert]
17:03:30 [miketaylr]
miketaylr has joined #css
17:10:55 [fantasai]
17:15:03 [Zakim]
17:15:06 [Zakim]
17:15:08 [Zakim]
17:16:13 [Zakim]
17:16:14 [Zakim]
Style_CSS FP()12:00PM has ended
17:16:16 [Zakim]
Attendees were florian, plinss, +1.206.552.aaaa, nimbupani, +34.93.329.aabb, dbaron, stearns, johnjansen, fantasai, smfr, +1.415.832.aacc, arno, Bert, antonp, howcome, cathy,
17:16:18 [Zakim]
... +1.281.305.aadd, TabAtkins_, SteveZ
17:16:29 [smfr]
smfr has left #css
17:16:36 [antonp]
antonp has left #css
17:53:55 [stearns]
stearns has joined #css
18:53:52 [dbaron]
dbaron has joined #css
19:05:41 [howcome]
howcome has left #css
19:15:13 [nimbupani]
nimbupani has joined #css
19:19:58 [Zakim]
Zakim has left #css
19:21:58 [hober]
fantasai: want to pop into (freenode) #webkit to answer a question from hyatt re: orthogonal flows & css3-writing?
19:44:23 [nimbupani]
nimbupani has joined #css
20:00:34 [nimbupani]
nimbupani has joined #css
20:15:59 [karl]
karl has joined #CSS