IRC log of css on 2008-10-19

Timestamps are in UTC.

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