/irc-logs / freenode / #whatwg / 2008-01-17 / end

Options:

  1. # Session Start: Thu Jan 17 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:09] * Joins: phsiao (n=shawn@c-71-232-12-131.hsd1.ma.comcast.net)
  4. # [00:11] * Quits: virtuelv (n=virtuelv@65.80-202-82.nextgentel.com) ("Leaving")
  5. # [00:15] * Joins: webben (n=benh@91.84.244.69)
  6. # [00:17] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  7. # [00:23] * Joins: othermaciej_ (n=mjs@17.203.15.209)
  8. # [00:24] * Quits: othermaciej (n=mjs@17.255.110.3) (Nick collision from services.)
  9. # [00:24] * othermaciej_ is now known as othermaciej
  10. # [00:31] * Quits: billmason (n=billmaso@ip129.unival.com) (".")
  11. # [00:32] * Quits: webben (n=benh@91.84.244.69) (Connection timed out)
  12. # [00:40] * Joins: weinig (n=weinig@17.203.15.140)
  13. # [00:51] * Quits: tndH (i=Rob@adsl-87-102-83-222.karoo.KCOM.COM) ("ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  14. # [00:52] * weinig is now known as weinig|bbl
  15. # [01:21] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  16. # [01:26] * weinig|bbl is now known as weinig
  17. # [01:50] * Quits: aroben (n=aroben@unaffiliated/aroben)
  18. # [01:54] * Joins: othermaciej_ (n=mjs@17.255.110.3)
  19. # [02:04] * Quits: othermaciej (n=mjs@17.203.15.209) (Read error: 110 (Connection timed out))
  20. # [02:09] * Quits: othermaciej_ (n=mjs@17.255.110.3)
  21. # [02:12] * Joins: othermaciej (n=mjs@17.203.15.209)
  22. # [02:15] * Parts: a_magical_me2 (n=a_magica@c-67-171-194-99.hsd1.or.comcast.net)
  23. # [02:50] * Quits: markp (n=mark@adsl-221-79-53.rmo.bellsouth.net) (Remote closed the connection)
  24. # [03:09] <Hixie> Philip`: http://www.whatwg.org/specs/web-apps/current-work/#shadows
  25. # [03:09] <Hixie> Philip`: what do you think? i tried avoiding the maths...
  26. # [03:11] <Philip`> Hixie: "Shadows form part of the source image during composition." - they don't in Safari
  27. # [03:11] <Hixie> oh?
  28. # [03:11] <Philip`> (The shadow gets composited onto the canvas first, and then the source image is composited on top)
  29. # [03:11] <Hixie> that seems dumb
  30. # [03:12] <Hixie> wouldn't that mean you would get non-shadow-like effects when your globalcompositethingy is not source-over?
  31. # [03:14] <Philip`> http://canvex.lazyilluminati.com/misc/shadow/shadow2.html (in Safari) - the rows have different globalCompositeOperations, and it does result in things that don't really look like shadows
  32. # [03:15] * Joins: jasonw22 (n=jasonw22@64.74.213.174)
  33. # [03:15] <Hixie> does any browser to shadows other than safair?
  34. # [03:15] <Hixie> safari?
  35. # [03:15] <Philip`> No (though there's a patch for Firefox that I wrote)
  36. # [03:16] <Hixie> do you recommend that we try to get safari to change, or should i just make the spec do this weird behaviour?
  37. # [03:17] <Philip`> I assume Safari uses some CG function to draw shadows, so it'd be a pain if they had to rewrite it all to do custom rendering, and I don't think any other behaviour would be significantly less weird
  38. # [03:17] <Hixie> k
  39. # [03:18] <Philip`> (I don't have any kind of intuitive understanding of what should happen when you xor a semi-transparent shadowed shape onto a background, so everything is equally weird)
  40. # [03:19] <Hixie> true
  41. # [03:19] <Philip`> (and Safari's approach is at least sensible when you have operation=source-over and globalAlpha=anything)
  42. # [03:20] <Hixie> ok, changed the drawing model (it'll update in about 60 seconds)
  43. # [03:21] * Quits: weinig (n=weinig@17.203.15.140) (Read error: 104 (Connection reset by peer))
  44. # [03:21] * Joins: weinig (n=weinig@17.203.15.140)
  45. # [03:21] * Quits: jasonw22 (n=jasonw22@64.74.213.174) ("leaving")
  46. # [03:22] <Philip`> "The shadowBlur attribute specifies the number of coordinate space units that the blurring is to cover." - it doesn't really specify that, since there's some non-linear calculation to convert shadowBlur into the Gaussian radius and then the blur is theoretically infinitely wide; so maybe it should say something vague like "The shadowBlur attribute determines the size of the blur"
  47. # [03:24] <Philip`> "Copy the alpha channel of A to B, offset by shadowOffsetX in the positive x direction, and shadowOffsetY in the positive y direction." - shadowOffsetY is not a link
  48. # [03:24] <Philip`> "let σ be the square root of span>shadowBlur*2" - HTML leakage, and also the sentence doesn't end with a "."
  49. # [03:26] <Hixie> thanks, fixed and regenning...
  50. # [03:26] <Philip`> "Perform a Gaussian Blur on B" - might be slightly clearer as "Perform a 2D Gaussian blur on B"
  51. # [03:26] <Hixie> fixed and regenning...
  52. # [03:27] <Hixie> do you have a good reference for 2D Gaussian Blur, btw? i looked at google scholar for a siggraph paper or something, but found nothing
  53. # [03:27] <Philip`> "Multiply the alpha component of every pixel in B by the alpha components of the color of shadowColor." - s/components/component/
  54. # [03:28] <Hixie> fixed internally
  55. # [03:29] <Philip`> Hmm, I don't know of any references
  56. # [03:30] <Philip`> Gauss probably wasn't into computer graphics much, and afterwards Gaussian blurs were sufficiently obvious that maybe nobody could publish research papers about it
  57. # [03:30] <Hixie> heh
  58. # [03:32] <Philip`> Maybe there's some standard graphics textbook that describes fundamental things like that, but I wouldn't know of it
  59. # [03:32] <Hixie> several people have suggested text books, but i'd rather refer to the original reference or to nothing at all
  60. # [03:35] <Philip`> "Rendered the shadow from image A, using the current shadow styles, creating image B." - s/Rendered/Render/
  61. # [03:35] * Quits: roc (n=roc@202.0.36.64)
  62. # [03:35] <Philip`> It's not clear what should be done when shadows are not supported
  63. # [03:35] * Joins: roc (n=roc@202.0.36.64)
  64. # [03:36] <kig> it's a convolution kernel with the factors following a gaussian distribution, right?
  65. # [03:36] <Hixie> Philip`: hm, good point
  66. # [03:36] <Philip`> kig: Yes
  67. # [03:39] <Philip`> "Multiply the alpha component of every pixel in B by globalAlpha." (and subsequent lines) - "B" should be italics
  68. # [03:40] <Hixie> will fix
  69. # [03:41] <Philip`> Back at the beginning, "Shadows form part of the source image during composition." should be removed (if it isn't already)
  70. # [03:43] <Philip`> Is it worth saying something like "σ (may|should) be clamped to a maximum value before drawing, to prevent excessive memory usage"?
  71. # [03:44] <Philip`> Hmm, don't think I see anything else to comment on at the moment
  72. # [03:45] <Philip`> (It's sensible to avoid the maths for the blurring - I don't know why I originally suggested writing it all explicitly, when it's not like anyone is going to implement it based on the spec's maths)
  73. # [03:47] <Hixie> would this be ok:
  74. # [03:47] <Hixie> <p>User agents may limit values of <var title="">&sigma;</var> to
  75. # [03:47] <Hixie> an implementation-specific maximum value to avoid memory or CPU
  76. # [03:47] <Hixie> limitations during the Gaussian blur operation.</p>
  77. # [03:47] <Hixie> s/avoid memory/avoid exceeding memory/
  78. # [03:48] <Hixie> and s/memory or CPU/hardware/
  79. # [03:49] <Philip`> I think that sounds reasonable, just as a hint to implementors that they should prevent shadowBlur=1e10
  80. # [03:49] * Joins: jwalden (n=waldo@RANDOM-SEVENTY-TWO.MIT.EDU)
  81. # [03:51] <Hixie> is clearRect() affected by the clipping region?
  82. # [03:52] <Philip`> Yes, in Opera/Firefox/Safari
  83. # [03:52] <Hixie> but not globalAlpha or globalCompositeOperation, right?
  84. # [03:52] <Philip`> according to http://philip.html5.org/tests/canvas/suite/tests/2d.clearRect.clip.html (although Opera is a bit funny and gets the alpha slightly wrong)
  85. # [03:52] <Philip`> No (except globalCompositeOperation in Opera 9.2 (not 9.5)), according to http://philip.html5.org/tests/canvas/suite/tests/2d.clearRect.globalcomposite.html
  86. # [03:53] <Hixie> ok
  87. # [03:53] <Philip`> (and http://philip.html5.org/tests/canvas/suite/tests/2d.clearRect.globalalpha.html)
  88. # [03:53] <Hixie> thanks
  89. # [03:53] <Philip`> (and it's affected by shadows in Safari, which seems silly)
  90. # [03:54] <Hixie> ok, regenning the new text for shadows and clearRect()
  91. # [03:57] <Hixie> i don't seem to be getting as much mail this year as last year
  92. # [03:57] <Hixie> let's hope this lasts
  93. # [03:58] <Hixie> regenned
  94. # [04:03] <Philip`> Is there any value in being explicit that shadowOffset[XY] are not affected by the CTM?
  95. # [04:03] <Philip`> (since it's now mentioned that shadowBlur is unaffected by it)
  96. # [04:04] <Philip`> "... the new value is igored." - I'm not sure what Igor is doing here
  97. # [04:05] <Philip`> The whole "Let A be the source image for which a shadow is being created." etc section has non-italic "A", whereas the Drawing Model section has italic "A"
  98. # [04:07] <Philip`> "If shadowBlur is less than 8, let σ be shadowBlur/2; otherwise, let σ be the square root of shadowBlur*2." - the "/" and "*" look a bit out of place - maybe use the proper divide and times symbols?
  99. # [04:08] <Philip`> I'll assume implementors can work out for themselves that the shadow rendering can be skipped iff shadowColor.alpha == 0
  100. # [04:09] <Philip`> (since they'd be stupid to not optimise that case)
  101. # [04:10] <Philip`> It'd be nice if "Render the shadow from image A, using the current shadow styles, creating image B." linked back to the definition of how to render a shadow
  102. # [04:10] * Philip` can't think of any comments now again
  103. # [04:12] * Philip` goes to bed
  104. # [04:28] * Quits: dbaron (n=dbaron@guest-229.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  105. # [05:04] * Quits: weinig (n=weinig@17.203.15.140)
  106. # [05:27] * Joins: roc_ (n=roc@202.0.36.64)
  107. # [05:34] * Joins: roc__ (n=roc@202.0.36.64)
  108. # [05:36] * Quits: roc (n=roc@202.0.36.64) (Read error: 110 (Connection timed out))
  109. # [05:52] * Quits: roc_ (n=roc@202.0.36.64) (Read error: 110 (Connection timed out))
  110. # [06:01] * Quits: roc__ (n=roc@202.0.36.64)
  111. # [06:13] * Joins: dbaron (n=dbaron@c-71-204-145-103.hsd1.ca.comcast.net)
  112. # [06:24] * Quits: jruderman (n=jruderma@guest-229.mountainview.mozilla.com)
  113. # [06:26] * Joins: markp (n=mark@adsl-221-79-53.rmo.bellsouth.net)
  114. # [06:40] * Quits: othermaciej (n=mjs@17.203.15.209) (Read error: 104 (Connection reset by peer))
  115. # [06:51] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  116. # [07:13] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  117. # [07:33] * MacDome is now known as MacDomeSleep
  118. # [07:41] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  119. # [07:53] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca/")
  120. # [08:18] * Quits: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl) (Read error: 110 (Connection timed out))
  121. # [08:21] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  122. # [08:36] * Quits: dbaron (n=dbaron@c-71-204-145-103.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  123. # [08:53] * weinig is now known as weinig|zZz
  124. # [09:05] * Joins: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl)
  125. # [09:06] * Joins: roc (n=roc@121-72-35-221.dsl.telstraclear.net)
  126. # [09:15] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  127. # [09:34] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  128. # [10:01] * MacDomeSleep is now known as MacDome
  129. # [10:08] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  130. # [10:13] * Joins: webben (n=benh@nat/yahoo/x-9708837d264970f8)
  131. # [10:13] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (devel) (IRC client for Emacs)")
  132. # [10:14] * Joins: ROBOd (n=robod@89.122.216.38)
  133. # [10:26] * Joins: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  134. # [10:43] * Joins: roc_ (n=roc@121-72-13-251.dsl.telstraclear.net)
  135. # [10:44] * Joins: Camaban (n=adrianle@host81-133-229-168.in-addr.btopenworld.com)
  136. # [10:50] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
  137. # [10:52] * Quits: roc (n=roc@121-72-35-221.dsl.telstraclear.net) (Read error: 110 (Connection timed out))
  138. # [10:54] * Quits: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  139. # [11:01] * Joins: peepo (n=Jay@host217-42-95-198.range217-42.btcentralplus.com)
  140. # [11:01] * Quits: roc_ (n=roc@121-72-13-251.dsl.telstraclear.net) (Read error: 110 (Connection timed out))
  141. # [11:06] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  142. # [11:06] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) (Remote closed the connection)
  143. # [11:07] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  144. # [11:19] * Quits: peepo (n=Jay@host217-42-95-198.range217-42.btcentralplus.com) ("later")
  145. # [11:47] * Joins: tndH_ (i=Rob@adsl-87-102-83-222.karoo.KCOM.COM)
  146. # [11:47] * tndH_ is now known as tndH
  147. # [12:00] * Joins: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  148. # [12:19] * Quits: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl) ("Trillian (http://www.ceruleanstudios.com")
  149. # [12:26] * Joins: gsnedders (n=gsnedder@host217-42-133-143.range217-42.btcentralplus.com)
  150. # [12:27] * Quits: heycam (n=cam@210-84-62-145.dyn.iinet.net.au) ("bye")
  151. # [12:30] * Joins: heycam (n=cam@210-84-62-145.dyn.iinet.net.au)
  152. # [12:31] * Quits: jwalden (n=waldo@RANDOM-SEVENTY-TWO.MIT.EDU) (Remote closed the connection)
  153. # [12:50] * Quits: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  154. # [13:01] * Quits: webben (n=benh@nat/yahoo/x-9708837d264970f8)
  155. # [13:26] * Joins: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl)
  156. # [13:47] * MacDome is now known as MacDomeSleep
  157. # [13:47] * Quits: MacDomeSleep (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  158. # [13:55] * Joins: MacDome (n=eric@c-69-181-78-198.hsd1.ca.comcast.net)
  159. # [13:56] * MacDome is now known as MacDomeSleep
  160. # [14:04] * Joins: webben (n=benh@nat/yahoo/x-f4ac65ba2d1aa3b8)
  161. # [14:09] * Quits: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl) ("Trillian (http://www.ceruleanstudios.com")
  162. # [14:28] * Joins: vant (n=vant@p3165-ipbf2804marunouchi.tokyo.ocn.ne.jp)
  163. # [15:07] * Quits: weinig|zZz (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  164. # [15:08] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  165. # [15:11] * Joins: jgraham__ (n=jgraham@81-86-212-85.dsl.pipex.com)
  166. # [15:13] * Quits: jgraham (n=james@81-86-209-97.dsl.pipex.com) (Read error: 110 (Connection timed out))
  167. # [15:13] * Joins: jgraham (n=james@81-86-212-85.dsl.pipex.com)
  168. # [15:14] * Quits: jgraham_ (n=jgraham@81-86-209-97.dsl.pipex.com) (Read error: 110 (Connection timed out))
  169. # [15:20] <hsivonen> based on the minutes, the waf telecon seems to have been one that would have been interesting to listen to...
  170. # [15:20] * Quits: webben (n=benh@nat/yahoo/x-f4ac65ba2d1aa3b8) (Read error: 110 (Connection timed out))
  171. # [15:22] <Dashiva> Are the minutes public?
  172. # [15:22] <hsivonen> Dashiva: yes.
  173. # [15:23] <hsivonen> Dashiva: http://www.w3.org/mid/213B17B2-B67E-4D5F-A6D9-D7C3499AB228@nokia.com
  174. # [15:24] * Joins: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  175. # [15:31] <Dashiva> Interesting indeed
  176. # [15:41] * Joins: webben (n=benh@nat/yahoo/x-1283f4392d2de7cc)
  177. # [15:50] * Quits: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  178. # [16:27] * Quits: phsiao (n=shawn@c-71-232-12-131.hsd1.ma.comcast.net)
  179. # [16:30] * Joins: csarven (n=nevrasc@on-irc.csarven.ca)
  180. # [16:37] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) (Remote closed the connection)
  181. # [16:46] * Joins: billmason (n=billmaso@ip129.unival.com)
  182. # [17:03] * Joins: phsiao (n=shawn@74.92.58.17)
  183. # [17:12] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  184. # [17:24] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  185. # [17:29] * Quits: billmason (n=billmaso@ip129.unival.com) (Read error: 104 (Connection reset by peer))
  186. # [17:29] * Joins: aroben (n=aroben@c-76-124-50-18.hsd1.pa.comcast.net)
  187. # [17:32] * Joins: billmason (n=billmaso@ip129.unival.com)
  188. # [17:39] * Joins: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  189. # [17:40] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  190. # [17:53] * Joins: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  191. # [18:03] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  192. # [18:09] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  193. # [18:11] * Quits: vant (n=vant@p3165-ipbf2804marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  194. # [18:11] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  195. # [18:19] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  196. # [18:24] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  197. # [18:31] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  198. # [18:32] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  199. # [18:42] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("Leaving")
  200. # [18:45] * Quits: csarven (n=nevrasc@on-irc.csarven.ca) (Read error: 110 (Connection timed out))
  201. # [18:48] * Joins: csarven (n=nevrasc@on-irc.csarven.ca)
  202. # [18:50] * Parts: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  203. # [18:51] * Quits: phsiao (n=shawn@74.92.58.17)
  204. # [18:52] * Quits: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  205. # [19:01] * Quits: webben (n=benh@nat/yahoo/x-1283f4392d2de7cc)
  206. # [19:01] * Joins: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  207. # [19:02] * Joins: webben (n=benh@nat/yahoo/x-30a792eed0c8fba3)
  208. # [19:08] * Joins: dbaron (n=dbaron@c-71-204-145-103.hsd1.ca.comcast.net)
  209. # [19:10] * Parts: Camaban (n=adrianle@host81-133-229-168.in-addr.btopenworld.com)
  210. # [19:10] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  211. # [19:23] * Joins: phsiao (n=shawn@nat/ibm/x-9f37440f3a1ab8ea)
  212. # [19:24] * Quits: csarven (n=nevrasc@on-irc.csarven.ca) (Read error: 110 (Connection timed out))
  213. # [19:27] * Joins: hdh (n=hdh@118.71.74.134)
  214. # [19:30] * Joins: Lachy_ (n=Lachlan@ti200710a340-1582.bb.online.no)
  215. # [19:31] * Quits: Lachy_ (n=Lachlan@ti200710a340-1582.bb.online.no) (Client Quit)
  216. # [19:31] * Joins: weinig (n=weinig@17.203.15.140)
  217. # [19:33] * Joins: Lachy_ (n=Lachlan@ti200710a340-1582.bb.online.no)
  218. # [19:38] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  219. # [19:47] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  220. # [19:47] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  221. # [19:51] * Quits: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  222. # [19:54] * Joins: hober (n=ted@unaffiliated/hober)
  223. # [19:56] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  224. # [19:57] * Quits: Lachy_ (n=Lachlan@ti200710a340-1582.bb.online.no) (Read error: 110 (Connection timed out))
  225. # [19:57] * Joins: csarven (n=nevrasc@on-irc.csarven.ca)
  226. # [20:00] <hsivonen> annevk: FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=289938#c16
  227. # [20:07] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("Leaving")
  228. # [20:24] * Joins: roc (n=roc@121-72-13-251.dsl.telstraclear.net)
  229. # [20:36] * Joins: SadEagle (n=maksim@kde/orlovich)
  230. # [20:37] <SadEagle> Hiya Hixie... Any chance you have a reference/spec on how you expect button.type to behave? Mozilla's and Opera's implementations are not interoperable (and ours just play sucks)
  231. # [20:41] <SadEagle> I guess WF2.0 behavior is consistent with Opera, though..
  232. # [20:41] * Quits: roc (n=roc@121-72-13-251.dsl.telstraclear.net)
  233. # [20:43] * MacDomeSleep is now known as MacDome
  234. # [20:46] <heycam> Hixie, the not crashing requirement on safari 3 for the acid3 submissions, is that an actual safari 3 release, rather than a webkit nightly?
  235. # [20:59] * Quits: dbaron (n=dbaron@c-71-204-145-103.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  236. # [21:00] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  237. # [21:11] <Hixie> SadEagle: dom2 html :-)
  238. # [21:11] <Hixie> heycam: both, ideally
  239. # [21:12] <SadEagle> Hixie: come on. You know as well as me that that spec is barely above useless.
  240. # [21:13] <SadEagle> I can make some guesses about what they -meant- by the case folding remark. But it says nothing about what to do when the value isn't one of the button / submit / reset.
  241. # [21:15] <SadEagle> Mozilla behavior is that the values submit / button / reset are case folded on return. Other values are unaffected, including returning uppercase (which does contradict the lowercasing remark). Lack of attribute (what you test for, I think?) is interpreted as submit.
  242. # [21:16] <heycam> Hixie, ok
  243. # [21:16] <SadEagle> Opera (and ~now Konq) behavior is to revert to 'submit' if the value of type isn't valid (or blank), and otherwise return the type.
  244. # [21:17] * Joins: roc (n=roc@202.0.36.64)
  245. # [21:19] <Hixie> SadEagle: unless WF2 says something else, i don't have any better spec yet. HTML5 will eventually cover this of course. Feel free to send mail to whatwg or public-html to remind me to fix this.
  246. # [21:20] <SadEagle> Hixie: well, WF2 says that invalid values of attributes should be ignored, which is basically what opera does, with the interpretation that type is returning the computed value..
  247. # [21:43] * Joins: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  248. # [21:49] * Quits: weinig (n=weinig@17.203.15.140)
  249. # [21:50] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  250. # [21:50] <othermaciej> Hixie: I'm not sure tests 26 and 27 are a good idea, since it is an obscure case and the obvious ways preserving connected ancestors as well as descendants across GC would likely hurt DOM performance
  251. # [21:50] <othermaciej> (I guess we can see if it does for real though)
  252. # [21:55] <othermaciej> the expected behavior also could cause web apps to unintentionally hold down larger chunks of memory than they might expect (XHR, grab a single node without removing it, now you have extended the lifetime of the whole result document)
  253. # [21:55] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (Connection timed out)
  254. # [21:56] * gsnedders annevk pig
  255. # [21:57] * gsnedders can't type
  256. # [21:57] <gsnedders> that was meant to be: /msg annevk ping
  257. # [22:07] <Hixie> othermaciej: i disagree, iv'e run into this kind of thing before, as have others, and i think it's clear that the DOM requires browsers to not be GCing accessible stuff
  258. # [22:09] <othermaciej> Hixie: I'm not sure it's particularly clear that the DOM requires anything on this
  259. # [22:10] <Hixie> i think you'd be hard-pressed to argue that the DOM allows you to just start setting parentNode to null whimsically
  260. # [22:11] <othermaciej> I don't think it's clear that it doesn't require it either - just not sure "clear" is a word that applies
  261. # [22:11] <othermaciej> it doesn't say anything about what operations not mentioned by the DOM spec may mutate the DOM
  262. # [22:12] <othermaciej> it's clearly not "none", since other specs require various things to mutate the DOM
  263. # [22:12] <Hixie> so you're saying that if IE started moving nodes around randomly in the DOM, it would be conforming?
  264. # [22:12] <othermaciej> I can see how a sensible person might not think "allocating memory" shouldn't be one of those operations
  265. # [22:12] <othermaciej> well, it would be a perverse interpretation of the spec
  266. # [22:13] <othermaciej> but I don't think the spec is "clear" on this
  267. # [22:13] <Hixie> there is no normative prose anywhere that allows the parentNode to change, as far as i can tell
  268. # [22:13] <Hixie> in this spec or any other
  269. # [22:14] <Hixie> and since parentNode is defined as returning the parent, and appendChild is defined as setting the parent, i don't see how you can have an interpretation that allows the parent to change
  270. # [22:14] <othermaciej> you mean, "as a result of garbage collection", or no prose allows the parentNode to change ever?
  271. # [22:14] <Hixie> i meant as a result of the browser randomly deciding to do it (e.g. as part of GC)
  272. # [22:15] <Hixie> if there was some text that could define _when_ exactly the parent would be lost, then ok
  273. # [22:15] <Hixie> but there isn't, and browsers are losing the parent in different ways because of it
  274. # [22:15] * Quits: webben (n=benh@nat/yahoo/x-30a792eed0c8fba3)
  275. # [22:16] <Hixie> this is an interoperability nightmare that should be fixed by not dropping parts of the DOM on the floor
  276. # [22:16] <Hixie> it's not like you're actually saving memory intentionally on real sites because of this
  277. # [22:16] <Hixie> bbiab
  278. # [22:16] <othermaciej> it's true that no normative prose explicitly allows that, but nor does it explicitly forbid it
  279. # [22:16] <annevk> hsivonen, actually, we have magic behavior that approaches Gecko, just not for all public identifiers that Gecko recognizes, such as MathML
  280. # [22:16] <Hixie> othermaciej: yes it does! it says it should return the parent, and the parent was set by appendChild
  281. # [22:17] <othermaciej> Hixie: but clearly there's things not in the DOM Core spec which would require you to change the parent
  282. # [22:17] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Read error: 113 (No route to host))
  283. # [22:17] <othermaciej> even things that do not result from any DOM call (like parsing a document)
  284. # [22:17] <Hixie> othermaciej: and none of those things are happening here
  285. # [22:18] <Hixie> othermaciej: indeed _nothing_ is happening here, it's one piece of script
  286. # [22:18] <othermaciej> if script is executing then obviously something is happening
  287. # [22:19] <Hixie> othermaciej: i mrsn nothing is happening to the DOM, between the setting and the checking
  288. # [22:19] <Hixie> othermaciej: specs cannot say what must not happen, there's an infinite list of things that would have to be listed
  289. # [22:20] <Hixie> othermaciej: "browsers must not set attributes for no reason. browsers must not change the values of attributes for no reason. browsers must not..."
  290. # [22:20] <Hixie> othermaciej: if you go down this line of argument, then almost any bug can be explained as "well the spec doesn't say it _shouldn't_ happen on the 3rd of september at 2pm..."
  291. # [22:21] <Hixie> really must go, will be back shortly
  292. # [22:22] <othermaciej> I'm not sure if there's a justification in the text of DOM Core why html parsing can mutate the DOM but garbage collection (or occurence of a random date) is not, but I admit I can't think of how you would write it to make that clear
  293. # [22:24] <othermaciej> it can't just be "another standard says so" because I don't think the fact that insertAdjacentHTML mutates the DOM would be considered nonconforming to the DOM spec
  294. # [22:25] <annevk> HTML parsing defines what DOM mutations are to be performed
  295. # [22:25] <othermaciej> but it does indeed seem lame to assume that therefore anything is permitted
  296. # [22:25] <annevk> which is slightly different I'd say
  297. # [22:26] <othermaciej> well, I could write a document saying what DOM mutations may or may not be performed when garbage collecting, but I don't think that should retroactively change the meaning of DOM Core
  298. # [22:27] <othermaciej> and no spec defines what DOM mutations are to be performed when calling insertAdjacentHTML
  299. # [22:27] <annevk> no spec defines insertAdjacentHTML
  300. # [22:28] <othermaciej> that is true
  301. # [22:29] <roc> defining side effects that can happen during GC is nasty, because GC is very non-deterministic
  302. # [22:29] <othermaciej> there is a spec that defines ECMAScript garbage collection, namely ECMA-262
  303. # [22:31] <othermaciej> but it's probably super vague about participation of host objects in GC
  304. # [22:32] <annevk> in the name of interop it's probably good that Acid3 includes things that really annoy each of the browser vendors
  305. # [22:32] <othermaciej> the logical model is that child references are strong references and parent references are weak references
  306. # [22:32] <annevk> the 0 bytes in the DOM issue bites us
  307. # [22:32] * Quits: zcorpan (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  308. # [22:33] <roc> surely by now all browser vendors are too jaded to be annoyed by anything
  309. # [22:33] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  310. # [22:33] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 110 (Connection timed out))
  311. # [22:33] <othermaciej> yeah
  312. # [22:35] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  313. # [22:35] <roc> othermaciej: weak references suck too. especially when they're not explicit
  314. # [22:35] <othermaciej> actually I think it would be easy to make the specific acid3 test for this pass, the hard case would be preserving pieces of the DOM that have never been referenced from JS
  315. # [22:36] <roc> if (elem.parentNode) { elem.parentNode.setAttribute(...) }
  316. # [22:36] <roc> sure hope you didn't GC in there!
  317. # [22:37] <roc> at least with explicit weak refs like in Java, I have to declare the weak ref and then do a .get() to get the real reference, so I know something's up
  318. # [22:38] <othermaciej> I'm not saying it's great behavior, it just happens to be what we lovingly reverse-engineered from Mozilla as best we could
  319. # [22:39] <roc> oh, I didn't know there was a compatibility argument
  320. # [22:40] <othermaciej> I'm not sure compatibility cares that much one way or the other
  321. # [22:40] <roc> so why'd you reverse engineer it?
  322. # [22:40] <othermaciej> (about preserving parents in detached DOM fragments)
  323. # [22:40] <othermaciej> there was some site that required specific things about preserving DOM wrappers for descendants of detached DOM subtrees years ago
  324. # [22:41] <othermaciej> (actually worse than a site, I think it was an "enterprise" app's html interface)
  325. # [22:41] <hsivonen> doesn't the Web JS concurrency model guarantee that if you walk down the tree, you can walk back up in the same method without someone else mutating the tree in ways that make weak refs collectable?
  326. # [22:41] <othermaciej> so we tested what other browsers did for parents or siblings of detached trees across GC
  327. # [22:42] <othermaciej> hsivonen: if what you're getting at is that roc's example can't possibly fail if "eleme" is in the document tree then I think you are right
  328. # [22:43] <roc> yeah
  329. # [22:43] <roc> but if it isn't...
  330. # [22:43] <hsivonen> othermaciej: I meant roc's case, yes
  331. # [22:43] <Hixie> one thing to consider is that any argument that could be made to say test 23 is invalid could also be used to make test 99 invalid
  332. # [22:44] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 131 (Connection reset by peer))
  333. # [22:44] <Hixie> er, s/23/26/
  334. # [22:44] <Hixie> and i really don't think you want test 99 to be invalid
  335. # [22:44] <othermaciej> if elem is not in the document tree then indeed weird things could happen in very speculative theory, but in fact won't, since there's nothing to trigger a GC at times that no temporary expression holds a reference
  336. # [22:44] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  337. # [22:44] <hsivonen> I still don't understand when parentNode is a weak ref to something for which there isn't a reciprocal hard ref
  338. # [22:44] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  339. # [22:44] <hsivonen> isn't parentNode nulled automatically if you detach a node from the tree?
  340. # [22:45] <othermaciej> if you removeChild, yes, it is nulled
  341. # [22:46] <othermaciej> the case where it is effectively a weak ref in WebKit (and was in Gecko and IE at least last time I tested) is if you have node A containing node B in document D, then you remove node A from the document, keep a reference to node B, and drop all your references to node A
  342. # [22:47] <hsivonen> hmm. interesting case
  343. # [22:47] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  344. # [22:47] <Hixie> the gc bg fails in gecko differently than webkit
  345. # [22:47] <roc> FWIW it still is weak in Gecko, we fail testcase 26, but we have enough infrastructure to fix it pretty easily post-FF3
  346. # [22:47] <Hixie> in one the ndoes have to still be in the doc, in the other the nodes have to be outside of the dic
  347. # [22:47] <othermaciej> Hixie: test 99 is comedy gold
  348. # [22:48] <Hixie> indeed
  349. # [22:48] <hsivonen> I don't recall seeing any weak refs in Java DOM impls, but then weak refs wasn't what I was paying attention to
  350. # [22:48] <Hixie> hsivonen: you have to have weak refs if you're using ref counting, otherwise you'll never reach zero
  351. # [22:48] <Hixie> hsivonen: not so much an issue with other GC schemes
  352. # [22:49] <roc> you wouldn't expect to, Java has a real collector so cyclic structures were never a problem
  353. # [22:49] <othermaciej> Java DOM impls probably have strong refs both ways because Java DOMs would be written in pure Java
  354. # [22:49] <hsivonen> ah right.
  355. # [22:50] <roc> othermaciej: "if elem is not in the document tree then indeed weird things could happen in very speculative theory, but in fact won't" ... I'm not sure about that. I can easily imagine running unrelated windows in different threads sharing a common JS heap
  356. # [22:51] <roc> or the Gears thread stuff
  357. # [22:53] <othermaciej> roc: that's the kind of stuff that I considered to be in the "speculative theory" category (though Gears might potentially be less speculative)
  358. # [22:54] * Joins: virtuelv (n=virtuelv@65.80-202-82.nextgentel.com)
  359. # [22:57] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  360. # [22:58] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  361. # [22:58] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  362. # [23:00] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  363. # [23:00] * Joins: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  364. # [23:01] * MacDome is now known as MacDomeAFK
  365. # [23:02] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  366. # [23:02] * Quits: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 54 (Connection reset by peer))
  367. # [23:02] <roc> ok
  368. # [23:02] * Joins: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  369. # [23:03] <roc> we can differ on how far-fetched it is
  370. # [23:05] <roc> I think the only thing preventing that case from occurring in Gecko + Gears today is where we place our GC safe points
  371. # [23:05] <roc> so I don't see it as all that far-fetched
  372. # [23:10] <roc> anyway, if that doesn't bother you, there's still the problem that inserting almost any code between the test of parentNode and the use of parentNode could allocate and trigger GC itself
  373. # [23:15] * Parts: hdh (n=hdh@118.71.74.134)
  374. # [23:17] <jruderman> Hixie: does safari 3 fail acid3's text-shadow by having the shadow too close to the text?
  375. # [23:17] <Hixie> what maks you ask that?
  376. # [23:17] <Hixie> makes
  377. # [23:17] <jruderman> its shadow is close to the text "Acid3" than in the reference
  378. # [23:18] <Hixie> not on my machine...
  379. # [23:18] <Hixie> but yes, if it is not pixel perfect, then it has failed
  380. # [23:18] <jruderman> ok
  381. # [23:22] <annevk> are you testing for multiple shadows?
  382. # [23:22] <annevk> that will make Safari fail
  383. # [23:22] <Hixie> no, just the one
  384. # [23:22] <Hixie> multiple shadows are out in css3, iirc
  385. # [23:23] <Hixie> ok i found a way to make the shift-click thing work in 3/4 browsers, up from 2/4
  386. # [23:23] <Hixie> still doesn't work in opera though
  387. # [23:23] <annevk> they're not out
  388. # [23:23] <Hixie> i thought they were out?
  389. # [23:23] <annevk> afaict they're not
  390. # [23:23] <Hixie> huh
  391. # [23:23] <Hixie> oh well
  392. # [23:23] <Hixie> they should be :-
  393. # [23:23] <Hixie> )
  394. # [23:24] <annevk> if you use document.close() it might start working in Opera
  395. # [23:24] <annevk> i haven't actually tested that myself though
  396. # [23:25] <annevk> oh, you do that now
  397. # [23:25] <Hixie> well if you work out something that will make it work in opera, let me know
  398. # [23:25] <Hixie> in the meantime, i'm out of here
  399. # [23:25] <Hixie> later
  400. # [23:25] <annevk> use <pre>
  401. # [23:26] * Quits: aroben (n=aroben@unaffiliated/aroben)
  402. # [23:26] <annevk> thought that requires some additional effort to escape the rest
  403. # [23:31] * MacDomeAFK is now known as MacDome
  404. # [23:34] * Quits: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no) ("Leaving")
  405. # [23:34] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  406. # [23:38] * Quits: csarven (n=nevrasc@on-irc.csarven.ca) (Connection timed out)
  407. # [23:39] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  408. # [23:52] * Quits: billmason (n=billmaso@ip129.unival.com) (".")
  409. # [23:55] * Joins: billmason (n=billmaso@ip129.unival.com)
  410. # Session Close: Fri Jan 18 00:00:00 2008

The end :)