/irc-logs / freenode / #whatwg / 2007-12-28 / end

Options:

  1. # Session Start: Fri Dec 28 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:02] * jacobolus1 is now known as jacobolus
  4. # [00:03] <gsnedders> Hixie: 2.1 doesn't seem to have complete error handling when I last looked, though
  5. # [00:03] <Hixie> what got overlooked?
  6. # [00:03] * gsnedders can't remember
  7. # [00:03] <gsnedders> I don't have the time to look right now
  8. # [00:03] * gsnedders is half asleep
  9. # [00:07] * Quits: jacobolus (n=jacobolu@pool-71-119-190-119.lsanca.dsl-w.verizon.net)
  10. # [00:14] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  11. # [00:15] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  12. # [00:34] * Joins: Dashimon (i=Dashiva@wikia/Dashiva)
  13. # [00:34] * Quits: Dashiva (i=Dashiva@wikia/Dashiva) (Read error: 104 (Connection reset by peer))
  14. # [00:34] * Dashimon is now known as Dashiva
  15. # [00:38] * Joins: mpt (n=mpt@host-134-225-176-194.readingconnect.net)
  16. # [00:42] * Joins: jdandrea (n=jdandrea@ool-44c0a1fe.dyn.optonline.net)
  17. # [00:45] <Hixie> it's very sad that despite not actually targetting IE at all, IE7 fails every test in acid3 so far
  18. # [00:46] <Philip`> Does it run the test framework correctly?
  19. # [00:46] <Philip`> (That was a significant problem for me with canvas tests in Safari and Firefox...)
  20. # [00:46] <Hixie> oh it doesn't fail _every_ test
  21. # [00:47] <Hixie> it passes 80 and 83
  22. # [00:47] <Hixie> wait 83 isn't done yet
  23. # [00:47] <Hixie> so it passes exactly one test
  24. # [00:47] <Hixie> i wonder who fails it
  25. # [00:48] <Hixie> seems nobody fails 80
  26. # [00:48] <Hixie> maybe i should change it
  27. # [00:48] <gsnedders> :D
  28. # [00:49] <gsnedders> the fun of acid tests… "wait, nobody fails this. better change this then…"
  29. # [00:50] <Hixie> oh hold on
  30. # [00:50] <Hixie> IE7 _does_ fail 80
  31. # [00:50] <Hixie> it just fails it in a way that does something odd to the results
  32. # [00:53] <takkaria> Hixie: have the ie8 team talked to you at all about more acid tests, or are you just doing acid3 because its time has come?
  33. # [00:55] <Hixie> neither
  34. # [00:56] <Hixie> i have asked the IE team to suggest tests, but they have refused to do so
  35. # [00:56] <Hixie> and i've been working on acid3 for at least 6 months now, on and off
  36. # [00:57] <G0k> what kind of stuff does acid3 test?
  37. # [00:58] <Hixie> dom
  38. # [00:58] <G0k> does anyone come close to passing it?
  39. # [00:58] <Hixie> any suggestions are welcome, and should ideally come in the form of a 1-20 line JS function that returns true or false
  40. # [01:06] * Quits: tndH (i=Rob@83.100.183.125) ("ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  41. # [01:08] * Quits: G0k (n=hmason@c-67-164-171-32.hsd1.co.comcast.net)
  42. # [01:09] * Quits: weinig (n=weinig@17.203.15.140)
  43. # [01:21] * Quits: billmason (n=billmaso@ip156.unival.com) (".")
  44. # [01:26] <Lachy_> Hixie, do you have any estimate for when you expect to complete acid 3?
  45. # [01:26] <Hixie> nope
  46. # [01:27] <Hixie> still many tests to come up with
  47. # [01:27] <Lachy_> yeah, I've noticed. I had a look at it last week to see how well Opera does
  48. # [01:27] <Lachy_> it's not too bad, but it certainly fails a lot
  49. # [01:32] * Quits: digx (n=rick@c-76-109-201-140.hsd1.fl.comcast.net) (brown.freenode.net irc.freenode.net)
  50. # [01:32] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (brown.freenode.net irc.freenode.net)
  51. # [01:34] * Joins: digx (n=rick@c-76-109-201-140.hsd1.fl.comcast.net)
  52. # [01:34] * Joins: gavin_ (n=gavin@firefox/developer/gavin)
  53. # [01:37] * Joins: weinig (n=weinig@17.203.15.140)
  54. # [01:46] * Joins: jgraham (n=james@cpc1-flee2-0-0-cust327.glfd.cable.ntl.com)
  55. # [01:47] * Quits: jdandrea (n=jdandrea@ool-44c0a1fe.dyn.optonline.net)
  56. # [02:08] * Quits: mpt (n=mpt@host-134-225-176-194.readingconnect.net) ("Leaving")
  57. # [02:22] * Quits: doublec (n=Chris_Do@203-97-173-6.cable.telstraclear.net) ("ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  58. # [02:30] * Quits: jgraham (n=james@cpc1-flee2-0-0-cust327.glfd.cable.ntl.com) ("This computer has gone to sleep")
  59. # [02:32] * Quits: weinig (n=weinig@17.203.15.140)
  60. # [02:32] * Joins: jgraham (n=james@cpc1-flee2-0-0-cust327.glfd.cable.ntl.com)
  61. # [02:33] * Quits: jgraham (n=james@cpc1-flee2-0-0-cust327.glfd.cable.ntl.com) (Client Quit)
  62. # [02:47] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) ("Leaving")
  63. # [02:52] * Joins: Lachy (n=Lachlan@ti200710a340-2416.bb.online.no)
  64. # [03:05] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  65. # [03:05] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  66. # [03:06] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  67. # [03:06] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  68. # [03:07] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  69. # [03:08] * Joins: othermaciej (n=mjs@67-41-200-69.hlrn.qwest.net)
  70. # [03:12] <Philip`> String attrib = attribs.getQName(i);
  71. # [03:12] <Philip`> if(attrib.startsWith("xmlns:")) {
  72. # [03:12] <Philip`> String space = attrib.substring(6);
  73. # [03:12] <Philip`> if(!space.equals("xsd")) {
  74. # [03:12] <Philip`> ...
  75. # [03:12] <Philip`> Could I be forgiven for thinking that's not the optimal way to process XML namespaces?
  76. # [03:12] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  77. # [03:13] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  78. # [03:16] * Quits: Lachy (n=Lachlan@ti200710a340-2416.bb.online.no) (Read error: 110 (Connection timed out))
  79. # [03:20] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  80. # [03:20] * Joins: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  81. # [03:21] <othermaciej> Philip`: that's some sad looking code
  82. # [03:26] <Philip`> As far as I can see, the code looks for <X3D xmlns:foo="[the X3D namespace URI]"> (where <X3D> has exactly qname "X3D", assuming it's not nested inside another <X3D>, and where foo != "xsd") and after that point it converts <foo:bar> into <bar> before its normal element processing
  83. # [03:27] <Philip`> which seems quite horrendously wrong
  84. # [03:36] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  85. # [03:43] <othermaciej> is xsd conventionally the prefix for something specific?
  86. # [03:43] <othermaciej> wondering why code would even check for that
  87. # [03:44] <Philip`> XML Schema
  88. # [03:45] <Philip`> The code does 'if(attrib.equals("xsd:noNamespaceSchemaLocation"))' to enable some extra processing or something
  89. # [03:47] <Philip`> The X3D world seems unpleasantly confused about namespaces and DTDs and schemas and whatnot
  90. # [03:47] * Quits: Lachy__ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 110 (Connection timed out))
  91. # [04:33] * Quits: othermaciej (n=mjs@67-41-200-69.hlrn.qwest.net)
  92. # [05:11] * Joins: hober (n=ted@unaffiliated/hober)
  93. # [06:19] * Joins: grimboy (n=grimboy@85-211-255-99.dsl.pipex.com)
  94. # [07:01] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  95. # [07:30] * Joins: othermaciej (n=mjs@198.202.202.20)
  96. # [07:32] * Quits: othermaciej (n=mjs@198.202.202.20) (Connection reset by peer)
  97. # [07:32] * Joins: othermaciej (n=mjs@198.202.202.20)
  98. # [07:32] * Quits: othermaciej (n=mjs@198.202.202.20) (Read error: 104 (Connection reset by peer))
  99. # [07:33] * Joins: othermaciej (n=mjs@198.202.202.20)
  100. # [07:34] * Quits: othermaciej (n=mjs@198.202.202.20) (Read error: 104 (Connection reset by peer))
  101. # [07:35] * Joins: othermaciej (n=mjs@198.202.202.20)
  102. # [07:36] * Quits: othermaciej (n=mjs@198.202.202.20) (Read error: 104 (Connection reset by peer))
  103. # [07:37] * Joins: othermaciej (n=mjs@198.202.202.20)
  104. # [07:37] * Quits: othermaciej (n=mjs@198.202.202.20) (Read error: 104 (Connection reset by peer))
  105. # [07:38] * Joins: othermaciej (n=mjs@198.202.202.20)
  106. # [07:38] * Quits: othermaciej (n=mjs@198.202.202.20) (Read error: 104 (Connection reset by peer))
  107. # [07:38] * Joins: othermaciej (n=mjs@198.202.202.20)
  108. # [07:40] * Quits: othermaciej (n=mjs@198.202.202.20) (Read error: 104 (Connection reset by peer))
  109. # [07:40] * weinig is now known as weinig|away
  110. # [07:40] * Joins: othermaciej (n=mjs@198.202.202.20)
  111. # [07:41] * Quits: othermaciej (n=mjs@198.202.202.20) (Read error: 104 (Connection reset by peer))
  112. # [07:41] * Joins: othermaciej (n=mjs@198.202.202.20)
  113. # [08:02] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  114. # [08:03] * Quits: othermaciej (n=mjs@198.202.202.20) (No route to host)
  115. # [08:03] * Quits: weinig|away (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  116. # [08:09] * Hixie makes extra sure to remove font metric dependencies in Ahem3
  117. # [08:09] <Hixie> er
  118. # [08:09] <Hixie> Acid3
  119. # [08:18] <Hixie> sigh, i still have so many tests to write and no idea what to do with them
  120. # [08:20] <jruderman> acid-style tests are overrated, imo. it's more meaningful to say "Browser X passes the entire test suite for Y" than "Browser X passes Acid N"
  121. # [08:24] <Hixie> i agree
  122. # [08:25] <Hixie> but try getting media attention for a test suite
  123. # [08:26] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (devel) (IRC client for Emacs)")
  124. # [08:40] * Joins: G0k (n=hmason@c-67-164-171-32.hsd1.co.comcast.net)
  125. # [08:42] * Joins: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  126. # [09:00] <jruderman> hehe
  127. # [09:14] <Hixie> i can't believe that with basically no effort on my part, IE fails every test
  128. # [09:15] <Hixie> i only targetted IE specifically for a couple of tests
  129. # [09:29] * MacDome wonders which tests
  130. # [09:29] <MacDome> which test suite rather
  131. # [09:32] <Hixie> acid3
  132. # [09:33] <Hixie> http://www.hixie.ch/tests/evil/acid/003/NOT_READY_PLEASE_DO_NOT_USE.html
  133. # [09:33] <Hixie> if you have any suggestions of what to test, btw, do let me know
  134. # [09:33] <MacDome> yeah, Safari seems to fail pretty hard
  135. # [09:34] <Hixie> i'm trying to make safari and moz fail
  136. # [09:34] <Hixie> so i'm especially interested in bugs that affect those browsers
  137. # [09:34] <MacDome> Hixie: well you already found the strange JS parsing forgiveness bug in FF
  138. # [09:35] <Hixie> actually that's in the spec as far as i can tell
  139. # [09:35] <MacDome> the fact that somehow it didn't barf at "table." on a line by itself
  140. # [09:35] <Hixie> oh that
  141. # [09:35] <Hixie> yeah i need to add that back
  142. # [09:35] <MacDome> add that back!?
  143. # [09:35] <MacDome> it's a bug in FF AFAICT
  144. # [09:35] <Hixie> right
  145. # [09:35] <Hixie> need to catch it
  146. # [09:35] <MacDome> I guess.
  147. # [09:36] <G0k> but are bugs in the js parser really relevant?
  148. # [09:36] <MacDome> you'd have to load a separate JS file which you expected to fail to parse
  149. # [09:36] <Hixie> eval baby
  150. # [09:36] <MacDome> G0k: Acid2 had all sorts of irrelevant stuff :)
  151. # [09:36] <Hixie> G0k: yes, that's what i'm trying to test
  152. # [09:36] <Hixie> G0k: JS and DOM
  153. # [09:37] <G0k> mightn't you accidentally make the test incompatible with future ECMAScript version?
  154. # [09:37] <G0k> or extensions?
  155. # [09:37] <Hixie> maybe
  156. # [09:38] <Hixie> but i try to avoid things i know will happen
  157. # [09:39] <G0k> say so has anyone implemented the cross-document messaging thing?
  158. # [09:39] <MacDome> you're using all sorts of CSS3 which we don't have yet :)
  159. # [09:39] <MacDome> by "all sorts" I mean CSS3 selectors
  160. # [09:40] <Hixie> i'm only testing things that were in CR or better as of 2004
  161. # [09:40] <annevk> G0k, Opera has
  162. # [09:40] <Hixie> so at least 3 year old technologies
  163. # [09:40] <annevk> but Hixie changed the spec to make our impl incompatible with what's in the spec...
  164. # [09:40] <Hixie> everyone should have had time to implement them
  165. # [09:41] <G0k> annevk: say i had an idea i wanted to discuss with you
  166. # [09:41] <annevk> sure
  167. # [09:41] <G0k> so the dom event stream thing
  168. # [09:41] * annevk just woke up, has time :)
  169. # [09:41] * MacDome wonders if Acid 3 will include SVG
  170. # [09:41] <Hixie> no, only DOM and JS stuff
  171. # [09:42] <G0k> so since there's been talk about throwing it out and most of the real suggested uses of the event stream stuff has been chat-style apps...
  172. # [09:42] <G0k> what about just specifying a DOM interface to XMPP or some other already existing messaging protocol?
  173. # [09:43] <G0k> xmpp would be particularly cool since it can be tunneled over HTTP and has a defined way of including XMLy stuff
  174. # [09:43] <Hixie> good lord that would be obscenely complicated
  175. # [09:43] <Hixie> XMPP over HTTP
  176. # [09:44] <G0k> it already exists....
  177. # [09:44] <Hixie> one of hte requirements is that you can implement this from scratch in perl or python with 10-20 lines of code
  178. # [09:44] <Hixie> fully conforming
  179. # [09:44] <G0k> you can implement an SQL database in 10-20 lines of perl or python, fully conforming?
  180. # [09:45] <Hixie> by authors, i mean
  181. # [09:45] <Hixie> for author technologies
  182. # [09:45] <Hixie> author-side, that is
  183. # [09:45] <MacDome> yay for Acid3 crashing Safari :)
  184. # [09:46] <Hixie> really?
  185. # [09:46] <Hixie> i've been avoiding crash bugs
  186. # [09:46] <krijnh> Doesn't crash Safari 3 on Windows
  187. # [09:46] <MacDome> http://bugs.webkit.org/show_bug.cgi?id=16632
  188. # [09:47] <MacDome> the inspector crashed
  189. # [09:47] <G0k> i mean there's already lots of perl/python XMPP libs
  190. # [09:47] <MacDome> by somehow causing us to go down an unsupported code path in our Image code
  191. # [09:47] <G0k> sending a message is easily a one liner
  192. # [09:48] <annevk> you are making the web dependent upon the XMPP protocol though, which does sound like overkill
  193. # [09:50] <G0k> i guess i just really really don't understand the point of inventing a new protocol here
  194. # [09:50] <G0k> there are so many network event style protocols....and instead we're taking the one that isn't (HTTP) and trying to beat it into submission
  195. # [09:51] <annevk> this one is over HTTP
  196. # [09:52] <annevk> and a lot simpler than XMPP
  197. # [09:53] <G0k> yeah but it has an installed base of very approximately zero, and basically no existing server-side APIs
  198. # [09:54] <G0k> i mean the beauty of it not "needing" an API because it's simple is cool
  199. # [09:54] <G0k> but how well is that going to scale?
  200. # [09:55] <G0k> other protocols are at least somewhat widely implemented
  201. # [09:56] <annevk> the main thing this needs for adoption is more client-side impl
  202. # [09:57] <G0k> but does it really do anything that, say, slow download XHR doesn't do already?
  203. # [09:59] <annevk> it requires less connections and is more convenient
  204. # [10:00] <annevk> you can probably implement this on top of an <iframe> too, but it's not pretty
  205. # [10:03] <annevk> hehe https://bugzilla.mozilla.org/show_bug.cgi?id=349255
  206. # [10:04] <Lachy> Hixie, is acid3 affected at all if the user doesn't have Ahem installed?
  207. # [10:06] <Lachy> Hixie, you could use Ahem as a downloadable font, using @fontface stuff from CSS2
  208. # [10:07] <annevk> that wasn't really a CR three years ago
  209. # [10:08] * Quits: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  210. # [10:10] * Parts: annevk (n=annevk@5352CE6F.cable.casema.nl)
  211. # [10:10] * Joins: annevk (n=annevk@5352CE6F.cable.casema.nl)
  212. # [10:13] <G0k> ok well my final argument is that XMPP can be implemented as a javascript library for non-supported UAs: http://zeank.in-berlin.de/jsjac/
  213. # [10:13] * Joins: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  214. # [10:13] <G0k> which I think would be much harder for the event stream spec, at least as its written right now
  215. # [10:14] <MacDome> Hixie: it would be nice if Acid3 would do a bit of logging :)
  216. # [10:14] <MacDome> as in, if it displayed some sort of message for each failed test
  217. # [10:14] <krijnh> MacDome: Click the <h1>
  218. # [10:14] <MacDome> interesting
  219. # [10:15] <G0k> *it's
  220. # [10:16] * MacDome is trying to figure out why buckets/result/intructions renders incorrect in WebKit
  221. # [10:21] * MacDome thinks that somehow #result is supposed to be placing itself below <h1> and it's failign to do so correctly
  222. # [10:24] <annevk> hmm, Hixie changed Acid3!
  223. # [10:24] <annevk> Opera renders it worse and fails more
  224. # [10:28] <MacDome> Hixie, krijnh: yeah, but assertions with actual logs are much easier to debug. :) I could point you towards our decent set of assertion functions for our JS tests if you like
  225. # [10:28] * Joins: ROBOd (n=robod@89.122.216.38)
  226. # [10:28] <G0k> is test 1 really fair? i mean isn't i possible that a DOM exists for PNG images that we just don't know about yet? :)
  227. # [10:29] <Lachy> at least outputting the results to something other tan an alert would be more useful so the results could be copied and pasted
  228. # [10:30] <annevk> hmm, you can't copy alert text?
  229. # [10:32] <annevk> btw, I dropped the advanced CSS value interfaces from the CSSOM
  230. # [10:32] <annevk> CSS animations seem better suited than using ECMAScript, even with convenient APIs
  231. # [10:33] <Lachy> annevk, not in all browsers. Only in Opera.
  232. # [10:33] <annevk> bah
  233. # [10:33] * annevk notes that the test URI is pretty clear about the state of the test, though
  234. # [10:34] <krijnh> You think so? :)
  235. # [10:35] <MacDome> annevk: yeah, just hoping to provide some early feedback :)
  236. # [10:35] <annevk> Hixie, may I suggest that instead of a text/html MIME type you give that test a "bogus" MIME type?
  237. # [10:35] <annevk> Hixie, such as Content-Type:bogus
  238. # [10:35] <MacDome> eeew
  239. # [10:36] <annevk> Hixie, because when we previously implemented proper support for MIME types and CSS loading it turned out Gecko didn't
  240. # [10:36] <annevk> and we broke a site
  241. # [10:37] <G0k> yeah i mean.....DOM doesn't define how to not parse other documents
  242. # [10:39] <G0k> whereas recognizing an invalid mime type is indeed a good UA behavior
  243. # [10:39] <annevk> I mean this test: <link rel="stylesheet" href="empty.css"><!-- text/html file (should be ignored, <h1> will go red if it isn't) -->
  244. # [10:40] <G0k> ohz
  245. # [10:41] <G0k> that is a tough one, since it's really bad behavior but i'm sure fixing that will break sites
  246. # [10:41] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
  247. # [10:42] <annevk> well, Gecko does it in standards mode, but it only does it if the MIME type actually parses correctly
  248. # [10:42] <annevk> for some value of "correctly"
  249. # [10:42] <annevk> I believe it checks if "/" or "\" occurs in the MIME type string...
  250. # [10:42] <G0k> so if it were text/bogus, what would happen?
  251. # [10:42] <annevk> then it would not apply in Gecko
  252. # [10:43] <annevk> but if it was "bogus" it would
  253. # [10:43] <G0k> hm. and what if it were omited?
  254. # [10:43] <G0k> if that...even makes snese
  255. # [10:43] <annevk> if Content-Type is not there it would also apply
  256. # [10:43] <annevk> in Gecko
  257. # [10:44] <annevk> we decided not to implement that and just ignore 404 URIs
  258. # [10:44] <annevk> which was the main problem
  259. # [10:52] * Quits: G0k (n=hmason@c-67-164-171-32.hsd1.co.comcast.net)
  260. # [10:55] <MacDome> Hixie: I'm not even sure if you want me filing these... :) but in case you wanted to know: http://bugs.webkit.org/show_bug.cgi?id=16636 http://bugs.webkit.org/show_bug.cgi?id=16637
  261. # [10:59] <annevk> MacDome, IE doesn't do proper DOM exceptions, Firefox does...
  262. # [11:00] <MacDome> annevk: if so, then it seems that that test is in disagreement with the DOM Core 2 spec
  263. # [11:00] <annevk> I think we emulated the e.SYNTAX_ERR stuff as well, but I'm not sure if it's supported by any spec
  264. # [11:02] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  265. # [11:03] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) (Remote closed the connection)
  266. # [11:03] <MacDome> annevk: and since we auto-gen our dom interfaces from the IDLs, we just match the official IDL in this case
  267. # [11:03] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  268. # [11:07] <annevk> I guess DOM Bindings / Web IDL should address this case
  269. # [11:07] <annevk> if it doesn't already
  270. # [11:16] * Joins: hdh (n=hdh@58.187.95.252)
  271. # [11:16] * Parts: hdh (n=hdh@58.187.95.252)
  272. # [11:35] * Joins: jgraham (n=james@cpc1-flee2-0-0-cust327.glfd.cable.ntl.com)
  273. # [11:43] * Quits: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  274. # [11:54] * Joins: maikmerten (n=maikmert@L8f28.l.pppool.de)
  275. # [11:55] * Quits: jgraham (n=james@cpc1-flee2-0-0-cust327.glfd.cable.ntl.com) ("This computer has gone to sleep")
  276. # [12:02] <annevk> grmbl, getComputedStyle and various other CSSOM APIs are really quite crap in terms of documentation, implementation, etc.
  277. # [12:02] <annevk> DOM Level 2 Style is sort of like HTML4
  278. # [12:03] <Hixie> Lachy: in theory acid3 doesn't depend on fonts at all
  279. # [12:08] <Hixie> annevk: i can't find a spec that defines how to handle Content-Type: bogus
  280. # [12:09] <annevk> Hixie, I can't find a spec that defines that when <link rel=stylesheet href=test> returns Content-Type:text/html it can't be parsed as CSS
  281. # [12:10] <annevk> also, I don't think it's acceptable for other browsers to fix that bug in a way that Firefox handles it
  282. # [12:11] <Hixie> HTTP section 7.2.1 paragraph 3 sentence 2 is what i'm basing the current test on
  283. # [12:12] <Hixie> Content-Type: text/html is a given type, so sniffing is not allowed
  284. # [12:12] <Hixie> but I can't see anything telling me whether Content-Type: bogus is a given type or not
  285. # [12:12] <Hixie> so I could argue it both ways
  286. # [12:12] <Hixie> so it can't go in an acid test
  287. # [12:13] <annevk> hmm, given that text Firefox behavior (apart form the quirky parsing) does make some sense, but still...
  288. # [12:13] <annevk> I rather ignore Content-Type algother and just honer 404 and such...
  289. # [12:15] <Hixie> oh i agree
  290. # [12:15] <Hixie> well
  291. # [12:16] <Hixie> i don't think we should ever treat a text/html file as a stylesheet
  292. # [12:16] <Hixie> (except in quirks)
  293. # [12:16] <Hixie> but i agree that bogus should be treated like text/html
  294. # [12:16] <Hixie> i just can't test it in the acid3 test
  295. # [12:17] <annevk> why would we want a quirks there?
  296. # [12:17] <annevk> it's not like we have any trouble doing this for <script> or <img>
  297. # [12:17] <Hixie> there are lots of css files sent as not-text/css last i checked
  298. # [12:18] <Hixie> i have a lot of trouble, i just can't see any way to save it
  299. # [12:18] <Hixie> with those two
  300. # [12:18] <Hixie> the problem with css is that text/html files often end up containing CSS inline, and if you apply that to the other doc, it usually isn't what you meant to do
  301. # [12:18] <annevk> the only cases of that in wild are 404 docs
  302. # [12:19] <annevk> which you'd ignore anyway
  303. # [12:20] <annevk> Content-Type:bogus was actually used a on somewhat important website which is why Opera doesn't adhere to MIME types for CSS files
  304. # [12:20] <Hixie> well, 404 pages aren't always 404 Not Found
  305. # [12:20] <Hixie> witness the webstandards.org site recently
  306. # [12:20] <Hixie> but yeah
  307. # [12:20] <Hixie> i'd love to change the rules here
  308. # [12:21] <Hixie> i just don't see that we can convince the httpwg to do so
  309. # [12:21] <Hixie> and under that regime, the test is correct
  310. # [12:21] <annevk> i believe the HTTP WG doesn't care about "error handling"
  311. # [12:22] <Hixie> that does seem to be the case
  312. # [12:22] <annevk> so if we decide that the case of <link rel=stylesheet> pointing to a non text/css file is non-conforming but nevertheless must be treated as text/css they are probably happy
  313. # [12:25] <Hixie> i doubt it very much
  314. # [12:25] <Hixie> since that's not necessarily an error
  315. # [12:25] <Hixie> xslt, e.g.
  316. # [12:26] <annevk> surely what's conforming for <link rel=stylesheet> is not up to them?
  317. # [12:26] <annevk> (this is probably stretching it)
  318. # [12:27] * Joins: doublec (n=Chris_Do@203-97-173-6.cable.telstraclear.net)
  319. # [12:29] <Hixie> it's not a matter of <link rel>
  320. # [12:29] <Hixie> <link rel> is just one of several ways of including a stylesheet
  321. # [12:29] <Hixie> including @import, Link:, etc
  322. # [12:29] <Hixie> as well as just direct access e.g. by an editor
  323. # [12:34] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  324. # [12:39] * Joins: tndH_ (i=Rob@83.100.183.125)
  325. # [12:39] * tndH_ is now known as tndH
  326. # [12:43] * Joins: jgraham (n=james@cpc1-flee2-0-0-cust327.glfd.cable.ntl.com)
  327. # [12:48] * Quits: MikeSmith (n=MikeSmit@71-218-59-131.hlrn.qwest.net) ("Less talk, more pimp walk.")
  328. # [12:49] * Quits: grimboy (n=grimboy@85-211-255-99.dsl.pipex.com) (Read error: 110 (Connection timed out))
  329. # [13:07] <Hixie> anyone got IE?
  330. # [13:07] <Hixie> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%3A%3Cscript%3Eif%20(true)%20function%20a()%20{%20document.write(%27FAIL%27)%20}%20a()%3B%3C%2Fscript%3E
  331. # [13:07] <Hixie> does it say FAIL?
  332. # [13:09] <annevk> yes
  333. # [13:10] <annevk> well, ":FAIL"
  334. # [13:12] <Lachy> Hixie, the test looks wrong to me. Why shouldn't it print ":FAIL"?
  335. # [13:12] <Hixie> ES3 section 12.4
  336. # [13:12] <Hixie> and 12.5
  337. # [13:12] <annevk> does that say you can't define functions within if() statements or something?
  338. # [13:13] * Quits: doublec (n=Chris_Do@203-97-173-6.cable.telstraclear.net) ("ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  339. # [13:13] <Hixie> somewhat
  340. # [13:13] <Lachy> is it because function a() is out of scope when it's invoked?
  341. # [13:14] <annevk> I don't think if/else blocks create a new scope
  342. # [13:15] <othermaciej> Hixie: I think printing FAIL is correct behavior there
  343. # [13:16] <Hixie> othermaciej: it's not, per spec. i think the spec should change though. (webkit is the only compliant browser at the moment)
  344. # [13:17] <othermaciej> actually maybe not, due to lack of semicolon
  345. # [13:17] <Lachy> WebKit does something weird. It doesn't print "FAIL" for that test, but If you include the braces around the if block, then it does.
  346. # [13:18] <othermaciej> this should certainly print FAIL:
  347. # [13:18] <othermaciej> <!DOCTYPE html>:<script>if (true) { function a() { document.write('FAIL') }}; a();</script>
  348. # [13:18] <othermaciej> function declarations are processed before execution
  349. # [13:18] <Hixie> Lachy: that's correct per spec
  350. # [13:18] <othermaciej> and have either function or global scope
  351. # [13:18] <othermaciej> is the first version a syntax error?
  352. # [13:18] <Hixie> yes, if you add braces it should parse
  353. # [13:18] <Hixie> without braces it's a syntax error per spec
  354. # [13:19] <othermaciej> ah, I see
  355. # [13:19] <webben> because of "an ExpressionStatement cannot start with the function keyword because that might make it ambiguous with a FunctionDeclaration." ?
  356. # [13:19] <othermaciej> an if statement's condition is a statement, not a source element
  357. # [13:19] <othermaciej> a block is a valid statement
  358. # [13:20] <othermaciej> but a function declaration is not
  359. # [13:20] <othermaciej> it's a source element, but not a statement
  360. # [13:20] <Lachy> oh, ok. now I understand
  361. # [13:20] <Lachy> so only webkit passes
  362. # [13:20] <othermaciej> (and it's not an expression statement either, because that is disallowed)
  363. # [13:20] <othermaciej> good night all
  364. # [13:20] * othermaciej is now known as om_sleep
  365. # [13:20] * Quits: om_sleep (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  366. # [13:35] <Dashiva> Hixie: How does adding braces change it? The contents of a BlockStatement are Statements, just like the tail of an if
  367. # [13:37] <Hixie> hm, you are correct
  368. # [13:39] <webben> But without the brackets it's an expressionstatement not a block isn't it?
  369. # [13:39] <Dashiva> No, it's invalid syntax in both cases
  370. # [13:40] <Dashiva> ExpressionStatement can't start with "function", and nothing else matches
  371. # [13:41] <webben> sorry ... yes, I mean with brackets it would be a block.
  372. # [13:41] <Dashiva> yeah
  373. # [13:42] <webben> and http://bclary.com/2004/11/07/#a-12.1 doesn't say blocks can't start with function declarations
  374. # [13:42] <Dashiva> It says a Block contains Statement, and that's the same place we were in with the if
  375. # [13:42] <Dashiva> (well, StatementList)
  376. # [13:43] <webben> hmm
  377. # [13:44] <Dashiva> It's not attractive code, though. As macie mentioned, function declarations are processed first, so it's either a) always add the function, regardless of if test failing or b) break with es3 behavior (this is more like let x = function(){})
  378. # [13:45] <Hixie> yeah what's sad is that the spec doesn't match realitty
  379. # [13:45] <webben> so when http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Statements:function refers to function as a statement, is that a misnomer?
  380. # [13:45] <Hixie> oh well
  381. # [13:45] <Dashiva> webben: Yes and no
  382. # [13:45] <Hixie> if any of you come up with anything for me to test, do let me know
  383. # [13:46] <Hixie> nn
  384. # [13:46] <Dashiva> nn
  385. # [13:46] <Dashiva> webben: In spec terms, it's a SourceElement, which can be either a Statement or a function decl. But outside grammar parsing, calling it a statement makes for better text
  386. # [13:47] <Dashiva> I'm curious what WebKit does, though. If they crash on the function statement, or on the function invocation
  387. # [13:59] <webben> Dashiva: If it /can/ be a Statement, then can't it be the first statement in a block's statement list?
  388. # [14:00] <Dashiva> But it isn't a Statement in the grammar sense of the word
  389. # [14:01] <webben> ah I see
  390. # [14:12] * Quits: maikmerten (n=maikmert@L8f28.l.pppool.de) (Remote closed the connection)
  391. # [14:16] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  392. # [14:23] <othermaciej> Dashiva: if (true) function a() {} is a parse error in webkit, so it fails at the declaration, not the invocation
  393. # [14:25] <othermaciej> webkit accepts SourceElements in many places that technically require a StatementList, probably for compatibility reasons
  394. # [14:27] <annevk> hmm, is that fixed in ECMA4?
  395. # [14:32] <othermaciej> I don't know
  396. # [14:33] <othermaciej> I can't find enough of a spec draft for ES4 to tell
  397. # [14:33] <othermaciej> I guess there is a grammar published so you can check that
  398. # [14:34] <Dashiva> The spec is still fragmented and wiki-dead and all that, I think
  399. # [14:34] <othermaciej> it doesn't really exist in a readable form; makes me wonder how they plan to finalize it next year
  400. # [14:35] <annevk> hmm
  401. # [14:35] <annevk> crap, WebKit implemented getPropertyCSSValue
  402. # [14:35] <annevk> I hope that's an internal API only
  403. # [14:35] <othermaciej> someone sent me a link to an semi-officiall grammar though
  404. # [14:36] <othermaciej> ./css/CSSStyleDeclaration.idl: CSSValue getPropertyCSSValue(in DOMString propertyName);
  405. # [14:36] <othermaciej> nope
  406. # [14:36] <othermaciej> (is getPropertyCSSValue a bad thing?)
  407. # [14:36] <annevk> http://www.w3.org/mid/Pine.LNX.4.05.10310302134070.1173-100000@lanalana.inria.fr
  408. # [14:37] <othermaciej> grammar here: http://www.ecmascript.org/es4/spec/grammar.pdf
  409. # [14:39] <othermaciej> annevk: is WebKit the only engine to implement the old CSSOM?
  410. # [14:39] <othermaciej> (that seems unlikely)
  411. # [14:40] <annevk> maybe Gecko has some bits of it
  412. # [14:40] <othermaciej> Mozilla appears to have getPropertyCSSValue
  413. # [14:40] <othermaciej> and the CSSValue interface
  414. # [14:41] <othermaciej> (well, from searching their source code it seems that way)
  415. # [14:42] <annevk> In Opera the method throws a NOT_IMPLEMENTED_ERR and in Gecko it always returns null
  416. # [14:42] <annevk> it won't be part of the next CSSOM if it's up to me
  417. # [14:43] <othermaciej> div id="foo" style="color: red">x</div>
  418. # [14:43] <othermaciej> <script>
  419. # [14:43] <othermaciej> var foo = document.getElementById("foo");
  420. # [14:43] <othermaciej> alert(document.defaultView.getComputedStyle(foo, "").getPropertyCSSValue("color"));
  421. # [14:43] <othermaciej> </script>
  422. # [14:43] <othermaciej> does what I expect in Firefox 2
  423. # [14:44] <othermaciej> (and Firefox 3 Beta 1)
  424. # [14:45] <othermaciej> it's pretty likely some content depends on it, even more so that some content depends on the CSSValue interface and related interfaces
  425. # [14:46] <othermaciej> (it does return null in Firefox on foo.style though, which is certainly weird)
  426. # [14:47] <annevk> we haven't had a single bug report on not supporting it
  427. # [14:47] <annevk> and IE doesn't support it
  428. # [14:47] <othermaciej> does IE support getComputedStyle()?
  429. # [14:47] <annevk> fair point
  430. # [14:48] <othermaciej> we have had bug reports relating to getComputedStyle before (due to the fact that document.defaultView was originally not the same document as window)
  431. # [14:48] <annevk> oh, yeah, pages rely on getComputedStyle
  432. # [14:49] <annevk> i guess I can file a bug on WebKit and Gecko and see what happens
  433. # [14:49] <othermaciej> to remove getPropertyCSSValue?
  434. # [14:49] <annevk> yeah
  435. # [14:50] <annevk> is CSSStyleDeclaration implemented on various objects btw that behave slightly different?
  436. # [14:50] <othermaciej> what's the reason to remove it?
  437. # [14:50] <annevk> that it has been obsoleted by the CSS WG
  438. # [14:50] <othermaciej> that's not a good reason
  439. # [14:50] <annevk> and that the API is awkward for the Web
  440. # [14:50] <othermaciej> that one, sadly, isn't either
  441. # [14:51] <annevk> if anything we want something like .style.width.px
  442. # [14:51] <othermaciej> neither of those is worth breaking content, even if it's Apple-only content like Dashboard widgets
  443. # [14:51] <annevk> bloat would be another reason
  444. # [14:51] <othermaciej> I'd certainly be open to having a nicer CSS API in addition
  445. # [14:52] <othermaciej> the CSSValue part of the API specifically is not a lot of code
  446. # [14:52] <annevk> i doubt anything relies on it, but you could be right
  447. # [14:52] <othermaciej> getComputedStyle is the hard part, if anything
  448. # [14:52] <othermaciej> (and CSS parsing)
  449. # [14:53] <annevk> CSS parsing is madness
  450. # [14:53] <othermaciej> it's better than HTML parsing :-)
  451. # [14:53] * annevk always thought CSS was a simple language
  452. # [14:53] <othermaciej> or JavaScript parsing
  453. # [14:54] <annevk> b\000061ckground
  454. # [14:54] <annevk> or b\061\063kground
  455. # [14:56] <othermaciej> escape sequences aren't particularly complicated to parse
  456. # [14:56] <othermaciej> (all handled by the lexer)
  457. # [14:57] <annevk> true
  458. # [14:58] <annevk> i probably don't get enough of the CSS grammar yet
  459. # [14:59] <annevk> it's not entirely clear to me what the intersection is of the appendix and the core grammar etc.
  460. # [15:02] <annevk> Mozilla is not working anymore on getPropertyCSSValue per that CSS WG message
  461. # [15:02] <annevk> so that's encouraging
  462. # [15:02] <annevk> (info from bugs in bugzilla)
  463. # [15:03] <othermaciej> it looks like ES4 does allow function definitions in blocks, but not in places that expect a single statement (as far as I can tell from the grammar)
  464. # [15:04] <othermaciej> (side note: we appear to have the UnknownRule interface too, but I dunno if that gets used by anything)
  465. # [15:06] <annevk> UknownRule is incompatible with the CSS parser so that sounds interesting :)
  466. # [15:07] <othermaciej> I think the interface exists but nothing actually ever makes one
  467. # [15:10] <annevk> to get back to my earlier question, to properly define CSSStyleDeclaration would I have to define two separate implementations of it?
  468. # [15:10] <annevk> one that is readonly and one that is read-write
  469. # [15:10] <annevk> and maybe there's also a computed / non-computed distinction?
  470. # [15:10] <othermaciej> probably, yes
  471. # [15:11] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  472. # [15:11] <othermaciej> we internally have CSSSMutableStyleDeclaration and CSSComputedStyleDeclaration classes
  473. # [15:12] <othermaciej> they both implement the CSSStyleDeclaration interface but the Computed version either ignores or throws on all attempts at mutation (can't remember which)
  474. # [15:12] <annevk> Mozilla actually exposes the latter as interface name
  475. # [15:12] <annevk> it throws
  476. # [15:12] * annevk read bits of the source
  477. # [15:13] <annevk> one of the larger problems with CSSValue and any kind of dedicated CSS API is that it's hard to make them scale
  478. # [15:14] <othermaciej> but yeah, it would be nicer if there was a read-write interface inheriting from a read-only interface, not sure what the consequences of changing now would be
  479. # [15:14] <annevk> at some point background-image could have returned CSSUrlValue
  480. # [15:14] <othermaciej> there's probably not much risk of someone depending on existence of a method that always throws
  481. # [15:14] <annevk> now it needs to return a list
  482. # [15:15] <annevk> can I actually do that in IDL?
  483. # [15:15] <annevk> inherit and modify members
  484. # [15:16] <annevk> another option would to have separate interfaces where you simply don't have modifying stuff on one of them...
  485. # [15:16] <othermaciej> you can inherit and add members
  486. # [15:16] <gsnedders> annevk: peh! anyone on the HTTPbis mailing list is a member of the WG! Some people in the WG care about error handling :P
  487. # [15:16] <othermaciej> but I dunno if it's praactically changeable at this point
  488. # [15:17] <othermaciej> probably easier to just spec computed styles as implementing the same interface but throwing on mutation
  489. # [15:18] <gsnedders> annevk: SimplePie (another feed parser) has similar behaviour to UFP for text/xml as of the latest dev copy
  490. # [15:19] <gsnedders> it also uses content-type sniffing based on HTML 5.
  491. # [15:19] <gsnedders> Only real breakage is text/plain feeds
  492. # [15:20] <annevk> othermaciej, yeah ok, it doesn't really matter either way I suppose
  493. # [15:20] <gsnedders> The other breakages have mainly been impl bugs
  494. # [15:22] * gsnedders wonders how you're meant to deal with application/octet-stream
  495. # [15:27] * Quits: webben (n=benh@82.152.123.69) (Read error: 110 (Connection timed out))
  496. # [15:38] <annevk> the other annoying thing is that getComputedStyle does not return the computed style
  497. # [15:38] <annevk> <body style=width:20em> the computed style of 'width' is not 320px afaict
  498. # [15:40] <annevk> or without 'width' it should be auto
  499. # [15:40] <annevk> however, I get back 1452px instead
  500. # [15:41] <annevk> currentStyle in IE is much closer to giving back the computed style it seems
  501. # [17:10] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  502. # [17:29] <annevk> bah, updates to <style>.media.mediaText and presumably similar stuff has no effect
  503. # [17:30] <annevk> (for a normal persistent style sheet)
  504. # [17:31] <annevk> (haven't tested Safari)
  505. # [17:32] <annevk> actually, IE7 does do updates but it does not have MediaList object...
  506. # [17:32] <annevk> in IE7 <style>.sheet.media is a simple string
  507. # [17:33] <annevk> (<style>.media above should've been <style>.sheet.media as well)
  508. # [17:40] * Quits: Hixie (i=ianh@trivini.no) (brown.freenode.net irc.freenode.net)
  509. # [17:40] * Quits: YaaL (i=yaal@hell.pl) (brown.freenode.net irc.freenode.net)
  510. # [17:40] * Quits: hsivonen (n=hsivonen@kekkonen.cs.hut.fi) (brown.freenode.net irc.freenode.net)
  511. # [17:40] * Quits: ianloic (i=yakk@glub.dreamhostps.com) (brown.freenode.net irc.freenode.net)
  512. # [17:40] * Joins: Hixie (i=ianh@trivini.no)
  513. # [17:40] * Joins: YaaL (i=yaal@hell.pl)
  514. # [17:40] * Joins: ianloic (i=yakk@glub.dreamhostps.com)
  515. # [17:40] * Joins: hsivonen (n=hsivonen@kekkonen.cs.hut.fi)
  516. # [17:51] * Joins: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  517. # [17:53] <annevk> actually, Opera seems to do dynamic updates too, but not always
  518. # [17:54] <annevk> and <style>.media is not updated after changes from <style>.sheet.media
  519. # [18:38] * Quits: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  520. # [18:40] * Joins: MacDome (n=eric@c-24-118-60-240.hsd1.mn.comcast.net)
  521. # [18:44] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Remote closed the connection)
  522. # [18:47] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  523. # [18:47] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Remote closed the connection)
  524. # [18:48] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  525. # [18:49] * Joins: gavin_ (n=gavin@people.mozilla.com)
  526. # [19:01] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  527. # [19:02] * Joins: gavin__ (n=gavin@people.mozilla.com)
  528. # [19:02] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  529. # [19:02] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Read error: 104 (Connection reset by peer))
  530. # [19:02] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  531. # [19:07] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  532. # [19:30] * Quits: digx (n=rick@c-76-109-201-140.hsd1.fl.comcast.net) (brown.freenode.net irc.freenode.net)
  533. # [19:32] * Joins: digx (n=rick@c-76-109-201-140.hsd1.fl.comcast.net)
  534. # [19:32] * Parts: digx (n=rick@c-76-109-201-140.hsd1.fl.comcast.net) ("Boing!")
  535. # [19:32] * Joins: digx (n=rick@c-76-109-201-140.hsd1.fl.comcast.net)
  536. # [19:43] * Joins: hober (n=ted@unaffiliated/hober)
  537. # [19:44] * Quits: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 104 (Connection reset by peer))
  538. # [19:45] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  539. # [19:47] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Client Quit)
  540. # [19:48] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  541. # [19:53] * Quits: annevk (n=annevk@5352CE6F.cable.casema.nl) (Read error: 110 (Connection timed out))
  542. # [19:54] * Joins: webben (n=benh@82.152.123.69)
  543. # [20:01] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com) (Read error: 110 (Connection timed out))
  544. # [20:20] * Joins: Lachy_ (n=Lachlan@cm-84.215.54.100.getinternet.no)
  545. # [20:31] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) (Read error: 110 (Connection timed out))
  546. # [20:42] * Joins: jdandrea (n=jdandrea@ool-18e42ae7.dyn.optonline.net)
  547. # [21:54] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  548. # [22:42] * Joins: weinig (n=weinig@17.203.15.140)
  549. # [22:59] * Quits: jdandrea (n=jdandrea@ool-18e42ae7.dyn.optonline.net)
  550. # [23:09] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  551. # [23:18] * Joins: dbaron (n=dbaron@pool-72-94-185-124.phlapa.fios.verizon.net)
  552. # [23:41] * Quits: Thezilch (n=fuz007@ip68-111-154-116.sd.sd.cox.net) (Read error: 104 (Connection reset by peer))
  553. # [23:43] * Quits: psa (n=yomode@71.93.19.66) (Remote closed the connection)
  554. # [23:45] * Quits: weinig (n=weinig@17.203.15.140)
  555. # Session Close: Sat Dec 29 00:00:01 2007

The end :)