/irc-logs / w3c / #css / 2010-12-22 / end

Options:

  1. # Session Start: Wed Dec 22 00:00:00 2010
  2. # Session Ident: #css
  3. # [00:00] * Joins: homata (homata@58.158.182.50)
  4. # [00:44] * Joins: miketaylr (miketaylr@38.117.157.140)
  5. # [01:20] * Quits: nimbupani (Adium@24.22.131.46) (Quit: Leaving.)
  6. # [01:30] * Quits: miketaylr (miketaylr@38.117.157.140) (Ping timeout)
  7. # [01:50] * Quits: kennyluck (kennyluck@128.30.52.169) (Quit: kennyluck)
  8. # [02:00] * Joins: miketaylr (miketaylr@64.132.60.70)
  9. # [02:03] * Quits: plinss_ (plinss@192.6.114.30) (Quit: plinss_)
  10. # [02:32] * Joins: nimbupani (Adium@24.22.131.46)
  11. # [02:41] * Quits: miketaylr (miketaylr@64.132.60.70) (Quit: miketaylr)
  12. # [03:16] * Joins: homata_ (homata@58.158.182.50)
  13. # [03:17] * Quits: homata (homata@58.158.182.50) (Ping timeout)
  14. # [04:43] * Joins: kennyluck (kennyluck@128.30.52.169)
  15. # [06:11] * Quits: kennyluck (kennyluck@128.30.52.169) (Quit: kennyluck)
  16. # [06:11] * Joins: kennyluck (kennyluck@128.30.52.169)
  17. # [06:13] * Quits: kennyluck (kennyluck@128.30.52.169) (Quit: kennyluck)
  18. # [06:49] * Quits: nimbupani (Adium@24.22.131.46) (Quit: Leaving.)
  19. # [08:07] * Joins: homata (homata@58.158.182.50)
  20. # [08:09] * Quits: homata_ (homata@58.158.182.50) (Ping timeout)
  21. # [08:19] * Joins: Ms2ger (Ms2ger@91.181.155.117)
  22. # [09:55] * Quits: Ms2ger (Ms2ger@91.181.155.117) (Ping timeout)
  23. # [10:23] * Quits: homata (homata@58.158.182.50) (Quit: Leaving...)
  24. # [11:13] * Joins: Ms2ger (Ms2ger@91.181.155.117)
  25. # [12:59] * Joins: kennyluck (kennyluck@128.30.52.169)
  26. # [13:31] * Quits: kennyluck (kennyluck@128.30.52.169) (Quit: kennyluck)
  27. # [15:25] * Joins: miketaylr (miketaylr@173.101.64.171)
  28. # [15:38] * Joins: kennyluck (kennyluck@128.30.52.169)
  29. # [16:08] * Joins: rafahl (5e43462f@207.192.75.252)
  30. # [16:08] <rafahl> hi all
  31. # [16:09] * Parts: rafahl (5e43462f@207.192.75.252)
  32. # [16:14] * Joins: nimbupani (Adium@24.22.131.46)
  33. # [16:45] * Quits: Ms2ger (Ms2ger@91.181.155.117) (Quit: bbl)
  34. # [16:59] * Quits: miketaylr (miketaylr@173.101.64.171) (Quit: miketaylr)
  35. # [17:27] * Joins: glazou (glazou@82.247.96.19)
  36. # [17:27] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  37. # [17:27] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  38. # [17:27] <RRSAgent> logging to http://www.w3.org/2010/12/22-CSS-irc
  39. # [17:27] <glazou> Zakim, this will be Style
  40. # [17:27] <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 36 minutes
  41. # [17:27] <glazou> RRSAgent, make logs public
  42. # [17:27] <RRSAgent> I have made the request, glazou
  43. # [17:59] * Joins: dsinger (dsinger@17.197.20.4)
  44. # [17:59] * dsinger changes topic to 'Christmas with Substance and Style woohoo! group'
  45. # [18:02] <Zakim> Style_CSS FP()12:00PM has now started
  46. # [18:02] <Zakim> +[Apple]
  47. # [18:02] * Joins: dbaron (dbaron@98.111.140.119)
  48. # [18:02] * glazou cannot join, zakim refuses
  49. # [18:03] <dsinger> zakim, [apple] has dsinger
  50. # [18:03] <Zakim> +dsinger; got it
  51. # [18:03] <Zakim> +[Microsoft]
  52. # [18:03] * dsinger no problem for me...
  53. # [18:03] <Zakim> +glazou
  54. # [18:03] <glazou> ah finally
  55. # [18:03] <glazou> ROFL
  56. # [18:03] <glazou> what's that music ?
  57. # [18:03] <glazou> dsinger: you ?
  58. # [18:03] * dsinger sounds like christmas music to me
  59. # [18:03] * Joins: Arron (arronei@131.107.0.72)
  60. # [18:03] <glazou> yes
  61. # [18:04] <glazou> Zakim, who is here ?
  62. # [18:04] <Zakim> On the phone I see [Apple], [Microsoft], glazou
  63. # [18:04] <Zakim> [Apple] has dsinger
  64. # [18: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,
  65. # [18:04] * Joins: smfr (smfr@68.183.26.214)
  66. # [18:04] <Zakim> ... fantasai, gsnedders, Bert
  67. # [18:04] <Zakim> + +1.206.324.aaaa
  68. # [18:04] * Quits: arronei (arronei@131.107.0.110) (Ping timeout)
  69. # [18:04] * Joins: sylvaing (sylvaing@98.232.9.174)
  70. # [18:04] * Quits: Arron (arronei@131.107.0.72) (Quit: Arron)
  71. # [18:04] <glazou> Microsoft, thanks :)
  72. # [18:04] * sylvaing well, that puts the F in WTF
  73. # [18:04] <glazou> can we stop that now ?
  74. # [18:04] * Joins: arronei (arronei@131.107.0.72)
  75. # [18:04] * dsinger ok, folks, gather near
  76. # [18:05] <glazou> Zakim, mute [Microsoft]
  77. # [18:05] <Zakim> [Microsoft] should now be muted
  78. # [18:05] <glazou> ah not you
  79. # [18:05] <Zakim> +smfr
  80. # [18:05] <glazou> Zakim, unmute [Microsoft]
  81. # [18:05] <Zakim> [Microsoft] should no longer be muted
  82. # [18:05] <dsinger> zakim, who was making noise?
  83. # [18:05] <Zakim> I don't understand your question, dsinger.
  84. # [18:06] * gsnedders wonders whether to dial in using his mobile seeming Skype is down…
  85. # [18:06] * Joins: bradk (bradk@99.7.175.117)
  86. # [18:06] <Zakim> +bradk
  87. # [18:06] <Zakim> +plinss_
  88. # [18:06] * dsinger skype is down? wow
  89. # [18:06] * Joins: danielweck (dweck2@81.157.12.143)
  90. # [18:07] <danielweck> Note: Daniel Weck only on IRC (not audio concall)
  91. # [18:07] <glazou> ok danielweck
  92. # [18:07] * gsnedders dsinger: is was totally earlier, now it's just some people can't sign-in, myself included :\
  93. # [18:07] <plinss> zakim, plinss_ is me
  94. # [18:07] <Zakim> +plinss; got it
  95. # [18:08] <Zakim> + +44.758.419.aabb
  96. # [18:08] <glazou> Zakim, who is here ?
  97. # [18:08] <Zakim> On the phone I see [Apple], [Microsoft], glazou, +1.206.324.aaaa, smfr, bradk, plinss, +44.758.419.aabb
  98. # [18:08] <Zakim> [Apple] has dsinger
  99. # [18:08] <Zakim> On IRC I see danielweck, bradk, arronei, sylvaing, smfr, dbaron, dsinger, RRSAgent, Zakim, glazou, nimbupani, kennyluck, trackbot, plinss, karl, TabAtkins, Hixie, CSSWG_LogBot,
  100. # [18:08] <gsnedders> zaim, aabb is me
  101. # [18:08] <Zakim> ... shepazu, krijnh, jgraham, fantasai, gsnedders, Bert
  102. # [18:08] <gsnedders> zakim, aabb is me
  103. # [18:08] <Zakim> +gsnedders; got it
  104. # [18:08] <gsnedders> zakim, mute me
  105. # [18:08] <Zakim> gsnedders should now be muted
  106. # [18:08] <Zakim> +fantasai
  107. # [18:08] * Joins: fantasai_ (fantasai@68.248.62.130)
  108. # [18:08] <TabAtkins> I'm here on IRC.
  109. # [18:09] <sylvaing> Zakim, aaaa is sylvaing
  110. # [18:09] <Zakim> +sylvaing; got it
  111. # [18:09] <gsnedders> zakim, who's making noise?
  112. # [18:09] * dsinger zakim, who is in an airport?
  113. # [18:09] * Zakim I don't understand your question, dsinger.
  114. # [18:09] * Joins: szilles (chatzilla@24.6.120.172)
  115. # [18:09] <Zakim> gsnedders, listening for 10 seconds I heard sound from the following: [Apple] (29%), glazou (14%)
  116. # [18:10] <Zakim> +SteveZ
  117. # [18:10] * sylvaing assumes this was a US airport as the flight was heading somewhere
  118. # [18:10] <fantasai_> ScribeNick: fantasai
  119. # [18:10] <Zakim> +David_Baron
  120. # [18:10] <fantasai_> glazou: two items on agenda, one about comments to other wgs
  121. # [18:11] <fantasai_> glazou: first one was WOFF, other was Progress Events
  122. # [18:11] <fantasai_> glazou: jdaggett requested deferring WOFF until next call, since he can't attend today
  123. # [18:11] <fantasai_> glazou: Any other comments?
  124. # [18:11] <fantasai_> sylvain: Bert sent comments, but we need them on the public mailing list
  125. # [18:11] <fantasai_> glazou: progress events or woff?
  126. # [18:12] <fantasai_> sylvain: woff
  127. # [18:12] <fantasai_> glazou: We'll discuss that next time
  128. # [18:12] <fantasai_> glazou: Progress Events?
  129. # [18:12] <fantasai_> glazou: Simon and I agree we have nothing else to say. Any other opinion?
  130. # [18:12] <glazou> Zakim, who is noisy?
  131. # [18:12] <Zakim> glazou, listening for 12 seconds I heard sound from the following: fantasai (86%), David_Baron (7%)
  132. # [18:12] * fantasai_ notes that her comp battery might die, in which case someone will need to take over
  133. # [18:12] <glazou> Zakim, mute fantasai_
  134. # [18:12] <Zakim> sorry, glazou, I do not know which phone connection belongs to fantasai_
  135. # [18:12] * fantasai_ is mute dlocally
  136. # [18:12] <glazou> Zakim, mute fantasai
  137. # [18:12] <Zakim> fantasai should now be muted
  138. # [18:13] * dbaron assumes fantasai is the one in an airport
  139. # [18:13] <fantasai_> glazou: Ok, I will send a message that we have no comments
  140. # [18:13] * fantasai_ is indeed in an airport
  141. # [18:13] <fantasai_> Topic: CSS2.1
  142. # [18:13] <glazou> Zakim, unmute fantasai
  143. # [18:13] * dbaron notes that means fantasai was not in fact muted
  144. # [18:13] <Zakim> fantasai should no longer be muted
  145. # [18:14] <fantasai_> Arron: I'm looking at the issues list, looks like there are a couple open issues still
  146. # [18:14] <fantasai_> glazou: Any issues we can deal with now?
  147. # [18:14] <fantasai_> fantasai: Issue 138 is apparently not clear enough to justify one of its tests
  148. # [18:15] <fantasai_> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0122.html
  149. # [18:17] <fantasai_> dbaron: I tend to think that we should fix the spec
  150. # [18:17] <fantasai_> Arron: Only Opera, Safari, and Chrome fail it. All others pass, including old versions
  151. # [18:17] <fantasai_> plinss: Missing data for Gecko
  152. # [18:17] <Zakim> -glazou
  153. # [18:17] <fantasai_> dbaron: Gecko fails
  154. # [18:17] <glazou> damn
  155. # [18:17] <fantasai_> arronei: In 3 it passes
  156. # [18:17] <fantasai_> arronei: FF3.6 it passes
  157. # [18:18] <glazou> yes it does
  158. # [18:18] <fantasai_> dbaron: So in 4 it's failing
  159. # [18:18] <fantasai_> regression?
  160. # [18:18] <fantasai_> plinss: I don't see it passing in 3
  161. # [18:18] <fantasai_> passes on my machine
  162. # [18:18] <Zakim> +glazou
  163. # [18:18] <fantasai_> LInux
  164. # [18:18] <fantasai_> Arron: Passes for me on Windows
  165. # [18:18] <gsnedders> Passes in 3.6 and fails in 4.0 on Linux.
  166. # [18:19] <glazou> failed with FF4 on mac
  167. # [18:19] <fantasai_> dbaron: I think there's something funny about the test, but maybe we should discuss the spec issue
  168. # [18:19] <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?
  169. # [18:20] <fantasai_> dbaron: That's what the summary of issue 138 says, but the emails in 138 were specific to block-within-inline positioning
  170. # [18:20] <fantasai_> dbaron: If there's a block inside the inline, then the float does move, and we clarified that.
  171. # [18:20] <fantasai_> dbaron: But this is just a float inside an inline
  172. # [18:21] <fantasai_> dbaron: The spec doesn't say currently anything to imply that the relpos affecting the float
  173. # [18:21] <fantasai_> s/ing/s/
  174. # [18:21] <fantasai_> glazou: Any opinions here?
  175. # [18:21] <fantasai_> arronei: I'm still looking
  176. # [18:22] <fantasai_> arronei: I'm not going to be able to give a quick answer here
  177. # [18:22] <fantasai_> glazou: Seems this discussion will take some time to figure out the correct answer.
  178. # [18:22] <fantasai_> glazou: On the other hand we already have two impl passing the test
  179. # [18:23] <fantasai_> glazou: So the question is, is it something that we can deal with as an errata after the spec is done?
  180. # [18:24] <fantasai_> arronei: My only problem with errata in my case is that it could completely change what is correct
  181. # [18:24] <fantasai_> arronei: It's not "here's more info", it's "we're changing this behavior"
  182. # [18:24] <fantasai_> glazou: Does it fail in FF4 because the impl changed, or is it a bug?
  183. # [18:24] <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
  184. # [18:24] * fantasai_ notes that floats are blocks
  185. # [18:25] * fantasai_ and that the spec explicitly says that blocks inside inlines are moved
  186. # [18:26] * Joins: amphibulus (47ae4933@207.192.75.252)
  187. # [18:26] <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
  188. # [18:27] <dbaron> (and it says "in-flow")
  189. # [18:28] <fantasai_> glazou: going in circles
  190. # [18:28] <fantasai_> glazou: dbaron, have an opinion?
  191. # [18:28] <fantasai_> glazou: I suggest we action someone to write a proposal
  192. # [18:28] <fantasai_> glazou: Any volunteers?
  193. # [18:28] <fantasai_> dbaron: I could do it
  194. # [18:29] <fantasai_> ACTION dbaron Write proposal to handle position of float inside relpos'd inline
  195. # [18:29] * trackbot noticed an ACTION. Trying to create it.
  196. # [18:29] <trackbot> Created ACTION-284 - Write proposal to handle position of float inside relpos'd inline [on David Baron - due 2010-12-29].
  197. # [18:29] <fantasai_> glazou: If we don't decide, we'd have to remove the test and make the behavior undefined.
  198. # [18:29] <fantasai_> glazou: Any other issue or test we could review right now?
  199. # [18:30] <plinss> http://lists.w3.org/Archives/Public/public-css-testsuite/2010Dec/0158.html
  200. # [18:30] <fantasai_> arronei: did we ever finish discussing issue 159?
  201. # [18:31] <fantasai_> glazou: We discussed it in October 27 and resolved on it
  202. # [18:31] <fantasai_> glazou: I think it was fixed.
  203. # [18:32] <fantasai_> arronei: sounds like a =bert= edit
  204. # [18:32] <dbaron> resolved in minutes here: http://lists.w3.org/Archives/Public/www-style/2010Oct/0842.html
  205. # [18:32] <fantasai_> glazou: actions were 270 and 271
  206. # [18:32] * glazou notes he speaks like Clooney in a european Nespresso tv ad
  207. # [18:32] <fantasai_> glazou: Anything else?
  208. # [18:33] <fantasai_> glazou: Peter pasted something
  209. # [18:33] <fantasai_> plinss: Responses to invalid tests in RC4
  210. # [18:36] <fantasai_> arronei: I have 10 more cases but am pretty much done
  211. # [18:36] <fantasai_> glazou: How many cases are still considered invalid?
  212. # [18:36] <fantasai_> arronei: I have 13, but other people think there are a lot more than that
  213. # [18:37] <fantasai_> plinss: I have a list of tests that have been reported invalid and not touched,
  214. # [18:37] <fantasai_> plinss: But there's a large number of tests here that need to be addressed
  215. # [18:37] <fantasai_> fantasai: Most of the invalid ones are the page breaking ones
  216. # [18:38] <fantasai_> glazou: Fixing the invalid tests takes a long time
  217. # [18:39] <fantasai_> fantasai points to her email that analyzes the invalid tests
  218. # [18:39] <plinss> http://test.csswg.org/harness/results?s=CSS21_%HTML_RC4&t=0&f[]=1&f[]=2&f[]=4&f[]=16
  219. # [18:40] <dbaron> http://test.csswg.org/suites/css2.1/20101210/html4/counter-increment-013.htm
  220. # [18:40] <fantasai_> dbaron: I think the counter-increment tests are invalid
  221. # [18:41] <fantasai_> dbaron: In the first test, it tests that the implementation truncates the counter to a 32-bit signed integer
  222. # [18:41] <fantasai_> arron: That test was created after the F2F in Japan
  223. # [18:41] <fantasai_> dbaron: But that's not what we agreed to.
  224. # [18:41] <fantasai_> dbaron: We agreed that you could test for a reasonable range of values
  225. # [18:41] * gsnedders http://www.w3.org/TR/CSS2/generate.html#propdef-counter-incremen claims to be an ED, nice…
  226. # [18:42] <fantasai_> dbaron: But implementing beyond that range is allowed
  227. # [18:42] <fantasai_> arronei: What I was trying to test there is that you don't overflow into a negative number
  228. # [18:42] <fantasai_> arronei: I could change the test so that it allows either truncation or incrementing
  229. # [18:43] <fantasai_> glazou: If it's not in the spec, it doesn't need testing
  230. # [18:43] <fantasai_> arronei: The only statement in the spec is that you support <integer>, but the range is undefined
  231. # [18:43] <fantasai_> arronei: According to the spec, you only need to specify one number.
  232. # [18:43] <fantasai_> sylvaing: Is there anything in the test that mandates overflow behavior?
  233. # [18:43] <fantasai_> arronei: No
  234. # [18:45] <fantasai_> fantasai: You could test that the implementaiton supports the full 32-bit unsigned range
  235. # [18:45] <fantasai_> fantasai: by testing that the counter can go up to its limits
  236. # [18:46] <fantasai_> fantasai: this would test for a reasonable range
  237. # [18:46] <fantasai_> sylvaing: That's not in the spec
  238. # [18:47] <gsnedders> I'm +1 with what fantasai_ is saying now, FWIW.
  239. # [18:47] <fantasai_> dbaron: The agreement was that this would be a test suite assumption
  240. # [18:48] <TabAtkins> We still need to spec a required supported range for <integer>.
  241. # [18:48] <fantasai_> discussion on test suite assumptions vs spec requirements
  242. # [18:48] <TabAtkins> (Separate from the test discussion, which we did indeed discuss.)
  243. # [18:48] <TabAtkins> s/discussion/distinction/
  244. # [18:49] <fantasai_> plinss: integer overflow behavior isn't covered in the spec. We can add it to the spec later
  245. # [18:50] <fantasai_> glazou: I suggest we add a clarification to the spec that we expect 32-bit integers, and write tests for it
  246. # [18:50] <dbaron> there are already separate tests for the case you want to change this one to
  247. # [18:52] <fantasai_> fantasai doesn't think we need to put this in the spec, test suite assumption is enough
  248. # [18:52] <fantasai_> all we need is to have the tests only check that the range is supported, not check overflow behavior
  249. # [18:52] <gsnedders> Zakim: unmute me
  250. # [18:52] <gsnedders> Zakim, unmute me
  251. # [18:52] <Zakim> gsnedders should no longer be muted
  252. # [18:52] <fantasai_> Straw Poll
  253. # [18:53] <dbaron> I listed two different sets of tests in http://lists.w3.org/Archives/Public/public-css-testsuite/2010Oct/0040.html
  254. # [18:54] <dbaron> the tests in the first half test overflow behavior; the tests in the second half don't
  255. # [18:54] <fantasai_> sylvaing: I don't agree that the spec should require 32-bit integers
  256. # [18:54] <fantasai_> s/sylvaing/simon/
  257. # [18:54] <fantasai_> simon: But I do think that the spec should specify what happens when you overflow whatever range you support
  258. # [18:54] <szilles> +1 for what simon says
  259. # [18:55] <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
  260. # [18:55] <smfr> http://www.w3.org/TR/CSS2/syndata.html#value-def-integer
  261. # [18:55] <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
  262. # [18:55] <fantasai_> dbaron: Others do the overflow at parse times
  263. # [18:55] <fantasai_> dbaron: So there are two different overflow conditions happening
  264. # [18:56] <fantasai_> plinss: Here's my concrete proposal.
  265. # [18:56] <fantasai_> plinss: We leave the 32-bit assumption in the test suite
  266. # [18:56] * dbaron Zakim, mute fantasai
  267. # [18:56] * Zakim fantasai should now be muted
  268. # [18:56] <fantasai_> plinss: Define overflow behavior in a future spec
  269. # [18:56] <fantasai_> plinss: Remove this test for now
  270. # [18:56] <fantasai_> plinss: Change the test to match the overflow behavior in the spec
  271. # [18:57] <fantasai_> plinss: and allow e.g. 64-bit implementations pass
  272. # [18:57] <fantasai_> plinss: Instead of removing this test we could make it a may or a should
  273. # [18:57] <fantasai_> Zakim: unmute fantasai
  274. # [18:58] <dsinger> or at least a 'note' (Note: counters up to 32 bits are normally supported)
  275. # [18:58] <fantasai_> glazou: Peter, do you accept an action to write a clarification?
  276. # [18:58] * dbaron Zakim, unmute fantasai
  277. # [18:58] * Zakim fantasai should no longer be muted
  278. # [18:59] <fantasai_> fantasai: If we keep the tests, then they should be a 'may', because the behavior is not recommended, just allowed
  279. # [18:59] <fantasai_> fantasai: Also they should be updated so that a 64-bit implementation will pass
  280. # [18:59] <fantasai_> plinss: Failure condition should be showing a negative number
  281. # [19:00] <fantasai_> plinss: truncating for 255 is valid according to the test
  282. # [19:00] <fantasai_> Proposal:
  283. # [19:00] <fantasai_> 1. No change to spec
  284. # [19:00] <fantasai_> 2. Update tests to fail only if returning negative number
  285. # [19:01] <fantasai_> (i.e. any supported range is ok, but overflowing is not)
  286. # [19:01] <fantasai_> 3. Mark tests as 'may'
  287. # [19:01] <bradk> +1
  288. # [19:01] <fantasai_> 4. Add assumption of 32-bit integers to test suite assumptions page
  289. # [19:01] <dbaron> I'd have preferred keeping the tests that test values within the 32-bit range as required, given (4).
  290. # [19:02] <fantasai_> Yes, only mark the tests for overflow behavior as may :)
  291. # [19:02] <fantasai_> arronei: I agree that this is fine
  292. # [19:03] <dbaron> I'm happy with fantasai's proposal.
  293. # [19:03] <TabAtkins> I'm fine with that.
  294. # [19:03] <fantasai_> dsinger: Might want to add a note that stepping outside 32-bit integers is not a good idea so authors know
  295. # [19:04] <fantasai_> glazou: Any objections to the propsoal?
  296. # [19:04] <fantasai_> RESOLVED: Proposal above accepted.
  297. # [19:04] <fantasai_> ACTION plinss: Create a note for the errata
  298. # [19:04] * trackbot noticed an ACTION. Trying to create it.
  299. # [19:04] * RRSAgent records action 1
  300. # [19:04] <trackbot> Created ACTION-285 - Create a note for the errata [on Peter Linss - due 2010-12-29].
  301. # [19:04] <Zakim> -David_Baron
  302. # [19:04] <fantasai_> Meeting closed.
  303. # [19:04] <Zakim> -[Microsoft]
  304. # [19:04] <Zakim> -smfr
  305. # [19:04] <Zakim> -SteveZ
  306. # [19:04] <Zakim> -bradk
  307. # [19:04] <Zakim> -glazou
  308. # [19:04] <Zakim> -fantasai
  309. # [19:04] <Zakim> -gsnedders
  310. # [19:05] <Zakim> -plinss
  311. # [19:05] * Quits: glazou (glazou@82.247.96.19) (Quit: glazou)
  312. # [19:05] * Quits: danielweck (dweck2@81.157.12.143) (Quit: danielweck)
  313. # [19:06] * Quits: bradk (bradk@99.7.175.117) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
  314. # [19:07] * dsinger changes topic to 'Cascading Style Sheets (CSS) Working Group'
  315. # [19:07] <Zakim> -[Apple]
  316. # [19:07] * Quits: dsinger (dsinger@17.197.20.4) (Quit: dsinger)
  317. # [19:08] <arronei> What should we do about + and * notation in the value definitions?
  318. # [19:08] <arronei> What assumption should the test suite be making about those?
  319. # [19:10] <Zakim> -sylvaing
  320. # [19:10] <Zakim> Style_CSS FP()12:00PM has ended
  321. # [19:10] <Zakim> Attendees were dsinger, [Microsoft], glazou, +1.206.324.aaaa, smfr, bradk, plinss, +44.758.419.aabb, gsnedders, fantasai, sylvaing, SteveZ, David_Baron
  322. # [19:11] * Parts: smfr (smfr@68.183.26.214)
  323. # [19:17] * Joins: anne (annevk@83.85.115.123)
  324. # [19:20] * Quits: szilles (chatzilla@24.6.120.172) (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014])
  325. # [19:21] * Quits: fantasai_ (fantasai@68.248.62.130) (Ping timeout)
  326. # [19:36] * Joins: fantasai_ (fantasai@68.248.62.130)
  327. # [19:38] * Quits: fantasai_ (fantasai@68.248.62.130) (Quit: Lost terminal)
  328. # [20:26] * Quits: amphibulus (47ae4933@207.192.75.252) (Quit: http://www.mibbit.com ajax IRC Client)
  329. # [20:45] <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
  330. # [20:46] <dbaron> (indents by 200px, so it's pretty obvious)
  331. # [20:46] <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.)
  332. # [21:03] <dbaron> trackbot, ACTION-284?
  333. # [21:03] <trackbot> Sorry, dbaron, I don't understand 'trackbot, ACTION-284?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
  334. # [21:03] <dbaron> trackbot, url?
  335. # [21:03] <trackbot> Sorry, dbaron, I don't understand 'trackbot, url?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
  336. # [21:03] <dbaron> ACTION-284?
  337. # [21:03] * trackbot getting information on ACTION-284
  338. # [21:03] <trackbot> ACTION-284 -- David Baron to write proposal to handle position of float inside relpos'd inline -- due 2010-12-29 -- OPEN
  339. # [21:03] <trackbot> http://www.w3.org/Style/CSS/Tracker/actions/284
  340. # [21:15] * Zakim excuses himself; his presence no longer seems to be needed
  341. # [21:15] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  342. # [21:19] * Quits: anne (annevk@83.85.115.123) (Quit: anne)
  343. # [23:38] <arronei> dbaron: IE9 indents only item 2.
  344. # [23:39] <dbaron> arronei, good... does it somehow still pass http://test.csswg.org/suites/css2.1/20101210/html4/block-in-inline-relpos-002.htm ?
  345. # [23:41] <arronei> dbaron: we now fail that case with our latest builds so it looks like we are more inline with everyone else.
  346. # [23:42] <dbaron> arronei, ok, so that moves me more strongly towards the opinion that the spec is fine and we should just fix the test :-)
  347. # [23:42] <arronei> Yes I agree. We should just fix the test and leave the spec.
  348. # Session Close: Thu Dec 23 00:00:00 2010

The end :)