IRC log of CSS on 2010-12-22

Timestamps are in UTC.

16:24:20 [RRSAgent]
RRSAgent has joined #CSS
16:24:20 [RRSAgent]
logging to http://www.w3.org/2010/12/22-CSS-irc
16:24:34 [glazou]
Zakim, this will be Style
16:24:34 [Zakim]
ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 36 minutes
16:24:40 [glazou]
RRSAgent, make logs public
16:56:02 [dsinger]
dsinger has joined #css
16:59:28 [Zakim]
Style_CSS FP()12:00PM has now started
16:59:35 [Zakim]
+[Apple]
16:59:45 [dbaron]
dbaron has joined #css
17:00:00 [dsinger]
zakim, [apple] has dsinger
17:00:00 [Zakim]
+dsinger; got it
17:00:07 [Zakim]
+[Microsoft]
17:00:22 [Zakim]
+glazou
17:00:22 [glazou]
ah finally
17:00:30 [glazou]
ROFL
17:00:35 [glazou]
what's that music ?
17:00:39 [glazou]
dsinger: you ?
17:00:51 [Arron]
Arron has joined #CSS
17:00:53 [glazou]
yes
17:01:01 [glazou]
Zakim, who is here ?
17:01:01 [Zakim]
On the phone I see [Apple], [Microsoft], glazou
17:01:03 [Zakim]
[Apple] has dsinger
17:01:04 [Zakim]
On IRC I see Arron, dbaron, dsinger, RRSAgent, Zakim, glazou, nimbupani, kennyluck, arronei, trackbot, plinss, karl, TabAtkins, Hixie, CSSWG_LogBot, shepazu, krijnh, jgraham,
17:01:05 [smfr]
smfr has joined #css
17:01:06 [Zakim]
... fantasai, gsnedders, Bert
17:01:07 [Zakim]
+ +1.206.324.aaaa
17:01:22 [sylvaing]
sylvaing has joined #css
17:01:24 [glazou]
Microsoft, thanks :)
17:01:34 [glazou]
can we stop that now ?
17:01:35 [arronei]
arronei has joined #CSS
17:02:23 [glazou]
Zakim, mute [Microsoft]
17:02:23 [Zakim]
[Microsoft] should now be muted
17:02:28 [glazou]
ah not you
17:02:30 [Zakim]
+smfr
17:02:36 [glazou]
Zakim, unmute [Microsoft]
17:02:36 [Zakim]
[Microsoft] should no longer be muted
17:02:50 [dsinger]
zakim, who was making noise?
17:02:51 [Zakim]
I don't understand your question, dsinger.
17:03:34 [bradk]
bradk has joined #css
17:03:42 [Zakim]
+bradk
17:03:48 [Zakim]
+plinss_
17:03:50 [danielweck]
danielweck has joined #css
17:04:13 [danielweck]
Note: Daniel Weck only on IRC (not audio concall)
17:04:24 [glazou]
ok danielweck
17:04:36 [plinss]
zakim, plinss_ is me
17:04:36 [Zakim]
+plinss; got it
17:05:14 [Zakim]
+ +44.758.419.aabb
17:05:14 [glazou]
Zakim, who is here ?
17:05:14 [Zakim]
On the phone I see [Apple], [Microsoft], glazou, +1.206.324.aaaa, smfr, bradk, plinss, +44.758.419.aabb
17:05:17 [Zakim]
[Apple] has dsinger
17:05:18 [Zakim]
On IRC I see danielweck, bradk, arronei, sylvaing, smfr, dbaron, dsinger, RRSAgent, Zakim, glazou, nimbupani, kennyluck, trackbot, plinss, karl, TabAtkins, Hixie, CSSWG_LogBot,
17:05:21 [Zakim]
... shepazu, krijnh, jgraham, fantasai, gsnedders, Bert
17:05:21 [gsnedders]
zaim, aabb is me
17:05:26 [gsnedders]
zakim, aabb is me
17:05:26 [Zakim]
+gsnedders; got it
17:05:30 [gsnedders]
zakim, mute me
17:05:30 [Zakim]
gsnedders should now be muted
17:05:41 [Zakim]
+fantasai
17:05:43 [fantasai_]
fantasai_ has joined #css
17:05:47 [TabAtkins]
I'm here on IRC.
17:06:08 [sylvaing]
Zakim, aaaa is sylvaing
17:06:08 [Zakim]
+sylvaing; got it
17:06:34 [gsnedders]
zakim, who's making noise?
17:06:38 [szilles]
szilles has joined #css
17:06:45 [Zakim]
gsnedders, listening for 10 seconds I heard sound from the following: [Apple] (29%), glazou (14%)
17:06:59 [Zakim]
+SteveZ
17:07:30 [fantasai_]
ScribeNick: fantasai
17:07:48 [Zakim]
+David_Baron
17:07:51 [fantasai_]
glazou: two items on agenda, one about comments to other wgs
17:08:06 [fantasai_]
glazou: first one was WOFF, other was Progress Events
17:08:20 [fantasai_]
glazou: jdaggett requested deferring WOFF until next call, since he can't attend today
17:08:26 [fantasai_]
glazou: Any other comments?
17:08:43 [fantasai_]
sylvain: Bert sent comments, but we need them on the public mailing list
17:08:53 [fantasai_]
glazou: progress events or woff?
17:08:57 [fantasai_]
sylvain: woff
17:09:02 [fantasai_]
glazou: We'll discuss that next time
17:09:06 [fantasai_]
glazou: Progress Events?
17:09:16 [fantasai_]
glazou: Simon and I agree we have nothing else to say. Any other opinion?
17:09:17 [glazou]
Zakim, who is noisy?
17:09:29 [Zakim]
glazou, listening for 12 seconds I heard sound from the following: fantasai (86%), David_Baron (7%)
17:09:36 [glazou]
Zakim, mute fantasai_
17:09:36 [Zakim]
sorry, glazou, I do not know which phone connection belongs to fantasai_
17:09:54 [glazou]
Zakim, mute fantasai
17:09:54 [Zakim]
fantasai should now be muted
17:10:21 [fantasai_]
glazou: Ok, I will send a message that we have no comments
17:10:40 [fantasai_]
Topic: CSS2.1
17:10:42 [glazou]
Zakim, unmute fantasai
17:10:42 [Zakim]
fantasai should no longer be muted
17:10:57 [fantasai_]
Arron: I'm looking at the issues list, looks like there are a couple open issues still
17:11:07 [fantasai_]
glazou: Any issues we can deal with now?
17:11:19 [fantasai_]
fantasai: Issue 138 is apparently not clear enough to justify one of its tests
17:11:56 [fantasai_]
http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0122.html
17:14:01 [fantasai_]
dbaron: I tend to think that we should fix the spec
17:14:17 [fantasai_]
Arron: Only Opera, Safari, and Chrome fail it. All others pass, including old versions
17:14:26 [fantasai_]
plinss: Missing data for Gecko
17:14:28 [Zakim]
-glazou
17:14:29 [fantasai_]
dbaron: Gecko fails
17:14:39 [glazou]
damn
17:14:39 [fantasai_]
arronei: In 3 it passes
17:14:52 [fantasai_]
arronei: FF3.6 it passes
17:14:56 [glazou]
yes it does
17:14:58 [fantasai_]
dbaron: So in 4 it's failing
17:15:03 [fantasai_]
regression?
17:15:14 [fantasai_]
plinss: I don't see it passing in 3
17:15:28 [fantasai_]
passes on my machine
17:15:29 [Zakim]
+glazou
17:15:29 [fantasai_]
LInux
17:15:37 [fantasai_]
Arron: Passes for me on Windows
17:15:47 [gsnedders]
Passes in 3.6 and fails in 4.0 on Linux.
17:16:09 [glazou]
failed with FF4 on mac
17:16:18 [fantasai_]
dbaron: I think there's something funny about the test, but maybe we should discuss the spec issue
17:16:51 [fantasai_]
dbaron: The spec issue, basically the quesiton is, if you have a float that is inside a relpos inline, does the relpos of the inline move the float?
17:17:19 [fantasai_]
dbaron: That's what the summary of issue 138 says, but the emails in 138 were specific to block-within-inline positioning
17:17:30 [fantasai_]
dbaron: If there's a block inside the inline, then the float does move, and we clarified that.
17:17:48 [fantasai_]
dbaron: But this is just a float inside an inline
17:18:13 [fantasai_]
dbaron: The spec doesn't say currently anything to imply that the relpos affecting the float
17:18:16 [fantasai_]
s/ing/s/
17:18:43 [fantasai_]
glazou: Any opinions here?
17:18:50 [fantasai_]
arronei: I'm still looking
17:19:18 [fantasai_]
arronei: I'm not going to be able to give a quick answer here
17:19:47 [fantasai_]
glazou: Seems this discussion will take some time to figure out the correct answer.
17:19:55 [fantasai_]
glazou: On the other hand we already have two impl passing the test
17:20:19 [fantasai_]
glazou: So the question is, is it something that we can deal with as an errata after the spec is done?
17:21:00 [fantasai_]
arronei: My only problem with errata in my case is that it could completely change what is correct
17:21:13 [fantasai_]
arronei: It's not "here's more info", it's "we're changing this behavior"
17:21:28 [fantasai_]
glazou: Does it fail in FF4 because the impl changed, or is it a bug?
17:21:45 [fantasai_]
dbaron: When I analyzed the spec, on October 13th, my understanding was that the test was testing something that the spec didn't say
17:23:13 [amphibulus]
amphibulus has joined #css
17:23:42 [fantasai_]
dbaron: That part of the spec also talks about splitting inlines around blocks, and I'm pretty sure we don't want that to apply to floats
17:24:30 [dbaron]
(and it says "in-flow")
17:25:00 [fantasai_]
glazou: going in circles
17:25:12 [fantasai_]
glazou: dbaron, have an opinion?
17:25:31 [fantasai_]
glazou: I suggest we action someone to write a proposal
17:25:44 [fantasai_]
glazou: Any volunteers?
17:25:54 [fantasai_]
dbaron: I could do it
17:26:19 [fantasai_]
ACTION dbaron Write proposal to handle position of float inside relpos'd inline
17:26:19 [trackbot]
Created ACTION-284 - Write proposal to handle position of float inside relpos'd inline [on David Baron - due 2010-12-29].
17:26:42 [fantasai_]
glazou: If we don't decide, we'd have to remove the test and make the behavior undefined.
17:26:51 [fantasai_]
glazou: Any other issue or test we could review right now?
17:27:00 [plinss]
http://lists.w3.org/Archives/Public/public-css-testsuite/2010Dec/0158.html
17:27:18 [fantasai_]
arronei: did we ever finish discussing issue 159?
17:28:44 [fantasai_]
glazou: We discussed it in October 27 and resolved on it
17:28:49 [fantasai_]
glazou: I think it was fixed.
17:28:57 [fantasai_]
arronei: sounds like a =bert= edit
17:28:59 [dbaron]
resolved in minutes here: http://lists.w3.org/Archives/Public/www-style/2010Oct/0842.html
17:29:04 [fantasai_]
glazou: actions were 270 and 271
17:29:39 [fantasai_]
glazou: Anything else?
17:29:57 [fantasai_]
glazou: Peter pasted something
17:30:05 [fantasai_]
plinss: Responses to invalid tests in RC4
17:33:15 [fantasai_]
arronei: I have 10 more cases but am pretty much done
17:33:22 [fantasai_]
glazou: How many cases are still considered invalid?
17:33:30 [fantasai_]
arronei: I have 13, but other people think there are a lot more than that
17:34:08 [fantasai_]
plinss: I have a list of tests that have been reported invalid and not touched,
17:34:18 [fantasai_]
plinss: But there's a large number of tests here that need to be addressed
17:34:24 [fantasai_]
fantasai: Most of the invalid ones are the page breaking ones
17:35:11 [fantasai_]
glazou: Fixing the invalid tests takes a long time
17:36:45 [fantasai_]
fantasai points to her email that analyzes the invalid tests
17:36:56 [plinss]
http://test.csswg.org/harness/results?s=CSS21_%HTML_RC4&t=0&f[]=1&f[]=2&f[]=4&f[]=16
17:37:13 [dbaron]
http://test.csswg.org/suites/css2.1/20101210/html4/counter-increment-013.htm
17:37:23 [fantasai_]
dbaron: I think the counter-increment tests are invalid
17:38:14 [fantasai_]
dbaron: In the first test, it tests that the implementation truncates the counter to a 32-bit signed integer
17:38:30 [fantasai_]
arron: That test was created after the F2F in Japan
17:38:36 [fantasai_]
dbaron: But that's not what we agreed to.
17:38:47 [fantasai_]
dbaron: We agreed that you could test for a reasonable range of values
17:39:13 [fantasai_]
dbaron: But implementing beyond that range is allowed
17:39:32 [fantasai_]
arronei: What I was trying to test there is that you don't overflow into a negative number
17:39:55 [fantasai_]
arronei: I could change the test so that it allows either truncation or incrementing
17:40:08 [fantasai_]
glazou: If it's not in the spec, it doesn't need testing
17:40:24 [fantasai_]
arronei: The only statement in the spec is that you support <integer>, but the range is undefined
17:40:39 [fantasai_]
arronei: According to the spec, you only need to specify one number.
17:40:51 [fantasai_]
sylvaing: Is there anything in the test that mandates overflow behavior?
17:40:53 [fantasai_]
arronei: No
17:42:29 [fantasai_]
fantasai: You could test that the implementaiton supports the full 32-bit unsigned range
17:42:42 [fantasai_]
fantasai: by testing that the counter can go up to its limits
17:43:01 [fantasai_]
fantasai: this would test for a reasonable range
17:43:15 [fantasai_]
sylvaing: That's not in the spec
17:44:14 [gsnedders]
I'm +1 with what fantasai_ is saying now, FWIW.
17:44:34 [fantasai_]
dbaron: The agreement was that this would be a test suite assumption
17:45:07 [TabAtkins]
We still need to spec a required supported range for <integer>.
17:45:13 [fantasai_]
discussion on test suite assumptions vs spec requirements
17:45:17 [TabAtkins]
(Separate from the test discussion, which we did indeed discuss.)
17:45:24 [TabAtkins]
s/discussion/distinction/
17:46:28 [fantasai_]
plinss: integer overflow behavior isn't covered in the spec. We can add it to the spec later
17:47:11 [fantasai_]
glazou: I suggest we add a clarification to the spec that we expect 32-bit integers, and write tests for it
17:47:36 [dbaron]
there are already separate tests for the case you want to change this one to
17:49:00 [fantasai_]
fantasai doesn't think we need to put this in the spec, test suite assumption is enough
17:49:26 [fantasai_]
all we need is to have the tests only check that the range is supported, not check overflow behavior
17:49:28 [gsnedders]
Zakim: unmute me
17:49:36 [gsnedders]
Zakim, unmute me
17:49:36 [Zakim]
gsnedders should no longer be muted
17:49:47 [fantasai_]
Straw Poll
17:50:46 [dbaron]
I listed two different sets of tests in http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0040.html
17:51:02 [dbaron]
the tests in the first half test overflow behavior; the tests in the second half don't
17:51:10 [fantasai_]
sylvaing: I don't agree that the spec should require 32-bit integers
17:51:16 [fantasai_]
s/sylvaing/simon/
17:51:29 [fantasai_]
simon: But I do think that the spec should specify what happens when you overflow whatever range you support
17:51:54 [szilles]
+1 for what simon says
17:52:05 [fantasai_]
dsinger: It's reasonable for a spec to specify a range that must be supported, and what's outside the range is implementation-dependent
17:52:06 [smfr]
http://www.w3.org/TR/CSS2/syndata.html#value-def-integer
17:52:32 [fantasai_]
dbaron: one comment about what simon said, some of the test reach an overflow by using counters to take two integers within the 32-bit range and add them
17:52:41 [fantasai_]
dbaron: Others do the overflow at parse times
17:52:48 [fantasai_]
dbaron: So there are two different overflow conditions happening
17:52:56 [fantasai_]
plinss: Here's my concrete proposal.
17:53:03 [fantasai_]
plinss: We leave the 32-bit assumption in the test suite
17:53:12 [fantasai_]
plinss: Define overflow behavior in a future spec
17:53:16 [fantasai_]
plinss: Remove this test for now
17:53:52 [fantasai_]
plinss: Change the test to match the overflow behavior in the spec
17:54:02 [fantasai_]
plinss: and allow e.g. 64-bit implementations pass
17:54:29 [fantasai_]
plinss: Instead of removing this test we could make it a may or a should
17:54:41 [fantasai_]
Zakim: unmute fantasai
17:54:59 [dsinger]
or at least a 'note' (Note: counters up to 32 bits are normally supported)
17:55:03 [fantasai_]
glazou: Peter, do you accept an action to write a clarification?
17:56:24 [fantasai_]
fantasai: If we keep the tests, then they should be a 'may', because the behavior is not recommended, just allowed
17:56:37 [fantasai_]
fantasai: Also they should be updated so that a 64-bit implementation will pass
17:56:45 [fantasai_]
plinss: Failure condition should be showing a negative number
17:57:19 [fantasai_]
plinss: truncating for 255 is valid according to the test
17:57:27 [fantasai_]
Proposal:
17:57:29 [fantasai_]
1. No change to spec
17:57:39 [fantasai_]
2. Update tests to fail only if returning negative number
17:57:56 [fantasai_]
(i.e. any supported range is ok, but overflowing is not)
17:58:01 [fantasai_]
3. Mark tests as 'may'
17:58:14 [bradk]
+1
17:58:25 [fantasai_]
4. Add assumption of 32-bit integers to test suite assumptions page
17:58:44 [dbaron]
I'd have preferred keeping the tests that test values within the 32-bit range as required, given (4).
17:59:07 [fantasai_]
Yes, only mark the tests for overflow behavior as may :)
17:59:25 [fantasai_]
arronei: I agree that this is fine
18:00:14 [dbaron]
I'm happy with fantasai's proposal.
18:00:40 [TabAtkins]
I'm fine with that.
18:00:46 [fantasai_]
dsinger: Might want to add a note that stepping outside 32-bit integers is not a good idea so authors know
18:00:59 [fantasai_]
glazou: Any objections to the propsoal?
18:01:05 [fantasai_]
RESOLVED: Proposal above accepted.
18:01:15 [fantasai_]
ACTION plinss: Create a note for the errata
18:01:15 [trackbot]
Created ACTION-285 - Create a note for the errata [on Peter Linss - due 2010-12-29].
18:01:35 [Zakim]
-David_Baron
18:01:39 [fantasai_]
Meeting closed.
18:01:43 [Zakim]
-[Microsoft]
18:01:44 [Zakim]
-smfr
18:01:46 [Zakim]
-SteveZ
18:01:47 [Zakim]
-bradk
18:01:49 [Zakim]
-glazou
18:01:50 [Zakim]
-fantasai
18:01:50 [Zakim]
-gsnedders
18:02:01 [Zakim]
-plinss
18:04:27 [Zakim]
-[Apple]
18:05:25 [arronei]
What should we do about + and * notation in the value definitions?
18:05:29 [arronei]
What assumption should the test suite be making about those?
18:07:05 [Zakim]
-sylvaing
18:07:06 [Zakim]
Style_CSS FP()12:00PM has ended
18:07:08 [Zakim]
Attendees were dsinger, [Microsoft], glazou, +1.206.324.aaaa, smfr, bradk, plinss, +44.758.419.aabb, gsnedders, fantasai, sylvaing, SteveZ, David_Baron
18:08:04 [smfr]
smfr has left #css
18:13:58 [anne]
anne has joined #css
18:32:58 [fantasai_]
fantasai_ has joined #css
19:42:46 [dbaron]
Could somebody tell me which items IE9 indents on this test? http://dbaron.org/css/test/2010/css21-issue-138-simple-float-test-with-more-tests
19:43:00 [dbaron]
(indents by 200px, so it's pretty obvious)
19:43:35 [dbaron]
(For comparison, Firefox 3.6 indents items 2 and 5, Firefox trunk, Chromium trunk, and Opera 11 all indent only item (2), and IE8 indents all 5 items.)
20:00:17 [dbaron]
trackbot, ACTION-284?
20:00:17 [trackbot]
Sorry, dbaron, I don't understand 'trackbot, ACTION-284?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
20:00:27 [dbaron]
trackbot, url?
20:00:27 [trackbot]
Sorry, dbaron, I don't understand 'trackbot, url?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
20:00:43 [dbaron]
ACTION-284?
20:00:43 [trackbot]
ACTION-284 -- David Baron to write proposal to handle position of float inside relpos'd inline -- due 2010-12-29 -- OPEN
20:00:43 [trackbot]
http://www.w3.org/Style/CSS/Tracker/actions/284
20:12:46 [Zakim]
Zakim has left #CSS
22:35:30 [arronei]
dbaron: IE9 indents only item 2.
22:36:15 [dbaron]
arronei, good... does it somehow still pass http://test.csswg.org/suites/css2.1/20101210/html4/block-in-inline-relpos-002.htm ?
22:38:21 [arronei]
dbaron: we now fail that case with our latest builds so it looks like we are more inline with everyone else.
22:39:15 [dbaron]
arronei, ok, so that moves me more strongly towards the opinion that the spec is fine and we should just fix the test :-)
22:39:37 [arronei]
Yes I agree. We should just fix the test and leave the spec.