/irc-logs / w3c / #css / 2008-10-19 / end

Options:

# Session Start: Sun Oct 19 00:00:00 2008
# Session Ident: #css
# [00:07] * Quits: anne (annevk@81.253.28.193) (Connection reset by peer)
# [09:12] * Joins: glazou (daniel@81.253.60.166)
# [09:15] * Joins: plinss_ (plinss@81.253.60.106)
# [09:17] * Joins: dbaron (dbaron@81.253.60.210)
# [09:20] <glazou> http://wiki.csswg.org/planning/mandelieu-2008
# [09:21] * Joins: Zakim (rrs-bridgg@128.30.52.30)
# [09:21] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
# [09:21] <RRSAgent> logging to http://www.w3.org/2008/10/19-css-irc
# [09:27] * Joins: anne (annevk@81.253.61.222)
# [09:36] * Joins: sylvaing (sylvaing@81.253.60.202)
# [09:39] * dbaron couldn't hear the observer's name
# [09:40] * anne same here, and i was sitting next to him :/
# [09:40] * Joins: jdaggett (jdaggett@81.253.60.209)
# [09:41] <dbaron> ScribeNick: dbaron
# [09:41] <dbaron> Scribe: David Baron
# [09:41] <glazou> http://wiki.csswg.org/planning/mandelieu-2008
# [09:41] <dbaron> Meeting: CSS Working Group Face-to-Face meeting
# [09:41] <dbaron> Topic: Agenda
# [09:42] <dbaron> Daniel: I just posted wiki URL. Request to discuss CSS2 system colors with another WG, probably tomorrow morning.
# [09:42] <dbaron> Daniel: Who is attending conflicting meetings?
# [09:42] <dbaron> Steve: I'm chairing another meeting on Tuesday.
# [09:42] <dbaron> Anne: I have Web Apps Monday and Tuesday; I'll try to alternate, but both don't have an agenda yet.
# [09:43] <dbaron> Daniel: To those who won't be here Monday/Tuesday, anything you want discussed today?
# [09:43] <dbaron> Anne: I want to attend the cross-WG one listed at the bottom of the page ("User control over UI").
# [09:43] <dbaron> Anne: "Special behavior of BODY" we could do, but it should be trivial.
# [09:44] <dbaron> Steve: My preference is that things like syntax and selectors occur on Tuesday.
# [09:44] <dbaron> Elika: Melinda wants paged media on Tuesday.
# [09:45] <dbaron> Steve: Although I'd prefer paged media not on Tuesday.
# [09:46] <dbaron> Anne: Dean Jackson wanted to discuss Apple proposals... he's not here now.
# [09:46] <dbaron> Daniel: maybe Monday
# [09:47] <dbaron> Anne: We'd like it as well, and Mozilla has implemented parts of it.
# [09:48] <dbaron> Daniel: <goes rapidly over list of topics>
# [09:48] <dbaron> Daniel: While everybody is here, we should probably discuss 2 things: (1) next f2f meetings
# [09:48] <fantasai> Topic: F2Fs next year
# [09:49] <dbaron> Peter: I'd like 4 2-day meetings.
# [09:49] <dbaron> Elika: ...
# [09:49] <dbaron> Steve: I think 3 3-day is more practical... especially given travel budgets.
# [09:49] <fantasai> Elika: That's tough for people travelling from far away
# [09:49] <dbaron> Daniel: What time of year?
# [09:49] * Joins: alexmog (alexmog@81.253.60.150)
# [09:50] <fantasai> Elika: It takes a couple days just to adjust to the new time zone
# [09:50] <fantasai> David: One issue we've had the past few years is that we've put the summer meeting late in the summer and thus very close to the fall meeting
# [09:50] <dbaron> Daniel: We could do February, June, November...
# [09:51] <dbaron> John: Can't confirm for sure, but could do one in Tokyo.
# [09:54] <dbaron> (February)
# [09:54] <dbaron> ?: Sophia-Antipolis in June?
# [09:54] <dbaron> Bert: My holidays are first half of June.
# [09:55] <dbaron> RRSAgent, make logs public
# [09:55] <RRSAgent> I have made the request, dbaron
# [09:55] <dbaron> Daniel: And TPAC in October/November.
# [09:56] * Quits: sylvaing (sylvaing@81.253.60.202) (Quit: sylvaing)
# [09:56] * Joins: sylvaing (sylvaing@81.253.60.202)
# [09:56] <dbaron> Daniel: Either Boston or Santa Clara.
# [09:57] <dbaron> Daniel: Let us know about days that are bad in Feb/Mar and late June.
# [09:57] <dbaron> Elika: I can't do second half of March.
# [09:58] <dbaron> Steve: Week of President's Day (US) can be a good week.
# [09:58] * Quits: sylvaing (sylvaing@81.253.60.202) (Quit: sylvaing)
# [09:59] <dbaron> Daniel: I think Haakon may have offered to host in Oslo...
# [10:00] <dbaron> Daniel: Tentative plan is Tokyo in Feb/Mar, Sophia-Antipolis in June, TPAC in US in Oct/Nov.
# [10:00] * Joins: sylvaing (sylvaing@81.253.60.202)
# [10:01] <fantasai> Daniel needs to check school vacation calendar, prefers to be home 25th of Feb
# [10:01] <dbaron> Daniel: I'd like to be home 25 Feb.
# [10:01] <fantasai> Anne: No constraints
# [10:01] <fantasai> Bert: First 2 weeks of June
# [10:01] <fantasai> Bert: can't do
# [10:02] <fantasai> Steve: June is difficult, but I can probably work around it
# [10:02] <fantasai> Daniel: I prefer after March 2nd
# [10:03] <fantasai> Alex: MSFT March 18-20 not a good time
# [10:03] <fantasai> David: I have a weak preference for avoiding US Government holidays
# [10:04] <fantasai> Peter: no constraints
# [10:04] <fantasai> John: no constraints
# [10:04] <fantasai> Elika: Not second half of March
# [10:04] <fantasai> Alex: Also SxSW is March 13-22
# [10:06] <fantasai> Discussing dates in June
# [10:07] <fantasai> Steve prefers week of 22n-26
# [10:08] <fantasai> Bert is returning on the 23rd
# [10:10] <fantasai> Elika: I can't do May 29-June1
# [10:11] <fantasai> Daniel: So, target 24-25-26 June 2009
# [10:12] <fantasai> Daniel: Target for 1st meeting, 2 first weeks of March
# [10:12] <fantasai> ACTION: glazou email w3c-css-wg with proposed dates and ask for comments/constraints
# [10:12] * trackbot noticed an ACTION. Trying to create it.
# [10:12] * RRSAgent records action 1
# [10:12] <trackbot> Created ACTION-113 - Email w3c-css-wg with proposed dates and ask for comments/constraints [on Daniel Glazman - due 2008-10-26].
# [10:13] <dbaron> Topic: Keeping web designers involved as invited experts
# [10:13] <fantasai> Topic: Web Designers as Invited Experts
# [10:13] <fantasai> Daniel: Jason Cranford Teague has left the WG
# [10:13] <fantasai> Daniel: Since his perpsective is exteremely valuable, we wanted to propose to keep him as an Invited Expert to the WG
# [10:14] <fantasai> Daniel: This raises an issue because AOL is the kind of company that could join the WG, but they are leaving the WG
# [10:14] <fantasai> Daniel: Jason was never really representing AOL as much as himself and the web designers, so I think it makes sense
# [10:14] <fantasai> Daniel: I understand from a W3C Process point of view it's difficult, but we really need web designers
# [10:15] <fantasai> Steve: I would support that. I agree that Jason's contributions are from the perspective of a designer, but I think the precedent it establishes in W3C is potentially dangerous
# [10:15] <fantasai> John: People who are very hard are people who are technically oriented, but ...
# [10:16] <fantasai> John: A lot of issues break down to implementation issues, there has to be a balance between making an implementation consistent etc. and what will make it useful and easy for designers
# [10:16] <fantasai> Daniel: That's a difficulty in this WG. A trivial proposal, a one-liner, can be extremely difficult to implement and most web designers don't understand that
# [10:16] <fantasai> Daniel: Jason says he has time
# [10:17] <fantasai> Bert: Has to pass Morrow and W3CM. He's clearly an AOL employee
# [10:17] <fantasai> Bert and Steve want him here, but are concerned about process stuff
# [10:17] <glazou> Mauro
# [10:17] <dbaron> s/Morrow/Mauro/
# [10:18] <dbaron> Elika: Other people?
# [10:18] <dbaron> Daniel: We already had this discussion... remember failure of CSS 11?
# [10:19] * Joins: MoZ (chatzilla@80.125.173.55)
# [10:21] <fantasai> Daniel: ... strictly speaking, it is difficult to make Jason an official Invited Expert
# [10:21] <fantasai> Daniel: but almost everything we do here is public, so he can still contribute
# [10:21] <fantasai> Steve: We have to be careful about IPR
# [10:24] <dbaron> (various discussion)
# [10:26] <fantasai> Topic: Margin Collapsing
# [10:26] <fantasai> Bert: Was wondering about margin collapsing in vertical
# [10:26] <fantasai> Bert: If you have a vertical block inside a horizontal one
# [10:27] <fantasai> Alex: That's a yes-or-no question. In our implementation they do collapse
# [10:27] <fantasai> David: You'd be making a new block formatting context
# [10:27] <dbaron> (break)
# [10:29] <fantasai> RESOLVED: make a new block formatting context when block direction switches, margins outside the bfc do collapse
# [10:35] * Quits: MoZ (chatzilla@80.125.173.55) (Ping timeout)
# [10:43] * Joins: MoZ (chatzilla@81.253.3.138)
# [10:45] * Quits: sylvaing (sylvaing@81.253.60.202) (Quit: sylvaing)
# [11:03] <dbaron> Topic: Special behavior of BODY
# [11:04] <dbaron> Daniel: Proposal by Simon Pieters is to make the body element in XHTML magic just like in HTML.
# [11:06] * Joins: mib_apftg8 (c0960ac8@67.207.141.120)
# [11:07] <dbaron> Anne: Was partly implemented per spec, marked at risk, implementations shifted back.
# [11:07] * Quits: mib_apftg8 (c0960ac8@67.207.141.120) (Quit: http://www.mibbit.com ajax IRC Client)
# [11:07] <fantasai> David: Originally everyone did what simon is proposing
# [11:07] <fantasai> David: Then the XHTML WG asked us to make this change, and some browsers followed
# [11:07] <fantasai> David: There are two different quirks. One for background, one for overflow
# [11:07] <fantasai> David: I think Mozilla followed both briefly
# [11:07] <fantasai> David: Webkit followed one but not the other
# [11:07] * Joins: sylvaing (sylvaing@81.253.6.77)
# [11:08] <fantasai> David: So we didn't have two implementations of both
# [11:08] * Joins: SteveZ (c0960ac8@67.207.141.120)
# [11:08] <fantasai> David: so we marked it at risk
# [11:08] <fantasai> David: Mozilla, Opera, and Webkit currently treat HTML body and XHTML body the same way
# [11:08] <fantasai> David: And simon has a test suite for this quirk stuff
# [11:09] <dbaron> Elika: Can we get these tests in the 2.1 test suite?
# [11:09] <fantasai> Elika: Anne, make sure they're in the right format and check them into svn?
# [11:10] <dbaron> David: HTML5 spec wants HTML and XHTML to be treated the same; don't know that it's been discussed in WG.
# [11:11] <dbaron> Alex: We don't do XHTML yet; would be easiest to not do anything special for XHTML.
# [11:11] <dbaron> Daniel: That sounds like a consensus?
# [11:11] <dbaron> Bert: I'd rather do the other way around, but...
# [11:11] <dbaron> Bert: I think it's ugly but it doesn't break anything.
# [11:11] <dbaron> Daniel: And it helps people who want to convert a Web page from HTML4 to XHTML.
# [11:12] <dbaron> Bert: But harder to convert to Docbook or other things.
# [11:12] <dbaron> Bert: I don't like it, but I don't think it's dangerous, just ugly.
# [11:12] <dbaron> Peter: I'd almost like to see a way of declaring in CSS that element N should have this behavior.
# [11:12] <dbaron> Anne: Seems too obscure to complicate the language.
# [11:13] <dbaron> Elika: Seems like a quirk that we just have to deal with for HTML.
# [11:13] <dbaron> Elika: It's there because of backwards-compatibility, not because it's useful.
# [11:14] <dbaron> Bert: But what happens if people create new formats that reuse parts of HTML?
# [11:14] <dbaron> Anne: If it's in the HTML namespace, then it will have the same special behavior.
# [11:14] <dbaron> Anne: ... if it meets all the requirements of being a body (second child of HTML element, or something...).
# [11:15] <dbaron> Daniel: The BODY is mandatory; you can't remove it.
# [11:15] <dbaron> David: You can remove it through the DOM.
# [11:17] <dbaron> (discussion)
# [11:17] <dbaron> David: We don't want to get into the discussion of what an HTML document is for the DOM.
# [11:18] <dbaron> Steve: If it's invalid, then interoperability is irrelevant.
# [11:18] <dbaron> Anne: You're confusing authoring requirements and user-agent requiremnets.
# [11:20] <dbaron> (discussion of HTML and DOM issues)
# [11:21] <dbaron> s/requiremnets/requirements/
# [11:26] <dbaron> Alex: Any concern about describing behavior of invalid documents?
# [11:26] <dbaron> Anne: Not at all unusual... e.g., style sheets missing closing }
# [11:27] <dbaron> Daniel: I abstain (no objection).
# [11:27] <dbaron> Anne, Elika, David, Alex: in favor
# [11:28] <dbaron> Anne: We should separate user-agent requirements and authoring requirements.
# [11:28] <dbaron> (in response to comment by Alex)
# [11:28] <dbaron> Daniel: ok, resolved.
# [11:29] <anne> http://www.w3.org/Style/css2-updates/issues-4-20061106.html#issue-31
# [11:29] <dbaron> RESOLVED: accept proposal in http://www.w3.org/Style/css2-updates/issues-4-20061106.html#issue-31
# [11:32] <dbaron> http://lists.w3.org/Archives/Public/www-style/2007Mar/0035.html
# [11:33] * Zakim excuses himself; his presence no longer seems to be needed
# [11:33] * Parts: Zakim (rrs-bridgg@128.30.52.30)
# [11:34] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-80
# [11:34] <dbaron> (Were we accepting the 17.5 changes as well?)
# [11:36] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-79
# [11:37] <dbaron> RESOLVED: accept proposal in http://www.w3.org/Style/css2-updates/issues-4-20061106.html#issue-31 (chapters 11 and 14 parts)
# [11:37] <dbaron> Topic: Margin collapsing (issue 79)
# [11:38] <dbaron> Alex: When min-height has an effect, it prevents the bottom margin of the element from collapsing with the bottom margin of its last child.
# [11:38] <dbaron> Alex: What exactly does this mean?
# [11:39] <dbaron> Alex: Does it mean that the element's height is exactly the min-height, or bigger?
# [11:39] <fantasai> ScribeNick: fantasai
# [11:39] <fantasai> Alex draws a blue rectangle.
# [11:39] <fantasai> Alex: Here we have a parent with some margin, and it has a child with some other margin
# [11:39] <fantasai> Alex draws a short margin below the blue box
# [11:40] <fantasai> Alex draws a red box inside the blue box, with a large margin that extends outside the box
# [11:41] <fantasai> Alex: If the height was not specified, the parent would be as big as its child, and their margins would collapse, and the box after it (Alex draws a green box below the margin)
# [11:41] <fantasai> would be after the collapsed margin.
# [11:41] <fantasai> Alex: What's going to happen if we add a min-height that is bigger than the natural height?
# [11:41] <fantasai> Alex: The parent box would grow
# [11:41] <fantasai> Alex: but the margins no longer collapse
# [11:41] <fantasai> s/margins/bottom margins/
# [11:42] <fantasai> Alex: What happens to the margins?
# [11:42] <fantasai> Alex: We have two options
# [11:42] <fantasai> Alex: We treat the min-height as height,
# [11:42] <fantasai> Alex: which causes us to ignore the bottom margin of the child
# [11:42] <fantasai> Alex: which means the effective margin is much smaller than before, and the green box moves higher
# [11:43] <fantasai> Alex: the other option is for the child's margin to be included in the parent's content box
# [11:43] <fantasai> Alex: so the parent box grows bigger than the min-height in order to contain the margin
# [11:44] <fantasai> Alex: and this is another interpretation of not collapsing the margins
# [11:44] <fantasai> Alex: I have two options here. I could go with Firefox's behavior (the former) which is the easiest to implement
# [11:44] <fantasai> Alex: Other option is to do the second option, which requires redoing size computation
# [11:45] <fantasai> David: You'd have a discontinuity
# [11:45] <fantasai> Elika: You have one in both cases
# [11:45] <dbaron> http://dbaron.org/css/test/2008/min-height-margin-collapse
# [11:45] <fantasai> Elika: In FF's case the green box jumps up once min-height takes effect
# [11:46] <fantasai> We look at dbaron's testcase
# [11:46] <fantasai> Alex: In this case it can become 200px or 400px
# [11:47] <fantasai> Alex: That would be the difference between the different options
# [11:47] <fantasai> Alex: Once the bottom margin doesn't collapse anymore, then you lose the distance between the bottom of this box and the next box
# [11:47] <glazou> (observer is Hartmut Glaser from NIC.br)
# [11:48] <fantasai> David: It seems to me that it should be 200px high but you should have a 200px margin as well
# [11:49] <fantasai> Elika: That wouldn't make sense if the parent's min-height would contain its child including its margin
# [11:50] <fantasai> Peter: What I don't want to see is the margin collapsing of the child change behavior based on whether the min-height is applying in this scenario...
# [11:50] <fantasai> Peter actually said something about large margins appearing and disappearing mysteriously
# [11:50] <fantasai> when you hit a discontinuity point
# [11:51] <fantasai> ...
# [11:52] <fantasai> David: In Oslo in 2003 we rewrote margin collapsing, and I didn't like that we introduced a discontinuity. We had a big discusison on how clearance, margin collapsing, and height computation
# [11:52] <fantasai> interact
# [11:53] <fantasai> Peter: If the height of an elemetn depends on the viewport width and resizing the window causes a giant margin to appear and disappear, nobody is going to be happy with that result
# [11:54] <fantasai> Alex: So I think we should include the margin in the parent's height
# [11:54] <fantasai> Steve: I realize the agreements reached in Oslo are very fragile, would doing what Alex says break those agreements?
# [11:54] <fantasai> David: No
# [11:55] <fantasai> Anne: So it seems all browsers are doing different things
# [11:58] <fantasai> ....
# [12:00] <fantasai> Alex: we could do Opera's solution (collapse the bottom borders even in the presence of min-height)
# [12:00] <fantasai> Elika: That would not make sense if the min-height is big enough to contain the margin
# [12:01] <fantasai> Alex: but its behavior is continuous
# [12:01] <fantasai> Discussion about what is intuitive
# [12:01] <fantasai> Steve: It really bothers me that we don't have any designers here
# [12:02] <fantasai> Steve: At least Alex's proposal is consistent with what happens when margin collapsing is turned off elsewhere
# [12:03] <fantasai> David: I think from a designer's pov parent-child margin collapsign was a mistake
# [12:03] <fantasai> Peter: There are cases where it makes esnes from a designer's pov
# [12:04] <fantasai> Peter: what doesn't make sense is the margin collapsing turning on and off for inexplicable reasons
# [12:05] <fantasai> ...
# [12:05] <fantasai> Peter: The margin of a box should not begin somewhere far below the box, it should always be attached
# [12:05] <fantasai> Elika: You're asking for partial collapsing
# [12:06] <fantasai> David: THat's what we decided never to do in Oslo
# [12:06] <fantasai> ...
# [12:06] <fantasai> Alex: Let's suppose the next element has a top margin of 300px, what will that margin collapse with?
# [12:07] <fantasai> Steve: It shouldn't make any difference, it will collapse with the collapsed result of what we get here
# [12:08] <fantasai> Steve tries to explain the margin collapsing model
# [12:10] <fantasai> Bert: What about when we introduce vertical-alignment?
# [12:10] <fantasai> Elika: We decided that that would create a new block formatting context, then you wouldn't collapse the parent and child margins
# [12:11] <fantasai> Alex: ... partial collapsing
# [12:11] <glazou> (sorry for the phone call, it's was my plumber, and no his name is NOT Joe :-)
# [12:12] <fantasai> Bert: That was the original intention, that you take the lowest of the bottom of the relevant margins
# [12:12] <fantasai> Anne: Is it really worth making margin collapsing that much more complicated?
# [12:14] <fantasai> discussion of usage of margins
# [12:15] <fantasai> Margin collapsing is designed not for layout, but for when you have a continuous flow of content: headings, paragraphs, etc
# [12:15] <fantasai> Elika; We have several options here, let's list them
# [12:15] <fantasai> A. Firefox's behavior, which to truncate to min-height
# [12:15] <fantasai> and ignore the child margin
# [12:16] <fantasai> B. Alex' 1st proposal, which is to growt include the child and min-height
# [12:16] <fantasai> C. Opera behavior: collapse margins, then apply min-height
# [12:16] <fantasai> D. Define partial collapsing
# [12:18] <fantasai> David: I don't think it's really partial collapsing that you want to define, it's putting the edge of an element in the middle of a margin collapse
# [12:18] <fantasai> David: But that's really a huge change at this point
# [12:18] <fantasai> Steve: Are there other cases where this happens?
# [12:18] <fantasai> David, Bert: THere are other cases with clear where something like this happens.
# [12:18] <fantasai> David: THe concept of clearance was created in the discussion I'm talking about
# [12:19] <fantasai> David: Before 2003 clearance didn't exist, clear just added a margin which then collapsed
# [12:19] <dbaron> It's not really partial collapsing -- it's making the top/bottom edge of an element be in the middle of its margin
# [12:19] <dbaron> but that's what we decided to avoid in 2003.
# [12:20] <fantasai> Alex: but floats...
# [12:20] <fantasai> David: We ended up saying that the position of a float can be in one of these places
# [12:20] <dbaron> To be clear, I really don't want to change the big stuff (i.e., go with (D)) at this point.
# [12:21] <fantasai> Elika: Do we have consensus on eliminating D?
# [12:21] <fantasai> Steve: No, because that's what would make the most sense from a designer's perspective
# [12:22] <fantasai> Alex: Min-height is as currently specified has a side-effect on margin collapsing that is not intuitive to the designer
# [12:22] <fantasai> Steve: I'm trying to think of reasons why a designer would set min-height
# [12:22] <fantasai> Alex: Let's try to come up with examples
# [12:23] <fantasai> Alex: maybe I have business cards, and I set min-width min-height to 2/3
# [12:23] <fantasai> Alex: so if someone's card has more info at least it shows
# [12:23] <fantasai> Steve: in that case I wouldn't want the child margins to spill outside the box
# [12:24] <fantasai> Alex: Say I have a series of paragraphs and a div around some of them
# [12:25] <fantasai> Alex: Don't want setting min-height to make the margins between the apragraphs to disappear
# [12:25] <dbaron> E. Say min-height != 0 always prevents collapsing.
# [12:26] <fantasai> Daniel: I use min-height all the time.
# [12:27] <fantasai> Daniel: I have a <pre>, and I want a minimum height for my code box
# [12:27] <dbaron> Designers aren't really using min-height in the wild because of IE support, I think.
# [12:29] <fantasai> everybody has a different idea of what designers would want for min-height and margin collapsing
# [12:29] <fantasai> fantasai posts to twitter and gives up trying to minute
# [12:31] <fantasai> Discuss dbaron's option E
# [12:31] <fantasai> Alex: That's what IE8 impelements, and I'm not convinced it's more intuitive
# [12:31] <fantasai> Alex: Min-height normally doesn't have any effect when the min-height is very small
# [12:33] * Quits: SteveZ (c0960ac8@67.207.141.120) (Quit: http://www.mibbit.com ajax IRC Client)
# [12:33] <fantasai> David: Using min-height along with an auto height has two uses
# [12:34] <fantasai> David: You're sayin to use the maximum of the content height and the given min-height
# [12:34] <fantasai> David: We dont' know which is going to be the normal case, it's different fro different uses
# [12:34] <anne> (in the case where you really want to use the margin of the parent you just use parent > :last-child { margin-bottom:0 } )
# [12:34] <fantasai> in some cases your base case using the content height, and the min-height is an exception
# [12:35] <fantasai> and in other cases your base case is the min-height, and the content height is the exception (for when there's too much content)
# [12:35] <fantasai> fantasai thinks that david baron's point here is really important!!!
# [12:40] <dbaron> So one other question is whether we want there to be differences between "height: auto; min-height: 200px" and "min-height: min-content; height: 200px"
# [12:45] <fantasai> Steve: We remove the line that says min-height turns margin collapsing off.
# [12:45] <fantasai> Steve: Then we still have the question of how margin collapsing behaves when it's on and min-height has an effect
# [12:46] <fantasai> RESOLVED: min-height does not turn off margin collapsing
# [12:47] <fantasai> fantasai is skeptical and reserves judgement
# [12:48] * Quits: plinss_ (plinss@81.253.60.106) (Quit: plinss_)
# [12:48] * Quits: jdaggett (jdaggett@81.253.60.209) (Quit: jdaggett)
# [12:48] <fantasai> LUNCH
# [12:48] * Quits: sylvaing (sylvaing@81.253.6.77) (Quit: sylvaing)
# [12:49] * Quits: dbaron (dbaron@81.253.60.210) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [12:50] * Quits: glazou (daniel@81.253.60.166) (Ping timeout)
# [12:51] * Quits: MoZ (chatzilla@81.253.3.138) (Ping timeout)
# [13:52] * Joins: jdaggett (jdaggett@81.253.18.52)
# [13:59] * Joins: MoZ (chatzilla@81.253.18.31)
# [14:04] * Joins: shepazu (schepers@128.30.52.30)
# [14:06] <jdaggett> shepazu: http://wiki.csswg.org/planning/mandelieu-2008
# [14:08] <shepazu> thanks, jdaggett
# [14:09] * Joins: plinss_ (plinss@81.253.19.37)
# [14:11] * Joins: glazou (daniel@81.253.19.75)
# [14:13] * Joins: sylvaing (sylvaing@81.253.19.77)
# [14:15] * Joins: SteveZ (51fd1277@67.207.141.120)
# [14:17] <SteveZ> This is a test
# [14:17] <fantasai> ScribeNick: SteveZ
# [14:17] * Joins: dbaron (dbaron@81.253.18.37)
# [14:18] <SteveZ> Issue: CSS2.1 issue 60 - Z index
# [14:18] * trackbot noticed an ISSUE. Trying to create it.
# [14:18] <trackbot> Created ISSUE-68 - CSS2.1 issue 60 - Z index ; please complete additional details at http://www.w3.org/Style/CSS/Tracker/issues/68/edit .
# [14:18] <fantasai> Elika: Issue #60 is that Appendix E conflicts with chapter 9 in the CSS2.1 text
# [14:20] <fantasai> http://dev.moonhenge.net/css21/spec/z-index/
# [14:21] <SteveZ> Start with 2.1. Stacking context–like behaviour
# [14:21] <dbaron> s/Issue:/Topic:/
# [14:26] <SteveZ> This topic is postponed until tomorrow
# [14:26] <SteveZ> so that Hixie can participate
# [14:27] <SteveZ> Topic: Value pseudo attribute
# [14:29] <SteveZ> DB: this came out of discussion on WhatWG list
# [14:29] <SteveZ> DB: there was a proposal to have text (specially identified) that can be typed over
# [14:30] <SteveZ> DB: Styling should specify how that text is specially identified
# [14:30] <SteveZ> DB: this is attribute like, but not actually an attribute
# [14:30] <SteveZ> AvK: This is sort of like a DOM attribute
# [14:31] <SteveZ> AvK: it seems to apply to placeholders
# [14:31] <SteveZ> DB: you could combine it with the focus selector
# [14:31] <fantasai> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016544.html
# [14:31] <anne> WebKit has implemented :-webkit-placeholder for this case. That works for focusing the input control as well and such.
# [14:32] <dbaron> http://lists.w3.org/Archives/Public/www-style/2008Oct/0144.html
# [14:32] <dbaron> but it would actually need input[:value=""]:not(:focus)
# [14:32] <SteveZ> DG: I was wrong to complain that it would be difficult to internationalize because this applies only to the content of an attribute
# [14:33] <SteveZ> AvK: When this facility (sample text) is added to HTML, then having a placeholder pseudo element would make sense
# [14:36] <SteveZ> BB: I find that having the placeholder disappear when a partial selection is done disturbing; I want to be able to select the text and cut it and paste it
# [14:36] <SteveZ> BB: the above point is really an HTML not a CSS point
# [14:37] <fantasai> Topic: Selectors
# [14:37] <SteveZ> Does the current Hover element apply to the parent if the child is outside of the display space of the parent
# [14:38] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/65
# [14:39] <anne> test
# [14:39] <SteveZ> DG: e.g. a child element is relatively positioned outside its structural parent
# [14:39] <anne> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%20div%3Ahover%20%7B%20background%3Ayellow%20!important%20%7D%20%3C%2Fstyle%3E%0D%0A...%3Cdiv%20style%3Dheight%3A50px%3Bwidth%3A50px%3Bbackground%3Alime%3E%0D%0A%3Cdiv%20style%3Dheight%3A50px%3Bwidth%3A50px%3Bbackground%3Ared%3Bposition%3Aabsolute%3Btop%3A40px%3Bleft%3A100px%3E%3C%2Fdiv%3E%0D%0A%3C%2Fdiv%3E
# [14:39] <anne> (that test tests the behavior)
# [14:39] <anne> (being discussed)
# [14:39] * Bert (About previous topic: If there is really no room to put the label next to the text box, then a compromise might be to put it inside, but in gray rather than black text. Safari's search box does that. Gray text looks less "selectable" than black text.)
# [14:40] <SteveZ> DG: all browsers do selection of the parent
# [14:41] <SteveZ> AM: I have an example where I show help text outside the button to which it applies and I want the hover to stay on if the cursor moves over the help text
# [14:41] <SteveZ> AvK: There are other examples which depend on this behavior
# [14:42] <SteveZ> DG: I want to be sure that the specification will make clear what a user should expect; in particular, that it is not just the physical position of the cursor that triggers hover behavior.
# [14:43] <SteveZ> DG and EE: this probably needs a note in the spec
# [14:43] <SteveZ> DB: you figure out which element would receive the event and that element and all its ancestors are in the hover state
# [14:44] <SteveZ> DB: you have to keep compatibility with hovering over a link or any of its descendents will keep the link in the hover state
# [14:46] <SteveZ> PL: we should define the hover processing in terms of event processing and accept that the specs that define event processing will say what elements are affected
# [14:47] <SteveZ> DB: the behavior of events on hidden elements is not consistent across browsers
# [14:47] <SteveZ> DB: SVG has a property called "pointer events" that may make sense to adopt at some point
# [14:48] <SteveZ> DB: right now this is massively undefined in the selector spec; I would favor more specification as would PL
# [14:49] <SteveZ> AvK: Say when the element is in "the hover state" (as defined by some spec) then the behavior is ....
# [14:49] <SteveZ> DB and EE: but is there a spec that defines "the hover state"
# [14:50] <SteveZ> DB: We can define things in terms of DOM level 2 events (a REC)
# [14:51] <SteveZ> DB: we are leaving the hit testing definition to some other spec, but we can define the rest now
# [14:52] <SteveZ> DB: why are we changing only hover and not "active"
# [14:52] <SteveZ> EE: "active" is not well defined
# [14:53] <SteveZ> EE: in IE an element remains active even after a click is released
# [14:53] <SteveZ> AM: this works on the iPhone
# [14:53] * Quits: jdaggett (jdaggett@81.253.18.52) (Quit: jdaggett)
# [14:53] <SteveZ> PL: thie activity persists during a load, but not forever.
# [14:54] <SteveZ> DB: does it matter that browsers have different behaviors for "active"
# [14:54] <SteveZ> EE: the differences are so subtle that it is OK
# [14:55] <SteveZ> DB: I am OK with differing when something begins being active and ends being active, but not with not saying whether the ancestors are active or not
# [14:56] <SteveZ> EE: I would say that "active" does not propogate up; e.g. clicking on something (a span) inside an anchor makes only the span active
# [14:56] <anne> data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><style> a:active { background:lime }</style><a href="test">a<a href="test">b<a href="test">c</a></a></a></html>
# [14:57] <SteveZ> AvK: active only applies to the element being activated is active, but in Mozilla and Webkit the ancestors are active as well
# [14:58] <SteveZ> AvK: I thnk that in Firefox, nested links have some anomolies in behavior
# [14:59] <SteveZ> EE: CSS does not define what elements get activated or for how long
# [15:00] <fantasai> or what triggers the activation
# [15:00] <SteveZ> DB: current spec says "while it is being activated" not "while it is active".
# [15:00] <fantasai> EE: e.g. clicking on something (a span) inside an anchor makes only the *anchor* active (not the span)
# [15:01] <fantasai> EE: and clicking on a triple-nested link should only apply :active to the link that's been activated
# [15:01] <SteveZ> DB: not sure that this is something that should be defined differently in different specs
# [15:02] <shepazu> SCXML and the SMIL State module define state (but I don't know if they are compatible with each other, much less what CSS would mean by "state")
# [15:02] <SteveZ> DS: (Doug Schepers): there are two specs that define states: SMIL and an SVG spec
# [15:02] <shepazu> s/SVG spec/MMI spec/
# [15:02] <dbaron> ScribeNick: dbaron
# [15:03] <dbaron> EE: So we want text for the :hover issue.
# [15:03] <glazou> s/we/I
# [15:03] <dbaron> EE: I'm ok with saying that the parent of an element that's :active is not necessarily :active, but that :hover is propagated to ancestors.
# [15:04] <anne> data:text/xml testcase as link http://annevankesteren.nl/test/css/temp/003.xml
# [15:05] <dbaron> BB: Leave it undefined for :active because we don't know what elements can be activated.
# [15:06] <anne> So I said that Opera activates the innermost link, where Firefox activates the outermost
# [15:06] <dbaron> DB: ?
# [15:06] <dbaron> DG: The original issue was just this one clarification.
# [15:06] <dbaron> DB: But it was a clarification about something that's explicitly undefined.
# [15:06] <dbaron> ScribeNick: SteveZ
# [15:06] <anne> And that what Opera does is currently specified in HTML5 and probably matches what IE does (you can test using submit buttons and links)
# [15:06] <SteveZ> BB: if an ancestor has a hover selector does that block propogation?
# [15:07] <SteveZ> PL: no, the existance of selectors is indpendent of event propogation
# [15:08] <SteveZ> BB: if you have two ancestors with pop-ups on hover, you will get both unless the first one blocks propogation
# [15:09] <fantasai> proposal: t
# [15:09] <fantasai> If an element that is ':hover' causes its parent to
# [15:09] <fantasai> be in ':hover', then it is possible for an element that is not underneath
# [15:09] <fantasai> the pointing device is in ':hover'.
# [15:10] <fantasai> If an element that is ':hover' causes its parent to
# [15:10] <fantasai> be ':hover', then it is possible for an element that is not underneath
# [15:10] <fantasai> the pointing device to be ':hover'.
# [15:11] <glazou> if :hover applies to an element causes :hover apply to the parent element, then it's possible :hover applies to an element that is not underneath the pointing device
# [15:14] <SteveZ> BB: the typical use case for "hover" is to indicate what can be activated so only the things that can be activated should be in hover; not all ancestors
# [15:14] <fantasai> If it's possible for ':hover' to apply to an element because its
# [15:14] <fantasai> child is designated by a pointing device, then it's possible for
# [15:14] <fantasai> ':hover' to apply to an element that is not underneat the pointing
# [15:14] <fantasai> device.
# [15:14] <fantasai> If it's possible for ':hover' to apply to an element because its
# [15:14] <fantasai> child is designated by a pointing device, then it's possible for
# [15:14] <fantasai> ':hover' to apply to an element that is not underneat the pointing
# [15:14] <fantasai> device.
# [15:15] <SteveZ> DB: the WG did not resolve that hover was heirarchical but with IE8 all implementations seem to make it hierarchical
# [15:16] <SteveZ> N.B. the above text by fantasai is intended as a NOTE
# [15:16] * Quits: alexmog (alexmog@81.253.60.150) (Ping timeout)
# [15:16] <fantasai> checked in
# [15:16] <fantasai> RESOLVED: proposal above accepted
# [15:17] <dbaron> http://dbaron.org/css/test/sec051103b is a testcase for hierarchical :hover
# [15:17] <dbaron> (and :active)
# [15:17] <SteveZ> Topic: Grammer for an+b for nth child
# [15:21] <SteveZ> DG: although whether hover applies to ancestors is officially undefined; millions of websites would break if it were otherwise defined
# [15:21] <shepazu> I'd just like to note that you could define "hovered" as being defined by the host language
# [15:22] <glazou> http://www.w3.org/Style/CSS/Tracker/issues/66
# [15:22] <shepazu> then it's out of the CSS's problem
# [15:22] <shepazu> s/out of /not /
# [15:24] <dbaron> You want the n, the even, and the odd to be written using the {n}, {o}, etc. productions from the grammar
# [15:24] <SteveZ> EE: we had already resolved where white space is allowed: not between a unary operator and the integer to which it applies nor between the integer and the "n"
# [15:25] <dbaron> and it would be nice to indent so the [] and () don't line up with the | because they look a lot like |
# [15:25] <SteveZ> DB: the odd and even need to be case insensitive
# [15:26] <SteveZ> DG: the 'n' is escapable, but not the "+" or "-"
# [15:26] <dbaron> (since units are escapable, but sign is not... right?)
# [15:27] <SteveZ> Resoved: the proposed grammer is accepted, with the modification to allow the 'n' is escapable.
# [15:27] <fantasai> s/Resolved/RESOLVED/
# [15:27] <SteveZ> Topic: ::selectors
# [15:27] <dbaron> Ah, so we haven't had the pseudo-element argument for a few years, so we need to do it again...
# [15:28] * Quits: anne (annevk@81.253.61.222) (Ping timeout)
# [15:28] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/67
# [15:30] <fantasai> ScribeNick: fantasai
# [15:30] <fantasai> David: Pseudo-elements have this thing where their boundaries don't line up with the tree
# [15:31] <fantasai> David: The question is do you split the into 2 pieces, or do you split the pseudo-element into 2 pieces?
# [15:31] <fantasai> David: The current spec says you split the pseudo-element
# [15:31] <SteveZ> DB: pseudo elements have boundaries that do not necessarily match the boundaries of the mark-up; which is split: the pseudo element or the real element?
# [15:31] <fantasai> Daniel: Can the pseudo-element contain more than pcdata and replaced elements?
# [15:32] <fantasai> Peter: you could have a selection, for example in the example in 67
# [15:32] <fantasai> Peter: you can't contain the children and still be well-formed
# [15:32] * Joins: alexmog (alexmog@81.253.60.150)
# [15:32] <dbaron> The question is: Does A<pseudo>BC</pseudo> give the tree A<pseudo>B</pseudo><pseudo>C</pseudo> or A<pseudo>BC</pseudo>?
# [15:33] <fantasai> Peter: the HTML5 spec might say something about this, wrt malformed markup
# [15:33] <fantasai> Peter: In this scenario, what you get with the pseudo-element should always be describable as valid tree markup
# [15:33] <fantasai> Daniel: It's describable as a DOM range
# [15:33] <anne> ls
# [15:34] <anne> sorry about that
# [15:34] <fantasai> David: The problem is that many CSS properties, including inheritance, are defined in terms of a tree
# [15:34] <fantasai> Daniel: Question remains, do I have multiple outlines for richtext::selection?
# [15:35] <fantasai> ...
# [15:35] <fantasai> David: What Mozilla actually implements now, I think, is something that sounds even more complicated than these two
# [15:35] <fantasai> David: We do both
# [15:35] <fantasai> David: We do one for the inherited properties and one for the non-inherited properties
# [15:36] <SteveZ> DB: Mozilla implements that 3rd option: it treats the inherited and non-inherited properties
# [15:36] <fantasai> Daniel: I wonder if we should just remove outline from the list of properties allowed?
# [15:36] <SteveZ> differently
# [15:37] <fantasai> David: I'm not even sure if that's quite what we do
# [15:37] <anne> http://annevankesteren.nl/test/css/temp/004.xml
# [15:37] <fantasai> Anne: Opera doesn't apply outline at all
# [15:37] <SteveZ> BB: in David's solution "outline" is an outer thing so goes around the whole thing and "color" is an inner thing so it would be inside the markup elements
# [15:42] <fantasai> Anne: It seems nobody implements outline
# [15:45] <dbaron> Peter: What about p::selection { color: inherit } ?
# [15:47] * Joins: mollydotcom (mollyholzs@70.176.234.187)
# [15:48] <SteveZ> DB: Warning: at some point I may want to propose styling of multiple ranges
# [15:48] <SteveZ> DB: "background" is non-inherited so its behavior would be the same as that for "outline"
# [15:48] <dbaron> I think for ::selection it's important that the ::selection is innermost for the 'color'.
# [15:50] <SteveZ> AvK: if there is a span::selecction it should apply; it does in Opera but not in Firefox
# [15:51] <dbaron> With ::selection, do you ever get <p::selection><span::selection>sel</span::selection></p::selection>, or something else?
# [15:51] <glazou> hey mollydotcom!!!!
# [15:51] <mollydotcom> greetings all
# [15:51] <dbaron> and how do global ::selection styles interact with that?
# [15:52] <mollydotcom> catching up on the topic, having tea to wake up, be with you all in a bit
# [15:52] <fantasai> David: Suppose you have a selection that includes an element that is 20 levels nested
# [15:52] <dbaron> If you have a ::selection{} rule and your selection is in an element 20 levels nested within the tree, and your background color is rgba(255, 0, 0, 0.2), what happens?
# [15:52] <dbaron> Do you have 20 pseudos?
# [15:53] <fantasai> If you have p::selection and you set a color on it
# [15:53] <fantasai> And you have a span inside the p, you want the selection inside the span to have the color you set on p::selection
# [15:54] <fantasai> (that was dbaron, btw, not me)
# [15:55] <fantasai> David: So this is not a tree-based approach. How do you deal with inheritance?
# [15:55] <dbaron> p::selection { color: blue } span { color: purple; }
# [15:55] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
# [15:55] <dbaron> Text << text span text >> text.
# [15:55] <dbaron> we want the "span" to be blue rather than purple
# [15:57] <dbaron> We definitely don't want to distinguish "in the selection" from "contains the selection" because it can be half and half.
# [15:57] <dbaron> What about 'color: inherit' ?
# [15:59] <fantasai> Peter points out that Daniel's concept of a global selection is incompatible with the idea of styling p::selection and span::selection differently
# [16:00] <fantasai> Steve: A selection is a set of DOM ranges.
# [16:00] <fantasai> Steve: That's the One Selection
# [16:01] <fantasai> Steve: Then there's the issue of how to style it
# [16:01] <fantasai> Steve: THe proposal is to style it as if the selection is not there
# [16:01] <fantasai> Steve: Then go back and for the pieces that fall into the range, you restyle them
# [16:01] <fantasai> Anne: That's not desired for the span case because then p::selection would not apply to the span nested inside the p
# [16:04] <fantasai> David: I think it would help to have concrete examples
# [16:04] <SteveZ> DG: I will come up with a list of requirements for what ::selection should and should not do
# [16:05] <SteveZ> DG: one requirement is that we do not want nested outlines
# [16:05] <SteveZ> DG: we want color to nest locally
# [16:06] <SteveZ> ACTION: (DG) develop requirements for ::selection behavior
# [16:06] * trackbot noticed an ACTION. Trying to create it.
# [16:06] <trackbot> Sorry, couldn't find user - (DG)
# [16:06] * RRSAgent records action 2
# [16:07] <Bert> How about: insert <::selection> at the start, </::selection> before every tag, <::selection> after every tag, and </::selection> at the end: ...........<<<<::>.......</::><::> </::><::>......</::><::>......</::>>>>.......
# [16:07] <dbaron> http://dbaron.org/css/test/sec051103b is a testcase for hierarchical :hover
# [16:07] <Bert> (and then think about 'outline' separately)
# [16:07] <SteveZ> ACTION:glazou, develop requirements for ::selection behavior
# [16:07] * RRSAgent records action 3
# [16:15] <mollydotcom> I look at this and try to imagine designers having a clue. It isn't working.
# [16:18] <mollydotcom> just bear in mind designers want very explicit control of every piece within a given selection
# [16:20] * Quits: sylvaing (sylvaing@81.253.19.77) (Quit: sylvaing)
# [16:33] <SteveZ> This is a test
# [16:33] * Quits: SteveZ (51fd1277@67.207.141.120) (Quit: http://www.mibbit.com ajax IRC Client)
# [16:34] * Joins: SteveZ (51fd1277@67.207.141.120)
# [16:35] <SteveZ> WG resumes at 4:30PM
# [16:36] <SteveZ> Topic: First line, First letter pseudoelements
# [16:36] <glazou> http://lists.w3.org/Archives/Public/www-style/2006Jan/0209.html
# [16:38] * Joins: sylvaing (sylvaing@81.253.29.40)
# [16:38] * anne test!
# [16:39] * Bert test received
# [16:39] * Joins: anne (annevk@81.253.61.222)
# [16:39] <glazou> http://lists.w3.org/Archives/Public/www-style/2006Jan/0091.html
# [16:40] <fantasai> David: I think this is what we solved by doing the inherited/non-inherited properties split
# [16:40] <fantasai> David: He put a display property on the :first-line and then display:inhert on a span in the first line
# [16:40] <glazou> http://lists.w3.org/Archives/Public/www-style/2005Oct/0163.html
# [16:40] <dbaron> http://lists.w3.org/Archives/Public/www-style/2005Oct/0163.html
# [16:41] <fantasai> David: What we used to do on this test case was crash
# [16:44] <fantasai> David looks up what exactly Mozilla does here
# [16:47] <fantasai> David: If you have property: inherit; on an element that is inside the :first-line, then we don't inherit from the :first-line
# [16:48] <fantasai> David: for non-inherited properties
# [16:48] <fantasai> David: The effective change for this is only when the 'inherit' keyword is used on a non-inherited property
# [16:49] <fantasai> David: That's a very uncommon case
# [16:49] <fantasai> David: It's possible we want to change the behavior on more common cases
# [16:49] <fantasai> David: like a tiled background image on ::first-line
# [16:50] <fantasai> David reviews the spec
# [16:50] <fantasai> David: no, that's should probably work...
# [16:53] <fantasai> David: So how should we be changing the spec to try to address this?
# [16:53] <SteveZ> DG: The current spec says that the span is split into two separate boxes
# [16:53] <glazou> s/DG/DB ?
# [16:54] <SteveZ> DG: How should the spec be changed to allow/require what Mozilla does?
# [16:54] <fantasai> David: Do we want to say what Mozilla does with inheritance is allowed, or required, or it's undefined, or make another change
# [16:54] <fantasai> Alex: IE does exactly what Mozilla does at this point.
# [16:54] <SteveZ> AM: it appears that IE does what Mozilla does at this point
# [16:54] <fantasai> Alex: inheritance comes not from the pseudo-class but from the actual parent
# [16:54] <fantasai> David: but for an inherited property like color?
# [16:55] <fantasai> Alex: doesn't inherit
# [16:55] <SteveZ> s/DG/DB/
# [16:56] <fantasai> David inspects Alex's testcase
# [16:57] <Bert> (Is it the case that proeprties that don't apply to :first-line are also not inherited from :first-line? Or are only non-inherited properties not inherited?)
# [16:57] <fantasai> only non-inherited properties are not inherited
# [16:58] <SteveZ> DB: explicit inheritance of non-inherted properties ignores the firstline and firstchar properties in computed the inherited value
# [17:00] <SteveZ> DB: inheritence of inherited properties do use the properties of firstline where relevant
# [17:03] <SteveZ> EE: the split between non-inheritable properties do not inherit from the pseudo element properties and inheritable properties do inhert makes sense
# [17:04] <SteveZ> AM: background and text decoration are safe to inherit
# [17:04] <SteveZ> BB and DB: position and float are not safe to inherit
# [17:05] <SteveZ> DB: if you set "whitespace: nowrap" this may change the firstline behavior (beyond just the inheritance question).
# [17:06] <SteveZ> BB: The keyworld inherits from either the parent of the first line or the firstline; which should be used?
# [17:07] <SteveZ> BB: one rule might be to inherit from the firstline if the property is applicable to the firstline and the parent otherwise.
# [17:13] <SteveZ> suggested text: The portion of a child element that occurs on the first line inherits properties applicable to the firstline pseudo element; for properties not applicable to the firstline pseudo element, the inheritence is from the parent of the first line pseudo element
# [17:15] <fantasai> s/parent/non-pseuo-element parent/
# [17:16] <SteveZ> add: The portion of a child element that does not occur on the first line always inherits from the parent of that child.
# [17:16] <fantasai> RESOLVED: proposal above accepted
# [17:20] <SteveZ> DB: Firefox does not have the same rules for firstletter because firstletter is not layout based; it is only storage order based
# [17:22] <SteveZ> Many: but, note that a quote followed by a character whose bidi order is opposite from the context in which the quote occurs may separate the quote and the following letter by the rest of the embedded bidi string
# [17:25] * Joins: jdaggett (jdaggett@81.253.27.176)
# [17:26] * Parts: sylvaing (sylvaing@81.253.29.40)
# [17:26] <glazou> ======== ADJOURN FOR TODAY ===========
# [17:28] * fantasai wants ideas for http://lists.w3.org/Archives/Public/www-style/2008Sep/0142.html yo
# [17:28] <mollydotcom> Have some fun tonight for me . . . any good restaurants on the plan?
# [17:28] <Bert> We were just discussing l'Ermitage du Riou...
# [17:29] <mollydotcom> Bert: Yes, yes, didn't Peter say he had a little room on that HP credit card? ;)
# [17:29] <mollydotcom> It's a wonderful restaurant
# [17:30] * plinss_ conducted the credit card stress test last night :-)
# [17:30] <mollydotcom> plinss_ and it's not even officially day one of TP/AC
# [17:30] * plinss_ will have to wait for peer review before concluding it was a success
# [17:30] <mollydotcom> you gotta be ready for the long haul
# [17:30] <mollydotcom> hehe
# [17:30] <mollydotcom> enjoy, enjoy. I will be vicariously enjoying through you
# [17:31] <mollydotcom> and back as time zones permit
# [17:31] * mollydotcom waves to all
# [17:31] * fantasai waves
# [17:31] * mollydotcom is now known as mollydotcom_afk
# [17:31] * glazou waves back
# [17:34] * Quits: glazou (daniel@81.253.19.75) (Ping timeout)
# [17:35] * Quits: MoZ (chatzilla@81.253.18.31) (Ping timeout)
# [17:41] * Quits: plinss_ (plinss@81.253.19.37) (Quit: plinss_)
# [17:41] * Quits: alexmog (alexmog@81.253.60.150) (Quit: alexmog)
# [17:43] * Quits: jdaggett (jdaggett@81.253.27.176) (Quit: jdaggett)
# [18:01] * Quits: dbaron (dbaron@81.253.18.37) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [18:04] * Quits: SteveZ (51fd1277@67.207.141.120) (Quit: http://www.mibbit.com ajax IRC Client)
# [18:06] * Quits: anne (annevk@81.253.61.222) (Ping timeout)
# [18:42] * Quits: mollydotcom_afk (mollyholzs@70.176.234.187) (Quit: Quitting!)
# [19:24] * Joins: myakura (myakura@122.29.60.226)
# [19:36] * Quits: myakura (myakura@122.29.60.226) (Quit: Leaving...)
# [22:37] * Quits: arronei (arronei@131.107.0.74) (Ping timeout)
# [22:43] * Joins: arronei (arronei@131.107.0.73)
# Session Close: Mon Oct 20 00:00:00 2008

The end :)