IRC log of CSS on 2010-08-04

Timestamps are in UTC.

15:22:03 [RRSAgent]
RRSAgent has joined #CSS
15:22:03 [RRSAgent]
logging to
15:22:11 [glazou]
Zakim, this will be Style
15:22:11 [Zakim]
ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 38 minutes
15:22:20 [glazou]
RRSAgent, make logs public
15:22:34 [dbaron]
dbaron has joined #css
15:30:00 [dydz]
dydz has joined #css
15:53:18 [arronei]
arronei has joined #CSS
15:54:33 [arronei]
arronei has joined #CSS
15:55:48 [glazou]
Zakim, code ?
15:55:48 [Zakim]
the conference code is 78953 (tel:+1.617.761.6200 tel:+ tel:+44.203.318.0479), glazou
15:55:56 [Zakim]
Style_CSS FP()12:00PM has now started
15:56:03 [Zakim]
15:56:21 [Zakim]
15:57:03 [dsinger_]
dsinger_ has joined #css
15:57:13 [glazou]
Zakim, mute dsinger
15:57:13 [Zakim]
dsinger should now be muted
15:57:17 [dsinger_]
zakim, mute dsinger
15:57:17 [Zakim]
dsinger was already muted, dsinger_
15:57:37 [glazou]
np, the noise was too loud
15:57:43 [dsinger_]
zakim, who is here?
15:57:44 [Zakim]
On the phone I see glazou, dsinger (muted)
15:57:44 [Zakim]
On IRC I see dsinger_, arronei, dbaron, RRSAgent, Zakim, glazou, Curt`, bradk, nimbupani, miketaylr, shepazu, dsinger, TabAtkins_, karl, fantasai, krijnh, plinss_, lhnz, Bert,
15:57:49 [Zakim]
... Peter`, tabatkins, trackbot, plinss, Hixie, jgraham
15:57:51 [sylvaing]
sylvaing has joined #css
15:57:58 [nimbupani]
nimbupani has left #css
15:58:47 [Zakim]
15:58:52 [oyvind]
oyvind has joined #css
16:00:17 [arronei]
zakim, microsoft is me
16:00:17 [Zakim]
+arronei; got it
16:00:34 [Zakim]
16:01:47 [Zakim]
16:02:24 [Zakim]
16:02:51 [Zakim]
16:03:31 [Zakim]
+ +1.650.766.aaaa
16:03:47 [glazou]
Zakim, aaaa is bradk
16:03:47 [Zakim]
+bradk; got it
16:03:49 [Zakim]
16:04:00 [smfr]
smfr has joined #css
16:04:09 [Zakim]
16:04:10 [Zakim]
16:04:41 [glazou]
Zakim, P16 is fantasai
16:04:41 [Zakim]
sorry, glazou, I do not recognize a party named 'P16'
16:04:49 [glazou]
Zakim, ?P16 is fantasai
16:04:49 [Zakim]
sorry, glazou, I do not recognize a party named '?P16'
16:05:01 [glazou]
Zakim, you're annoying
16:05:01 [Zakim]
I don't understand 'you're annoying', glazou
16:06:01 [dsinger_]
Zakim, p16 is fantasai
16:06:01 [Zakim]
sorry, dsinger_, I do not recognize a party named 'p16'
16:06:20 [dsinger_]
zakim, who is on the phone?
16:06:20 [Zakim]
On the phone I see glazou, dsinger (muted), arronei, plinss_, [Microsoft], Bert, sylvaing, bradk, smfr, ??P16, SteveZ
16:06:48 [dsinger_]
Zakim, ??p16 is fantasai
16:06:48 [Zakim]
+fantasai; got it
16:06:48 [JohnJansen]
JohnJansen has joined #css
16:06:51 [fantasai]
Administrative: no more agenda items
16:06:57 [fantasai]
Topic: CSS Test Suite
16:07:09 [glazou]
Zakim, [Microsoft] has JohnJansen
16:07:09 [Zakim]
+JohnJansen; got it
16:07:20 [fantasai]
arronei: Lots of tests need updating in response to review comments. Plan to get these done before the F2F.
16:07:24 [fantasai]
Topic: CSS2.1
16:07:25 [glazou]
16:07:49 [Zakim]
16:08:07 [fantasai]
glazou: Asked everyone to review issue 120, and if no comments, it's accepted
16:08:26 [fantasai]
glazou: Are there any comments?
16:08:27 [szilles]
szilles has joined #css
16:08:45 [fantasai]
Bert: I just sent my review of the text. I had three places where I didn't agree with the replacements.
16:09:16 [fantasai]
16:11:34 [fantasai]
Bert: block-level is not defined
16:12:05 [fantasai]
Bert: second issue is the definition of atomic inline box
16:12:14 [fantasai]
Bert: I'm wondering if it's necessary -- it's only used in one place
16:13:25 [fantasai]
fantasai: That seems alright to me.
16:13:55 [fantasai]
Steve: I'm fine with that as a resolution. However if we ever get around to Tab's split of the 'display' property or something similar, it would be a useful term to have.
16:14:06 [fantasai]
Steve: The concept is a useful one for people to understand
16:15:18 [Zakim]
16:15:25 [dsinger]
zakim, [apple] has dsinger
16:15:25 [Zakim]
+dsinger; got it
16:15:43 [fantasai]
fantasai agrees with Steve
16:15:45 [Zakim]
16:16:08 [fantasai]
Steve: If there's no harm in introducing it here, it could be useful in the future.
16:16:48 [fantasai]
Bert: My third comment is wrt its use in the z-index property description, where I don't think we should use it.
16:17:00 [fantasai]
Bert: So we would define the term but not use it anywhere in CSS2
16:17:14 [fantasai]
Steve: That's fine, I think just the recognition that there is such a thing would be useful.
16:17:41 [fantasai]
Bert: The other changes seem fine to me.
16:18:51 [fantasai]
fantasai: There were some comments on the mailing list, mostly editorial, about improving the text there. I will need to incorporate those as well.
16:18:53 [glazou]
16:19:03 [fantasai]
RESOLVED: Proposal for 120 accepted with changes mentioned above.
16:19:42 [fantasai]
Bert's response to 167:
16:19:49 [Zakim]
+ +1.650.214.aabb
16:19:55 [TabAtkins_]
Zakim, aabb is me
16:19:55 [Zakim]
+TabAtkins_; got it
16:19:59 [glazou]
hi tabatkins
16:20:21 [fantasai]
Bert: In some cases a backslash is not an escaping mechanism.
16:20:49 [fantasai]
Bert: The way he defines that is to say it has "no special meaning", and then defines "no special meaning" inside a note, which is a non-normative part.
16:21:09 [fantasai]
Bert: Otherwise I think his changes are fine, other than the non-normative part.
16:21:26 [fantasai]
Bert: I would rather not define "no special meaning", but instead just say that the backslash stands for itself directly.
16:21:45 [fantasai]
glazou: Other comments?
16:22:34 [fantasai]
fantasai: I agree with Bert's changes, and I trust Bert to have made sure the proposal is correct
16:22:53 [glazou]
16:22:55 [fantasai]
RESOLVED: Proposal accepted for issue 167 as corrected by Bert
16:23:32 [fantasai]
Steve: Basically I went back and looked at OpenType standard, and then checked with some font guys at Adobe to make sure I understood it.
16:23:57 [fantasai]
Steve: THe catch is, the em-box a) isn't really defined, other than to say that the coordinate system used in other values is given in units per em
16:24:09 [fantasai]
Steve: and b) its position is not really defined
16:24:29 [fantasai]
Steve: The ascent and descent values which dbaron mentioned are related to this
16:24:53 [fantasai]
Steve: There are three sets of such values
16:24:59 [fantasai]
Steve: One that tends to be Mac-centric
16:25:05 [fantasai]
Steve: One set tends to be Windows-centric
16:25:23 [fantasai]
Steve: And the third set, were put in to be platform independent.
16:25:37 [fantasai]
Steve: Those should be used if they exist.
16:25:49 [fantasai]
Steve: Then it's recommended that the distance between them equal one em, but it's not required.
16:26:00 [fantasai]
Steve: There are fonts for which it doesn't hold.
16:26:25 [Zakim]
16:26:27 [fantasai]
Steve: I suggest the difference between that and an em be split, half above and half below, just like leading
16:26:43 [Zakim]
16:26:45 [fantasai]
Steve: The last point is, the reason you need to do that is that leading + embox = line height.
16:27:30 [fantasai]
glazou: Do you mean we can't rely on the font's definitionof embox because it doesn't exist?
16:27:40 [fantasai]
Steve: Right. I didn't get as far as suggesting a rewording of the text.
16:27:47 [fantasai]
Steve: I got hung up on what centering meant.
16:28:34 [fantasai]
Bert: I can come up with wording for that.
16:28:47 [fantasai]
Bert: I have one concern which is, this applies to OpenType, but what about other font formats?
16:29:14 [fantasai]
Steve: I think the general approach I talk about works for any font with ascent and descent information. We assume that information exists.
16:29:29 [fantasai]
dbaron: We could say more broadly for any font that has any measurement relating the baseline to the edges of it
16:29:51 [fantasai]
dbaron: What Steve describes matches what we implement more than Bert's definition.
16:30:11 [fantasai]
dbaron: Although we never calculate the em-box, we just use the ascent and descent direction -- which is a shortcut for the same results.
16:30:27 [fantasai]
Bert: Do we still keep the references to OpenType fields?
16:30:34 [fantasai]
Steve: I would put it in an appendix or a note.
16:31:52 [dbaron]
s/descent direction/descent and compute the half-leading differently/
16:31:53 [fantasai]
fantasai: I would suggest putting the field names in a note, but using ascent and descent generically in the normative text.
16:33:03 [fantasai]
Brad would like to make sure there's interop for the use of OpenType tables.
16:33:09 [fantasai]
Steve suggests writing a test.
16:33:50 [fantasai]
Bert: I think we can't make this more precise wrt OpenType in CSS2.
16:33:58 [fantasai]
glazou: Do you have enough to come up up with wording?
16:34:01 [fantasai]
Bert: I think so
16:34:20 [fantasai]
ACTION: Bert to write updated proposal for 167
16:34:20 [trackbot]
Created ACTION-247 - Write updated proposal for 167 [on Bert Bos - due 2010-08-11].
16:34:52 [fantasai]
glazou: Any progress on other issues?
16:36:21 [fantasai]
glazou: Let's have proposals done by the F2F
16:37:04 [glazou]
Zakim, who is noisy?
16:37:15 [Zakim]
glazou, listening for 10 seconds I heard sound from the following: glazou (47%), arronei (13%), Bert (34%)
16:37:50 [fantasai]
glazou: Issue 181
16:38:02 [dbaron]
TabAtkins_, Where's the message you mentioned sending that had questions about margin collapsing?
16:38:05 [glazou]
16:39:02 [fantasai]
fantasai suggests 184-186 being more important to discuss
16:39:18 [TabAtkins_]
dbaron, and 528
16:40:23 [fantasai]
Tab: I think several things are way easier if you consider pseudo-elements as part of the element tree
16:40:37 [fantasai]
Bert: But then the element tree is not a tree
16:42:41 [fantasai]
glazou: Could say which sections pseudo-elements are treated as elements
16:42:53 [fantasai]
fantasai: That would be pretty much the entire spec except the Selectors chapter
16:44:21 [fantasai]
SteveZ: I support the "except" proposal in the issues list
16:45:32 [fantasai]
dbaron: I might go so far as saying :before and :after are treated as real elements except where specified, and have :first-line and :first-letter just be defined by the Selectors chapter
16:45:46 [fantasai]
fantasai: That doesn't give them enough definition -- e.g. how do we assign properties to them?
16:45:53 [fantasai]
dbaron: That's already pretty bizarre
16:48:44 [fantasai]
glazou: "Pseudo-elements behave just like real elements except as described below and elsewhere."
16:49:01 [fantasai]
Steve: But then I have to search the entire spec.
16:49:13 [fantasai]
Steve: At least point to the relevant sections
16:50:03 [fantasai]
fantasai: I think the relevant section is 12.1
16:50:21 [glazou]
16:50:21 [fantasai]
RESOLVED: "Pseudo-elements behave just like real element except as described below and in section 12.1"
16:51:28 [fantasai]
dbaron: There are 2 different cases here, and I'm not sure which one he tested.
16:52:04 [fantasai]
dbaron: There's one where you have a zero-height float whose position is right at the edge of a line
16:52:22 [fantasai]
dbaron: And the other is where you have a zero-height float whose position is in the middle of the line (e.g. below another float)
16:53:10 [fantasai]
dbaron: If the top of a float is even with the bottom of a line, or the bottom of a float is even with the top of a line, that's not considered an intersection.
16:53:18 [fantasai]
dbaron: I'm not sure about the case of a zero-height float in the middle of a line
16:53:31 [fantasai]
dbaron: But we should be careful that we're testing the right cases here.
16:54:35 [fantasai]
16:55:25 [fantasai]
dbaron: There's another bug in browsers where floats that don't intersect the top of a line are not considered. This shows up in Wikipedia a lot because they use floats for their intended purpose.
16:55:37 [fantasai]
dbaron: The only browsers that handle that right are IE6 and recent versions of Gecko
16:55:43 [dbaron]
16:55:46 [dbaron]
I think
16:56:00 [glazou]
sylvaing: hey *I* did not get married last month ;-)
16:56:24 [fantasai]
Tab: If you have two floats stacked on top of each other, one which is at the top of a line, and then a cleared float in the middle of the line, that second float doesn't push the line box even if it's wider than the line box.
16:56:49 [fantasai]
Tab: In Gecko it pushes only if it's visible; if it's zero height it doesn't.
16:57:25 [fantasai]
Tab: I don't mind Gecko's current behavior. And everyone else who doesn't match, they have a bug anyway.
16:58:12 [fantasai]
Tab: I could go either way on it -- detecting or not detecting zero-height floats both make sense.
16:58:38 [fantasai]
SteveZ: It makes sense for consistency to ignore it; since when it falls between lines it's ignored.
16:59:05 [fantasai]
SteveZ: Why would one have a zero-height float?
16:59:18 [fantasai]
SteveZ: I understand how it can happen; but is there a use case for it?
16:59:25 [fantasai]
Tab can't think of one
16:59:38 [fantasai]
Bert: It's a bit like positioned elements, that it's positioned at the auto position
17:00:14 [smfr]
smfr has joined #css
17:00:18 [fantasai]
Bert: I don't know if it would make sense to use a zero-height float instead of abspos, but if you wanted to make it overlap...
17:00:58 [Zakim]
17:02:03 [fantasai]
Brad: What about a transition from zero-height to another height?
17:02:25 [Zakim]
17:02:30 [fantasai]
Brad: You might want to cause reflow vertically, but not horizontally.
17:03:06 [fantasai]
SteveZ: Is there a use case that isn't an edge use case for this?
17:03:47 [fantasai]
glazou: If we have no use case, what do you suggest?
17:04:03 [fantasai]
SteveZ: If we have interop, then it seems strange to break that.
17:04:08 [fantasai]
Bert: What interop do we have?
17:04:52 [fantasai]
dbaron: The other possibility is that we say zero-height floats never push lines. Which is nice, because it makes one implementation strategy easier.
17:05:21 [fantasai]
dbaron: We split each side of a bfc into vertical ranges, and we check for whether to push lines by checking for an intersection.
17:05:37 [fantasai]
dbaron: If we need to check for zero-height floats, then we need to deal with zero-height ranges, which is a bit of a pain.
17:05:43 [TabAtkins_]
Isn't that exactly what's being proposed?
17:06:00 [fantasai]
dbaron: If floats are changing height, there will be a lot of reflow anyway
17:06:50 [Zakim]
17:06:51 [Zakim]
17:06:52 [Zakim]
17:06:53 [Zakim]
17:06:54 [Zakim]
17:06:54 [Zakim]
17:06:55 [Zakim]
17:06:56 [Zakim]
17:06:57 [fantasai]
SteveZ: So, proposed to make zero-height floats not affect line boxes, will ask for objections and resolve next week.
17:07:04 [Zakim]
17:07:07 [Zakim]
17:07:20 [Zakim]
17:07:21 [Zakim]
Style_CSS FP()12:00PM has ended
17:07:23 [Zakim]
Attendees were glazou, dsinger, arronei, plinss_, Bert, sylvaing, +1.650.766.aaaa, bradk, smfr, SteveZ, fantasai, JohnJansen, David_Baron, +1.650.214.aabb, TabAtkins_
17:08:25 [TabAtkins_]
arronei: You can call me whenever. Same number as before.
17:57:26 [nimbupani]
nimbupani has joined #css
18:25:30 [dbaron]
dbaron has joined #css
19:13:02 [smfr]
smfr has left #css
19:53:22 [ChrisL]
ChrisL has joined #css
19:55:05 [Zakim]
Zakim has left #CSS
20:03:24 [jdaggett]
jdaggett has joined #css
20:23:54 [nimbupani]
nimbupani has joined #css
22:05:23 [fantasai]
anne: Did the URI spec you were talking about in ever get written?
22:09:10 [fantasai]
jdaggett: Can I assume is on your radar somewhere?
22:31:44 [jdaggett]
that was added to appendix a
22:31:53 [jdaggett]
er, maybe that's b now
22:48:49 [Curt`]
Curt` has joined #css
23:03:19 [szilles]
szilles has joined #css