Options:
- # Session Start: Mon Mar 29 00:00:00 2010
- # Session Ident: #css
- # [01:19] * Quits: arronei (arronei@131.107.0.73) (Ping timeout)
- # [01:25] * Joins: arronei (arronei@131.107.0.94)
- # [01:29] * Joins: anne (annevk@76.253.3.102)
- # [01:31] * Quits: anne (annevk@76.253.3.102) (Connection reset by peer)
- # [01:32] * Joins: anne (annevk@76.253.3.102)
- # [04:42] * Quits: Curt` (DorkeyDear@76.243.205.159) (Quit: Leaving)
- # [04:46] * Quits: paul_irish (paul_irish@71.192.163.128) (Quit: Leaving...)
- # [04:50] * Joins: paul_irish (paul_irish@71.192.163.128)
- # [07:00] * Quits: anne (annevk@76.253.3.102) (Ping timeout)
- # [07:07] * Quits: TabAtkins (chatzilla@76.253.3.102) (Ping timeout)
- # [07:30] * Joins: TabAtkins (chatzilla@76.253.3.102)
- # [08:04] * Quits: TabAtkins (chatzilla@76.253.3.102) (Ping timeout)
- # [08:57] * Quits: dydz (dydz@75.37.27.246) (Quit: dydz)
- # [09:10] * Joins: dydz (dydz@75.37.27.246)
- # [10:23] * Joins: lstorset (lstorset@213.236.208.22)
- # [10:28] * Parts: lstorset (lstorset@213.236.208.22)
- # [10:35] * Joins: Lachy (Lachlan@83.170.95.133)
- # [10:54] * Quits: Lachy (Lachlan@83.170.95.133) (Quit: This computer has gone to sleep)
- # [11:41] * Joins: Lachy (Lachlan@64.208.192.130)
- # [11:41] * Joins: Lachy_ (Lachlan@83.170.95.133)
- # [11:44] * Quits: Lachy (Lachlan@64.208.192.130) (Ping timeout)
- # [11:51] * Quits: Lachy_ (Lachlan@83.170.95.133) (Quit: This computer has gone to sleep)
- # [12:34] * Joins: Lachy (Lachlan@64.208.192.130)
- # [12:35] * Quits: Lachy (Lachlan@64.208.192.130) (Quit: Leaving)
- # [13:41] * Joins: lstorset (lstorset@213.236.208.22)
- # [14:00] * Parts: lstorset (lstorset@213.236.208.22)
- # [16:27] * Joins: lstorset (lstorset@213.236.208.22)
- # [16:28] * Parts: lstorset (lstorset@213.236.208.22)
- # [16:52] * Joins: TabAtkins (chatzilla@76.253.3.102)
- # [17:04] * Quits: TabAtkins (chatzilla@76.253.3.102) (Ping timeout)
- # [17:07] * Joins: TabAtkins (chatzilla@76.253.3.102)
- # [17:37] * Quits: TabAtkins (chatzilla@76.253.3.102) (Ping timeout)
- # [17:46] * Joins: dbaron (dbaron@17.244.2.46)
- # [18:06] * Joins: plinss__ (plinss@17.244.3.217)
- # [18:09] * Joins: anne (annevk@17.244.3.72)
- # [18:12] * Joins: sylvaing (sylvaing@17.244.0.225)
- # [18:14] * Joins: dethbakin (dethbakin@17.244.1.225)
- # [18:14] * Joins: TabAtkins (chatzilla@17.244.2.48)
- # [18:15] * Quits: dbaron (dbaron@17.244.2.46) (Ping timeout)
- # [18:15] * Joins: ChrisL (ChrisL@128.30.52.169)
- # [18:15] * Joins: smfr (smfr@17.244.1.194)
- # [18:23] * Joins: css_projector (css_projec@17.201.14.208)
- # [18:23] <smfr> test
- # [18:25] <anne> win
- # [18:25] * Joins: dbaron (dbaron@63.245.220.11)
- # [18:26] * Joins: glazou (glazou@17.244.0.83)
- # [18:26] * dbaron wonders if css_projector has interesting highlight settings
- # [18:26] * TabAtkins doesn't get to show off his color scheme again. ;_;
- # [18:27] <TabAtkins> ScribeNick: TabAtkins
- # [18:28] <TabAtkins> plinss: Anyone with new topics?
- # [18:28] <sylvaing> http://wiki.csswg.org/planning/cupertino-2010
- # [18:28] * Joins: Arron (arronei@17.244.2.216)
- # [18:29] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
- # [18:30] <TabAtkins> plinss: k, no new topics.
- # [18:30] <TabAtkins> plinss: First topic, TPAC. Need to set our dates.
- # [18:30] <TabAtkins> ChrisL: Request for monday/tuesday?
- # [18:30] * Joins: dbaron (dbaron@63.245.220.11)
- # [18:31] <TabAtkins> glazou: Yes, from szilles and others. Want to make sure everyone is available for nov 1 and 2.
- # [18:31] * anne wonders what's going on in that other room
- # [18:31] * TabAtkins other room?
- # [18:32] * fantasai html5 political discussions, I think
- # [18:32] <TabAtkins> glazou: Two hotels around the venue, Hilton and something else.
- # [18:32] <TabAtkins> glazou: Early rates, roughly 110 euros/night.
- # [18:32] <TabAtkins> glazou: Cheaper in the center of Lyons, but it's further away, and no easy connection via public transport.
- # [18:33] <TabAtkins> glazou: Unless there's a strong objection to monday/tuesday, we should let the w3c know.
- # [18:33] <TabAtkins> RESOLVED: CSSWG meeting is on November 1 and 2.
- # [18:34] <TabAtkins> glazou: We also need to discuss at some point the dates/location of first meeting in 2011.
- # [18:34] <TabAtkins> glazou: Who's willing to host in 2011?
- # [18:35] <TabAtkins> dbaron: There's a bunch of us who could host in the Bay Area.
- # [18:35] <TabAtkins> glazou: Probably fair to host in Bay Area after 2 meetings in Europe.
- # [18:35] <TabAtkins> dbaron: I'd be happy to host. (Mozilla)
- # [18:36] <TabAtkins> howcome: Seems to be too early to set up dates yet.
- # [18:37] <TabAtkins> glazou: Anytime in March is good. No good in February.
- # [18:37] <TabAtkins> dbaron: MIT spring break is march 21-26, and thus probably the AC meeting.
- # [18:38] <TabAtkins> glazou: So, if we meet on the last week of March, or 2nd or 3rd week, it would be better.
- # [18:38] <dbaron> Easter 2011 is April 24
- # [18:38] <TabAtkins> glazou: Let's stick with the idea of a March meeting hosted by Mozilla, and move on for now.
- # [18:39] <TabAtkins> TOPIC: CSS 2.1 issues
- # [18:40] <TabAtkins> List of attendees: Dean, Simon, Anne, Steve, Beth, Sylvain, Alex, Chris, Bert, Arron, Elika, dbaron, Brad, Tab, Daniel, Peter, Hakon.
- # [18:40] <plinss__> http://wiki.csswg.org/spec/css2.1
- # [18:40] * Joins: howcome (howcome@17.244.0.146)
- # [18:41] * Joins: dino (dino@17.244.0.219)
- # [18:41] <dbaron> Present: Dean Jackson, Simon Fraser, Anne van Kesteren, Steve Zilles, Beth Dakin, Sylvain Galineau, Alex Mogilevsky, Chris Lilley, Bert Bos, Aaron Eicholtz, Elika Etemad, David Baron, Brad Kemper, Tab Atkins, Daniel Glazman, Peter Linss, Håkon Lie
- # [18:43] <TabAtkins> fantasai: Start with issue 60.
- # [18:43] <plinss__> http://wiki.csswg.org/spec/css2.1#issue-60
- # [18:43] * Joins: szilles (chatzilla@17.244.0.143)
- # [18:43] <TabAtkins> sylvaing: Issue 60 is from Anton Prouse and issues about z-index and stacking.
- # [18:43] <TabAtkins> sylvaing: There is no interop issues, it's mostly just cleanup and making sure that different parts of the spec agree.
- # [18:43] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-60
- # [18:44] <TabAtkins> sylvaing: I suggested minimal changes, and he accepted most of them, there's just a few things left. I think we can get it closed in a few days.
- # [18:44] <TabAtkins> sylvaing: Mostly it's just terminology and a few other things that are confusing.
- # [18:44] <TabAtkins> sylvaing: Like intermixing "stacking order" and "painting order" and such.
- # [18:44] <TabAtkins> sylvaing: So, mostly editorial. We'll try to close it.
- # [18:45] <TabAtkins> sylvaing: In 9.9.1, there are a few errors, but browsers follow Appendix E, which is the important one.
- # [18:45] * Joins: alexmog (alexmog@17.244.1.2)
- # [18:45] * glazou notes last time the CSS WG gathered 17 people in same room was long ago...
- # [18:47] <TabAtkins> howcome: Seems like it's more than editorial, like #4 there.
- # [18:48] <TabAtkins> sylvaing: Yeah, #4 was the one actual error where 9.9.1 is out of sync with appendix E, but browsers do the right thing there.
- # [18:48] * Joins: bradk (bradk@17.244.0.81)
- # [18:48] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
- # [18:48] <TabAtkins> szilles: My suggestion is that we reaffirm that Appendix E is the normative text.
- # [18:49] * Joins: dbaron (dbaron@63.245.220.11)
- # [18:49] <TabAtkins> howcome: Don't we already say that somewhere?
- # [18:49] <TabAtkins> szilles: I think we do, but it wouldn't hurt to affirm it as a Working Group.
- # [18:50] <TabAtkins> plinss: So we're agreed to accept Sylvain's changes?
- # [18:52] * Quits: TabAtkins (chatzilla@17.244.2.48) (Connection reset by peer)
- # [18:52] <fantasai> RESOLVED: Defer to Sylvain for resolution of Issue 60, Bert will verify when editing that the changes are only editorial.
- # [18:52] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-69
- # [18:53] * Joins: TabAtkins (chatzilla@17.244.2.48)
- # [18:54] * TabAtkins is back!
- # [18:54] <fantasai> In paged media where there is no viewport, a 'fixed' background is fixed with respect to the pa and is therefore replicated on every page."
- # [18:56] <fantasai> s/pa and/page box and/
- # [18:56] * Quits: dino (dino@17.244.0.219) (Quit: dino)
- # [18:57] * glazou dino leaves
- # [18:57] <TabAtkins> bradk: Should we mention something about box-decoration-break wrt fixed backgrounds?
- # [18:57] <TabAtkins> Arronei: Not in 2.1, but we'd have to in 3.
- # [18:58] <TabAtkins> szilles: What about bleeds?
- # [18:58] <TabAtkins> fantasai: Not addressed here. Backgrounds on the page box may bleed, but not on the document.
- # [18:58] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
- # [18:59] * Joins: dbaron (dbaron@63.245.220.11)
- # [18:59] <anne> I thought sending over 587 ought to work?
- # [18:59] <anne> meh
- # [18:59] <TabAtkins> howcome: There is a bleed property in gcpm.
- # [18:59] * TabAtkins anne, 587 doesn't work. dbaron decided that.
- # [18:59] <TabAtkins> RESOLVED: In paged media where there is no viewport, a 'fixed' background is fixed with respect to the pa and is therefore replicated on every page."
- # [19:00] <fantasai> page box
- # [19:00] <TabAtkins> plinss: Issue #111
- # [19:00] <TabAtkins> plinss: Font-weight bolder/lighter, synchronize with css3?
- # [19:00] <TabAtkins> fantasai: Did we want to do #71?
- # [19:00] <TabAtkins> Bert: I'm in the process of responding to that, but have email troubles.
- # [19:01] * Quits: sylvaing (sylvaing@17.244.0.225) (Quit: sylvaing)
- # [19:01] <TabAtkins> fantasai: issue 73, peter was supposed to write a note?
- # [19:01] * anne I thought that was the one that would work? what else is there?
- # [19:01] <TabAtkins> plinss: Not sure; it's been a while. I'll check.
- # [19:01] * anne oh well
- # [19:01] * TabAtkins anne, shrug.
- # [19:01] <fantasai> ACTION: Plinss find or write note for issue 73 by this afternono
- # [19:01] * trackbot noticed an ACTION. Trying to create it.
- # [19:01] <trackbot> Created ACTION-209 - Find or write note for issue 73 by this afternono [on Peter Linss - due 2010-04-05].
- # [19:01] <fantasai> s/nono/noon/
- # [19:03] <TabAtkins> fantasai: Issue 111?
- # [19:04] <TabAtkins> fantasai: Don't have a strong opinion on this.
- # [19:04] * glazou thinks he needs antibiotics...
- # [19:04] <TabAtkins> TabAtkins: So Daggett's suggestion was to make bolder/lighter act as if there were only four weights.
- # [19:04] <smfr> http://wiki.csswg.org/spec/css2.1#issue-111
- # [19:05] <TabAtkins> ChrisL: As long as you can get to the other weights someway.
- # [19:05] <TabAtkins> szilles: This isn't great, but it's less bad than others.
- # [19:05] <TabAtkins> Bert: This is the same text as in the Fonts module?
- # [19:05] <TabAtkins> szilles: Yes.
- # [19:05] <TabAtkins> Bert: I'm okay with that.
- # [19:05] * Joins: sylvaing (sylvaing@17.244.0.225)
- # [19:05] <TabAtkins> szilles: Obvious issue is, what do current browsers do with this?
- # [19:06] <TabAtkins> arronei: Currently, we test by having a list, and see if it's lighter or darker. Purely visual.
- # [19:06] <TabAtkins> szilles: Does the suggested algorithm keep this same behavior?
- # [19:06] <TabAtkins> Arronei: Should.
- # [19:07] <TabAtkins> RESOLVED: Accept Daggett's changed (from Fonts), back into CSS2.1.
- # [19:07] <TabAtkins> plinss: Related is issue 156.
- # [19:08] <TabAtkins> fantasai: ChrisL says "I'd prefer to see the mapping made normative."
- # [19:08] <TabAtkins> fantasai: Different mapping from issue 111.
- # [19:08] <fantasai> http://www.w3.org/TR/CSS21/fonts.html#font-boldness
- # [19:08] <fantasai> last bullet in the list
- # [19:08] <fantasai> "If there are fewer then 9 weights in the family"
- # [19:09] <TabAtkins> ChrisL: above that, it says "in typical cases", which makes it untestable.
- # [19:10] <TabAtkins> ChrisL: So, I'd like to drop that sentence.
- # [19:10] <TabAtkins> fantasai: OpenType fonts use a numerical scale, but they may not line up with multiples of 100.
- # [19:11] <TabAtkins> ChrisL: 4th bullet gives you a more precise description of that.
- # [19:11] <TabAtkins> ChrisL: I've seen things like a font with weights like 400 and 250, and that's fine. 200 and 300 aren't mapped explicitly.
- # [19:12] <TabAtkins> fantasai: You might actually want to map the 250 to 100.
- # [19:12] <TabAtkins> ChrisL: No, that'd expose more weights, but would put them in the wrong place. If you need precise mapping, just use @font-face.
- # [19:13] <TabAtkins> plinss: I think certain platforms made fonts map their weights wrong to get around bad heuristics.
- # [19:13] <TabAtkins> ChrisL: I haven't seen platform-specific weight tables like that.
- # [19:13] <TabAtkins> fantasai: I'm happy to make bullet 4 normative, but I'm less convinced about the other rules being normative.
- # [19:14] <TabAtkins> fantasai: I think mapping fonts to weights can be messy, and we shouldn't define that in css 2.1
- # [19:14] <TabAtkins> fantasai: But after the font has been mapped into the CSS font-weight scale, then we can follow the guidelines in bullet 4 to find missing weights.
- # [19:14] <TabAtkins> fantasai: That seems consistent.
- # [19:14] * Quits: sylvaing (sylvaing@17.244.0.225) (Quit: sylvaing)
- # [19:14] <TabAtkins> fantasai: The rules before that are about establishing the scale, and needs to be flexible to accomodate whatever twisted things we get into with fonts.
- # [19:15] * dbaron wonders if jdaggett should be around for this discussion
- # [19:15] <TabAtkins> fantasai: So the specific changes for this would be to pull bullet 4 out of the list and remove "typical".
- # [19:15] <fantasai> remove "default"
- # [19:16] <TabAtkins> s/typical/default/
- # [19:16] <fantasai> Chris: Replace "typical mappings" from the sentence below to "this mapping"
- # [19:16] <TabAtkins> RESOLVED: Pull bullet 4 of the font-weight mapping rules out into its own paragraph, tweak wording to imply exactness, not "typical" or "default".
- # [19:17] <TabAtkins> plinss: Next is issue 114.
- # [19:17] <TabAtkins> fantasai: let's defer until dbaron is back.
- # [19:17] <TabAtkins> plinss: Issue 115
- # [19:18] <TabAtkins> fantasai: Summary should be "Zero clearance should be distinguished from not having clearance".
- # [19:19] <TabAtkins> fantasai: There are some cases in which you have clearance, but it calculates to 0, and the spec isn't clear about distinguishing this from no clearance.
- # [19:19] <TabAtkins> fantasai: Some things happen when there isn't clearance (margin collapsing, frex).
- # [19:20] <TabAtkins> fantasai: So these other behaviors should still trigger when there is clearance, even if the value happens to compute to 0.
- # [19:20] <TabAtkins> alexmog: Any interop issues?
- # [19:21] <TabAtkins> plinss: Do we have testcases for current behavior?
- # [19:22] <TabAtkins> fantasai: I doubt we need any. It would require very unnatural code.
- # [19:22] <TabAtkins> fantasai: (to make 0 clearance act like no clearance)
- # [19:22] <TabAtkins> plinss: So do we have tests for clearance showing interop?
- # [19:22] <TabAtkins> fantasai: Sorta. Clearance is not the most interop portion of the spec.
- # [19:22] * Joins: dino (dino@17.244.86.57)
- # [19:23] <TabAtkins> arronei: According to test cases, we do have at least two browsers agreeing.
- # [19:24] <TabAtkins> alexmog: I'm not sure if the first change is just about this issue...
- # [19:24] <TabAtkins> fantasai: Check the second email, it overrides that.
- # [19:24] <TabAtkins> fantasai: We'd take everything *but* the first change from the first email, and then all the changes from the second email.
- # [19:24] * Joins: sylvaing (sylvaing@17.244.0.225)
- # [19:25] <TabAtkins> RESOLVED: Accept fantasai's proposals for issue 115.
- # [19:26] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-115
- # [19:27] <fantasai> all but the first change in http://lists.w3.org/Archives/Public/www-style/2009May/0186.html
- # [19:27] <fantasai> plus changes in http://lists.w3.org/Archives/Public/www-style/2009Aug/0394.html
- # [19:29] <TabAtkins> <br type=coffee>
- # [19:29] * Quits: bradk (bradk@17.244.0.81) (Quit: Computer has gone to sleep)
- # [19:30] * Joins: bradk (bradk@17.244.0.81)
- # [19:37] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
- # [19:37] * Joins: dbaron (dbaron@63.245.220.11)
- # [19:51] * Quits: szilles (chatzilla@17.244.0.143) (Ping timeout)
- # [19:52] * Quits: dino (dino@17.244.86.57) (Quit: dino)
- # [19:55] <fantasai> http://fantasai.inkedblade.net/style/specs/css2.1/zero-clearance
- # [19:56] * Joins: dino (dino@17.244.86.57)
- # [19:59] <TabAtkins> fantasai: issue 150
- # [19:59] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-115
- # [19:59] <TabAtkins> fantasai: If those changes look good we can close on it.
- # [19:59] <fantasai> http://fantasai.inkedblade.net/style/specs/css2.1/zero-clearance
- # [19:59] <fantasai> combined proposal
- # [19:59] <TabAtkins> s/issue 150/issue 115/
- # [20:00] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
- # [20:01] <TabAtkins> plinss: Bert sent an email for issue 71.
- # [20:02] <TabAtkins> Bert: We discussed this a year ago, and I looked at the minutes for that meeting.
- # [20:02] <TabAtkins> Bert: If you find at @-rule in the middle of a declaration block, the rule says to ignore the @-rule, but you *want* to ignore the whole block.
- # [20:02] <TabAtkins> Bert: I think the error is the rule for ignoring @ keywords is meant for the rules, not declarations.
- # [20:03] <TabAtkins> Bert: So I suggest to make that explicit.
- # [20:03] <fantasai> body {
- # [20:03] <fantasai> @foo {}
- # [20:03] <fantasai> background: green;
- # [20:03] <Bert> http://lists.w3.org/Archives/Public/www-style/2010Mar/0485.html
- # [20:03] <fantasai> }
- # [20:03] <fantasai> Does that handle this?
- # [20:03] <TabAtkins> fantasai: We wanted the rule to stop ignoring at the close brace.
- # [20:03] <TabAtkins> plinss: Is that what we want?
- # [20:04] <TabAtkins> plinss: In paged media, we have @page which can be mixed with other @ blocks.
- # [20:04] <TabAtkins> fantasai: Right; right now the rules say the background should *not* be green - they say we should ignore until the semicolon.
- # [20:04] <TabAtkins> plinss: So you want the background:green to apply.
- # [20:04] <TabAtkins> fantasai: Right.
- # [20:05] <TabAtkins> Bert: My proposal is to do what CSS 2.1 says. I thought that's what we decided last year.
- # [20:05] <TabAtkins> Bert: Which would mean we ignore up to the semicolon, so there would be no green.
- # [20:05] <TabAtkins> plinss: Any @ keyword followed by a block or a semicolon should be ignored up to the next block or semicolon; we don't need to go farther.
- # [20:05] <TabAtkins> howcome: Is that what browsers do today?
- # [20:05] <TabAtkins> Bert: Yes.
- # [20:06] <fantasai> body { color: @foo {} background: red; }
- # [20:06] <TabAtkins> plinss: So existing browsers would ignore the background:green?
- # [20:06] <fantasai> body { @foo {} background: green; }
- # [20:07] <TabAtkins> glazou: Right, that should be ignored up to the semicolon, since it's inside the value of color.
- # [20:07] <TabAtkins> glazou: But we didn't discuss @ rules inside @ rules.
- # [20:07] <TabAtkins> fantasai: That's what issue 71 is about.
- # [20:07] <fantasai> body { color @foo {}: red; }
- # [20:08] <TabAtkins> fantasai: After you start a declaration, as soon as you see a property, the @ rules become invalid tokens.
- # [20:08] * Quits: dino (dino@17.244.86.57) (Quit: dino)
- # [20:08] <TabAtkins> anne: In CSSOM, they always have to come at the end or the start.
- # [20:09] <fantasai> Bert: I thought we resolved in css3-page that the @rules come after the declarations
- # [20:09] <TabAtkins> plinss: We have the problem of the existing behavior.
- # [20:09] <TabAtkins> bradk: But changing existing behavior won't break any pages.
- # [20:10] <TabAtkins> howcome: What's the value of fixing this in 2.1?
- # [20:10] <TabAtkins> plinss: Compatibility with CSS3?
- # [20:11] <TabAtkins> anne: We need to know the parsing rules.
- # [20:11] <TabAtkins> howcome: If we decide it now, we could put it in css3.
- # [20:11] <TabAtkins> glazou: We have only one parser. It will be the same in 2 or 3.
- # [20:11] <TabAtkins> dbaron: The forward-compatible rules should be the same in all levels and should not change.
- # [20:11] <TabAtkins> howcome: I can probably live with fixing it.
- # [20:12] <TabAtkins> Bert: But if you start with / or something, it would not be green.
- # [20:12] <TabAtkins> glazou: But @ is an acceptable token inside a rule. A / is not.
- # [20:12] <TabAtkins> glazou: @page is a declaration block.
- # [20:12] <TabAtkins> plinss: It's something new, a mixed declaration and @ block.
- # [20:13] <TabAtkins> anne: Bert is right.
- # [20:13] <TabAtkins> anne: Declaration blocks don't currently have the notion of an @ block.
- # [20:13] <TabAtkins> Bert: I don't understand why we want to keep the @page construct, because that's where the error is.
- # [20:13] <TabAtkins> fantasai: @page is deployed.
- # [20:13] <TabAtkins> Bert: So is this.
- # [20:13] <TabAtkins> fantasai: @page is deployed *and used*. This error isn't used.
- # [20:14] * Joins: dbaron (dbaron@17.244.2.46)
- # [20:14] <TabAtkins> fantasai: There are multiple impls. HP, Canon, Prince?
- # [20:14] <TabAtkins> fantasai: Antennae House and Epson.
- # [20:15] <TabAtkins> anne: Question is, do we want to change the parsing to allow @ blocks inside of declaration blocks in the future?
- # [20:15] <TabAtkins> howcome: We can do cool stuff with it, and we can create nightmares.
- # [20:16] <TabAtkins> ChrisL: I'd like to see named stylesets, bundles of properties applied at once.
- # [20:17] <TabAtkins> howcome: You want to represent these structures in the object model?
- # [20:17] <TabAtkins> anne: Yes. [explanation of @page stuff]
- # [20:17] <TabAtkins> howcome: That's a special fix for @page. We're talking about generic things.
- # [20:17] <TabAtkins> anne: Yeah, if it was generic, we'd want a generic structure that @page could inherit from.
- # [20:17] * Quits: dbaron (dbaron@17.244.2.46) (Ping timeout)
- # [20:17] * Joins: dbaron (dbaron@17.244.2.46)
- # [20:17] * Quits: dbaron (dbaron@17.244.2.46) (Quit: 8403864 bytes have been tenured, next gc will be global.)
- # [20:17] * Joins: dbaron (dbaron@63.245.220.11)
- # [20:18] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
- # [20:18] <RRSAgent> logging to http://www.w3.org/2010/03/29-CSS-irc
- # [20:18] * dbaron RRSAgent, make logs public
- # [20:18] * RRSAgent I have made the request, dbaron
- # [20:18] <TabAtkins> anne: We have the problem for @page, for what goes inside of @page, that we need to solve one way or another. We can make it special or we can make it generic.
- # [20:18] <ChrisL> rrsagent, this meeting spans midnight
- # [20:18] <RRSAgent> ok, ChrisL; I will not start a new log at midnight
- # [20:19] <TabAtkins> Bert: I proposed some time ago to create a 3rd type of block that would allow @page.
- # [20:19] <dbaron> Present: Dean Jackson, Simon Fraser, Anne van Kesteren, Steve Zilles, Beth Dakin, Sylvain Galineau, Alex Mogilevsky, Chris Lilley, Bert Bos, Aaron Eicholtz, Elika Etemad, David Baron, Brad Kemper, Tab Atkins, Daniel Glazman, Peter Linss, Håkon Lie, David Singer
- # [20:19] <TabAtkins> Bert: But I think people wouldn't want that.
- # [20:19] <dbaron> (that was the list of who was present earlier; Dean Jackson and David Singer are not currently present)
- # [20:20] <TabAtkins> anne: That wouldn't solve the earlier problem, the background wouldn't be green.
- # [20:20] <TabAtkins> Bert: Right, but it would let you do what @page wants.
- # [20:20] <TabAtkins> plinss: I'd prefer to see, if we see an @ rule, we parse it as a block, throw it away as invalid, and don't trash more than that.
- # [20:21] <TabAtkins> Bert: But that's inconsistent. Any other unknown token would throw away until the next semicolon.
- # [20:21] <TabAtkins> szilles: @ already has the role of being special.
- # [20:22] <TabAtkins> glazou: I think we agree that if an @ occurs inside a value isn't an @ rule.
- # [20:22] <TabAtkins> glazou: Frex, if the first token inside the brace is an @ token, we'd like it to be an @ rule.
- # [20:22] <TabAtkins> Bert: If that's a change, we can't do it.
- # [20:22] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
- # [20:22] <TabAtkins> glazou: It's something new that wouldn't break anything.
- # [20:22] * Joins: dbaron (dbaron@63.245.220.11)
- # [20:22] <TabAtkins> Bert: It's in the spec.
- # [20:23] <TabAtkins> howcome: This is a change in the eternal grammar.
- # [20:23] <TabAtkins> anne: It doesn't change valid stylesheets. I think it's fine.
- # [20:23] <TabAtkins> Bert: We have the error-recovery rules for consistency; you're changing the rules, so you're losing consistency.
- # [20:24] <TabAtkins> glazou: We are fighting about extensibility all the time.
- # [20:24] <TabAtkins> Bert: Things like adding to a shorthand is different, it fits in the grammar.
- # [20:25] <TabAtkins> Bert: Show me a place in CSS3 that is incompatible with the forward-compatible rules.
- # [20:25] <TabAtkins> plinss: @page
- # [20:25] <TabAtkins> ChrisL: @page is interoperably implemented. I don't see the benefit of changing it; we should allow it, and use the extension point it allows to do new things.
- # [20:26] <TabAtkins> howcome: This is a change in the eternal grammar, but we don't really have a great use-case.
- # [20:26] <TabAtkins> howcome: A green background isn't a good use-case.
- # [20:26] <TabAtkins> howcome: It's interoperable today, I'm not sure we should change it.
- # [20:27] <TabAtkins> howcome: We're suggesting this change to get a generic extension mechanism.
- # [20:27] <TabAtkins> plinss: We have @page, which allows intermingling of @ rules in a declaration block.
- # [20:27] <TabAtkins> plinss: If it's *only* valid here, with special rules and special error recovery, that's very surprising.
- # [20:27] <TabAtkins> howcome: Do we allow @page at the place where we're talking about?
- # [20:28] <alexmog> adding a semicolon to the use case makes it green, interoparably: body { @foo {}; background: green; }
- # [20:28] <TabAtkins> plinss: No, not right now. But @page acts like a declaration block, and allows more @ rules in it.
- # [20:28] <TabAtkins> glazou: [gives an example showing @page]
- # [20:28] <fantasai> plinss: If error-recovery from @foo inside @page's declaration block is different from in other declaration blocks, that's very surprising
- # [20:29] <TabAtkins> glazou: In @page, if you see another @page{}, it parses to that } and throws it away, allowing the next rules to work.
- # [20:29] * Joins: szilles (chatzilla@17.244.0.143)
- # [20:29] <TabAtkins> glazou: But if you have @page{ @foo {} background: green; }, the background is thrown away. That's very surprising.
- # [20:30] <TabAtkins> plinss: The problem is that an unknown @ rule at one point in the stylesheet, it parses to the }. If you put it at another spot, and it doesn't parse to the }, that's weird.
- # [20:31] <TabAtkins> dbaron: We already have that in some places. If an @rule appears in a value, or in a selector, it just makes an invalid value or selector.
- # [20:31] <dbaron> ... never mind what I said
- # [20:31] <TabAtkins> szilles: What anne just pointed out, if we have a single recovery mechanism, CSSOM can have a generic recovery mechanism.
- # [20:32] <TabAtkins> glazou: Non-generic means one parsing impl for @page, and another for other @ rules.
- # [20:32] <fantasai> We have different parsing of @keywords in different parts of the style sheet with or without the change we're proposing.
- # [20:32] <TabAtkins> glazou: That's ugly.
- # [20:32] <fantasai> For example, @keyword inside a declaration is still ignored as an invalid token
- # [20:32] <fantasai> However, having different parsing rules within a declaration block
- # [20:32] <fantasai> depending on whether the declaraiton block is inside @page or elsewhere,
- # [20:32] <fantasai> that is confusing
- # [20:32] <TabAtkins> alexmog: I'm agreeing with what Bert is saying. I'm not seeing use-cases, but we have interop against it.
- # [20:32] <fantasai> and it is a burden on implementors to implement two different types of error-recovery
- # [20:33] <anne> advantages: 1) consistent rules for authors 2) one code path for implementors
- # [20:33] <TabAtkins> alexmog: We'll have syntax that is ignored in older browsers but paid attention to in newer browsers.
- # [20:33] <TabAtkins> alexmog: We can just add a semicolon to the end of the @block and all browsers ignore it. It's not the prettiest, but it achieves the goal.
- # [20:34] <TabAtkins> anne: Advantages is consistent rules for authors, and implementors.
- # [20:34] <TabAtkins> alexmog: How much time until browsers have changed sufficiently to allow it?
- # [20:35] <TabAtkins> TabAtkins: No more time than it would take for any new @ rule to be usable.
- # [20:35] <TabAtkins> plinss: He has a good point. If we introduce a new @ rule, then authors using it will have their next declaration swallowed in older browsers.
- # [20:35] <TabAtkins> anne: But can't it sometimes be a start of a selector then?
- # [20:35] <TabAtkins> fantasai: No.
- # [20:36] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
- # [20:36] <TabAtkins> anne: If you recommend putting a semicolon after every @ rule, it is the start of a selector, and you don't get a green background.
- # [20:37] <TabAtkins> anne: IE "@foo {}; body { background: green; }" kills the body block.
- # [20:37] <TabAtkins> Bert: Oh, no, not ; after everything.
- # [20:37] * Quits: alexmog (alexmog@17.244.1.2) (Ping timeout)
- # [20:37] * Joins: alexmog (alexmog@17.244.1.2)
- # [20:37] <TabAtkins> anne: I think we can just recommend that authors put the @ blocks at the end of the declaration block.
- # [20:38] <TabAtkins> plinss: I think it will be really confusing if you would recommend putting ; at the end of @ blocks inside a declaration block, but not at the end of ones outside a declaration block.
- # [20:38] * fantasai has no opinion
- # [20:38] <TabAtkins> Bert: I think we made a mistake on @page, not in the grammar.
- # [20:39] <TabAtkins> plinss: I think we made a mistake in the grammar, instead.
- # [20:39] <TabAtkins> fantasai: I think you can't stick an @ rule without braces is invalid inside a declaration block in the core grammar.
- # [20:40] <TabAtkins> fantasai: We have some options. We could do nothing, which means no @ rules inside declaration blocks ever.
- # [20:40] <TabAtkins> fantasai: And then just have Paged Media declare that @ rules have to be at the end.
- # [20:40] <TabAtkins> plinss: The problem is that the longer we put it out, the more entrenched we'll get.
- # [20:40] <TabAtkins> Bert: Not expensive? It's been in the spec for years!
- # [20:41] <TabAtkins> anne: What kind of implementations are you thinking of?
- # [20:41] <TabAtkins> Bert: TVs, etc.
- # [20:41] <TabAtkins> glazou: They're all consistent right now, though, so nobody uses it anyway. It can't even be used as a browser selector.
- # [20:42] <TabAtkins> plinss: The problem isn't that it's an error now, but in a few years when we have a spec that uses @ rules in that area.
- # [20:42] <TabAtkins> anne: In a few years we'll have an upgraded set of browsers.
- # [20:43] <TabAtkins> szilles: So older browsers will throw it away, so nothing weird. Anne observes that if you put them at the end, it will prevent any rules from being dropped.
- # [20:43] <TabAtkins> Bert: So let's just put them at the end.
- # [20:43] <TabAtkins> fantasai: It's still invalid by the grammar.
- # [20:44] <TabAtkins> howcome: Eternal grammar isn't 'eternal', but I think it should still be harder to change than just writing a spec that says something different.
- # [20:44] <TabAtkins> howcome: We should have a very good reason to do it, and I haven't seen that reason.
- # [20:44] <TabAtkins> szilles: It simplifies the CSSOM model, for one. It simplifies parsing for CSS. It simplifies parsing for authors.
- # [20:45] * Quits: alexmog (alexmog@17.244.1.2) (Ping timeout)
- # [20:45] * Joins: alexmog (alexmog@17.244.1.2)
- # [20:46] <TabAtkins> @mixin(border-rules)(n) { -moz-border-radius: n; -webkit-border-radius: n; border-radius: n; } div{ @mixin(border-rule, 8px) }
- # [20:46] * TabAtkins bad syntax, but shrug.
- # [20:46] <TabAtkins> Bert: Why do you need an @rule in the one place where it's not allowed?
- # [20:46] * dbaron notes http://www.sas.upenn.edu/~baron/baron.css is CSS written by his dad
- # [20:47] <TabAtkins> plinss: Because @rule already has rules for swallowing things to the end of a block.
- # [20:47] <TabAtkins> glazou: If you remember the time before CSS2, we didn't have @page.
- # [20:47] <TabAtkins> glazou: Declaration were *only* for style rules. When we came up for @page, we suddenly had a new place for declarations.
- # [20:47] <TabAtkins> glazou: We want to be able to reuse an existing construct in the same way.
- # [20:48] <TabAtkins> glazou: It would open up a new type of contributions for authors that we can't usually do.
- # [20:49] <TabAtkins> Bert: Imagine changing XML.
- # [20:49] <TabAtkins> glazou: We did that when we added @media.
- # [20:49] <TabAtkins> Bert: That in 1998.
- # [20:50] <TabAtkins> szilles: I recommend the chairs take a straw poll.
- # [20:51] <TabAtkins> anne: And the options are 1) special handling of @page, or 2) generic handling?
- # [20:52] <anne> ... and 3) require at-rules at the end for @page
- # [20:52] <TabAtkins> plinss: Given the current definition of @page, legacy handling would mean swalling @margin rules inside of it, because @page contains a declaration block, which doesn't allow @ rules inside of it.
- # [20:53] * Quits: szilles (chatzilla@17.244.0.143) (Ping timeout)
- # [20:53] <TabAtkins> Bert: 3rd proposal, which has no chance, is to change Paged Media.
- # [20:53] <TabAtkins> s/3rd/4th/
- # [20:54] <TabAtkins> Bert: And pull out @margin rules from the @page blocks.
- # [20:54] <TabAtkins> fantasai: They should have probably been outside from the beginning, but right now we might as well remove them.
- # [20:54] <TabAtkins> howcome: Where would you put them if they were outside?
- # [20:54] * Joins: ChrisL (ChrisL@128.30.52.169)
- # [20:55] <ChrisL> CSS the Eternal Temple http://i40.tinypic.com/2nlwrjn.jpg
- # [20:55] <TabAtkins> howcome: [illustrates the change]
- # [20:55] <Bert> (One proposed change is in 13.2 say:... followed by a block of declarations <ins>and at-rules</ins>.)
- # [20:55] <TabAtkins> fantasai: Yeah, but we've got multiple implementations in printers, and so it can't be changed now.
- # [20:57] <TabAtkins> plinss: What's the point of putting @ at the end? It seems like an arbitrary place.
- # [20:57] <TabAtkins> fantasai: It makes it clearer how inheritance works.
- # [20:58] <TabAtkins> howcome: So how do we deal with @page containing @top-left and such?
- # [20:58] <TabAtkins> Bert: Right now, we don't. It's just invalid.
- # [20:58] <TabAtkins> Bert: We could create a special thing, not a declaration block, that would allow it.
- # [20:59] <TabAtkins> plinss: I'm reading the parsing rules, and I'm not seeing anything in CSS that says special handling of @ rules depending on the position.
- # [20:59] <TabAtkins> plinss: It doesn't say we only do this based on where it was.
- # [20:59] <TabAtkins> Bert: Right, but we discussed that it should behave that way.
- # [20:59] <TabAtkins> plinss: Please show me in the spec where it says it should behave the way you say it shoudl behave.
- # [20:59] <TabAtkins> Bert: The two points above that.
- # [21:00] <TabAtkins> Bert: The question is only if there is an exception if the @ keyword appears right after a semicolon.
- # [21:00] <TabAtkins> dbaron: We don't specify what happens when the formal grammar disagrees with the prose.
- # [21:00] <TabAtkins> plinss: But the formal grammar doesn't define the recovery rules, only the prose does.
- # [21:01] <dbaron> dbaron: we usually go with whatever's more specific
- # [21:01] <TabAtkins> howcome: What if we used ::top-left or something?
- # [21:01] <TabAtkins> fantasai: Still invalid in a declaration block. Should have been @page::top-left, but shrug.
- # [21:02] <TabAtkins> Straw Poll:
- # [21:02] <TabAtkins> 1) Generic Handling
- # [21:02] <TabAtkins> 2) Special handling for @page in any order (current spec)
- # [21:02] <TabAtkins> 3) Special handling, but @rules at the end.
- # [21:03] * sylvaing ::nth-strawpoll(2n+1)
- # [21:03] <TabAtkins> 4) Change Paged Media to nuke margin boxes and rewrite @page.
- # [21:03] <TabAtkins> smfr: 1
- # [21:03] <TabAtkins> anne: 1
- # [21:03] <TabAtkins> szilles: 1
- # [21:03] <bradk> 1 generic
- # [21:03] <TabAtkins> dbaron: 1
- # [21:03] <TabAtkins> s/dbaron/dethbakin/
- # [21:06] * Quits: dbaron (dbaron@63.245.220.11) (Ping timeout)
- # [21:06] * Joins: dbaron (dbaron@63.245.220.11)
- # [21:07] <TabAtkins> sylvaing: abstain
- # [21:07] <TabAtkins> alexmog: 3 or 4, whatever doesnt' change CSS 2.1
- # [21:08] <TabAtkins> ChrisL: 1
- # [21:08] <TabAtkins> Bert: Prefer 4, second is 3. could also live with 2. Can't live with 1
- # [21:08] <TabAtkins> arronei: 1
- # [21:08] <sylvaing> sylvaing abstains in the absence of a use-case
- # [21:08] <TabAtkins> fantasai: anything but 4, defer to dbaron
- # [21:08] <TabAtkins> dbaron: 4
- # [21:09] <TabAtkins> bradk: 1
- # [21:09] <TabAtkins> TabAtkins: 1
- # [21:09] <TabAtkins> glazou: 1
- # [21:09] <TabAtkins> plinss: 1
- # [21:09] <TabAtkins> howcome: 3
- # [21:09] <TabAtkins> dsinger: 1
- # [21:10] <fantasai> I think HP would raise a formal objection for 4
- # [21:10] <TabAtkins> glazou: Twelve for #1, three or four for 3 and 4.
- # [21:12] <TabAtkins> dsinger: We have agreement on *not* 2.
- # [21:12] <TabAtkins> plinss: And we cant' do 4 because of existing impls.
- # [21:12] <TabAtkins> glazou: Existing impls do 2, so we're rejecting the current impls!
- # [21:13] <TabAtkins> fantasai: Not sure if existing impls do 2, maybe they do 1?
- # [21:13] <TabAtkins> ChrisL: How would you tell the difference?
- # [21:13] <TabAtkins> fantasai: Just pop my testcase into a supporting impl.
- # [21:13] <anne> <!DOCTYPE html><style> body { @foo {} background: green; } </style>
- # [21:14] <ChrisL> it would be good to gather that implementation experience for printers that currently handle @page
- # [21:14] <TabAtkins> body {
- # [21:14] <TabAtkins> @foo {
- # [21:14] <TabAtkins> }
- # [21:14] <TabAtkins> background: green;
- # [21:14] <TabAtkins> }
- # [21:15] * fantasai has access to two printer implementations at home
- # [21:15] <TabAtkins> glazou: People will write it like Tab has, what will they expect?
- # [21:15] <TabAtkins> howcome: Prince considers this an error, and doesn't show a green background.
- # [21:15] <TabAtkins> fantasai: So it implements 2?
- # [21:16] * Quits: dbaron (dbaron@63.245.220.11) (Connection reset by peer)
- # [21:16] <TabAtkins> anne: Or 3, we can't tell.
- # [21:16] <TabAtkins> plinss: Elika, can you test with your printers and get back to us?
- # [21:17] <TabAtkins> fantasai: Would be good to get AH. Can we ping Murakami-san?
- # [21:17] <TabAtkins> fantasai: 3 would just mean normal 2.1 error-recovery mode.
- # [21:17] <TabAtkins> plinss: We'll come back when we get more implementations.
- # [21:18] * Quits: dethbakin (dethbakin@17.244.1.225) (Quit: dethbakin)
- # [21:19] * Joins: dbaron (dbaron@17.244.2.46)
- # [21:19] <TabAtkins> howcome: Is there anyone that can't live with 3?
- # [21:19] <TabAtkins> anne: #3 is actually pretty weird.
- # [21:20] <TabAtkins> anne: So if you had @ rules, normal rules, then more @ rules, presumably you should ignore all the normal rules since the appearance of the @ implies the end?
- # [21:20] <TabAtkins> howcome: I think we can live with #3 now, and then make #1 valid later.
- # [21:21] <TabAtkins> dsinger: Can we write that we can possibly allow #1 later? Warn people about it?
- # [21:21] <TabAtkins> plinss: I don't think there's any point to saying "Sometime in the future, we might add future-proofing."
- # [21:21] <ChrisL> :)
- # [21:21] <TabAtkins> dsinger: No, just that we might add a feature in the future that may require more generic handling, so don't depend on certain types of handling.
- # [21:22] * Joins: dbaron_ (dbaron@63.245.220.11)
- # [21:22] * Quits: dbaron (dbaron@17.244.2.46) (Ping timeout)
- # [21:23] <TabAtkins> howcome: There is no hole right now. You're creating a hole and then insisting it needs to be filled.
- # [21:23] <TabAtkins> anne: Paged Media doesnt' actually require them to be at the end.
- # [21:23] <TabAtkins> plinss: In my perspective, it's a bug in 2.1.
- # [21:24] <TabAtkins> plinss: In 2.1, we say when you see an @rule, swallow until the next block or semicolon. We don't say to do that only at the rule level.
- # [21:24] <TabAtkins> plinss: We need to make this clear one way or another. Bert's proposal is to say that applies only at the ruleset level, most others are saying apply at all levels.
- # [21:24] <TabAtkins> howcome: We have impl issues with that.
- # [21:25] <TabAtkins> plinss: We have an existing spec that needs @rules like this, and at least two more ideas I know of want that.
- # [21:25] <TabAtkins> Bert: But no one implements it like that anyway.
- # [21:25] <TabAtkins> plinss: Right. But my reading of CSS is that you throw away an invalid @ rule as a unit.
- # [21:26] <TabAtkins> Bert: Only at the toplevel.
- # [21:26] <TabAtkins> plinss: But CSS doesn't say that.
- # [21:26] <TabAtkins> howcome: This is a new situation. Bert is arguing *for* the browsers, Peter is arguing against?
- # [21:27] <TabAtkins> plinss: This isn't progressing. We'll get more examples. Until then we're not convincing anyone.
- # [21:27] <TabAtkins> szilles: Can we set a time for jdaggett's call? By my calc, 6am in Tokyo is 2pm here.
- # [21:27] <TabAtkins> szilles: Is 3pm okay for us (7am for him)?
- # [21:28] <TabAtkins> plinss: We have a lot of things for him to weigh in on.
- # [21:28] <TabAtkins> plinss: I'd like him as early as possible. I suggest we ask him when he's comfortable.
- # [21:28] * Joins: dino (dino@17.202.116.62)
- # [21:28] <TabAtkins> szilles: And then I"ll ask another Adobe employee to attend.
- # [21:28] <TabAtkins> <br type=lunch duration=1h>
- # [21:28] * Quits: glazou (glazou@17.244.0.83) (Quit: glazou)
- # [21:29] * Quits: bradk (bradk@17.244.0.81) (Quit: Computer has gone to sleep)
- # [21:29] * Quits: dbaron_ (dbaron@63.245.220.11) (Quit: 8403864 bytes have been tenured, next gc will be global.)
- # [21:29] * Quits: plinss__ (plinss@17.244.3.217) (Quit: plinss__)
- # [21:31] * Quits: smfr (smfr@17.244.1.194) (Quit: smfr)
- # [21:31] * Quits: Arron (arronei@17.244.2.216) (Ping timeout)
- # [21:32] * Quits: sylvaing (sylvaing@17.244.0.225) (Ping timeout)
- # [22:03] * Joins: dethbakin (dethbakin@17.244.64.200)
- # [22:07] * Quits: dethbakin (dethbakin@17.244.64.200) (Quit: dethbakin)
- # [22:37] * Joins: Lachy (Lachlan@85.196.122.246)
- # [22:39] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
- # [22:43] * Joins: bradk (bradk@17.244.0.81)
- # [22:43] * Joins: sylvaing (sylvaing@17.244.0.225)
- # [22:43] * Joins: dbaron (dbaron@63.245.220.11)
- # [22:44] * Joins: glazou (glazou@17.244.0.83)
- # [22:44] * Joins: plinss__ (plinss@17.244.3.217)
- # [22:45] * Joins: smfr (smfr@17.244.1.194)
- # [22:45] * Joins: Arron (arronei@17.244.2.216)
- # [22:46] * Quits: glazou (glazou@17.244.0.83) (Quit: glazou)
- # [22:47] * Quits: alexmog (alexmog@17.244.1.2) (Ping timeout)
- # [22:47] * Joins: alexmog (alexmog@17.244.1.2)
- # [22:47] * Joins: glazou (glazou@17.244.0.83)
- # [22:47] * Joins: ChrisL (ChrisL@128.30.52.169)
- # [22:49] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-114
- # [22:49] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-109
- # [22:49] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-26
- # [22:50] <fantasai> dbaron: The way the spec currently says that vertical-align in table cells works is
- # [22:50] <fantasai> ScribeNick: fantasai
- # [22:50] <fantasai> dbaron: You have a table
- # [22:50] <fantasai> dbaron: like this
- # [22:51] <fantasai> dbaron draws a table with 2 rows 2 cols
- # [22:51] <fantasai> dbaron: And you have a table cell likes this
- # [22:51] <fantasai> dbaron draws a cell box in the upper half of the first cell
- # [22:51] <fantasai> dbaron: The spec says ... and it says that the 'height' property sets the height of a cell box
- # [22:52] <fantasai> dbaron: Suppose it says the cell height is 200px
- # [22:52] <fantasai> dbaron: The cell box will be 200px
- # [22:52] <fantasai> dbaron: and if the row is 200px high
- # [22:52] <fantasai> dbaron: the cell box stays put, and its contents are clearly not vertical-align: bottom
- # [22:53] <fantasai> dbaron: Nobody does this, everybody aligns the contents to the bottom
- # [22:53] * Joins: jer (jer@17.244.2.51)
- # [22:53] <fantasai> s/.../vertical-align aligns the cell box inside the cell/
- # [22:54] * Parts: jer (jer@17.244.2.51)
- # [22:54] <fantasai> dbaron: There are 2 possible solutions here, with different implications, and different browsers pick different ones
- # [22:54] * Quits: ChrisL (ChrisL@128.30.52.169) (Ping timeout)
- # [22:54] <fantasai> dbaron: One alternative is to say that instead of 'height' setting the height of the cell box, it sets a minimal height for the row
- # [22:54] <fantasai> dbaron: The other solution is to say that you have two boxes
- # [22:55] <fantasai> dbaron: one of which wraps around the content, the other one of which wraps around that, and vertical-align aligns both of them, but the height only sets the height of the outer one
- # [22:55] <fantasai> dbaron: The tricky cases are where you have baseline alignment
- # [22:56] <fantasai> dbaron: You can get a case where baseline alignment requires more space than either cell would require alone
- # [22:56] <fantasai> dbaron: e.g. if you have a large-text box of auto height
- # [22:57] <fantasai> dbaron: and a small-text cell of large height
- # [22:57] <fantasai> dbaron: the baselines align
- # [22:57] <fantasai> dbaron: but the second box extends way below the bottom of the first
- # [22:57] <fantasai> dbaron draws this on the board
- # [22:58] <css_projector> http://dbaron.org/css/test/2010/css21-issue-26
- # [22:59] <fantasai> dbaron shows http://www.brunildo.org/test/td_height1.html
- # [23:00] <fantasai> fantasai: I would not expect vertical-align to increase the size of the cell there
- # [23:06] <fantasai> I would expect height to set the height of the same box that you paint borders and backgrounds on, not on the anonymous content holder inside it
- # [23:07] <smfr> http://www.w3.org/TR/CSS21/tables.html#height-layout
- # [23:10] <fantasai> fantasai: Does height include the padding?
- # [23:10] <fantasai> fantasai: border-widths?
- # [23:12] <fantasai> Looks like height in Mozilla is a border-box height
- # [23:14] * Joins: ChrisL (ChrisL@128.30.52.169)
- # [23:14] <fantasai> fantasai thinks we should say that the height sets the border-box height of the cell box
- # [23:14] * anne wonders why the efforts to describe the table layout model stopped
- # [23:14] <fantasai> The contents of the cell are wrapped in an anonymous box, and that is aligned inside the cell
- # [23:15] * fantasai because Markus swapped departments
- # [23:15] <fantasai> Alex: What do Mozilla and WebKit do for flexbox?
- # [23:15] <fantasai> dbaron: I'm not so concerned with that
- # [23:17] <fantasai> Steve: So you have two boxes, one that most properties apply to, and then the box that wraps the contents of the cell, that gets vertical-aligned
- # [23:17] <fantasai> Steve: The first box has border, padding, etc.
- # [23:19] <fantasai> dbaron: We should figure out what we want so that someone can write a proposal
- # [23:19] <fantasai> dsinger asks a question
- # [23:19] * sylvaing :nth-box-nth-removed { vertical-align:...
- # [23:19] <fantasai> dbaron: baseline alignment is a relative thing. You take all the cells in the row and baseline-align their contents.
- # [23:20] <fantasai> dbaron: If the height of the row is taller than the height of the aligned set of content, it's undefined what happens
- # [23:21] <fantasai> Steve: So your question is that ... can we give names to these things?
- # [23:21] <fantasai> dbaron: One of them is called the cell box, but it's not what you'd think of as the cell box
- # [23:25] <fantasai> dbaron: The simplest change it to go with IE and Opera and say that 'height' on the cell sets the minimum height of the row
- # [23:26] * anne ... it was dbaron and saloni writing it though
- # [23:26] * anne ... (each their own version)
- # [23:26] * fantasai not saloni, it was shuo
- # [23:26] * Quits: glazou (glazou@17.244.0.83) (Quit: glazou)
- # [23:26] * fantasai and it was because Markus was pushing it
- # [23:27] <anne> http://dev.w3.org/csswg/css3-tables-algorithms/Overview.src.htm
- # [23:28] * fantasai saloni's name is on their because she was supposed to take over, she didn't actually work on it much
- # [23:28] * fantasai shuo and markus and erika were the ones who actually did work on it
- # [23:28] <fantasai> howcome talks about making a bar chart
- # [23:29] <fantasai> dbaron: An explicit height on a table cell does not cause even the contents of that cell from increasing the height of the cell
- # [23:29] <fantasai> dbaron: Everything's like minimum heights in tables
- # [23:29] <fantasai> Alex agrees with Opera's interepretation
- # [23:30] <fantasai> Steve: If you want the other behavior, you can put a fixed height on a <div> inside
- # [23:30] <fantasai> plinss: Shouldn't require markup changes for layout
- # [23:31] <fantasai> fantasai: This is the most intuitive interpretation.
- # [23:32] <fantasai> fantasai: If I was an author, I'd associate the height of the table cell with the height of the box that has borders and backgrounds on it, not some invisible thing inside it
- # [23:32] <fantasai> ACTION: dbaron write proposal for IE-Opera behavior for issue 26
- # [23:32] * trackbot noticed an ACTION. Trying to create it.
- # [23:32] * RRSAgent records action 1
- # [23:32] <trackbot> Created ACTION-210 - Write proposal for IE-Opera behavior for issue 26 [on David Baron - due 2010-04-05].
- # [23:32] <fantasai> Simon: Hyatt doesn't really care which way this goes
- # [23:33] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-114
- # [23:35] * Joins: szilles (chatzilla@17.244.3.121)
- # [23:36] <fantasai> fantasai explains that the spec is unclear about what is allowed and what is invalid
- # [23:37] <fantasai> Arron has a bunch of testcases showing that results are very different across browsers
- # [23:38] <fantasai> There are two proposals for clarifying the spec
- # [23:38] <fantasai> one would make unquoted font names a series of identifier tokens
- # [23:38] <fantasai> the other would make them a series of nmchars tokens
- # [23:38] <fantasai> Chris suggests recommending quotes
- # [23:38] <fantasai> The spec already recommends quotes
- # [23:40] * Joins: dethbakin (dethbakin@17.246.18.154)
- # [23:40] * Quits: dethbakin (dethbakin@17.246.18.154) (Quit: dethbakin)
- # [23:40] * Joins: dethbakin (dethbakin@17.246.18.154)
- # [23:41] <fantasai> dbaron: right now in Gecko you have to escape or quote numbers
- # [23:43] * Joins: jer (jer@17.244.2.51)
- # [23:44] <fantasai> several: Let's allow everything
- # [23:44] <ChrisL> everything but comma
- # [23:44] <fantasai> fantasai: I don't like that, because you have to have some exceptions, which is what we have already, and it's already causing interop problems
- # [23:44] <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Mar/0395.html
- # [23:45] <fantasai> http://www.w3.org/TR/CSS21/fonts.html#font-family-prop
- # [23:46] <fantasai> Chris: How about making a grammar for what the prose already says
- # [23:47] * Quits: alexmog (alexmog@17.244.1.2) (Connection reset by peer)
- # [23:47] * Joins: alexmog (alexmog@17.244.1.2)
- # [23:50] <fantasai> discussion of what mistakes web authors are likely to make
- # [23:50] <ChrisL> some font families that might be useful for tests - "101 Dalmations" "3.14 Pi" "Twenty 4px"
- # [23:51] <fantasai> dbaron: right now the spec has document conformance reqs but no ua conformance reqs
- # [23:53] <fantasai> arron: If you run the testcases, you'll see a lot of constency except for numbers and brackets
- # [23:54] <fantasai> <br type=cookies>
- # [23:57] <fantasai> Topic: CSS2.1 Test Suite
- # [23:57] <fantasai> glazou: First issue is about inode strain on the server
- # [23:59] <fantasai> bert: it's not about space, it's our mirroring system
- # [23:59] <fantasai> Alex: Would adding another 15000 tests facilitate upgrading the system? :)
- # [23:59] <fantasai> Chris: It's generating emails to the mirrors for each file
- # Session Close: Tue Mar 30 00:00:00 2010
The end :)