/irc-logs / w3c / #css / 2010-08-23 / end

Options:

# Session Start: Mon Aug 23 00:00:00 2010
# Session Ident: #css
# [00:00] * Joins: nimbupani (nimbupani@24.22.131.46)
# [00:01] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [00:01] * Joins: nimbupani (nimbupani@24.22.131.46)
# [00:19] * Quits: dsinger (dsinger@84.208.65.171) (Quit: dsinger)
# [00:55] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [01:12] * Joins: nimbupani (nimbupani@173.10.103.73)
# [01:52] * Quits: nimbupani (nimbupani@173.10.103.73) (Quit: nimbupani)
# [04:11] * Quits: Martijnc (Martijnc@91.176.76.129) (Ping timeout)
# [04:40] * Joins: Martijnc (Martijnc@91.176.11.131)
# [05:03] * Joins: nimbupani (nimbupani@24.22.131.46)
# [05:33] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [05:38] * Quits: Curt``` (DorkeyDear@75.10.129.150) (Connection reset by peer)
# [05:38] * Joins: Curt`` (DorkeyDear@75.10.129.150)
# [06:13] * Quits: shepazu (schepers@128.30.52.169) (Quit: Core Breach)
# [07:17] * Joins: shepazu (schepers@128.30.52.169)
# [07:26] * Quits: Curt`` (DorkeyDear@75.10.129.150) (Quit: Leaving)
# [07:40] * Joins: dsinger (dsinger@84.208.66.187)
# [07:54] * Quits: dsinger (dsinger@84.208.66.187) (Quit: dsinger)
# [07:58] * Joins: nimbupani (nimbupani@24.22.131.46)
# [08:00] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [08:47] * Joins: glazou (glazou@213.236.208.247)
# [08:47] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [08:47] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
# [08:47] <RRSAgent> logging to http://www.w3.org/2010/08/23-CSS-irc
# [08:50] <glazou> RRSAgent, make logs public
# [08:50] <RRSAgent> I have made the request, glazou
# [08:53] <glazou> RRSAgent, this meeting spans midnight
# [08:53] <RRSAgent> ok, glazou; I will not start a new log at midnight
# [08:53] * Parts: glazou (glazou@213.236.208.247)
# [08:53] * Joins: glazou (glazou@213.236.208.247)
# [08:53] * Parts: glazou (glazou@213.236.208.247)
# [08:53] * Joins: glazou (glazou@213.236.208.247)
# [08:59] <glazou> test
# [09:05] * Joins: dsinger (dsinger@213.236.208.247)
# [09:06] * Joins: dbaron (dbaron@213.236.208.247)
# [09:07] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [09:10] * Joins: howcome (howcome@213.236.208.247)
# [09:10] <TabAtkins_> ScribeNick: TabAtkins_
# [09:11] * Joins: mollydotcom (mollyh@213.236.208.247)
# [09:12] * Joins: Arron (arronei@213.236.208.247)
# [09:12] * Joins: alexmog (alexmog@213.236.208.247)
# [09:12] * Joins: dstorey (dstorey@213.236.208.247)
# [09:13] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.13/2009073109])
# [09:13] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [09:14] <TabAtkins_> glazou: There are a few open issues with editorial work. I'd like to browse through them to see if they're ready.
# [09:14] <TabAtkins_> glazou: First is issue 26 on bert
# [09:14] <TabAtkins_> s/26/126/
# [09:14] * Joins: tantek (tantek@213.236.208.247)
# [09:15] <TabAtkins_> Bert: For 26, I did do the edit, but it's not verified yet.
# [09:15] <TabAtkins_> Bert: Same for 53.
# [09:15] <TabAtkins_> Bert: For 56, not done yet.
# [09:15] <TabAtkins_> Bert: 60, edited.
# [09:15] <TabAtkins_> Bert: 69, edited.
# [09:16] <TabAtkins_> Bert: 71, edited.
# [09:16] <TabAtkins_> Bert: 73, edited
# [09:16] <TabAtkins_> Bert: 84, edited
# [09:16] <TabAtkins_> Bert: 85, edited
# [09:16] <TabAtkins_> dbaron: 101, not done.
# [09:17] <TabAtkins_> glazou: Anyone else who can pick up 101?
# [09:17] <TabAtkins_> arronei: I can do a few testcases.
# [09:18] <TabAtkins_> dbaron: I wrote a few tests. They're not submitted to the testsuite.
# [09:18] <TabAtkins_> glazou: please send those tests to arronei
# [09:19] <TabAtkins_> Issue 101 is reassigned to Arron.
# [09:19] <dbaron> Figuring out what the text should be is the hard part...
# [09:19] <TabAtkins_> Bert: 107, edited.
# [09:19] <TabAtkins_> Bert: 109, not done yet.
# [09:19] <TabAtkins_> Bert: Not sure if it can be done this week, but certainly next week.
# [09:20] <TabAtkins_> glazou: So by the time of the next conf call?
# [09:20] <TabAtkins_> Bert: Yes.
# [09:20] <TabAtkins_> Bert: 110 relies on 109.
# [09:21] <TabAtkins_> glazou: Was john daggett supposed to be here?
# [09:21] <TabAtkins_> howcome: Yeah, we're missing jdaggett and szilles.
# [09:21] <TabAtkins_> Bert: 111, edited.
# [09:21] <TabAtkins_> glazou: Okay, we need John for those testcases.
# [09:21] <TabAtkins_> Bert: 114, edited.
# [09:21] <TabAtkins_> Bert: 115, edited.
# [09:21] <TabAtkins_> Bert: 117, edited.
# [09:22] <TabAtkins_> Bert: 118, edited.
# [09:22] <TabAtkins_> Bert: 119, edited.
# [09:22] <TabAtkins_> Bert: 120, not done yet.
# [09:23] <TabAtkins_> glazou: Can you get it by the conf call?
# [09:23] <TabAtkins_> Bert: Yes.
# [09:23] <TabAtkins_> Bert: 121, I sent a proposal.
# [09:23] <TabAtkins_> glazou: Did anyone review that?
# [09:24] <TabAtkins_> Bert: I just sent it 2 days ago, so maybe people haven't seen it yete.
# [09:24] <dbaron> is there a url?
# [09:24] <TabAtkins_> glazou: Action on everyone: review the proposal by next conf call.
# [09:24] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0411.html
# [09:25] <TabAtkins_> Bert: 122, not done yet.
# [09:25] <TabAtkins_> glazou: You already have the dbaron proposal for that, so same ETA?
# [09:25] <TabAtkins_> Bert: Yes.
# [09:25] <TabAtkins_> Bert: 127, edited.
# [09:25] <TabAtkins_> Bert: 128, edited.
# [09:25] * dbaron notes jdaggett's flight landed at 7:24
# [09:25] <TabAtkins_> glazou: Open issue now, about backup in tokenizer - 129.
# [09:25] <TabAtkins_> Bert: I sent a proposal to the list about that last week.
# [09:26] <Bert> http://lists.w3.org/Archives/Public/www-style/2010Aug/0417.html
# [09:26] <Bert> http://lists.w3.org/Archives/Public/www-style/2010Aug/0368.html
# [09:28] <TabAtkins_> glazou: Has anyone tested this in an implementation?
# [09:28] * Joins: johnjansen (qw3birc@128.30.52.28)
# [09:29] <TabAtkins_> dbaron: The only real change is that we change how we handle bad urls.
# [09:29] <TabAtkins_> dbaron: I think that we made the change in Moz a few weeks ago when the group decided to make the change in priciple.
# [09:29] <TabAtkins_> glazou: No objection? Good.
# [09:29] <TabAtkins_> RESOLVED: Accept Bert's proposal for 129.
# [09:30] <TabAtkins_> Bert: 131, I think I've already done it.
# [09:30] <TabAtkins_> fantasai: I need to go through all of them and make sure.
# [09:30] <TabAtkins_> glazou: Issue 134.
# [09:30] <fantasai> and then update the issues list )
# [09:31] <dbaron> I changed Gecko to match the new url() tokenization in https://bugzilla.mozilla.org/show_bug.cgi?id=569646 which has been on trunk since June 3.
# [09:31] <TabAtkins_> arronei: Done.
# [09:31] <TabAtkins_> Bert: 137, not done yet.
# [09:32] <TabAtkins_> Bert: 138, not done yet.
# [09:32] * Joins: CesarAcebal (acebal@193.213.156.111)
# [09:32] <TabAtkins_> Bert: 139, haven't done yet, but should be very easy.
# [09:33] <TabAtkins_> Bert: 140, sent a proposal yesterday.
# [09:33] <Bert> Ûhttp://lists.w3.org/Archives/Public/www-style/2010Aug/0435.html
# [09:33] <TabAtkins_> glazou: Everyone, review this so we can decide on it next call.
# [09:33] <TabAtkins_> Bert: 141, edited.
# [09:34] <TabAtkins_> Bert: 142, edited.
# [09:34] <TabAtkins_> Bert: 143, not done yet, but should be easy.
# [09:35] <TabAtkins_> glazou: 144, text-decoration and visibility. iirc, we didn't finish the discussion and deferred it to the ftf.
# [09:35] <TabAtkins_> glazou: I think you said that all browsers have interop, which doesn't match the new proposal.
# [09:35] <TabAtkins_> arronei: Yeah, they all do the same thing - drawing the decoration in the invisible area.
# [09:36] <TabAtkins_> glazou: So we can either change the spec or tell all the implementors to change. Your choice.
# [09:36] <TabAtkins_> glazou: I don't think decorations actually matter to authors very much.
# [09:37] <TabAtkins_> [jdaggett enters the arena]
# [09:37] <TabAtkins_> dbaron: I know we intentionally changed the image underlining, and I want to keep that.
# [09:37] * Joins: lstorset (lstorset@213.236.208.22)
# [09:40] <TabAtkins_> dbaron: So I want to keep the spec, and change Moz's impl.
# [09:41] <TabAtkins_> dbaron: Doing so would let us remove the quirks/standards impl for text-decoration.
# [09:41] <TabAtkins_> dbaron: I think webkit has a similar distinction.
# [09:41] <fantasai> s/remove/unify
# [09:41] <TabAtkins_> s/remove/unify/
# [09:42] <TabAtkins_> glazou: Hakon, opinion?
# [09:42] <TabAtkins_> johnjansen: We'd prefer not to change our impl.
# [09:43] <alexmog> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!doctype%20html%3E%0D%0A%3Cspan%20style%3D%22color%3Ablue%3B%20%20text-decoration%3A%20underline%3B%0D%0A%22%3E01%0D%0A%3Cspan%20style%3D%22color%3Ared%3B%20%20%20text-decoration%3A%20underline%3B%20%0D%0Avisibility%3Ahidden%3B%22%3E11%0D%0A%3Cspan%20style%3D%22color%3Agreen%3B%20text-decoration%3A%20none%3B%20%0D%0Avisibility%3Avisible%3B%22%3E21%0D%0A
# [09:43] <TabAtkins_> dstorey: Is it a minor change?
# [09:43] <TabAtkins_> glazou: Yeah, should be.
# [09:43] * Joins: jdaggett (jdaggett@213.236.208.247)
# [09:45] <TabAtkins_> fantasai: What if you use visibility:collapse?
# [09:46] <TabAtkins_> dbaron: You don't draw the collapsed cell at all. It's quite different.
# [09:46] <TabAtkins_> howcome: If we have interop, we should just keep that.
# [09:46] <TabAtkins_> dbaron: I think the interop behavior is a complete disaster.
# [09:46] <TabAtkins_> dbaron: And the quirksmode behavior is better than standards mode.
# [09:47] <TabAtkins_> glazou: Proposal - leave it undefined in 2.1 and leave a note, define it properly in css3.
# [09:48] <TabAtkins_> RESOLVED: Leave issue 144 officially undefined, add a note that it will be resolved in css3.
# [09:48] <TabAtkins_> arronei: I'll remove the tests.
# [09:49] <TabAtkins_> dbaron: The issue is that the spec was unclear about whether text decorations were based on the visibility of the text or the visibility of the element with text-decoration.
# [09:50] <TabAtkins_> fantasai: The spec is not clear, but the rest of the model that it outlined in the spec is more consistent with one impl than the other.
# [09:50] <TabAtkins_> glazou: Also, we discussed both underlined text, and about underlining images.
# [09:50] <TabAtkins_> fantasai: The image underlining issue is taken care of.
# [09:50] <TabAtkins_> glazou: What about impls?
# [09:51] <TabAtkins_> arronei: It's inconsistent.
# [09:51] <TabAtkins_> glazou: So the only ambiguity is about underlining text in a visibility:hidden element?
# [09:51] <TabAtkins_> fantasai: Yeah.
# [09:52] <TabAtkins_> Bert: 145, not done yet. I can get it by next call.
# [09:52] <TabAtkins_> Bert: 146, not done yet.
# [09:52] <TabAtkins_> Bert: 147, not done yet.
# [09:52] <TabAtkins_> Bert: 148, not done yet.
# [09:53] <TabAtkins_> Bert: 149, not done yet.
# [09:53] <TabAtkins_> glazou: I think Moz already implemented that.
# [09:54] <TabAtkins_> dbaron: I think other impls have it coming now.
# [09:54] <dbaron> I think other impls have done it for a while
# [09:57] <TabAtkins_> glazou: The decision was made during a conf call, and recorded in the minutes. You should be reading the minutes and objecting as soon as possible afterwards if you miss a call.
# [09:57] <TabAtkins_> dsinger: I think we might want a note that some user agents start off at a zoom factor other than 1.
# [10:02] <TabAtkins_> howcome: Where in this decision does it say that this only applies to screen media?
# [10:03] <TabAtkins_> fantasai: It doesn't need to do so explicitly. There is a note that high-res devices should set the in or other physical unit to the true physical size, while low-rez devices are recommended to use the px as the anchor unit.
# [10:05] <TabAtkins_> jdaggett: I think we shoudl go ahead and draft up some revised text for that.
# [10:05] <TabAtkins_> glazou: dsinger, can you send a suggestion for the note you want?
# [10:05] <TabAtkins_> glazou: If Hakon and others have comments, please make them as soon as possible.
# [10:05] <TabAtkins_> Bert: 150, edited.
# [10:06] <TabAtkins_> Bert: 151, not done yet. I can get it done by next conf call.
# [10:06] <TabAtkins_> Bert: 152, edited.
# [10:07] <TabAtkins_> Bert: 153, not done yet. Next conf call.
# [10:07] <TabAtkins_> arronei: 154, now that jdaggett and I are both here we can talk about it. Next conf call.
# [10:07] <TabAtkins_> Bert: 155, not done yet, but should be trivial.
# [10:07] <TabAtkins_> jdaggett: 156, the edit has been put in, but I think some of the surrounding statements need to be cleaned up to match.
# [10:08] <TabAtkins_> jdaggett: Is that a new issue or just wrap it up in the current one? I also haven't written a new test case.
# [10:08] <TabAtkins_> glazou: Not a new issue.
# [10:08] <TabAtkins_> jdaggett: Ok, I'll make a proposal for further edits tomorrow.
# [10:08] <TabAtkins_> Bert: 157, not done yet.
# [10:09] <mollydotcom> Tab: Proposal 831 cleared up some minor collapse issues
# [10:09] <fantasai> jdaggett, I think the edits didn't make it in 100% as there was a sentence "Once the family's weights..." in the proposal that didn't make it in for 156
# [10:09] <fantasai> afaict
# [10:10] <mollydotcom> Fantasai: issue 158
# [10:10] <dbaron> s/831/8.3.1/
# [10:10] <mollydotcom> Tab: Anything I've already is probably invalid at this point
# [10:11] <mollydotcom> Fantasai: I've seen some proposals from Anton, let's sit down and talk it through
# [10:11] <mollydotcom> Glazou: Do we need to make some time
# [10:11] <mollydotcom> Tab: Yes, we'll talk by ourselves tonight and then need some time
# [10:11] <mollydotcom> Glazou: We'll do our best
# [10:12] <mollydotcom> Glazou: Deferred until discussed
# [10:12] <TabAtkins_> glazou: Issue 159.
# [10:12] <glazou> http://lists.w3.org/Archives/Public/www-style/2010Feb/0015.html
# [10:13] <TabAtkins_> fantasai: That's what my 8.3.1 rewrite was for.
# [10:13] <TabAtkins_> TabAtkins_: And I think arronei reviewed it and said it was good.
# [10:13] <glazou> http://lists.w3.org/Archives/Public/www-style/2010Aug/0391.html
# [10:13] <TabAtkins_> dbaron: Link to the latest proposal?
# [10:13] <TabAtkins_> dbaron: I need more time to review it to make sure it's good.
# [10:14] <TabAtkins_> glazou: We'll discuss it on the first conf call after the meeting.
# [10:14] <TabAtkins_> ACTION everyone: review the 8.3.1 proposal
# [10:14] * trackbot noticed an ACTION. Trying to create it.
# [10:14] <trackbot> Sorry, couldn't find user - everyone
# [10:14] * RRSAgent records action 1
# [10:14] <TabAtkins_> Bert: 160, not done yet.
# [10:15] <TabAtkins_> Bert: 161, not done yet.
# [10:15] <TabAtkins_> Bert: 163, edited.
# [10:15] <TabAtkins_> Bert: 164, edited.
# [10:15] <TabAtkins_> Bert: 166, edited.
# [10:15] <TabAtkins_> Bert: 167, edited.
# [10:15] <TabAtkins_> Bert: 168, edited.
# [10:16] <TabAtkins_> Bert: 169, edited.
# [10:16] <TabAtkins_> Bert: 170, not done yet.
# [10:16] <TabAtkins_> Bert: 171, edited.
# [10:16] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0404.html
# [10:16] <TabAtkins_> glazou: Open to the WG, 172 - table caption and content overflows.
# [10:17] <tantek> FWIW - I reviewed http://lists.w3.org/Archives/Public/www-style/2010Aug/0391.html and it looks good to me (fantasai's v3 of Clarifying 8.3.1 Collapsing Margins)
# [10:17] * gsnedders waves from upstairs
# [10:17] <TabAtkins_> fantasai: Issue is that the caption overflows in non-useful ways when the table is small.
# [10:17] * TabAtkins_ waves back to gsnedders.
# [10:18] <TabAtkins_> fantasai: My proposal was to make the caption act like a cell for purpose of table width.
# [10:18] <TabAtkins_> dbaron: Does any impl do that?
# [10:18] <TabAtkins_> fantasai: Yes, Konqueror, and some older browsers, I think ie6.
# [10:18] <TabAtkins_> fantasai: This changes the computed final width of the table, essentially providing a minimum width for it.
# [10:19] <TabAtkins_> fantasai: So when you lay out a table, you calculate the actual width, and then use min(that, specified width). I'm proposing using the caption width also.
# [10:19] <fantasai> Tantek: http://test.csswg.org/source/contributors/csswg-issues/incoming/css2.1/table-caption-004.xht
# [10:21] * glazou looked carefully at the new france.fr web site and found... 404 html documents :-)
# [10:21] <TabAtkins_> dbaron: It might be worth noting that this only applies to top/bottom captions.
# [10:21] <TabAtkins_> fantasai: We can note that, sounds like a good idea.
# [10:23] * Quits: lstorset (lstorset@213.236.208.22) (Quit: Leaving.)
# [10:25] * Joins: glazou_ (glazou@213.236.208.247)
# [10:25] * Quits: glazou (glazou@213.236.208.247) (Connection reset by peer)
# [10:25] * jgraham wonders if there is an agenda around
# [10:26] <glazou_> yes
# [10:26] <glazou_> jgraham: you have access to w3c-css-wg@w3.org ?
# [10:26] * Joins: CesarAcebal_ (acebal@213.236.208.247)
# [10:27] * glazou_ is now known as glazou
# [10:28] * Quits: CesarAcebal (acebal@193.213.156.111) (Ping timeout)
# [10:28] * CesarAcebal_ is now known as CesarAcebal
# [10:29] <TabAtkins_> fantasai: This proposal will break the table-caption-004 test.
# [10:30] <TabAtkins_> dbaron: If the caption is large enough to make the page scroll, this change will make the entire table stretch off the page.
# [10:30] <TabAtkins_> glazou: Will this break anything?
# [10:31] <TabAtkins_> dbaron: table captions are used so rarely that I don't think it will affect anything significant.
# [10:32] <TabAtkins_> tantek: If I rewrite the test case to use <table>, I think IEMac5.2 matches your proposal.
# [10:32] <TabAtkins_> fantasai: Right, a lot of the older generation of browsers do that.
# [10:32] * gsnedders any idea of when test-suite disscussion will be?
# [10:33] <TabAtkins_> glazou: Can we reach a decision here?
# [10:33] <TabAtkins_> dbaron: I'm okay with it. I'm not super happy when the caption is extra wide, but shrug.
# [10:34] * gsnedders means beyond "this morning"
# [10:34] <glazou> gsnedders: mid-afternoon probably
# [10:34] <glazou> gsnedders: after all issues are browsed and discussed
# [10:35] <TabAtkins_> dbaron: Probably in the case that the caption width has a small fixed width, we should make it so that the table can be larger than that and the caption stays small.
# [10:35] <gsnedders> glazou: Okay, I'll probably join then
# [10:35] <TabAtkins_> RESOLVED: Accept fantasai's proposal for 172.
# [10:36] <TabAtkins_> <br duration=15min>
# [10:36] * Quits: dstorey (dstorey@213.236.208.247) (Quit: dstorey)
# [10:44] * Joins: Doofl (mstensho@213.236.208.247)
# [10:46] * Joins: lstorset (lstorset@213.236.208.247)
# [10:47] * Joins: dstorey (dstorey@193.213.156.111)
# [10:48] * Zakim excuses himself; his presence no longer seems to be needed
# [10:48] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [10:49] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [10:49] <glazou> RRSAgent, make logs public
# [10:49] <RRSAgent> I have made the request, glazou
# [10:50] <TabAtkins_> glazou: Issue 173
# [10:50] <glazou> Chris joined the meeting
# [10:50] * Joins: lhnz (lhnz@188.223.83.48)
# [10:50] <TabAtkins_> fantasai: I need to work on that.
# [10:50] <TabAtkins_> glazou: Is it still workable?
# [10:50] <TabAtkins_> fantasai: I've emailed back and forth with henri.
# [10:51] <TabAtkins_> fantasai: He says "I want carriage returns inserted wherever to be whitespace."
# [10:51] <TabAtkins_> fantasai: I said "What kind of whitespace?"
# [10:52] <fantasai> fantasai: He didn't know. Thought it should be normalized as a line break in pre
# [10:52] <fantasai> fantasai: But that would make DOM text and generated content text behave inconsistently, because CR is ignored in generated content
# [10:52] <TabAtkins_> fantasai: I think I'll still need a while to do this.
# [10:53] <TabAtkins_> fantasai: A couple of hours.
# [10:53] <TabAtkins_> fantasai: Maybe can do it before we end here, if not, then by the next conf call.
# [10:54] <TabAtkins_> glazou: Send it by next Wednesday, so we have a week to review it before the conf call.
# [10:54] <TabAtkins_> glazou: Otherwise it's undefined in 2.1
# [10:54] <TabAtkins_> chrisl: Does this have any effect on test suites?
# [10:55] <TabAtkins_> ACTION Elika: Send a proposal by next wednesday.
# [10:55] * trackbot noticed an ACTION. Trying to create it.
# [10:55] * RRSAgent records action 2
# [10:55] <trackbot> Created ACTION-248 - Send a proposal by next wednesday. [on Elika Etemad - due 2010-08-30].
# [10:55] <TabAtkins_> Bert: 174, 175 edited.
# [10:55] <TabAtkins_> Bert: 176, edited.
# [10:55] <TabAtkins_> Bert: 177, edited
# [10:55] * Joins: dstorey_ (dstorey@213.236.208.247)
# [10:55] <TabAtkins_> TabAtkins_: 178, I was crazy. Mark as invalid.
# [10:56] <TabAtkins_> Bert: 179, edited.
# [10:56] <TabAtkins_> Bert: 180, editd.
# [10:56] <TabAtkins_> fantasai: 181, I don't think it needs to be addressed right now.
# [10:56] <TabAtkins_> Bert: 182, edited.
# [10:56] * Quits: dstorey (dstorey@193.213.156.111) (Ping timeout)
# [10:57] <glazou> http://lists.w3.org/Archives/Public/www-style/2010Aug/0025.html
# [10:57] <TabAtkins_> glazou: new open issue, 183 - handling of malformed media types
# [10:58] <TabAtkins_> glazou: We seem to be saying two different things here about what to do with the malformed queries.
# [10:58] * Joins: ChrisL (ChrisL@128.30.52.169)
# [10:58] <TabAtkins_> chrisl: It should be possible for us to just match up with what MQ says now.
# [10:59] <TabAtkins_> dbaron: What's the mismatch? Is it just that we have 2.1 say that unknown identifiers dont' match anything, but aren't parse errors?
# [11:00] <TabAtkins_> fantasai: So 2.1 says to ignore unknown media types, but do you ignore malformed ones or throw them away?
# [11:00] <TabAtkins_> dbaron: I think we ignore.
# [11:01] <dbaron> The appendix G grammar says it has to be an identifier in 2.1
# [11:01] <TabAtkins_> fantasai: I don't think anything is said that media types have to be identifiers
# [11:01] <dbaron> but it doesn't seem to say that outside the appendix G grammar
# [11:02] <TabAtkins_> dbaron: Does this affect any impls?
# [11:02] <TabAtkins_> dbaron: Anyone that doesn't implement MQ that are currently maintained?
# [11:02] <TabAtkins_> dbaron: Because this change only affects impls that do 2.1 and not MQ.
# [11:02] <TabAtkins_> fantasai: I think some of the printers may.
# [11:03] <fantasai> fantasai: But they probably want to implement MQ as awell
# [11:03] <TabAtkins_> glazou: Can't we just say that MQ supercedes 2.1 here?
# [11:03] <TabAtkins_> fantasai: That's in the snapshot, but it's still not clear what an "unknown media type" is.
# [11:04] <TabAtkins_> dbaron: Since we're making Appendix G informative, we should add a note that media types must be identifiers, and non-identifiers make the whole thing invalid.
# [11:04] <TabAtkins_> dbaron: We should probably go through Appendix G and check for similar occurences like that.
# [11:04] * Quits: arronei (arronei@131.107.0.117) (Ping timeout)
# [11:04] <TabAtkins_> dsinger: Is there a difference between an unknown and an invalid type?
# [11:05] <TabAtkins_> fantasai: If it's not an identifier, it's invalid and throw it away.
# [11:05] <fantasai> "@media and @import rules with unknown media types are treated as if the unknown media types are not present. "
# [11:05] <fantasai> "@media and @import rules with unknown media types (as identifiers) are treated as if the unknown media types are not present."
# [11:05] <fantasai> ?
# [11:05] <fantasai> plus "If an @media rule contains a malformed media type (not an identifier) then the statement is invalid"
# [11:06] <fantasai> s/as identifiers/that are nonetheless valid identifiers/
# [11:06] <fantasai> Note: Media Queries supercedes this error handling.
# [11:07] <TabAtkins_> RESOLVED: Accept the change above for issue 183.
# [11:07] <TabAtkins_> Action Bert: Make the above edit for issue 183.
# [11:07] * trackbot noticed an ACTION. Trying to create it.
# [11:07] * RRSAgent records action 3
# [11:07] <trackbot> Created ACTION-249 - Make the above edit for issue 183. [on Bert Bos - due 2010-08-30].
# [11:07] <TabAtkins_> Bert: 184, edited
# [11:07] <TabAtkins_> Bert: 185, not done yet.
# [11:08] <TabAtkins_> glazou: We already closed 186.
# [11:08] <TabAtkins_> ACTION david: Find normative statement in appendix G that should now be written elsewhere.
# [11:08] * trackbot noticed an ACTION. Trying to create it.
# [11:08] <trackbot> Sorry, amibiguous username (more than one match) - david
# [11:08] <trackbot> Try using a different identifier, such as family name or username (eg. hyatt, dbaron, dsinger2)
# [11:08] * RRSAgent records action 4
# [11:08] <TabAtkins_> ACTION dbaron: Find normative statement in appendix G that should now be written elsewhere.
# [11:08] * trackbot noticed an ACTION. Trying to create it.
# [11:08] * RRSAgent records action 5
# [11:08] <trackbot> Created ACTION-250 - Find normative statement in appendix G that should now be written elsewhere. [on David Baron - due 2010-08-30].
# [11:09] <TabAtkins_> fantasai: 187 - The spec is confusing in this case. it's inconsistent about normal bidi working. I can write an email about that tonight.
# [11:09] <TabAtkins_> fantasai: I may need some time for this Tuesday or Wednesday.
# [11:10] <TabAtkins_> johnjansen: dbaron, can you do that appendix G trawling by next conf call?
# [11:10] <TabAtkins_> dbaron: Maybe.
# [11:10] * Joins: arronei (arronei@131.107.0.106)
# [11:10] <TabAtkins_> glazou: If we get the issue list closed down, perhaps we can have a firm roadmap for 2.1 by next conf call.
# [11:11] <TabAtkins_> Bert: 188, edited.
# [11:11] <TabAtkins_> Bert: 189, edited.
# [11:11] <TabAtkins_> Bert: 190, not done yet.
# [11:11] <TabAtkins_> glazou: 191, define stacking level of marker box.
# [11:11] <glazou> http://lists.w3.org/Archives/Public/www-style/2009Dec/0093.html
# [11:13] * glazou brucel says hi to the WG
# [11:13] <TabAtkins_> fantasai: I think arronei and I talked about this, and wanted to make it undefined in 2.1, since you can't move the marker box anyway. Also, there are some significant details that may be affected by implementations, so we want to wait and then spec behavior in CSS3.
# [11:13] <TabAtkins_> fantasai: We shouldn't put a recommendation in 2.1, but we might put a note saying it's undefined or leave it out completely.
# [11:13] <TabAtkins_> glazou: I prefer marking it undefined.
# [11:14] <TabAtkins_> RESOLVED: Add a note about marker box stacking level for outside markers being undefined in 2.1.
# [11:14] <TabAtkins_> ACTION fantasai: Propose note for issue 191 making marker box stacking level undefined.
# [11:14] * trackbot noticed an ACTION. Trying to create it.
# [11:14] * RRSAgent records action 6
# [11:14] <trackbot> Created ACTION-251 - Propose note for issue 191 making marker box stacking level undefined. [on Elika Etemad - due 2010-08-30].
# [11:14] <glazou> http://lists.w3.org/Archives/Public/www-style/2009Oct/0027.html
# [11:15] <TabAtkins_> dbaron: Anton's proposal for issue 1 looks fine.
# [11:16] <TabAtkins_> dbaron: I don't think we want to make the second change.
# [11:17] <TabAtkins_> dsinger: I think the "further" lacks a referent.
# [11:17] <fantasai> dbaron proposes s/further content/content after the float/
# [11:18] <fantasai> and s/it/that content/
# [11:19] <TabAtkins_> TabAtkins_: And the third issue is invalid - Bert gave an example where the content may have to be reflowed onto multiple lines.
# [11:19] <TabAtkins_> RESOLVED: Accept change for first issue, accept dbarons' change for the second issue, third issue is invalid.
# [11:19] <TabAtkins_> Bert: I've done the edits for 193.
# [11:19] * howcome says that a table has been reserved for us in the cafeteria for 11:30
# [11:19] <TabAtkins_> fantasai: I haven't written the tests yet.
# [11:20] <TabAtkins_> fantasai: I can do them this week.
# [11:21] <TabAtkins_> glazou: 194 is open to the working group - text-indent shouldn't apply to non-first-lines of an element.
# [11:21] <TabAtkins_> fantasai: The issue is that if you have a block split by another block, thus generating anonymous blocks, you don't want the two halves of the paragraph indented.
# [11:22] <TabAtkins_> dbaron: Prose text seems fine.
# [11:22] <dbaron> s/Prose/Proposed/
# [11:22] <TabAtkins_> RESOLVED: Accept the proposal in the issue list for 194.
# [11:22] <dbaron> proposed text is http://lists.w3.org/Archives/Public/www-style/2010Aug/0207.html
# [11:23] <TabAtkins_> glazou: Issue 195, clarifiction needed for inline boxes containing block boxes.
# [11:25] <TabAtkins_> fantasai: The behavior Boris proposes is currently implemented in Gecko.
# [11:26] <TabAtkins_> glazou: Do we all agree about the clarification needed? Any objections?
# [11:26] <TabAtkins_> fantasai: Looks like we have Opera and Firefox.
# [11:26] <TabAtkins_> dbaron: And Chromium seems to do the same thing too.
# [11:29] <glazou> http://lists.w3.org/Archives/Public/www-style/2010Feb/0156.html
# [11:29] <TabAtkins_> TabAtkins_: IE8 doesn't generate the second half.
# [11:30] <TabAtkins_> glazou: Fantasai, write up proposal.
# [11:30] <TabAtkins_> ACTION fantasai: Write up a proposal for issue 195.
# [11:30] * trackbot noticed an ACTION. Trying to create it.
# [11:30] * RRSAgent records action 7
# [11:30] <trackbot> Created ACTION-252 - Write up a proposal for issue 195. [on Elika Etemad - due 2010-08-30].
# [11:30] <TabAtkins_> glazou: Issue 196 - grammar and prose disagree on nbsp inside identifiers.
# [11:30] <TabAtkins_> dsinger: Do we have impl experience?
# [11:31] <TabAtkins_> fantasai: In the test, if it's underlined you accept nbsp in an identifier.
# [11:31] <TabAtkins_> dsinger: Safari is underlining, firefox is not.
# [11:31] <TabAtkins_> dbaron: Prose says nbsp isn't allowed, grammar says it is.
# [11:31] <TabAtkins_> glazou: We always say that prose is higher than the grammar.
# [11:32] <TabAtkins_> ChrisL: Is there a reason to be more restrictive?
# [11:32] <TabAtkins_> fantasai: Usually we use the prose to be more restrictive, but here there doesn't seem to be any reason for the difference.
# [11:34] <TabAtkins_> RESOLVED: Change prose to match the grammar.
# [11:34] <TabAtkins_> dbaron: The prose/grammar mismatch goes all the way back to CSS1.
# [11:35] * Quits: johnjansen (qw3birc@128.30.52.28) (Quit: Page closed)
# [11:35] * Quits: jdaggett (jdaggett@213.236.208.247) (Quit: jdaggett)
# [11:35] <TabAtkins_> <br type=lunch duration=1h>
# [11:35] * Quits: glazou (glazou@213.236.208.247) (Quit: glazou)
# [11:35] <TabAtkins_> ACTION bert: Fix the prose for issue 196 to match the grammar.
# [11:35] * trackbot noticed an ACTION. Trying to create it.
# [11:35] * RRSAgent records action 8
# [11:35] <trackbot> Created ACTION-253 - Fix the prose for issue 196 to match the grammar. [on Bert Bos - due 2010-08-30].
# [11:35] * Quits: dstorey_ (dstorey@213.236.208.247) (Quit: dstorey_)
# [11:36] * Quits: tantek (tantek@213.236.208.247) (Quit: tantek)
# [12:18] * Quits: CesarAcebal (acebal@213.236.208.247) (Connection reset by peer)
# [12:18] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [12:18] * Joins: dsinger_ (dsinger@213.236.208.247)
# [12:18] * Joins: CesarAcebal (acebal@213.236.208.247)
# [12:18] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (No route to host)
# [12:19] * Quits: Arron (arronei@213.236.208.247) (Ping timeout)
# [12:23] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [12:24] * Joins: Arron (arronei@213.236.208.247)
# [12:36] * Joins: glazou (glazou@213.236.208.247)
# [12:36] * Joins: dstorey (dstorey@193.213.156.111)
# [12:40] * Joins: tantek (tantek@213.236.208.247)
# [12:42] <fantasai> Resuming meeting
# [12:42] <fantasai> ScribeNick: fantasai
# [12:43] <fantasai> Resuming from CSS2.1 Issue 186
# [12:43] <fantasai> dbaron has pointed out that one of the ranges includes a bunch of control characters
# [12:44] * Joins: ChrisL (ChrisL@128.30.52.169)
# [12:44] <fantasai> fantasai: So there were two related issues, one is that the range given started at A1 instead of A0. We resolved to include A0
# [12:45] <fantasai> fantasai: The other issue is that the range in between the two formulations of the range used to not be characters
# [12:45] * Joins: JohnJansen (qw3birc@128.30.52.28)
# [12:45] <fantasai> fantasai: but now are control characters
# [12:45] <fantasai> fantasai: The spec relied on them not being characters when defining the range
# [12:45] <fantasai> fantasai: They should instead be explicitly excluded
# [12:47] <fantasai> RESOLVED: Range should be worded such that these characters are excluded
# [12:47] <glazou> http://lists.w3.org/Archives/Public/www-style/2010Feb/0156.html
# [12:47] * Joins: jdaggett (jdaggett@213.236.208.247)
# [12:47] <fantasai> CSS2.1 Issue 197
# [12:48] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-197
# [12:48] * Joins: szilles (chatzilla@213.236.208.247)
# [12:48] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [12:49] <glazou> http://www.w3.org/mid/20100808112430.GA23693@bowman.infotech.monash.edu.au
# [12:50] <glazou> http://www.w3.org/mid/4B513652.9020709@mit.edu
# [12:51] * glazou everyone, that's a 404 issue :-)
# [12:52] * Joins: dstorey_ (dstorey@213.236.208.247)
# [12:53] * Quits: dstorey (dstorey@193.213.156.111) (Ping timeout)
# [12:53] <fantasai> fantasai: I think what that's saying is that the 'clear' applies to the run-in if it becomes a block box, otherwise it applies to the parent block that it's been injected into
# [12:54] <fantasai> dbaron: Do run-ins get injected into the next block box if there is a float in between? Because that would make clear very interesting on run-ins
# [12:55] * Quits: dstorey_ (dstorey@213.236.208.247) (Connection reset by peer)
# [12:55] * Joins: dstorey (dstorey@213.236.208.247)
# [12:55] <Arron> http://test.csswg.org/suites/css2.1/20100815/html4/run-in-float-between-001.htm
# [12:56] <Arron> http://test.csswg.org/suites/css2.1/20100815/html4/run-in-clear-001.htm
# [12:58] <fantasai> Molly: Why would you put a float between the header and the beginning of a section
# [12:58] <fantasai> ?
# [12:58] <fantasai> dbaron: Suppose you have an article about an image, you might want to float it to the side
# [12:59] <fantasai> dbaron: Then someone comes and wants to make the headings all run-ins
# [13:00] <dbaron> (And do run-ins run in to a first child of the following block if the first child is also a block?)
# [13:00] <fantasai> fantasai and glazou give examples where it makes sense
# [13:01] * howcome unsorted images from yesterday http://www.wiumlie.no/img/2010/08-22-csswg/
# [13:01] * Joins: davve (davve@83.218.67.122)
# [13:02] <fantasai> http://www.w3.org/Style/Group/css2-src/
# [13:02] <dbaron> http://www.w3.org/Style/Group/css2-src/visuren.html#run-in
# [13:03] * Joins: futhark (rune@213.236.208.22)
# [13:03] * Joins: mg (mg@88.131.66.80)
# [13:05] <fantasai> the wg studies the run-in-clear-001 testcases, which has very poor wording!
# [13:06] <fantasai> Agreed on what the spec is intending to say and that it needs to be clarified
# [13:07] <fantasai> ACTION: fantasai and Bert, clarify spec for CSS2.1 197
# [13:07] * trackbot noticed an ACTION. Trying to create it.
# [13:07] * RRSAgent records action 9
# [13:07] <trackbot> Created ACTION-254 - And Bert, clarify spec for CSS2.1 197 [on Elika Etemad - due 2010-08-30].
# [13:08] <glazou> issue 198 now
# [13:08] <glazou> http://lists.w3.org/Archives/Public/www-style/2010Jan/0376.htm
# [13:11] <fantasai> dbaron: So this isn't as complicated as it looks.
# [13:11] <fantasai> dbaron: We just need to make sure the spec defines clear in terms of the box tree instead of the element tree.
# [13:12] <fantasai> dbaron: But that means we need to get the spec to admit that there is a box tree.
# [13:12] * Zakim excuses himself; his presence no longer seems to be needed
# [13:12] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [13:13] * Joins: Zakim (rrs-bridgg@128.30.52.169)
# [13:14] <fantasai> fantasai: The question here is whether you take floats out-of-flow before or after you process run-ins
# [13:14] <ChrisL> zakim, remind me in 5 hours to go home
# [13:14] <Zakim> ok, ChrisL
# [13:16] <fantasai> Tab: The definition of clearance is based on the element tree, so it's asking the <div> to clear the float here, even though the float would be inside the clearing element
# [13:16] <fantasai> s/clearing element/clearing box/
# [13:17] * glazou ( Anne just said on twitter : On my way to Oslo to attend the second and third day of the @csswg meeting )
# [13:17] <fantasai> dbaron: We could fix this by adding a parenthetical to the float rules talking about floats inside the clearaing element to explicitly include the contents of run-in elements
# [13:18] <dbaron> Inside "The 'clear' property does not consider floats inside the element itself or in other block formatting contexts." in 9.5.2
# [13:19] <dbaron> to something like "The 'clear' property does not consider floats inside the element itself (including floats inside a 'display:run-in' element that runs in to the element) or in other block formatting contexts."
# [13:19] <fantasai> dsinger: Is it completely clear what "inside" means in that section?
# [13:19] <fantasai> everyone: noe
# [13:19] <fantasai> s/noe/no/
# [13:20] <dbaron> We also need to fix the float positioning rules in 9.5.1
# [13:20] <dbaron> because they also go by source order.
# [13:20] <fantasai> bert: So what if you have a float in between the run-in and the block also?
# [13:23] <dbaron> and if the float not in the run-in has 'clear' on it then you have an explicit contradiction
# [13:24] <dbaron> we need a box tree
# [13:24] <fantasai> discussion of float placement rules
# [13:25] <fantasai> steve: So instead of saying that the float is inside the element that the float is inside a run-in rendered inside the principal box.
# [13:25] <fantasai> dbaron: how does that help?
# [13:25] <fantasai> dbaron: .. old problem. Doesn't help the new problem.
# [13:26] <fantasai> dbaron: The new problem is if you have
# [13:26] <fantasai> <runin><floatA/></runin>
# [13:26] <fantasai> <floatB/>
# [13:26] <fantasai> <block></block>
# [13:26] <fantasai> dbaron: The floats are both left
# [13:26] <fantasai> floatA, floatB { float: left; }
# [13:27] <fantasai> floatB, block { clear: left; }
# [13:27] <fantasai> dbaron: The definition of clear on floats says that floatB has to be below floatA
# [13:27] <fantasai> dbaron: Because it has to clear any elements earlier *in the source document*
# [13:28] <fantasai> dbaron: The definition of clear on blocks says that the block has to be below floatB
# [13:28] <fantasai> dbaron: And the float positioning rules say that floatA has to be even with the top of the block that contains, i.e. at or below the top of the block
# [13:29] <fantasai> steve: So say for a run-in, that combines with the following block, it is considered a reordering in the source docuent
# [13:30] <dbaron> so if "below" is "greater than", then floatB < floatA, block < floatB, and floatA <= block, which is a problem
# [13:30] <fantasai> tab: The more and more we try to patch the definitions here, the more of a mess it's going to get
# [13:30] <fantasai> tab: Maybe we can patch it here in 2.1 and make a CSS3 Box Tree module
# [13:31] <fantasai> ChrisL: We don't have to expose the box tree to the dom or anything, but we need to be clear about how it works
# [13:32] <fantasai> Bert: Another option is to say that floats inside the runin disable the runin
# [13:33] <fantasai> steve: What if I'm using float to get an initial drop-cap?
# [13:33] * Joins: lstorset2 (lstorset@213.236.208.247)
# [13:33] * Quits: lstorset (lstorset@213.236.208.247) (No route to host)
# [13:34] <fantasai> steve: We should go with run-in reordering the source tree in certain circumstances, and limit the circumstances where this occurs
# [13:34] <fantasai> steve: for layout purposes only
# [13:35] * Joins: miketaylr (miketaylr@24.42.95.108)
# [13:35] <fantasai> dbaron: We'd have to go through the whole spec and decide which instances would use the actual source order and which would use the virtual source order
# [13:35] <fantasai> dbaron: Which is what we mean by defining the box tree
# [13:35] * Quits: miketaylr (miketaylr@24.42.95.108) (Client exited)
# [13:36] <fantasai> alex: You'd also need to update Appendix E
# [13:37] <fantasai> fantasai: so for chapter 8 and above you pretend the source has been reordered
# [13:39] <dsinger_> but ... what happens if you need to be able to say something on the run-in that applies *without* this re-ordering, because then you would not be able to?
# [13:40] <fantasai> steve: the def of run-in box says that it's rendered as if it were an inline element in the next block box
# [13:40] <fantasai> steve: you could just clarify that the contents, including floats and abspos, are includedin this move
# [13:41] <fantasai> steve: you might need a note that you need an apparent reordering of the source
# [13:42] <fantasai> http://www.w3.org/TR/CSS21/visuren.html#run-in
# [13:43] <fantasai> "the run-in box becomes the first inline box of the block box"
# [13:43] <Bert> http://www.w3.org/Style/Group/css2-src/visuren.html#run-in
# [13:43] <TabAtkins_> http://www.w3.org/Style/Group/css2-src/visuren.html#run-in
# [13:44] <fantasai> steve: So we need a note to clarify
# [13:45] <fantasai> ACTION: Steve write note to clarify that run-in's contents are reordered by rule 2 in 9.2.3
# [13:45] * trackbot noticed an ACTION. Trying to create it.
# [13:45] * RRSAgent records action 10
# [13:46] <trackbot> Could not create new action (failed to parse response from server) - please contact sysreq with the details of what happened.
# [13:46] <trackbot> Could not create new action (unparseable data in server response: local variable 'd' referenced before assignment) - please contact sysreq with the details of what happened.
# [13:46] <fantasai> RESOLVED: Add note to be written by Steve for CSS2.1 issue 198 to clarify that this effectively causes a reordering of the source tree as far as all of the layout rules are concerned
# [13:49] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-199
# [13:50] <fantasai> so line boxes should be created for inline-level content and potentially marker boxes
# [13:51] <fantasai> collapsed-away whitespace does not create a line box
# [13:51] <fantasai> jdaggett: so you have a line box with no text in it. What font metrics do you use for it?
# [13:52] <fantasai> dbaron: known problem
# [13:52] <fantasai> Bert: We need to pick a font for finding the 'ex' unit
# [13:52] <fantasai> jdaggett: We don't have a font-finding algorithm that works without text
# [13:53] <fantasai> several you want to check against the first available font
# [13:53] <fantasai> steve: match against the empty string. Every font will match
# [13:53] <TabAtkins_> http://lists.w3.org/Archives/Public/www-style/2010May/0698.html
# [13:56] <fantasai> discussion of the phantom line boxes in 9.4.2
# [13:56] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010May/0698.html
# [13:57] <fantasai> ...
# [13:58] <fantasai> fantasai: You need the phantom line boxes to handle abspos static positioning
# [13:58] <fantasai> fantasai: but you need to ignore it for margin collapsing
# [13:59] <ChrisL> calling it 'potential' line box (which later resolves to no line box, or a real line box, may be better than 'phantom'
# [14:02] <fantasai> ACTION: Tab propose text for CSS2.1 Issue 199
# [14:02] * RRSAgent records action 11
# [14:02] * trackbot noticed an ACTION. Trying to create it.
# [14:02] <trackbot> Created ACTION-255 - Propose text for CSS2.1 Issue 199 [on Tab Atkins Jr. - due 2010-08-30].
# [14:02] <mollydotcom> ScribeNick: mollydotcom
# [14:02] <Arron> I feel that potential is a better term than phantom
# [14:03] <mollydotcom> Daniel: Last issue on the radar, then we will decide to stop on these issue or not
# [14:04] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0401.html and http://lists.w3.org/Archives/Public/www-style/2010Aug/0403.html
# [14:04] <mollydotcom> table-wrapper-box
# [14:04] <fantasai> RESOLVED: Accept proposal for CSS2.1 Issue 201 with "table wrapper box" as the term
# [14:04] * gsnedders test suite in a moment then?
# [14:05] <mollydotcom> szilles and fantasai discussing vertical-align
# [14:05] <mollydotcom> szilles: undefined is fine
# [14:05] * fantasai were you planning to visit for that? :)
# [14:05] * fantasai ^ gsnedders
# [14:06] <mollydotcom> Daniel: CSS 2.1 issues freeze
# [14:07] <mollydotcom> Daniel: stop registering issues now
# [14:07] <mollydotcom> David: As long as we keep a list of them
# [14:07] <mollydotcom> dsinger_: Will likely end up in errata or moved to CSS3
# [14:08] <mollydotcom> fantasai: We are publishing a last call working draft, we are required to accept comments. FOr this round of editing, there's no reason why we shouldn't close down, publish, and consider anything else last call issues
# [14:09] <mollydotcom> fantasai: they will have four weeks to comment
# [14:09] <mollydotcom> RESOLVED: CSS 2.1 issues: FROZEN
# [14:09] <mollydotcom> (no objections, very strong support)
# [14:10] * gsnedders fantasai yeah
# [14:11] <mollydotcom> Glazou: if we have interop shown by reports, we go directly to pr
# [14:11] <mollydotcom> (no objections)
# [14:11] * fantasai gsnedders, don't know what we're talking about next, but css2.1 ts seems like a likely possibility. glazou would know
# [14:12] * fantasai yeah, that's the topic now :)
# [14:12] <mollydotcom> Glazou: Everything relies on implementation reports - completion of test suites, so let's discuss
# [14:13] <fantasai> RESOLVED: LC->PR if we have exit criteria for 2.1
# [14:13] <mollydotcom> Glazou: What remains on the radar with the test suite and when are we able to say it's ready?
# [14:13] <mollydotcom> Fantasai: we have to have "no suspected" issues, when that's complete I can publish
# [14:14] <mollydotcom> jdaggett - there are tests that don't pass in any browsers
# [14:14] <mollydotcom> dbaron: a bunch of people did respond to the tests in that list
# [14:15] <mollydotcom> jdaggett: I've actively try to go to people I thought would care but I fear they will comment
# [14:15] <mollydotcom> Glazou: at some point we have to freeze things
# [14:16] <mollydotcom> Glazou: Browser vendors: you want css2.1 published but your teams have not evaluated the tests, have not already implemeted, even if we are going to CR/PR
# [14:16] <mollydotcom> Glazou: if you want it published, we rely on your implementations. The entire thing is in your hands, not the WGs
# [14:17] <mollydotcom> Fantasai: If there's a problem with the test
# [14:17] <mollydotcom> Fantasai: Email the list, and then we will take a look at the test
# [14:17] <mollydotcom> Fantasai: THEN we will push it to the WG
# [14:17] <mollydotcom> Glazou: Not an issue with the spec
# [14:18] <mollydotcom> fantasai: info on the wiki
# [14:18] <mollydotcom> Glazou: suggest 1 Oct. for test suite
# [14:19] <mollydotcom> Deadlines: Edits should be done for next conference call
# [14:19] <mollydotcom> Bert: I'll be able to do my edits
# [14:20] <mollydotcom> dsinger, fantasai: discussing automation of tests
# [14:21] <fantasai> +jgraham and gsnedders
# [14:22] <mollydotcom> gsnedders: Opera can help provide some help with that too
# [14:23] <mollydotcom> jdaggett, dbaron: discussing tests and windows limitations
# [14:23] <mollydotcom> Jdaggett: there are some tests that don't pass on any windows implementation but do pass on other platforms
# [14:23] <dbaron> dbaron: Aaron, could you share the list of which tests pass on which browsers?
# [14:24] <mollydotcom> jdaggett: for font tests this will be hard. Bold and non-bold versus bolder/lighter
# [14:24] <fantasai> jdaggett: On windows you only have bold and nott bold
# [14:24] <fantasai> jdaggett: you need to test on e.g. MacOS to get the full range of testing
# [14:25] <fantasai> jdaggett: Windows will allow trivial passes
# [14:25] <fantasai> glazou: The test suite isn't supposed to demonstrate interop, it'e supposed to demonstrate implementability
# [14:25] <fantasai> glazou: The tests aren't conformance tests, they're spec implementability tests
# [14:25] <fantasai> steve: You're testing for interoperable implementability
# [14:26] <fantasai> jdaggett: When I say font-weight 100, it should pick the 100 weight font not the 400 weight font
# [14:26] <fantasai> jdaggett: but on Windows you only get the 400 weight font
# [14:26] <fantasai> dsinger_: The problem is what if you have two section so fthe spec that can be implemented, but not at the same time
# [14:27] <fantasai> steve: The requirement is that there exist at least 2 impls
# [14:27] <fantasai> dbaron: You can also get tests that fail in all windows implementations, and you need to find non-Windows implementations to get passes
# [14:27] <dsinger_> s/section so fthe/sections of the/
# [14:28] <fantasai> glazou: Next step is writing the implementation reports..
# [14:28] <fantasai> dbaron: Arron, can you share that list of which tests pass on which browsers?
# [14:28] <fantasai> JohnJansen: No, we can't
# [14:29] <fantasai> ChrisL: The full data is a matrix in a spreadsheet that shows which tests pass in which versions of which browsers.
# [14:29] <fantasai> JohnJansen: It's a very expensive process
# [14:30] <ChrisL> And I would like to talk to Microsoft managers to get the relevant parts of that released to the working group. It will get us out of CR earlier
# [14:30] <fantasai> glazou: For Selectors, hixie and I had to write the implementation reports ourselves
# [14:31] <fantasai> glazou: It's always the case that some Members put in more resources into the WG on some things than others
# [14:32] <fantasai> ChrisL: We wouldn't be asking MS to provide the data if you didn't already have it.
# [14:32] <fantasai> dbaron: I don't consider it worth my time to go through the test suite.
# [14:32] <fantasai> dbaron: But if you provide a set of tests that we fail, then I will review those tests.
# [14:32] <fantasai> dbaron: So could you share the list of tests that fail in at least one browser?
# [14:33] <fantasai> Arron: I've shared the lists of tests that don't pass in any browser, and those that I think are invalid
# [14:33] <fantasai> Arron: Once we decide the test suite is solid, and we're getting there with Gérard reviewing a lot of the tests,
# [14:33] <fantasai> Arron: Then when you run the tests you can look more closely at the tests you fail
# [14:34] <fantasai> howcome: dbaron has 2 points I would like to emphasis
# [14:34] <fantasai> howcome: One is that the tests are too many and give us too little
# [14:34] <fantasai> howcome: We've all found ourselves in situations doing work on behalf of other browsers.
# [14:35] <fantasai> howcome: And you have done that -- all the tests you've contributed
# [14:35] <fantasai> glazou: It's perfectly normal.
# [14:35] <fantasai> glazou: Microsoft wants 2.1 to be released ASAP, because you rely on it.
# [14:35] <fantasai> glazou: Contributing the results of the tests will speed up the process. Not contributing it will slow us down.
# [14:35] <fantasai> glazou: It's in your interest to contribut the results.
# [14:36] <fantasai> Steve: The issue isn't the test results, the issue is the implementation reports
# [14:36] <ChrisL> I would like to see Arron's list of 'tests passed by no windows browser' on the wiki, then remove tests that are passed on other platforms
# [14:36] <fantasai> Steve: So we're not asking for a contribution of test results, we're asking for contribution of to the implementation reports
# [14:36] <fantasai> Arron: These are only the HTML test results, not the XHTML tests
# [14:37] <dbaron> dbaron: So there could be additional tests that don't pass in any browser.
# [14:38] <fantasai> JohnJansen: We shared a lot of the data we have. The list of suspected invalid tests, and the list of tests that don't match.
# [14:38] <fantasai> s/match/ pass/
# [14:38] <fantasai> howcome: Can you provide the list of tests that fail in any one browser?
# [14:39] <fantasai> glazou: A few years ago the only company interested in print was YesLogic.
# [14:39] <fantasai> glazou: And afterward HP
# [14:39] <fantasai> glazou: But not the other vendors were interested in print
# [14:39] <fantasai> glazou: But we contributed time to working on those specs
# [14:39] <fantasai> JohnJansen: The tests we contributed are available to anyone to run
# [14:40] <fantasai> JohnJansen: We're not hiding anything.
# [14:40] <fantasai> Arron: It's our time and money that we've put into creating the test results
# [14:41] <fantasai> dsinger_: I'm grateful if he gives me the data, I don't think I can ask him to do that work for me and save me that time and money.
# [14:41] <fantasai> JohnJansen: I wouldn't want you to trust our results either.
# [14:43] <fantasai> dsinger_: Can we keep a page on the wiki of tests that are suspected to be wrong?
# [14:44] <fantasai> ACTION: fantasai make said wiki page
# [14:44] * trackbot noticed an ACTION. Trying to create it.
# [14:44] * RRSAgent records action 12
# [14:44] <trackbot> Created ACTION-256 - Make said wiki page [on Elika Etemad - due 2010-08-30].
# [14:44] * Parts: howcome (howcome@213.236.208.247)
# [14:45] <fantasai> fantasai: People can start on implementation reports now. I can even throw out a beta 4 on Monday
# [14:45] <fantasai> fantasai: But whenever I publish a release now I list all tests that have changed
# [14:46] <fantasai> fantasai: So between releases you'd only have a handful of test results you might need to run
# [14:46] <fantasai> glazou: I am requesting browser vendors to start implementation reports now.
# [14:47] <fantasai> Arron: It takes 16 hours to run the tests by hand
# [14:47] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [14:47] <fantasai> dsinger asks about automating them
# [14:47] <fantasai> fantasai and Arron say it will take much longer to automate them
# [14:48] <fantasai> dsinger_: How good is the coverage of the test suite
# [14:48] <fantasai> gsnedders: Automating the tests isn't just a one time thing, because everyone would want to run them as regression tracking
# [14:48] <fantasai> gsnedders: if they're manuall, they won't be run very often
# [14:48] <fantasai> gsnedders: Automating the tests wont' just save time once
# [14:49] <fantasai> jdaggett: For CSS3 modules do we have to follow this pattern?
# [14:50] * fantasai answers that
# [14:51] <fantasai> glazou: If we don't get your implementation reports, things are going to slow down.
# [14:51] <fantasai> glazou: It relies on you.
# [14:51] <fantasai> glazou: The sooner we get it, the better.
# [14:51] * gsnedders "YOUR WORKING GROUP NEEDS YOU!"
# [14:51] <fantasai> dsinger_: Coverage?
# [14:51] <fantasai> gsnedders++
# [14:52] <fantasai> dbaron: There's questions of how you measure test coverage
# [14:52] <fantasai> dbaron: you'd have to measure e.g. code coverage
# [14:52] <glazou> gsnedders: exactly.
# [14:54] <fantasai> fantasai explains what we have
# [14:54] <fantasai> dbaron: The spec has lots and lots of interactions among features, many of which are not obvious
# [14:54] <fantasai> dbaron: We don't have good coverage of those interactions.
# [14:55] <fantasai> dbaron: There are sentences in the spec that require hundreds or thousands of tests just for that sentence. And we don't have that coverage.
# [14:55] <fantasai> glazou: Anything else on the test suite and the roadmap?
# [14:56] <fantasai> glazou: I remind you that the goal is still PR before the end of the year.
# [14:56] <fantasai> glazou: This is important for both the WG and the W3C itself.
# [14:56] <fantasai> glazou: We started this roughly ten years ago
# [14:56] <fantasai> ChrisL: If the CSS2.1 can get to PR by the end of the year, there's still a chance that SVG 1.1 can normatively point to CSS2.1.
# [14:56] <fantasai> ChrisL: I'd like that to happen.
# [14:57] <fantasai> glazou: if we move 2.1 to PR, Selectors can move to REC, we solve a lot of dependencies.
# [14:57] <ChrisL> s/1.1/1.1 Second Edition/
# [14:57] <fantasai> JohnJansen: If we got to PR by the end of the year, does that put REC at the end of January?
# [14:59] <fantasai> scheduled charter discussion for after the break
# [14:59] <fantasai> <br/>
# [15:01] * Quits: dstorey (dstorey@213.236.208.247) (Quit: dstorey)
# [15:02] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [15:08] * Joins: dstorey (dstorey@193.213.156.111)
# [15:09] * Joins: dstorey_ (dstorey@213.236.208.247)
# [15:10] * Joins: szilles (chatzilla@213.236.208.247)
# [15:11] * Quits: CesarAcebal (acebal@213.236.208.247) (Quit: CesarAcebal)
# [15:12] * Quits: dstorey (dstorey@193.213.156.111) (Ping timeout)
# [15:12] * Quits: szilles (chatzilla@213.236.208.247) (Connection reset by peer)
# [15:14] * Quits: dstorey_ (dstorey@213.236.208.247) (Ping timeout)
# [15:20] * Joins: szilles (chatzilla@213.236.208.247)
# [15:26] <glazou> Next topic is WG Charter
# [15:26] <JohnJansen> note: answer to earlier question from JohnJansen about REC at end of January: Yes.
# [15:29] * Joins: dsinger (dsinger@213.236.208.247)
# [15:29] * Quits: jdaggett (jdaggett@213.236.208.247) (Connection reset by peer)
# [15:29] * Quits: glazou (glazou@213.236.208.247) (Connection reset by peer)
# [15:29] * Quits: dsinger_ (dsinger@213.236.208.247) (Connection reset by peer)
# [15:29] * Quits: tantek (tantek@213.236.208.247) (Connection reset by peer)
# [15:29] * Joins: glazou (glazou@213.236.208.247)
# [15:29] * Joins: tantek (tantek@213.236.208.247)
# [15:29] * Joins: jdaggett (jdaggett@213.236.208.247)
# [15:29] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [15:29] * Joins: szilles (chatzilla@213.236.208.247)
# [15:29] * Joins: dstorey (dstorey@213.236.208.247)
# [15:30] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (No route to host)
# [15:31] <fantasai> Topic: Charter
# [15:31] <fantasai> glazou: Current topic ends at the end of November
# [15:31] <fantasai> glazou: We need to discuss the charter itself, goals, deliverables, scope, etc.
# [15:31] <fantasai> glazou: Make sure everyone in the WG agrees
# [15:31] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [15:32] <glazou> http://www.w3.org/Style/2008/css-charter
# [15:32] <fantasai> glazou: http://wiki.csswg.org/planning/charter-2008
# [15:33] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [15:34] <fantasai> fantasai: Propose to add Media Queries to 2007 snapshot text and call it Snapshot 2010
# [15:34] <fantasai> WG reviews the Scope section of CSS Charter
# [15:35] * Joins: ChrisL (ChrisL@128.30.52.169)
# [15:35] <fantasai> Everyone happy with 1.0
# [15:35] <ChrisL> rrsagent, here
# [15:35] <RRSAgent> See http://www.w3.org/2010/08/23-CSS-irc#T13-32-56
# [15:36] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [15:36] <tantek> note to ChrisL - http://dev.w3.org/csswg/css3-color/ has been updated per your request to make edits to Dependencies section, replacing "predefined" with color keywords, and removal of n/a rules in suggested style sheet that were using dropped attr() function.
# [15:36] <fantasai> Now looking at 1.1 -- list of modules
# [15:37] <fantasai> glazou: I think we need to shuffle soem of these items
# [15:37] * Joins: szilles (chatzilla@213.236.208.247)
# [15:37] <fantasai> glazou: We should preserve CSS2.1?
# [15:38] <fantasai> ChrisL: How about a 2 month extension to the current charter, then move it into maintenance
# [15:38] <fantasai> Tantek: And consider 2.1 Errata as the work item
# [15:40] <fantasai> Going through the list one at a time
# [15:40] <fantasai> CSS2.1 - expect PR by end of year
# [15:41] <fantasai> CSS3 Backgrounds and Borders - CR within 1.5 months, have implementations, need test suite, no PR by end of year, likely to REC within next period
# [15:41] <fantasai> CSS3 Color - PR by end of this year
# [15:41] <fantasai> CSS Mobile Profile - nobody here cares
# [15:42] <glazou> http://www.w3.org/TR/css-mobile/
# [15:42] <fantasai> It's in CR right now
# [15:43] <fantasai> No testing done
# [15:43] <fantasai> Tantek, Bert: To exit CR, you need two complete implementations.
# [15:44] <fantasai> dsinger: Send OMA a liaison asking if they have finished it
# [15:44] <fantasai> dbaron: It depends on specs not in CR
# [15:45] <fantasai> fantasai: css3-marquee is in CR right now
# [15:46] * Peter` is now known as Peter
# [15:46] * Joins: miketaylr (miketaylr@38.117.156.163)
# [15:46] <fantasai> RESOLVED: Move to low priority, send OMA liaison about this
# [15:47] <fantasai> CSS Namespaces - Almost ready for PR, waiting for a pass on one test
# [15:47] <fantasai> remains high priority
# [15:47] <fantasai> CSS Object Model View - ask anne
# [15:48] <dbaron> I'd say cssom-view is medium priority, but anyway...
# [15:48] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [15:49] * Quits: Doofl (mstensho@213.236.208.247) (Quit: Leaving.)
# [15:50] <fantasai> CSS Paged Media Level 3 - needs a lot more work to get to LC, then back to CR
# [15:51] <fantasai> high priority for several industries, but we are low on resources b/c we the editors are booked with other things
# [15:51] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [15:51] <fantasai> assigned medium priority right now
# [15:51] * Joins: szilles (chatzilla@213.236.208.247)
# [15:51] <fantasai> CSS Snapshot 2007 - rename to CSS Snapshots
# [15:51] <fantasai> keep high priority
# [15:51] <fantasai> CSS Variables - drop to low priority -- hasn't changed in 2 years
# [15:52] <fantasai> dbaron: Some of what stopped variables' progress is a misunderstanding
# [15:52] <fantasai> dbaron: We wanted more data on it, to show that we're going in the right direction
# [15:53] <fantasai> dbaron: rather than using up core bits of syntax wrongly
# [15:53] <fantasai> dbaron: That got interpreted as we don't want it
# [15:53] * Joins: ChrisL (ChrisL@128.30.52.169)
# [15:53] <fantasai> howcome: There's also complexity -- e.g. dom access to variables is more complicated than constants
# [15:53] <fantasai> howcome: It's not just a question of signing up an editor
# [15:54] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [15:54] * Quits: glazou (glazou@213.236.208.247) (Connection reset by peer)
# [15:54] * Quits: jdaggett (jdaggett@213.236.208.247) (Connection reset by peer)
# [15:54] * Joins: dsinger (dsinger@213.236.208.247)
# [15:54] * Quits: tantek (tantek@213.236.208.247) (Connection reset by peer)
# [15:54] * Quits: dstorey (dstorey@213.236.208.247) (No route to host)
# [15:54] <fantasai> Daniel: I could do the editorial work, ibut I need implementors who want to do this. [A
# [15:54] * Joins: glazou (glazou@213.236.208.247)
# [15:54] * Joins: tantek (tantek@213.236.208.247)
# [15:54] * Joins: dstorey (dstorey@213.236.208.247)
# [15:54] * Joins: jdaggett (jdaggett@213.236.208.247)
# [15:54] * Quits: szilles (chatzilla@213.236.208.247) (Connection reset by peer)
# [15:55] * Joins: szilles (chatzilla@213.236.208.247)
# [15:55] <fantasai> CSS Variables dropped to medium
# [15:55] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (No route to host)
# [15:55] <fantasai> Media Queries remains high priority
# [15:55] <fantasai> Selectors -> maintenance mode
# [15:55] <fantasai> Need to create a new one for maintenance
# [15:56] <fantasai> new group
# [15:56] <fantasai> glazou: Selectors 4?
# [15:56] <fantasai> dbaron, Tantek: Put it on low or medium priority
# [15:56] <fantasai> fantasai, Tab: We have items to work on, but it's not a high priority
# [15:56] * Quits: szilles (chatzilla@213.236.208.247) (Connection reset by peer)
# [15:57] <fantasai> moved to low priority
# [15:57] <fantasai> Selectors 4
# [15:57] * Joins: szilles (chatzilla@213.236.208.247)
# [15:58] <fantasai> dbaron: HTML5 defines when CSS3 Selectors and CSS3 UI selectors apply to HTML
# [15:59] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [15:59] * Joins: ChrisL (ChrisL@128.30.52.169)
# [15:59] <fantasai> dbaron: But does not introduce new ones
# [15:59] <fantasai> IIRC
# [16:00] * ChrisL is now known as ChrisL2
# [16:00] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [16:00] <TabAtkins_> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#pseudo-classes
# [16:02] <fantasai> CSS3 UI added as high priority, edited by Tantek
# [16:04] <fantasai> CSS3 Basic Box Model
# [16:04] <fantasai> stays at medium priority
# [16:04] <fantasai> CSS3 Fonts
# [16:04] <fantasai> high priority
# [16:04] <fantasai> jdaggett aiming for LC by end of the year
# [16:04] <fantasai> hopefully REC by end of next year
# [16:04] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [16:05] * Joins: szilles (chatzilla@213.236.208.247)
# [16:06] <fantasai> CSS3 Generated and Replaced Content
# [16:07] <fantasai> low priority
# [16:07] <fantasai> Tab Atkins
# [16:07] <fantasai> CSS Grid Positioning
# [16:07] <fantasai> low priority
# [16:08] <fantasai> jdaggett: I think there's a dependency from vertical text on Grid
# [16:08] <fantasai> fantasai disagrees
# [16:09] <fantasai> glazou: kept in charter, low priority
# [16:09] <fantasai> CSS Marquee -
# [16:09] <fantasai> Tab: That's only for mobile phones
# [16:09] <fantasai> Bert: That's indeed only for mobiel phones, the desktop browsers didn't want it
# [16:10] <ChrisL2> ask OMA
# [16:10] <fantasai> Bert: Maybe send in same liaison to OMA
# [16:10] <fantasai> low priority
# [16:10] <Peter> WebKit implements a large part of it in Chrome/Safari
# [16:10] <fantasai> CSS Multi-column Layout -
# [16:10] <fantasai> high priority
# [16:10] <fantasai> CSSOM - ask Anne
# [16:10] <fantasai> CSS Ruby -
# [16:11] <fantasai> fantasai: medium priority; Mozilla is implementing
# [16:11] <fantasai> CSS Template Layout -
# [16:11] <fantasai> Tab: keep at medium
# [16:11] <fantasai> CSS Transforms -
# [16:11] <fantasai> high priority
# [16:11] <fantasai> CSS Transitions -
# [16:11] <fantasai> high priority
# [16:12] <fantasai> CSS Values and Units
# [16:12] <fantasai> fantasai: medium priority
# [16:12] <fantasai> glazou: low
# [16:12] <fantasai> dbaron: high
# [16:13] <fantasai> dbaron: I'd like to see it in CR by the end of next year
# [16:13] <fantasai> howcome doesn't want to finish it
# [16:15] <fantasai> howcome: What happens if e.g. grid module needs a new unit?
# [16:15] <fantasai> jdaggett: rev the module
# [16:15] <fantasai> fantasai: or define it in the grid module
# [16:15] <fantasai> -> high priority
# [16:15] <fantasai> CSS3 Extended Box Module
# [16:15] <fantasai> discuss low or dropped?
# [16:16] <fantasai> dropped.
# [16:16] <fantasai> CSS Flexbox
# [16:16] <fantasai> medium priority
# [16:17] <fantasai> http://wiki.csswg.org/planning/charter-2010
# [16:17] <fantasai> Please update!
# [16:17] <fantasai> CSS GCPM
# [16:17] <fantasai> howcome: We have 2 implementations
# [16:17] <fantasai> dbaron and fantasai are skeptical of whether it's ready
# [16:18] * Joins: kubal (Kuba@195.116.30.193)
# [16:18] <fantasai> for CR
# [16:19] <fantasai> fantasai: I think it should be at least medium priority, but it's not ready for CR
# [16:19] <fantasai> fantasai: Much of it is underdefined
# [16:21] <fantasai> ChrisL: high priority
# [16:21] <fantasai> jdaggett: We have a lot of high priority items
# [16:21] <fantasai> JohnJansen: So what's the definition of high priority?
# [16:21] <fantasai> glazou: We need to list everything we want to work on
# [16:22] <fantasai> glazou: The high priority ones are the ones that we need to be in a good state, that the AC reps will check on
# [16:22] <fantasai> GCPM -> medium
# [16:22] <fantasai> CSS Lists
# [16:22] <fantasai> medium
# [16:22] <fantasai> CSS Tables
# [16:22] <fantasai> glazou: Any work done on Tables?
# [16:22] <fantasai> dbaron: Lots of work 2 years ago, but nothing since really
# [16:23] <fantasai> Alex: That was Markus. The work being done was trying to define existing behavior
# [16:23] <fantasai> dbaron: I would go for low priority, and keep it on the list. It's very similar to 2.1 maintenance -- it's an issue we deferred it because it was difficult, but it's 2.1 level work
# [16:24] <fantasai> dbaron, alex: if someone comes to work on it, should be able
# [16:24] <fantasai> to
# [16:24] <fantasai> CSS3 Text and CSS3 Text Layout
# [16:24] <fantasai> medium priority
# [16:24] <fantasai> needed for EPUB in Japan
# [16:24] <fantasai> glazou: Anything else not in the list?
# [16:25] <fantasai> Tantek: CSS4 UI
# [16:25] <fantasai> glazou: We can just write CSS UI under high priority, and nott list the level
# [16:26] <fantasai> dbaron: We should add Transforms 3D to the list
# [16:26] <fantasai> dsinger: add it to low priority
# [16:26] <fantasai> dbaron: We're implementing 3D, so we're getting to 2 implementations
# [16:26] <fantasai> dbaron: suggest medium
# [16:27] <fantasai> howcome: CSS Backgrounds and Borders Level 4
# [16:30] <fantasai> jdaggett: Line Box module?
# [16:30] <fantasai> jdaggett: I'd like to have something that's clearer on how text with different baselines is aligned
# [16:31] <fantasai> CSS Line Box
# [16:31] <fantasai> -> low priority
# [16:31] <fantasai> dbaron: The current draft is Michel Suignard's draft from 2001
# [16:31] <fantasai> dbaron: Plus a half-finished pile of edits I made to make it match 2.1 better
# [16:32] <fantasai> dbaron: And then some new features, we may or may not want
# [16:32] <fantasai> Tab: CSS3 Images
# [16:32] <fantasai> fantasai: we probably want that high priority
# [16:33] * Joins: nimbupani (nimbupani@24.22.131.46)
# [16:33] <fantasai> Bert: Speech?
# [16:34] <fantasai> dbaron: There's an incubator group working on speech
# [16:34] <fantasai> dbaron: Not sure if they'd be interested in this
# [16:35] <fantasai> kept off
# [16:35] <fantasai> dbaron: Scoping?
# [16:36] <fantasai> dbaron: HTML5 has scoped style sheets. We might want to put it back in the charter in case we need to work on it
# [16:36] <fantasai> dbaron: It's probably a feature at risk in HTMl5
# [16:36] <fantasai> s/Line Box/Line Layout/
# [16:37] * Joins: smfr (smfr@72.25.91.23)
# [16:37] <fantasai> fantasai: style attribute, high priority
# [16:38] <fantasai> ChrisL: Other things to talk about from the old charter
# [16:38] <fantasai> ChrisL: We should produce a report on the old charter, what we accomplished on the high priority list
# [16:38] <fantasai> Chris: how close they get to REC
# [16:39] <fantasai> ChrisL: Wrt liaisons, CDF closed
# [16:40] <fantasai> ChrisL: Also, I suggest having two groups, one where we have dependencies and one where we don't
# [16:40] * Quits: ChrisL2 (ChrisL@128.30.52.169) (Ping timeout)
# [16:40] <fantasai> Dependencies - HTML, SVG, WebApps, Webfonts
# [16:41] <fantasai> ChrisL: And add MathML
# [16:41] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [16:41] <fantasai> Daniel: Make maintenance list with 2.1 and Selectors, say that any other documents that go to REC will switch to maintenance
# [16:42] * Joins: szilles (chatzilla@213.236.208.247)
# [16:43] <fantasai> ACTION: Bert, glazou, CHrisL, Peter - draft charter 2010
# [16:43] * trackbot noticed an ACTION. Trying to create it.
# [16:43] <trackbot> Sorry, couldn't find user - Bert,
# [16:43] * RRSAgent records action 13
# [16:44] * Joins: SteveZ2 (chatzilla@213.236.208.247)
# [16:44] <fantasai> Discussed changing conference times
# [16:44] <fantasai> telecon
# [16:45] <fantasai> once a month to allow people in other countries to join
# [16:45] <fantasai> ChrisL: Also, is 1 hr/wk enough?
# [16:45] <fantasai> glazou: I think what we have now is a good compromise
# [16:46] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [16:46] <fantasai> dsinger: I suggest we put 5-minute decision-and-cut items at the front of the agenda
# [16:46] * SteveZ2 is now known as szilles
# [16:46] <fantasai> dsinger: and put technical discussions after that
# [16:47] <smfr> +1
# [16:47] <fantasai> glazou: It's very difficult for us co-chairmen to know if we're about to close on something
# [16:47] <fantasai> glazou: Sometimes we seem close to consensus, and then the discussion goes *rollercoaster sign*
# [16:48] <fantasai> dbaron: Might be a little extreme, but.. try and put things on the agenda
# [16:48] <fantasai> dbaron: ask people to respond by email if they have additional points to discuss
# [16:48] <fantasai> glazou: Once 2.1 is out, things are going to change.
# [16:49] <fantasai> dbaron: It will encourage people to read the agenda before the telecon and figure out what they think about things
# [16:49] <fantasai> glazou: I think the past few months the agenda was a collection of potential discussion topics, but reality it was 2.1, period.
# [16:49] * Joins: ChrisL (ChrisL@128.30.52.169)
# [16:49] <fantasai> alexmog: If we defer things for months, people working on css3 would take their own direction
# [16:49] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [16:49] <fantasai> glazou: we don't have unlimited resources, sorry
# [16:49] <fantasai> glazou: we do our best
# [16:50] <fantasai> 5 minutes break, then viewport discussion
# [16:50] * Joins: szilles (chatzilla@213.236.208.247)
# [16:50] * Joins: anne5 (annevk@84.208.74.81)
# [16:50] <fantasai> ??? introduces himself
# [16:50] <fantasai> working at opera 10+ years
# [16:50] <fantasai> ???? introduces himself
# [16:51] <TabAtkins_> First ??? is Rune, second ??? is Oyvind.
# [16:51] <fantasai> I'm Andre??, I lead our developer relations
# [16:51] * anne5 wonders if people are going out for food later
# [16:51] <anne5> Andreas
# [16:51] <fantasai> I'm just here to listen
# [16:51] <fantasai> anne5, yes, see howcome's email
# [16:51] <TabAtkins_> anne5: Yeah, we are. There's an email about it from Hakon.
# [16:51] * anne5 just arrived; will check
# [16:51] * fantasai welcome
# [16:51] <fantasai> 5 minutes break
# [16:52] <smfr> apologies, i won't be able to dial in for the viewport discussino
# [16:52] <smfr> i have to go and get some stitches removed
# [16:55] * anne5 ooh, sounds nice :)
# [16:56] <smfr> http://ajaxian.com/archives/the-css3-song
# [16:58] <fantasai> Topic: Viewport Proposal
# [16:58] <fantasai> Rune: I wrote an internal spec to explain how we implement the viewport meta tag that Safari implements
# [16:58] <fantasai> Rune: I've also written a propsoed CSS syntax for that functionality
# [16:58] <fantasai> Rune: Here's the URL to the proposal
# [16:59] <dbaron> http://people.opera.com/rune/TR/ED-css-viewport-20100806/
# [16:59] <fantasai> http://people.opera.com/rune/TR/ED-css-viewport-20100806
# [16:59] * Joins: howcome (howcome@213.236.208.247)
# [16:59] <alexmog> http://people.opera.com/rune/TR/ED-css-viewport-20100806/
# [16:59] <fantasai> Rune: Not ging to go over proposal in detail, just have a couple of slides
# [16:59] * Joins: SteveZ2 (chatzilla@213.236.208.247)
# [16:59] <fantasai> Rune: Problem is that in mobiel browsers you have a very narrow viewport.
# [17:00] <fantasai> Rune: If you format the page with the viewport as the ICB, most documents on the Web will look really bad
# [17:00] <fantasai> Rune: What mobile browsers now do is use a different ICB, more like a desktop width
# [17:00] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [17:01] <fantasai> Rune: Since the desktop width is being used, if page authors want to make pages specifically for smaller screens, they need to override that desktop width that the browser uses
# [17:01] * SteveZ2 is now known as szilles
# [17:01] <fantasai> Rune: THe current status is that Apple introduced a viewport meta tag
# [17:01] <fantasai> Rune: Several browser vendors have made their own implementation
# [17:01] <fantasai> Rune: Here's an example, you can specify a device width and set the zoom scale
# [17:01] * smfr is now known as smfr_afk
# [17:02] <fantasai> Bert: You set the initial zoom. That's the reader's business, not the author
# [17:02] <fantasai> Bert: It's the wrong way around. If I want a specific width, I should just set this.
# [17:02] <fantasai> Tantek: I strongly agree with your problem statement.
# [17:02] <fantasai> Tantek: But what does this get you that max-width on the root element does not
# [17:02] <fantasai> ?
# [17:03] <fantasai> fantasai: (or min-width?)
# [17:03] <fantasai> Tantek: I think the meta tag idea was just dumb
# [17:03] <fantasai> Tantek: If the author has set a max-width, the device didn't need to zoom out any more
# [17:03] <fantasai> Tantek: There's no need for the meta tag
# [17:04] <fantasai> Tantek: This was bad design by someone who did not understand how CSS works.
# [17:04] <fantasai> Tantek: I'm addressing your third point -- the need for the author saying that a document is made to fit for smaller screen sizes
# [17:04] <fantasai> dbaron: I think that's not entirely true.
# [17:05] <fantasai> dbaron: Another problem that come up with pages that use this is pages that have a lot of text.
# [17:05] <fantasai> dbaron: You really just want to read the text. You don't want to zoom out, and then zoom in to read the text.
# [17:05] <fantasai> dbaron: It doesn't matter how wide the page is. You want the font size to be readable on the device.
# [17:05] <fantasai> dbaron: In some cases you have a layout that works for anything from 150 to 400 pixels
# [17:06] <fantasai> dbaron: e.g. i want to read a newspaper article on a mobile phone
# [17:06] <fantasai> dbaron: I just want the text readable. I don't necessarily want to set a max-width.
# [17:06] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [17:07] <fantasai> Alex: fixed positioning is also not fixed by max-width
# [17:08] <fantasai> Tantek: I agree that dbaron's use case is valid. But it's not the problem solved by viewport meta tag, which *is* solved by max-width.
# [17:08] <fantasai> Tantek: I would like to see better guidance, with the UA understanding and using and trusting max-width on the root element.
# [17:12] <fantasai> Tantek: That solves the common use case.
# [17:12] * Joins: szilles (chatzilla@213.236.208.247)
# [17:12] <fantasai> glazou: Let's hear out the rest of the presentation, and we'll discuss that afterwards
# [17:13] <fantasai> Rune: Proposed syntax is to standardize the viewport meta functionality in CSS syntax
# [17:14] <fantasai> Rune: Proposal is an @viewport block similar to @page block
# [17:14] <fantasai> Rune: Properties include width, hieght, minimum-scale, maximum-scale, etc.
# [17:14] <fantasai> glazou: I suggest changing "initial-scale" to "zoom"
# [17:15] <fantasai> Rune: Issues include fixed positioning
# [17:15] <fantasai> Rune: Fixed positioning is defined relative to the viewport
# [17:15] <fantasai> Rune: with a containing block that matches the ICB
# [17:16] <fantasai> Rune: The actual viewport here won't be the same as the ICB
# [17:16] <fantasai> alexmog: That's why we have this concept of a virtual viewport
# [17:16] <fantasai> Rune explains how the small viewport moves around the virtual viewport, and then pushing it beyond that boundary causes the content to jump
# [17:17] <fantasai> Rune: My propose defines an extra viewport. I'm not sure if it's a good idea to call it the viewport or not.
# [17:17] <fantasai> Rune: Other issues are, is this out-of-scope for CSSWG?
# [17:17] <fantasai> Rune: e.g. the scaling values
# [17:18] <fantasai> glazou: I think it's in scope, just question of whether we want to work on it
# [17:18] <fantasai> Rune: You can also argue that aturhos should make pages that look good on all devices in the first place
# [17:19] <fantasai> Bert: The problem with this it that it breaks all pages that are designed to work on mobile browsers
# [17:19] <fantasai> Bert: My mobile browser worked fine, honored media queries, etc.
# [17:19] <fantasai> Bert: But on Safari it doesn't work.
# [17:19] <fantasai> Bert: I had to add this extra thing to make them readable.
# [17:19] <fantasai> Bert: The ones that used to be readable on devices, no longer are readable.
# [17:20] <fantasai> glazou: What is the interaction with Media Queries?
# [17:20] <fantasai> Rune: The width and height media queries will match the ICB
# [17:20] <fantasai> glazou: So what is the parsing order?
# [17:22] * smfr_afk is now known as smfr
# [17:22] <fantasai> fantasai: Paged media has the same problem with @page { size: ... }, see spec text there
# [17:23] <fantasai> fantasai: I share dbaron and bert's concerns about universal design
# [17:23] <fantasai> dbaron: i tried to design a page for iPhone both on landscape and portrait mode, and failed
# [17:24] <fantasai> dbaron: The logic of the implementation in Safari is somehow wrong
# [17:24] <fantasai> Andreas: Does it behave differently if load it in portrait mode first vs landscape mode first?
# [17:26] <fantasai> +smfr over phone
# [17:27] <fantasai> Tantek: I said that for the fixed width use case, the author can width or max-width today.
# [17:27] <fantasai> smfr: I filed a bug on Apple, we just need to fix that.
# [17:27] <fantasai> Tantek: For the device-width case, I do believe it belongs in CSS
# [17:28] <fantasai> Tantek: I'll state for the record I proposed @viewport in 2004, and it was rejected :)
# [17:28] <fantasai> Simon: I've been looking at feedback on the mailing list
# [17:29] <fantasai> Simon: A problem is that a lot of the specs refer to a viewport
# [17:29] <fantasai> Simon: This proposeal introduces 2 viewports, and you need to specify which viewport is being talked about
# [17:29] <fantasai> Simon: And also the interaction between the 2 viewports needs to be specified.
# [17:29] <fantasai> Rune: Yeah, I'm not sure if "viewport" is the right name
# [17:30] <fantasai> Rune: esp. fixed positioning
# [17:30] <fantasai> Simon: Fixed positioning is really difficult
# [17:30] <fantasai> Simon: It gets really weird, especially with scaling
# [17:30] <fantasai> Simon: Another concern I have is, I'm worried that we're settling on an implementation detail
# [17:31] <fantasai> Simon: Some of them do real scrolling behavior, others do panning
# [17:31] <fantasai> Simon: I'm worried that this is trying to specify something that different UAs will want to do differently.
# [17:31] <fantasai> Tantek: There's wording around the way that overflow is specified in CSS that provides a lot of flexibility in how UAs do "scrolling"
# [17:31] <fantasai> Tantek: I would like to see similar flexibility in this case as well.
# [17:32] <fantasai> Tantek: So I think it's possible to address your concern.
# [17:32] * Joins: lstorset (lstorset@213.236.208.247)
# [17:32] <fantasai> dbaron: So, with regards to how much of this to specify
# [17:32] * Quits: lstorset2 (lstorset@213.236.208.247) (Quit: Leaving.)
# [17:32] <fantasai> dbaron: I think one of the criteria of how much to specify is what's going to break web content if someone else decides to go do it differently.
# [17:33] <fantasai> dbaron: I think for some of the things you metnioned in CSSOM View, there's only one way that'll make e.g. events work right
# [17:33] <fantasai> wrt clientX, etc.
# [17:33] <fantasai> dbaron: You have to go with the assumptions the pages are making
# [17:33] <fantasai> Simon: Another thing is what authors need
# [17:34] <fantasai> Simon: e.g. some use cases need getClientRects to be relative to the visual viewport
# [17:34] * Quits: lstorset (lstorset@213.236.208.247) (Quit: Leaving.)
# [17:34] <fantasai> Rune: I think in most cases you want things relative to the layout viewport
# [17:35] <fantasai> Rune: I see the visual viewport as a peephole over the layout viewport
# [17:36] * Joins: tantek_ (tantek@213.236.208.247)
# [17:36] * Quits: tantek (tantek@213.236.208.247) (Connection reset by peer)
# [17:36] * Quits: glazou (glazou@213.236.208.247) (Connection reset by peer)
# [17:36] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [17:36] * Joins: dsinger (dsinger@213.236.208.247)
# [17:36] * Quits: jdaggett (jdaggett@213.236.208.247) (Connection reset by peer)
# [17:36] * Quits: dstorey (dstorey@213.236.208.247) (Connection reset by peer)
# [17:36] * tantek_ is now known as tantek
# [17:36] * Joins: glazou (glazou@213.236.208.247)
# [17:36] * Joins: dstorey (dstorey@213.236.208.247)
# [17:36] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (No route to host)
# [17:36] * Joins: jdaggett (jdaggett@213.236.208.247)
# [17:36] * Joins: TabAtkins_ (chatzilla@213.236.208.247)
# [17:36] <smfr> gotta go
# [17:36] * Quits: smfr (smfr@72.25.91.23) (Quit: smfr)
# [17:37] * Quits: JohnJansen (qw3birc@128.30.52.28) (Ping timeout)
# [17:37] <fantasai> Simon: I would survey current mobile browsers and see what they do in terms of scorlling, clientrects, etc.
# [17:37] <fantasai> Rune: I have a comment about the scale values.
# [17:38] <fantasai> Rune: The constraining procedure that has been taken from the Apple implementations
# [17:38] <fantasai> Rune: they alter the effect of the width and height values
# [17:38] <tantek> for the record - my original thoughts on styling the viewport (from 1998!) http://lists.w3.org/Archives/Public/www-style/1998Sep/0063.html and my proposal for @viewport with width and height properties from 2004: http://lists.w3.org/Archives/Public/www-style/2004May/0294.html
# [17:39] * Quits: mollydotcom (mollyh@213.236.208.247) (Client exited)
# [17:40] * Joins: mollydotcom (mollyh@213.236.208.247)
# [17:40] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
# [17:40] <fantasai> fantasai says some stuff
# [17:42] <fantasai> about how allowing fixed sizes but not ranges is bad
# [17:42] * Joins: ChrisL (ChrisL@128.30.52.169)
# [17:44] <fantasai> Tantek: We could put this in CSS4 UI
# [17:45] <fantasai> fantasai: or make a new module
# [17:45] <fantasai> Rune: If we remove the CSS syntax, what I have is the viewport meta tag
# [17:45] <fantasai> Tantek: How soon would you implement this?
# [17:46] <fantasai> Rune: Well, we have to support the meta tag. We don't have any pressing reason to support @viewport
# [17:46] <fantasai> Rune: It doesn't take too much time to implement it, but that depends on internal priorities
# [17:46] <fantasai> howcome: I think the approach makes sense
# [17:46] <fantasai> howcome: The big question is WebKit, what are they going to do
# [17:46] <fantasai> dsinger: We're happy to discuss it
# [17:48] <fantasai> glazou: My personal opinion is that it should be its own module.
# [17:48] <fantasai> glazou: Should we add it to the scope of the new charter?
# [17:48] <fantasai> howcome: Yes
# [17:50] <fantasai> Tantek: Feels like something good to whiteboard during a break
# [17:50] <fantasai> glazou: Should we add that to the charter?
# [17:51] <fantasai> fantasai: yes
# [17:51] <fantasai> what to call it?
# [17:51] <fantasai> CSS Viewport?
# [17:51] <fantasai> CSS Device Adaptation?
# [17:51] <fantasai> steve: put it in the charter for IPR commitments
# [17:52] <fantasai> Tantek: I think there's a level of urgency here
# [17:52] <fantasai> Steve: So the anser is, IPR commitments apply only to things that become REC.
# [17:53] <fantasai> Steve: There are two points where you can issue a call for exclusions. first one is FPWD, and the other is CR
# [17:54] * Quits: dstorey (dstorey@213.236.208.247) (Quit: dstorey)
# [17:54] * Joins: Curt` (DorkeyDear@75.10.129.150)
# [17:55] * ChrisL is now known as ChrisL3
# [17:55] <fantasai> fantasai: So, Rune, will you edit the spec?
# [17:55] <fantasai> Rune is hesitant
# [17:55] * Quits: jdaggett (jdaggett@213.236.208.247) (Quit: jdaggett)
# [17:56] <fantasai> RESOLVED: CSS Device Adaptation added to charter at medium priority, Rune to edit along with someone from Apple
# [17:58] * Quits: mollydotcom (mollyh@213.236.208.247) (Quit: mollydotcom)
# [17:59] * Quits: nimbupani (nimbupani@24.22.131.46) (Quit: nimbupani)
# [17:59] * Joins: dstorey (dstorey@213.236.208.247)
# [18:00] * Quits: TabAtkins_ (chatzilla@213.236.208.247) (Ping timeout)
# [18:00] * Quits: glazou (glazou@213.236.208.247) (Quit: glazou)
# [18:03] * Joins: dsinger_ (dsinger@213.236.208.247)
# [18:03] * Quits: dsinger (dsinger@213.236.208.247) (Connection reset by peer)
# [18:03] * Quits: tantek (tantek@213.236.208.247) (No route to host)
# [18:03] * dsinger_ is now known as dsinger
# [18:03] * Joins: tantek (tantek@213.236.208.247)
# [18:03] * Quits: Arron (arronei@213.236.208.247) (Ping timeout)
# [18:04] <fantasai> meeting closed
# [18:05] * Quits: howcome (howcome@213.236.208.247) (Ping timeout)
# [18:05] * Quits: dsinger (dsinger@213.236.208.247) (Quit: dsinger)
# [18:06] * Quits: szilles (chatzilla@213.236.208.247) (Ping timeout)
# [18:07] * Quits: dbaron (dbaron@213.236.208.247) (Ping timeout)
# [18:07] * Quits: alexmog (alexmog@213.236.208.247) (Ping timeout)
# [18:08] * Quits: tantek (tantek@213.236.208.247) (Quit: tantek)
# [18:08] * Quits: ChrisL3 (ChrisL@128.30.52.169) (Ping timeout)
# [18:14] <Zakim> ChrisL, you asked to be reminded at this time to go home
# [18:16] * Zakim excuses himself; his presence no longer seems to be needed
# [18:16] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [18:38] * Joins: glazou (glazou@193.69.156.250)
# [18:38] * Quits: glazou (glazou@193.69.156.250) (Quit: glazou)
# [18:52] * Joins: nimbupani (nimbupani@24.22.131.46)
# [18:55] * Quits: dstorey (dstorey@213.236.208.247) (Quit: dstorey)
# [19:12] * Joins: tantek (tantek@193.69.156.250)
# [19:47] * Quits: tantek (tantek@193.69.156.250) (Quit: tantek)
# [20:25] * Joins: tantek (tantek@193.69.156.250)
# [21:19] * Quits: tantek (tantek@193.69.156.250) (Quit: tantek)
# [22:28] * Quits: anne5 (annevk@84.208.74.81) (Quit: anne5)
# [22:44] * RRSAgent excuses himself; his presence no longer seems to be needed
# [22:44] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
# [22:56] * Joins: dbaron (dbaron@84.208.66.187)
# [22:56] * Quits: dbaron (dbaron@84.208.66.187) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [23:03] * Quits: miketaylr (miketaylr@38.117.156.163) (Client exited)
# [23:55] * Joins: Arron (arronei@84.208.66.187)
# Session Close: Tue Aug 24 00:00:00 2010

The end :)