15:27:41 RRSAgent has joined #css 15:27:41 logging to http://www.w3.org/2012/09/19-css-irc 15:27:47 RRSAgent, make logs public 15:33:45 nimbu has joined #css 15:43:39 fantasai: i was looking at state of affairs for print style support and was depressss 15:44:19 nimbu: do you mean css3-page in browser engines? 15:45:01 SimonSapin: wellll i mean orphans widows etc 15:45:13 i know page-break-* is being actively worked on for other reasons. 15:45:26 thead repeating on tables on multiple pages 15:45:33 I see 15:45:48 It's really tools like prince you need for that :/ 15:45:58 yaa :||||| 15:46:05 i mean here we are with webGL and coolness™ 15:46:12 cant even get print to work properly >_> 15:46:16 Also, doesn't SimonSapin have something similar? :) 15:46:18 Or weasyprint :D 15:46:23 i mean i am not that depressed but its just sad :| 15:46:41 alsooo i mean this h1, h2 { page-break-after: avoid; } should be default on browsers 15:46:48 why should designers/devs do it manually. 15:47:09 it’s in weasyprint’s UA stylesheet 15:47:20 It's not sexy, I'm afraid 15:47:28 WAT Ms2ger 15:47:51 In Prince’s too. 15:47:54 ohh nice. 15:48:00 BUT NOT IN BROWSERS WAI 15:51:10 jet has joined #CSS 15:52:57 bradk has joined #css 15:54:24 hello all 15:54:38 I have kids around, not sure I can join the call immediately 15:54:46 hi glazou how do you feel about going back to school for test the web forward!! 15:56:11 not the first time I go back to TelecomParis 15:56:24 lstorset has joined #css 15:56:57 ha. 15:57:07 nimbu: why? new choice ? 15:57:15 glazou: ya! its now at TelecomParis! 15:57:16 Style_CSS FP()12:00PM has now started 15:57:23 +plinss 15:57:24 antonp has joined #css 15:57:30 ah ok ; yeah the other venue rue de Charenton was a bit problematic, really 15:57:33 hi SimonSapin 15:57:39 and welcome 15:57:44 +fantasai 15:57:51 plinss: I need two other mins to join 15:57:55 +??P34 15:58:02 SimonSapin1 has joined #css 15:58:07 zakim, ++p34 is me 15:58:07 sorry, jdaggett, I do not recognize a party named '++p34' 15:58:10 Hi glazou 15:58:22 zakim, ??p34 is me 15:58:22 +jdaggett; got it 15:58:31 +richt 15:58:38 Zakim, richt is me 15:58:38 +lstorset; got it 15:59:14 CesarAcebal has joined #css 15:59:21 florian has joined #css 15:59:42 rbetts has joined #css 15:59:44 arronei_ has joined #css 15:59:47 +stearns 15:59:49 +bradk 16:00:20 +[Microsoft] 16:00:23 +[IPcaller] 16:00:24 yeah, Zakim recognized me this time! 16:00:43 + +34.60.940.aaaa 16:00:59 Zakim, aaaa is me. 16:01:00 + +93550aabb 16:01:04 + +1.206.324.aacc 16:01:08 + +1.253.307.aadd 16:01:18 +CesarAcebal; got it 16:01:19 Zakim, aabb is me 16:01:20 +rbetts 16:01:24 +antonp; got it 16:01:37 Zakim, aadd is me 16:01:37 +arronei_; got it 16:01:38 +??P63 16:01:48 JohnJansen has joined #css 16:01:53 +??P67 16:01:56 +SteveZ 16:01:58 Zakim, ??P67 is me 16:01:58 +glazou; got it 16:02:03 zakim, microsoft has JohnJansen 16:02:04 +JohnJansen; got it 16:02:08 +??P69 16:02:27 Zakim, who is noisy? 16:02:30 florian: http://www.w3.org/2006/tools/wiki/Zakim_Tips 16:02:38 glazou, listening for 10 seconds I heard sound from the following: 17 (34%) 16:02:39 Zakim, mute florian 16:02:39 Zakim, who is noisy? 16:02:40 sorry, glazou, I do not know which phone connection belongs to florian 16:02:50 bradk, listening for 10 seconds I could not identify any sounds 16:02:53 Zakim, ??P69 is me 16:02:56 (I think) 16:02:59 +SimonSapin; got it 16:03:08 Zakim, who is noisy? 16:03:09 Zakim, who is noisy? 16:03:18 fantasai, listening for 10 seconds I heard sound from the following: antonp (5%) 16:03:21 Zakim, mute 17 16:03:21 sorry, glazou, I do not know which phone connection belongs to 17 16:03:22 ow, my ears... 16:03:30 glazou, listening for 10 seconds I heard sound from the following: antonp (5%), glazou (29%) 16:03:37 zakim, mute antonp 16:03:37 antonp should now be muted 16:03:46 (I'm already muted) 16:04:14 peace and tranquility 16:04:17 I think it’s me 16:04:30 +??P27 16:04:34 -[IPcaller] 16:04:42 +dbaron 16:04:47 +??P33 16:04:56 Zakim, I am ??P33 16:04:56 +florian; got it 16:04:59 thiis is the worst 2 mins ever on this call I guess 16:05:03 smfr has joined #css 16:05:13 worst? is that a challenge? 16:05:18 zakim, who is on the call? 16:05:19 On the phone I see plinss, fantasai, jdaggett, lstorset, stearns, bradk, [Microsoft], CesarAcebal, antonp (muted), arronei_, +1.206.324.aacc, rbetts, ??P63, glazou, SteveZ, 16:05:19 ... SimonSapin, ??P27, dbaron, florian 16:05:19 [Microsoft] has JohnJansen 16:05:22 sylvaing: welcome back ;-) 16:05:37 box align names could give you a run for your money 16:05:39 thx 16:05:42 +smfr 16:05:58 what ? smfr is with us, no other apple event this week?-) 16:06:03 ScribeNick: antonp 16:06:22 plinss: Agenda additions? 16:06:30 jdaggett: css3-fonts WD request - please defer 16:06:39 http://lists.w3.org/Archives/Public/public-css-testsuite/2012Sep/0020.html 16:06:47 fantasai: like to discuss the above post 16:06:50 css3-sizing, FPWD??? https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0281.html 16:06:59 css3-flexbox CR??? https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0344.html 16:07:25 ITEM: Tokyo f2f dates 16:07:37 plinss: steve and john have a hard conflict 16:08:08 + +1.415.615.aaee 16:08:24 jdaggett: target date of June 5 through 7 (wed - Fri) 16:08:38 ...: SVG guys could do Mon and Tue, overlap with CSS on Weds 16:09:04 glazou: how many people in CSS will attend SVG on Weds? 16:09:28 jdaggett: Can treat Weds as a CSS day in which SVG guys participate 16:09:58 jdaggett: We can sponsor, but our present base can't hold both groups. We're hoping we'll find a larger space in time 16:10:16 ... for now, put down Mozilla Japan as sponsor, but need to check again in Jan 16:10:29 florian: proposed dates don't work for me, but nor do others 16:10:41 jdaggett: want to accommodate the AT meeting that's also in Tokyo 16:10:58 szilles: I have same problem as florian 16:11:27 s/szilles/SteveZ 16:12:35 florian: to accommodate me it'd have to be either a month earlier or a month later, so don't go too crazy trying to schedule for me 16:12:43 jdaggett: at TPAC we can talk again 16:13:07 jdaggett: I'll update the wiki with relevant info, proposing 5,6,7 June (with 5 June as crossover day) 16:13:23 florian: If I can only come on Sunday to TPAC, do I have to pay a fee? 16:13:31 SteveZ: no, no fee for that day 16:13:42 dbaron: Given that the next-to-AC-meeting dates don't work for Steve, doesn't seem like doing next-to-AC-meeting scheduling helps that many people. 16:14:18 TOPIC: svg2 property review 16:14:26 plinss: feedback everyone? 16:15:02 plinss: minor threads on www-style about IRIs/URLs 16:15:11 glazou: seems to be a point of contention 16:15:21 http://doodle.com/z99cyshc5fy96kbr ? 16:16:04 rossen: paintOrderProperty - name is good, but we've used the expression "paint order" to mean something quite different 16:16:13 s/rossen/sylvaing 16:16:49 plinss: do we need more time to review 16:17:06 glazou: I reviewed it but don't have comments, not really my area 16:17:30 plinss: revisit next week? 16:17:55 dbaron: I'm not that happy about paintOrder but don't have better ideas right now 16:18:15 s/paintOrder/paint-order 16:18:37 plinss: should we make that WG feedback, or individual feedback? 16:18:41 rhauck has joined #css 16:18:50 dbaron: I don't have a strong opinion, and am not crazy about WG feedback in general 16:18:59 glazou: we've been asked as a group for feedback 16:19:08 smfr has joined #css 16:19:18 dbaron: In that case, I'd like another week 16:19:33 RESOLVED: revisit next week, after review 16:19:58 ACTION on glazou: contact Cameron about the delay 16:19:58 Sorry, couldn't find user - on 16:20:11 Rossen has joined #css 16:20:15 ACTION glazou : contact Cameron on new 1 week delay 16:20:15 Created ACTION-508 - : contact Cameron on new 1 week delay [on Daniel Glazman - due 2012-09-26]. 16:20:27 TOPIC: DOM3 Events 16:20:39 glazou: I reviewed it; it seems fine 16:21:15 16:21:51 glazou: CSS is mentioned in 2 places: z-order manipulated by CSS, and the way in which mouse movements work 16:22:05 ... also mouse enter and mouse leave being like hover 16:22:41 smfr: Is "mouse event order" section describing something new, or something that's implemented? 16:22:49 glazou: seems to me that it's already implemented 16:23:36 -??P27 16:23:37 +[Microsoft.a] 16:23:39 SteveZ: seems like our response is "no comments" 16:23:48 RESOLVED: we have no comments on DOM3 Events 16:23:51 Zakim, [Microsoft.a] is me 16:23:51 +Rossen; got it 16:23:52 ACTION glazou: no comment on DOM 3 Events 16:23:52 Created ACTION-509 - No comment on DOM 3 Events [on Daniel Glazman - due 2012-09-26]. 16:24:07 ScribeNick: fantasai 16:24:13 http://lists.w3.org/Archives/Public/www-style/2012Sep/0041.html 16:24:22 zakim, unmute antonp 16:24:22 Zakim, unmute antonp 16:24:23 antonp should no longer be muted 16:24:23 antonp should no longer be muted 16:24:38 +??P56 16:24:42 antonp: This is about a proposal to introduce the term "block container element" 16:24:45 zakim, ??p56 is me 16:24:45 +koji; got it 16:24:50 antonp: We raised it briefly last week so ppl could have a week to review 16:24:53 hi koji 16:24:57 antonp: Noticed fantasai replied today 16:25:05 antonp: Rossen also wanted a chance to review 16:25:12 http://lists.w3.org/Archives/Public/www-style/2012Sep/0356.html 16:25:19 smfr: block container element is ? 16:25:35 antonp: we already have concept of block container box, but we have problem in CSS2.1 where we mix elements and boxes all over the place 16:25:46 antonp: would be good to have an element vs. box distinction 16:25:54 antonp: this will help us to write errata with the right terminology 16:26:08 antonp: don't think it introduces anything substantial 16:26:17 smfr: how does it work with anon boxes? 16:26:34 antonp: An anonymous box would never generate a principal box, so couldn't possibly be a principal block container element 16:26:43 antonp: anon boxes aren't produced by elements anyway, so no issue 16:26:58 antonp: anon boxes often are block boxes, but no corresponding block element 16:27:05 antonp: one question fantasai raised on list was 16:27:16 antonp: suggested some alternative wording of one paragraph, seems good to me 16:27:33 antonp: also made a comment on "Certain values" phrase 16:28:04 antonp: [talks about "principal box" term, how it's used but not defined] 16:28:37 antonp: I deliberately don't include inline boxes when talking about principal boxes 16:28:43 antonp: because they behave differently from other boxes 16:28:55 antonp: but fantasai feels that inlines do generate principal boxes 16:29:14 antonp: I don't think we need to answer that question for CSS2.1, which is why the wording is deliberately vague 16:29:31 antonp: a bit cheating, we can do anything in CSS3, since omitted from CSS2.1 16:29:51 dbaron: I think if you want something to be undefined, you should say so 16:30:17 dbaron: if it's omitted, it doesn't happen 16:31:33 fantasai: If block-level boxes can be principal, then so can inline boxes 16:31:44 fantasai: Reason inline elements have multiple boxes in CSS2.1 is that they're fragmented 16:31:53 fantasai: But block elements also get fragmented when they're paginated e.g. 16:32:04 fantasai: I think originally this was not considered by the spec authors 16:32:12 fantasai: inline elements were thought of as having multiple boxes 16:32:22 fantasai: but now we have concept of a "box", which is then fragmented into "fragments of boxes" 16:32:33 fantasai: And the same phenomenon applies to block-level elements as to inline ones 16:32:54 antonp: I agree, which is why not objecting to the idea of principal box for inlines 16:33:10 antonp: But I don't think that ties in with Chapter 10 16:33:22 -jdaggett 16:33:24 antonp: I know Bert's model doesn't really match this idea of principal boxes 16:33:35 antonp: But that said, I think there are actually existing problems in Chapter 10 anyway 16:33:50 antonp: So don't think ought to be changing our mind on basis of Chapter 10 that might not be the best anyway 16:33:56 antonp: So [...] 16:34:04 antonp: Which brings me back to dbaron's comment 16:34:12 antonp: I suppose, I can't argue against it 16:34:28 drublic has joined #css 16:34:35 antonp: but I do think if you're trying to clarify something thats unclear, and improve but not all the way, then it's still improvement 16:34:44 antonp: You could argue that either way 16:34:57 antonp: But if others not happy with that [...] 16:35:07 szilles: I think better to leave explicitly undefined 16:35:18 plinss: Do we need to leave it undefined? 16:35:53 Florian: Since tricky to define whether or not they define principal boxes, would do what Anton says 16:36:11 Ms2ger: from time to time, yes :) 16:36:12 Florian: Can make decision to define one way or another at some later point 16:36:24 fantasai: I'm fine either way 16:36:52 I would prefer to mark explicitely undefined for inlines, but otherwise do what anton says. 16:37:02 plinss: If there are issues in Chapter 10, let's just address them. 16:37:11 fantasai: I'd like to hear from Bert, is he on the call? 16:37:43 Bert: can't zakim call you ? 16:38:04 zakim, call bert 16:38:04 I am sorry, Bert; I do not know a number for bert 16:38:22 arronei: Can we just accept Anton's text and take the inline portion for next week? 16:38:29 Florian: That would work for me 16:39:04 fantasai: Can treat Anton's issue as separate from my comment, have that be another issue 16:39:23 dbaron: Would like it to be explicitly defined 16:39:29 SimonSapin has joined #css 16:39:41 s/defined/undefined if we don't know yet/ 16:39:46 +1 with David and Rossen 16:39:54 +1 16:40:03 I'd like to discuss with Anton why he thinks we need the concept of "principal" at all. To me, list-items just generate two boxes, one a block-level box, the other inline-level. We refer to one as the principal and the other as the marker, but that is just to describe them for the purposes of that para. There is no global concept of principal box. 16:40:10 rossen: I agree we should move forward with accepting this, but making the undefined part of it explicitly undefined 16:40:37 plinss: Not satisfied with leaving another open issue against it? 16:42:33 fantasai: It's not a technical issue, it has no affect on interpretation of a spec, it's just about tightening up prose. I don't think we need to draw attention to the fact that we're not 100% certain whether the term Principal applies here or not. 16:43:08 Bert: I sent you an e-mail today justifying the need for "principal box" as a label; I think it's useful to define these things like block container element 16:43:16 SteveZ: Since Principle is used to identify which elements are Block-container-elements, we should be clear about the handling of inline boxes 16:43:19 fantasai: I also don't think this is something to spend this much time on on the call 16:43:35 I can’t connect anymore in SIP nor with the EU gateway 16:43:42 SteveZ, regardless of whether inline boxes are principal or not, they're definitely not blocks so it doesn't matter :) 16:44:09 SimonSapin: Zakim has hickups from time to time :( 16:44:10 plinss: Is everyone happy with accepting Anton's text and leaving principal box of inlines issue open? 16:44:32 Zakim, who is on the phone? 16:44:32 On the phone I see plinss, fantasai, lstorset, stearns, bradk, [Microsoft], CesarAcebal, antonp, arronei_, +1.206.324.aacc, rbetts, ??P63, glazou, SteveZ, SimonSapin (muted), 16:44:35 Bert, do you object to what plinss just said@? 16:44:36 ... dbaron, florian, smfr, +1.415.615.aaee, Rossen, koji 16:44:36 [Microsoft] has JohnJansen 16:44:39 fantasai: Are there any objections to accepting Anton's text and leaving the issue open? 16:44:46 RESOLVED: accept Anton's proposal 16:45:04 SimonSapin: weird, you're still liste on the call 16:45:05 Topic: Spec Shortnames 16:45:13 plinss: We have three proposals for how to rename our spec shortnames 16:45:21 network dropped for me for a while 16:45:31 plinss: get a resolution on which direction to move in, then come up with concrete proposal 16:45:36 plinss: Any comments on which naming system to use? 16:46:01 http://wiki.csswg.org/spec/shortnames#versioned-names 16:46:12 B or C are fine, A is confusing 16:46:13 dbaron prefers C 16:46:24 + +33.9.52.34.aaff 16:46:32 A is cssN-foo, B is css-fooN, C is css-foo-N 16:46:34 glazou: I prefer C, too. The N is not related to CSS, it's related to the document 16:46:37 +1 for C 16:46:40 plinss: C 16:46:41 florian: C 16:46:41 Zakim, +33.9.52.34.aaff is me 16:46:41 +SimonSapin; got it 16:46:53 fantasai: So! Anyone for not C? :) 16:46:54 arronei_: C 16:46:58 RESOLVED: C 16:47:10 plinss: other question on wiki page was when do we move shortnames over to next level 16:47:13 http://wiki.csswg.org/spec/shortnames#unversioned-names 16:47:20 Florian: I would say A 16:47:48 szilles: I'm confused by that. We create version N+1 when we're trying to split it into pieces we can do now vs later 16:48:01 Does B imply waiting for the next snapshot? 16:48:58 A == CR, B == Snapshot acceptance, C == REC 16:49:27 ... 16:49:36 Florian: What's the criteria for snapshot? 16:49:41 I think I probably also lean towards B. 16:49:43 fantasai: p...] 16:49:43 someone should kill the people laughing loudly in the background... 16:49:49 Florian: In that case, I prefer B 16:49:51 sylvaing: me too 16:50:04 ?: Would motivate updating snapshot more often 16:50:13 plinss: Would update redirects when publishing snapshot 16:50:27 Florian: Only worry with option B that since it's not very systematic, would postpone 16:50:34 I can live with option B 16:50:36 Florian: Otherwise it's the right level 16:50:44 plinss: Snapshot is note, so we can update quickly 16:50:47 plinss: Objections to B? 16:50:52 RESOLVED: B 16:51:24 SteveZ: Should we reopen whether snapshots should be REC or not? 16:51:48 plinss: There's nothing testable. How do you prove a snapshot? 16:51:57 plinss: could revisit in the future, don't want to open now 16:52:11 Topic: Max Viewport Size on reftests 16:52:17 plinss: min or max? 16:52:21 dbaron: The viewport size 16:52:49 fantasai: The test should still work on larger sizes 16:52:57 http://lists.w3.org/Archives/Public/public-css-testsuite/2012Sep/0020.html 16:53:25 dbaron: It's the minimum size at which you should run the test, and the maximum size at which the test should have information for determining pass/fail 16:54:01 fantasai: Mozilla proposed 600x600, Chrome and Opera don't need to go smaller 16:54:15 arronei: Don't think we'd need to go maller 16:54:37 rossen: Is this for phones? 16:54:56 Leif: We run at desktop resolution only 16:55:05 Florian: May want to run on phones, too 16:55:10 Leif: Might want to, but don't now 16:55:16 Leif: Could look into it more closely 16:55:36 florian: Yeah, because even if not needed right now, if we decide to do it don't want to rewrite all the tests. 16:55:41 Leif: Ok, will look more into that 16:55:57 fantasai: Do MS or Apple need to look into it more? 16:56:08 smfr: We run at 800x600, and on mobile we scale down 16:56:23 smfr: For tests that test viewport specifically, might need to run at 320xwhatever 16:56:27 MS: Same scenario we have 16:56:39 dbaron: So if you run tests at 800x600... 16:56:46 dbaron: If ppl right tests at resolutions higher than this 16:56:57 dbaron: Might have existing tests not compatible with smaller resolution 16:57:02 dbaron: This is the reason we don't want to go too small 16:57:15 dbaron: but also have some devices where, for some reason... 16:58:01 smfr: 600x600 sounds constraining for some kinds of tests 16:58:20 dbaron: There are a lot of tests you make things x pixels wide, no reason to pick that number and not half that number 16:58:30 smfr: More regression tests, where putting things side by side in same test (?) 16:59:13 ?: What kinds of tests would be included here? No idea how big an impact this decision would have 16:59:24 Florian: Most tests draw a green box, could be just 100px wide 16:59:56 -[Microsoft] 16:59:57 s/?/lstorset 17:00:00 fantasai: Ok, people should look into it. We can come back next week. 17:00:17 dbaron: We need to know whether people have a reason to run at a smaller size 17:00:28 dbaron: Also whether anyone has a pool of tests planning to contribute that they can't bring down to this size 17:00:40 plinss: Haven't gotten much feedback on module prioritization, please do that 17:00:45 sylvaing: what is it for? 17:00:58 plinss: Will inform glazou and I how to reset priorities for the group 17:01:04 sylvaing: we've answered those things for charters 17:01:14 sylvaing: what are we going to do differently this time? 17:01:27 glazou: When we did this for the charter, it was also to know what were documents we wanted in the charter 17:01:35 glazou: Not the case here. All documents listed here are in scope. 17:01:43 sylvaing: Every meeting I go to, we start working on some new thing 17:01:55 sylvaing: Don't allocate time based on priorities 17:02:06 sylvaing: Is the plan to take some action based on priorities? 17:02:10 glazou: It's part of the plan 17:02:18 dbaron: One thing I found difficult to answer was 17:02:25 dbaron: How to balance newer specs vs older specs 17:02:41 dbaron: Tried to balance by trying to think about, if we spent time on issues for one or the other, which was higher priority? 17:02:50 dbaron: But that will also change over time, because function of where they are in the process 17:02:59 dbaron: Put down priorities for right now, but won't be valid for the long time 17:03:07 glazou: Not looking for long-term answer, looking for prioritization now. 17:03:17 sylvaing: I'd love to hear more on what you're thinking of to do with the answers 17:03:22 sylvaing: Fuzzy on that 17:03:34 glazou: You said yourself we have 50 docs on the radar, and new ones popping up every other week 17:03:38 glazou: We have limited time 17:03:49 glazou: need to dedicate our efforts on a single set of documents that we can move on rec track quite fast 17:03:57 glazou: we think such a list from you guys could help 17:04:12 sylvaing: So we're talking about when ppl bring up issue for telecon, and not high priority, you'll say no? 17:04:23 glazou: If it's low priority, and we have high priority issues, yes. 17:04:28 glazou: That's exactly what we did for CSS2.1 17:04:41 plinss: If we have time available, we'll spend it on low priority issue. But if not, then no. 17:04:53 glazou: We did this informally already 17:05:07 glazou: We'd discuss on Tuesday, this item isn't critical, so not add it to agenda 17:05:22 glazou: We want to do this based on your feedback, not just our opinions 17:05:31 glazou clarifies that invited experts rae expected to respond 17:05:47 -smfr 17:05:48 s/rae/are/ 17:05:50 fantasai: So, is Flexbox going to CR? 17:05:52 glazou: Yes 17:06:09 fantasai: So how is it getting there? When/who is publishing? 17:06:32 Meeting closd. 17:06:35 -stearns 17:06:36 -antonp 17:06:37 -SteveZ 17:06:38 -glazou 17:06:39 -bradk 17:06:39 - +1.206.324.aacc 17:06:40 -dbaron 17:06:41 -plinss 17:06:44 -CesarAcebal 17:06:45 -florian 17:06:47 -rbetts 17:06:49 - +1.415.615.aaee 17:06:51 -fantasai 17:06:53 -koji 17:06:55 -Rossen 17:06:56 lstorset has left #css 17:06:57 -arronei_ 17:07:00 -lstorset 17:07:01 -SimonSapin.a 17:07:03 -??P63 17:07:31 fantasai: ping 17:07:38 glazou: pong 17:07:50 fantasai: sending you the minutes by email, they're archived only on w3t-archive 17:08:03 glazou: Ok 17:08:15 glazou: Was there a problem? Is that why you did not announce to the CSSWG that it is moving to CR? 17:08:30 no ; I _just_ forgot because I'm human :-) 17:08:42 okay :) 17:08:43 that's good 17:08:58 and Bert is actioned by the minutes to do the work on flexbox 17:09:07 ok 17:09:07 fantasai: sent 17:09:38 fantasai: two kids around here, I need to go 17:09:41 ok 17:09:44 bye 17:09:57 SimonSapin1 has joined #css 17:10:38 Bert: Will Flexbox be published tomorrow? 17:11:41 Flexbox will be published and announced tomorrow, but dated the 18th. The webmaster didn't have time yesterday. (The real webmaster is on holiday, Alexandre fills in.) 17:11:51 disconnecting the lone participant, SimonSapin, in Style_CSS FP()12:00PM 17:11:54 Style_CSS FP()12:00PM has ended 17:11:54 Attendees were plinss, fantasai, jdaggett, lstorset, stearns, bradk, [IPcaller], +34.60.940.aaaa, +93550aabb, +1.206.324.aacc, +1.253.307.aadd, CesarAcebal, rbetts, antonp, 17:11:54 ... arronei_, SteveZ, glazou, JohnJansen, SimonSapin, dbaron, florian, smfr, +1.415.615.aaee, [Microsoft], Rossen, koji 17:12:02 Bert: Ok, is the draft up-to-date? 17:12:20 Bert: I put in some changes last Friday when I emailed the group 17:12:24 https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0344.html 17:12:34 Bert: There were some requests for clarifications, and I update the Changes section etc. 17:12:40 I hope it was up to date when I made the CR on Monday. :-) 17:12:46 okay :) 17:12:54 Monday is after Friday, so we should be good ;) 17:13:05 Thanks Bert! 17:13:42 I noticed the updated status section. I had already added almost the same text myself last week in my local copy, but I threw it away and used yours instead 17:14:16 heh 17:15:24 antonp has left #css 17:15:51 Until we rename Monday and Friday at Last Call 17:16:09 ahahaha 17:16:17 sylvaing!!! 17:16:27 nimbu!!! 17:16:36 :)) i meant it as sylvaing+++ 17:16:39 but i typoed. 17:56:30 nimbu has joined #css 18:04:57 rhauck has joined #css 18:06:36 dbaron has joined #css 18:13:03 arno has joined #css 18:29:00 nimbu1 has joined #css 18:29:28 nimbu has joined #css 18:30:49 nimbu has joined #css 18:37:13 SimonSapin has joined #css 18:58:14 Zakim has left #css 19:04:28 nimbu has left #css 19:56:04 nimbu has joined #css 19:58:09 nimbu has joined #css 20:02:28 nimbu has left #css 20:22:39 drublic has joined #css 20:39:40 miketaylr has joined #css 20:51:09 nimbu has joined #css 21:01:27 nimbu1 has joined #css 21:13:26 arno has joined #css 21:15:42 antonp has joined #css 21:22:01 arno has joined #css 21:23:53 shepazu has joined #css 21:37:23 jarek has joined #css 22:02:59 antonp1 has joined #css 22:05:44 drublic has joined #css 23:06:10 nimbu has joined #css 23:17:23 dbaron has joined #css 23:38:19 arno has joined #css