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