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.