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 http://www.w3.org/2011/09/21-css-irc
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]: +??P1
15:54:39 [florian]: Zakim, I am ??P1
15:54:39 [Zakim]: +florian; got it
15:55:01 [Zakim]: +plinss
15:56:08 [Martijnc]: Martijnc has joined #css
15:56:16 [Zakim]: +??P6
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]: +dbaron
16:00:29 [Zakim]: +[Microsoft]
16:00:37 [Zakim]: +stearns
16:00:40 [johnjansen]: zakim, microsoft has johnjansen
16:00:40 [Zakim]: +johnjansen; got it
16:00:43 [Zakim]: +??P19
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]: +[Apple]
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]: +Bert
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]: +howcome
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]: +cathy
16:06:24 [Zakim]: + +1.281.305.aadd
16:06:29 [TabAtkins_]: Zakim, aadd is me
16:06:32 [stearns]: howcome: http://www.cbsnews.com/stories/2011/09/21/501364/main20109337.shtml
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]: +SteveZ
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]: http://lists.w3.org/Archives/Public/www-style/2011Sep/0182.html
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]: welcome!
16:13:10 [TabAtkins_]: Topic: column-span and margin-collapsing
16:13:15 [antonp]: thanks!
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]: -arno
16:57:51 [fantasai]: fantasai: Any concerns with having logical values only?
16:57:53 [fantasai]: <silence>
16:58:05 [Zakim]: -stearns
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]: -[Microsoft]
16:59:03 [Zakim]: -dbaron
16:59:05 [Zakim]: -nimbupani
16:59:07 [Zakim]: -cathy
16:59:08 [Zakim]: -SteveZ
16:59:10 [Zakim]: -[Apple]
16:59:10 [Zakim]: -TabAtkins_
16:59:10 [Zakim]: -plinss
16:59:12 [Zakim]: -howcome
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]: -florian
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]: https://www.w3.org/blog/CSS/wp-admin/index.php
17:03:30 [miketaylr]: miketaylr has joined #css
17:10:55 [fantasai]: http://www.css3.info/angles-in-gradients/
17:15:03 [Zakim]: -Bert
17:15:06 [Zakim]: -fantasai
17:15:08 [Zakim]: -??P6
17:16:13 [Zakim]: -antonp
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