/irc-logs / freenode / #whatwg / 2007-09-29 / end

Options:

  1. # Session Start: Sat Sep 29 00:00:00 2007
  2. # Session Ident: #whatwg
  3. # [00:05] * Quits: Steve_f (n=chatzill@82-44-69-8.cable.ubr02.nmal.blueyonder.co.uk) (Read error: 110 (Connection timed out))
  4. # [00:08] * Quits: weinig_ (n=weinig@17.255.107.57)
  5. # [00:10] * Joins: weinig (n=weinig@17.203.15.140)
  6. # [00:15] <Hixie> crap, someone tried to ask for status on the naming debate
  7. # [00:16] <Hixie> some people need to learn to let sleeping dogs lie
  8. # [00:16] <Hixie> if they sleep for long enough, they die.
  9. # [00:16] <Hixie> <-- cat person
  10. # [00:19] * Joins: tndH (i=Rob@83.100.253.210)
  11. # [00:29] * gsnedders stares at Hixie blankly
  12. # [00:30] <gsnedders> Hixie: I guess the cat reference was a (bad) joke?
  13. # [00:30] <Dashiva> I once caught a cat the size of a semi-trailer
  14. # [00:35] * Quits: kingryan (n=kingryan@corp.technorati.com)
  15. # [00:40] * Joins: aroben (i=aroben@unaffiliated/aroben)
  16. # [00:47] <Hixie> gsnedders: yes :-P
  17. # [00:59] <Hixie> so nobody had any opinions on the manifest format huh
  18. # [01:04] <aa> I hate one-off formats, they always seem so cute at first, then you have to extend them and it becomes a mess
  19. # [01:04] <aa> See also: chrome.manifest in firefox
  20. # [01:04] <aa> JSON doesn't have any comment facilities
  21. # [01:04] <aa> so make it xml and be done with it
  22. # [01:05] <aa> (you asked)
  23. # [01:05] <Dashiva> Well, that's certainly an opinion :)
  24. # [01:05] <Hixie> aa: yeah, i don't like making my own format either
  25. # [01:05] * othermaciej__ is now known as othermaciej
  26. # [01:05] <Hixie> aa: but xml and json both don't define error recovery
  27. # [01:06] <aa> why do you have to recover?
  28. # [01:06] <aa> sorry, I've not been paying attention last few days
  29. # [01:06] <Hixie> well, if it doesn't the debugging is gonna be a pain, since there's nowhere to report the errors
  30. # [01:06] <Dashiva> Can't the browser dump the error to console?
  31. # [01:06] <othermaciej> Hixie: most browsers have an error console
  32. # [01:06] <aa> that's what I was going to say
  33. # [01:06] <Hixie> it could
  34. # [01:07] <aa> also if there is UI for updating, it could go there
  35. # [01:07] <Hixie> sigh... using xml or json is gonna make it so much harder to test for interop... but ok...
  36. # [01:07] * Quits: dev0_ (i=Tobias@unaffiliated/icefox0) ("dev0_ has no reason")
  37. # [01:07] <aa> I vote for json then
  38. # [01:07] <aa> for obvious reasons
  39. # [01:08] <Hixie> what reasons?
  40. # [01:08] <Dashiva> Well, with non-xml you have to test for interop on the format parser itself as well, don't you?
  41. # [01:08] <aa> Gears already has a JSON format
  42. # [01:08] <aa> and we don't really want to include an xml parser
  43. # [01:08] <othermaciej> if json doesn't have a way to add comments I think that's a big problem
  44. # [01:08] <aa> true, it is lame
  45. # [01:08] <Hixie> Dashiva: yeah but that becomes much easier, you don't have to test at the level of things like "what happens when you have a dictionary and are expecting a string" or "what happens when you have an element in the wrong namespace"
  46. # [01:09] <aa> othermaciej: that 'true' went to you
  47. # [01:09] <othermaciej> aa: roger that
  48. # [01:09] <Dashiva> JSON is just a format, we could define a comment property
  49. # [01:09] <aa> Dashiva: Not as convenient as being able to put it anywhere
  50. # [01:10] <aa> like above an individual array entry or something
  51. # [01:10] <othermaciej> does JSON not allow /* ... */ comments?
  52. # [01:10] <aa> I think json should just allow js comments, but I don't think it currently does, technically
  53. # [01:10] * Dashiva wonders how long until someone suggests JSON5
  54. # [01:12] <aa> othermaciej: json.org doesn't define any comment grammar at all
  55. # [01:12] <aa> obviously we could just spec it in :)
  56. # [01:12] <aa> by we, I mean hixie
  57. # [01:13] <Hixie> oh yeah that'll go down REAL well
  58. # [01:13] <othermaciej> I think changing the basic JSON serialization should be avoided
  59. # [01:13] <othermaciej> I don't think JSON is really that much better than XML
  60. # [01:13] <Hixie> not for this, no
  61. # [01:14] <Hixie> it has all the same problems of needing all kinds of edge case definitions
  62. # [01:17] <Dashiva> What about SML?
  63. # [01:17] <Hixie> uri?
  64. # [01:18] <Dashiva> Wait, sdf
  65. # [01:19] <Dashiva> The one zcorpan was working on, http://simon.html5.org/specs/sdf
  66. # [01:19] <Hixie> same problem as xml and json
  67. # [01:19] <Hixie> the whole point is that we _don't_ want a syntax with arbitrary structure
  68. # [01:19] * Quits: tantek (n=tantek@h460dacb0.area2.spcsdns.net)
  69. # [01:19] <Hixie> since then you have to define and implement and test how to handle every single possible unexpected structure
  70. # [01:21] * Quits: billmason (n=billmaso@ip156.unival.com) (".")
  71. # [01:21] <Dashiva> That kinda limits the options quite a bit
  72. # [01:22] * Joins: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
  73. # [01:23] <Hixie> bbiab, mtg
  74. # [01:45] * Joins: Steve_f_ (n=chatzill@82-44-69-8.cable.ubr02.nmal.blueyonder.co.uk)
  75. # [01:45] * Steve_f_ is now known as Steve_f
  76. # [01:53] * Quits: weinig (n=weinig@17.203.15.140) (Read error: 110 (Connection timed out))
  77. # [02:07] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  78. # [02:08] * Joins: weinig (n=weinig@c-67-169-182-231.hsd1.ca.comcast.net)
  79. # [02:12] * Quits: Lachy__ (n=Lachy@124-171-38-55.dyn.iinet.net.au) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072518]")
  80. # [02:12] * Joins: Lachy (n=Lachy@124-171-38-55.dyn.iinet.net.au)
  81. # [02:14] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  82. # [02:34] * Quits: tndH (i=Rob@83.100.253.210) ("ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  83. # [02:50] * Quits: MikeSmith (n=MikeSmit@131.107.204.126) ("Less talk, more pimp walk.")
  84. # [03:06] * Quits: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
  85. # [03:11] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  86. # [03:17] * Quits: KevinMarks (i=KevinMar@nat/google/x-52b7e7428ed4fa16) ("The computer fell asleep")
  87. # [03:17] * Quits: h3h (n=w3rd@66-162-32-234.static.twtelecom.net) ("|")
  88. # [04:35] * Joins: aroben_ (i=aroben@unaffiliated/aroben)
  89. # [04:37] * Quits: aroben_ (i=aroben@unaffiliated/aroben) (Client Quit)
  90. # [04:37] * Joins: aroben_ (i=aroben@unaffiliated/aroben)
  91. # [04:38] * Quits: aroben (i=aroben@unaffiliated/aroben) (" HydraIRC -> http://www.hydrairc.com <- Wibbly Wobbly IRC")
  92. # [04:38] * Quits: aroben_ (i=aroben@unaffiliated/aroben) (Client Quit)
  93. # [04:40] * Joins: aroben (i=aroben@unaffiliated/aroben)
  94. # [04:53] * Joins: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com)
  95. # [04:58] * Quits: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]")
  96. # [05:07] * Quits: weinig (n=weinig@c-67-169-182-231.hsd1.ca.comcast.net) (Remote closed the connection)
  97. # [05:07] * Joins: weinig (n=weinig@c-67-169-182-231.hsd1.ca.comcast.net)
  98. # [05:43] * Quits: othermaciej (n=mjs@17.203.15.168) (Read error: 110 (Connection timed out))
  99. # [06:05] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http:/www.csarven.ca")
  100. # [06:08] * Quits: aroben (i=aroben@unaffiliated/aroben) ("Leaving")
  101. # [06:40] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  102. # [07:20] * Quits: gsnedders (n=gsnedder@host86-137-237-196.range86-137.btcentralplus.com)
  103. # [07:23] * Joins: gsnedders (n=gsnedder@host86-137-237-196.range86-137.btcentralplus.com)
  104. # [07:26] * Quits: gsnedders (n=gsnedder@host86-137-237-196.range86-137.btcentralplus.com) (Client Quit)
  105. # [07:27] * Joins: gsnedders (n=gsnedder@host86-137-237-196.range86-137.btcentralplus.com)
  106. # [08:01] * Quits: heycam (n=cam@203-214-33-166.dyn.iinet.net.au) (Read error: 110 (Connection timed out))
  107. # [08:04] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  108. # [08:23] * Quits: gsnedders (n=gsnedder@host86-137-237-196.range86-137.btcentralplus.com)
  109. # [08:26] * Joins: gsnedders (n=gsnedder@host86-137-237-196.range86-137.btcentralplus.com)
  110. # [08:59] * Joins: KevinMarks (n=KevinMar@c-76-102-254-252.hsd1.ca.comcast.net)
  111. # [10:15] * Joins: peepo (n=Jay@host86-153-137-94.range86-153.btcentralplus.com)
  112. # [10:26] * Joins: ROBOd (n=robod@89.122.216.38)
  113. # [10:33] * Joins: Lachy_ (n=Lachy@124-171-38-55.dyn.iinet.net.au)
  114. # [10:49] * Quits: Lachy (n=Lachy@124-171-38-55.dyn.iinet.net.au) (Read error: 110 (Connection timed out))
  115. # [10:55] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  116. # [11:17] * Joins: heycam (n=cam@203-214-33-166.dyn.iinet.net.au)
  117. # [11:51] * Joins: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
  118. # [11:59] * Joins: grimeboy (n=grimboy@85-211-247-155.dsl.pipex.com)
  119. # [12:14] * Quits: grimboy (n=grimboy@85-211-255-37.dsl.pipex.com) (Read error: 110 (Connection timed out))
  120. # [12:22] * Quits: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
  121. # [12:22] * Joins: Ducki (n=Ducki@nrdh-d9b980d7.pool.mediaWays.net)
  122. # [12:32] * Joins: Lachy__ (n=Lachy@124-170-128-10.dyn.iinet.net.au)
  123. # [12:32] * Lachy__ is now known as Lachy
  124. # [12:35] * Joins: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  125. # [12:49] <hsivonen> is there any way to inform HTTP clients that the server accepts *inbound* gzip-compressed POST data?
  126. # [12:50] <hsivonen> will clients go crazy if I use Accept-Encoding as a *response* header and write support for Content-Encoding as a *request* header?
  127. # [12:52] * Quits: Lachy_ (n=Lachy@124-171-38-55.dyn.iinet.net.au) (Read error: 110 (Connection timed out))
  128. # [12:54] <gsnedders> hsivonen: clients will ignore the accept-encoding header
  129. # [12:54] <Dashiva> The form element has various attributes, but I'm not sure if any of them are able to do on-the-fly gzip
  130. # [12:55] <hsivonen> Dashiva: I'm mainly considering restful Web service clients
  131. # [12:56] <hsivonen> it appears that RFC 2616 allows Content-Encoding on Entities
  132. # [12:56] <hsivonen> i.e. both on response and request entities
  133. # [12:57] * hsivonen goes implement incoming gzip
  134. # [12:57] * Dashiva wonders why people make html versions of rfcs without hyperlinks
  135. # [13:00] <Dashiva> "If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type)."
  136. # [13:00] <Dashiva> Seems like you're expected to just try gzip and retry without if it fails on 415
  137. # [13:01] <hsivonen> I want to get compression right in both directions before I start advertising the Web service facet of validator.nu
  138. # [13:01] <hsivonen> so I can tell people from get-go that they can (should?) compress incoming stuff
  139. # [13:01] <hsivonen> incoming from my POV
  140. # [13:02] <Dashiva> Do you want to disallow identity entirely?
  141. # [13:02] <hsivonen> that would be extreme
  142. # [13:03] <hsivonen> I think I'll cross the bridge of banning uncompressed stuff if the bandwidth bill actually grows to be unmanageable
  143. # [13:04] <hsivonen> of course, the joke will be on me if the service ends up being CPU-bound instead of bandwidth/IO-bound
  144. # [13:04] <Dashiva> Because if identity is allowed, and you mention gzip is encouraged in the docs, shouldn't that be enough to get people who are willing to do gzip to do it?
  145. # [13:04] <hsivonen> Dashiva: hopefully
  146. # [13:05] <Dashiva> Can't really imagine a http client which supports automatic switching to gzip based on a non-documented header :)
  147. # [13:05] <hsivonen> I need to post some sample code, too
  148. # [13:05] * Quits: peepo (n=Jay@host86-153-137-94.range86-153.btcentralplus.com) ("later")
  149. # [13:09] * gsnedders has Xbox 360 fail
  150. # [13:09] * gsnedders watches his productivity rise massively
  151. # [13:26] * Quits: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  152. # [13:29] <hsivonen> hmm. hmm. the RFC is not too clear about the relationship of content-length and content-encoding
  153. # [13:35] <Philip`> Does inbound compression make DOS attacks easier? Someone could send a low-bandwidth compressed stream that expands into a huger amount of data on the server and uses up lots of CPU time
  154. # [13:36] <hsivonen> Philip`: do you mean a specially-crafted Gzip-stream designed to just expand?
  155. # [13:36] <hsivonen> Philip`: it seems to me the same risk exists with compressed streams read using GET
  156. # [13:37] <hsivonen> how do browsers cope with that case?
  157. # [13:37] <Philip`> Not necessarily specially-crafted - someone could just compress a gigabyte of space characters, transmit that (which is cheap for them), and your server would decompress and process it all (which is expensive for you)
  158. # [13:38] <Philip`> Browsers have observant users and a 'stop' button, whereas servers tend to blindly process whatever you send them
  159. # [13:39] <hsivonen> hmm. can a single read() from a GzipInputStream be worse that decompressing 32 KB of data?
  160. # [13:40] <hsivonen> that is, if I put a watchdog stream wrapper between the decompression and the parser, am I safe?
  161. # [13:41] <hsivonen> 32 KB is the default gzip window, isn't it?
  162. # [13:42] <hsivonen> am I right that Content-Length is the length of the compressed stream--not the length of the decompressed stream?
  163. # [13:42] * Philip` is unsure of how it works
  164. # [13:44] * gsnedders has reverse-engineered that yet
  165. # [13:44] <gsnedders> I can say it is not what is defined in RFC2616, though
  166. # [13:44] <Dashiva> It says "transfer-length", seems clear to me
  167. # [13:45] <gsnedders> But there again, a lot of RFC2616 isn't actually what things are done
  168. # [13:47] <Dashiva> hmm, no... tricky stuff this
  169. # [13:52] <Dashiva> content-length is the entity-length if there is no transfer-encoding. The entity-length is the length of the entity-body. The entity-body includes content-encoding.
  170. # [13:53] <hsivonen> moreover, transfer-encoding and content-encoding are different beast with potentially same values
  171. # [13:54] <hsivonen> I think I sort of grok content-encoding where there are no byte ranges involved
  172. # [13:54] <Dashiva> Well, if you use transfer-encoding it says to not use content-length at all. Not sure if that's how it works in practice, but still
  173. # [13:54] <gsnedders> is Opera the only browser to not download <img style="display:none" src="test.gif">?
  174. # [13:55] <krijnh> No
  175. # [13:55] <Dashiva> Let's find out
  176. # [13:56] <hsivonen> is non-chunked transfer-encoding used in the real world?
  177. # [14:00] * Joins: peepo (n=Jay@host86-153-137-94.range86-153.btcentralplus.com)
  178. # [14:01] <Dashiva> Both FF2 and IE7 downloaded the image
  179. # [14:01] * Joins: Ducki_ (n=Ducki@nrdh-d9b9804f.pool.mediaWays.net)
  180. # [14:02] * Quits: Ducki (n=Ducki@nrdh-d9b980d7.pool.mediaWays.net) (Read error: 113 (No route to host))
  181. # [14:04] <Philip`> If you do <object data="test.svg"><img src="test.png"></object> then FF2 downloads both files and Opera only downloads the .svg, if I remember correctly
  182. # [14:06] <hsivonen> http://www.aerasec.de/security/advisories/decompression-bomb-vulnerability.html
  183. # [14:06] <krijnh> Dashiva: you sure?
  184. # [14:07] <Dashiva> Apache logs do not lie (I hope)
  185. # [14:07] <krijnh> They do! :)
  186. # [14:07] <krijnh> Hmm
  187. # [14:07] <krijnh> I tested it with background images
  188. # [14:07] <krijnh> Those aren't downloaded for elements with display: none
  189. # [14:07] <krijnh> Or for :hover states
  190. # [14:08] <Dashiva> I could venture a guess, the img tag is recognized and starts downloading before the inline style is applied
  191. # [14:08] <Dashiva> Background image is not recognized as such until styling is applied
  192. # [14:08] <krijnh> That's probably it
  193. # [14:08] <krijnh> Background images with visibility: hidden are downloaded though
  194. # [14:11] * Joins: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  195. # [14:12] <zcorpan> hsivonen: http://simon.html5.org/temp/validator.nu/Validator.nu.htm
  196. # [14:12] * Joins: dev0 (i=Tobias@unaffiliated/icefox0)
  197. # [14:13] * Joins: tndH (i=Rob@83.100.253.210)
  198. # [14:15] <krijnh> hsivonen: why am I getting an IO Error: Circular redirect to ..
  199. # [14:16] <krijnh> For a page that can be viewed in a browser
  200. # [14:16] <zcorpan> hsivonen: although the file upload label doesn't seem to focus the "file" field in firefox :|
  201. # [14:20] <hsivonen> zcorpan: thank you
  202. # [14:20] <hsivonen> krijnh: URL?
  203. # [14:20] <krijnh> http://www.toernooi.nl/sport/teammatches.aspx?id=17064&tid=191
  204. # [14:20] * Quits: jgraham (n=jgraham@81-86-212-61.dsl.pipex.com) ("Ex-Chat")
  205. # [14:20] <krijnh> It's a weird site
  206. # [14:22] <hsivonen> krijnh: might have something to do with their cookie behavior
  207. # [14:24] <krijnh> If you disable cookies, you get back a really weird URL
  208. # [14:25] <hsivonen> yes, but still not circular
  209. # [14:25] <hsivonen> I wonder if Commons HttpClient is so aggressive with circularity that it ignores the query string
  210. # [14:26] <krijnh> Damnit, we really want to parse this site :)
  211. # [14:28] <zcorpan> hmm, doesn't tabindex on <label> work in ie/firefox?
  212. # [14:29] <hsivonen> I'm experiencing the jar version of dll hell when trying to debug :-(
  213. # [14:30] * Joins: virtuelv (n=virtuelv@51.80-203-76.nextgentel.com)
  214. # [14:31] <zcorpan> i can't get keyboard nav work in ie or firefox
  215. # [14:31] <zcorpan> s/work/to work/
  216. # [14:32] <zcorpan> perhaps it's better to add radio buttons after all
  217. # [14:47] <zcorpan> hsivonen: there, that works better, although it doesn't boot correctly in ie for some reason
  218. # [14:50] * Joins: jgraham (n=jgraham@81-86-214-191.dsl.pipex.com)
  219. # [14:55] <zcorpan> hsivonen: ie barks at "n.disabled = false" in toggleParsers()
  220. # [15:01] <hsivonen> krijnh: I suspect this is the problem: http://jakarta.apache.org/httpcomponents/httpclient-3.x//xref/org/apache/commons/httpclient/HttpMethodDirector.html#630
  221. # [15:03] <zcorpan> hsivonen: also, ie doesn't seem to uncheck the other radio buttons for some reason
  222. # [15:03] <krijnh> hsivonen: is that a bug?
  223. # [15:03] * Quits: peepo (n=Jay@host86-153-137-94.range86-153.btcentralplus.com)
  224. # [15:04] <krijnh> Or just bad behavior of that site?
  225. # [15:05] <hsivonen> krijnh: bad behavior of site coupled with over-eager counter-measures
  226. # [15:07] <krijnh> Bah
  227. # [15:07] * hsivonen tries to loosen the counter-measures
  228. # [15:07] <krijnh> Too bad that's the only site where results are posted :/
  229. # [15:15] * Quits: virtuelv (n=virtuelv@51.80-203-76.nextgentel.com) ("Leaving")
  230. # [15:21] <hsivonen> krijnh: fixed
  231. # [15:22] <krijnh> hsivonen: Cool, thanks :)
  232. # [15:23] <hsivonen> it took me like 3 tries to stick the params in the right place. Commons HttpClient has a zilloin places you can stick params into
  233. # [15:27] * Quits: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  234. # [15:29] <krijnh> hsivonen: What's a good entry point if you're not into HTML5, but you just want to use your parser in a Java project?
  235. # [15:34] <krijnh> http://about.validator.nu/htmlparser/ I guess :)
  236. # [15:36] <Philip`> With that parser, I found it pretty straightforward to set up the libraries and get it to parse a document into a DOM, so it seems to work fine :-)
  237. # [15:39] <hsivonen> krijnh: I suggest you check out how I instantiate the parser in XSLT4HTML5 (bundled sample)
  238. # [15:39] <krijnh> I'm not into Java
  239. # [15:39] <krijnh> Somebody else is going to try it out
  240. # [15:40] <krijnh> I hope :)
  241. # [15:40] <hsivonen> krijnh: do you want DOM, XOM or SAX?
  242. # [15:40] <krijnh> I really have no idea
  243. # [15:40] <hsivonen> krijnh: streaming or tree?
  244. # [15:40] <krijnh> We were talking about fetching results from a website, and now I'm pointing him to your library
  245. # [15:41] <hsivonen> krijnh: well, if the wants DOM, he should do new HtmlDocumentBuilder(XmlViolationPolicy.ALTER_INFOSET);
  246. # [15:41] <hsivonen> and then proceed the same way as with an XML DocumentBuilder instance
  247. # [15:42] <hsivonen> if he wants SAX, he should do new HtmlParser(XmlViolationPolicy.ALTER_INFOSET); and proceed as with a usual XMLReader instance
  248. # [15:43] <hsivonen> if he wants XOM, he should do new HtmlBuilder(XmlViolationPolicy.ALTER_INFOSET); and proceed as with a usual XOM Builder instance
  249. # [15:43] <hsivonen> familiarity with one of DOM, XOM or SAX in a prerequisite
  250. # [15:44] * Philip` was unfamiliar with all of those but just made it up as he went along and it kind of worked
  251. # [15:46] <Philip`> (Well, I suppose I had some familiarity with the JS DOM, and the Java version is basically the same except it takes four method calls to set an attribute (as far as I can see))
  252. # [15:47] <hsivonen> Philip`: elem.setAttribute("foo", "bar");
  253. # [15:49] <Philip`> hsivonen: Hmm
  254. # [15:49] <Philip`> Oh, it's because I was using Node instead of Element, and Node doesn't have setAttribute
  255. # [15:50] <Philip`> ... and I was using Node because stuff like getElementsByTagName returns a NodeList
  256. # [15:51] <Dashiva> Yeah, that one's a bit silly, there is no ElementList
  257. # [15:51] <hsivonen> Philip`: the interface hierarchy of DOM sucks big time with strongly-typed languages
  258. # [15:51] <Philip`> I guess I can cast things to Element, but casting always feels a little dirty and unsafe
  259. # [15:51] <Dashiva> Just check nodeType (or instanceof) and you're safe enough
  260. # [15:53] <Philip`> Sounds reasonable
  261. # [15:54] <Philip`> Too lazy to fix my code now, though :-p
  262. # [15:54] <hsivonen> it would be interesting to know if which one is faster: instanceof followed by cast or nodeType followed by cast
  263. # [15:55] <hsivonen> I'd expect instanceof to be slower than nodeType, but then I'd expect HotSpot to perform less expensive cast operations if it can prove that instanceof was just tested
  264. # [15:56] * Quits: jgraham (n=jgraham@81-86-214-191.dsl.pipex.com) (Read error: 110 (Connection timed out))
  265. # [16:00] <hsivonen> when I wrote my own XML tree API, I hoisted all methods to the top of the hierarchy to avoid casts when traversing
  266. # [16:17] * Joins: Ducki__ (n=Ducki@nrdh-d9b980ce.pool.mediaWays.net)
  267. # [16:20] * Joins: jgraham (n=jgraham@81-86-215-149.dsl.pipex.com)
  268. # [16:27] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  269. # [16:37] * Quits: Ducki_ (n=Ducki@nrdh-d9b9804f.pool.mediaWays.net) (Read error: 113 (No route to host))
  270. # [16:50] * Joins: virtuelv (n=virtuelv@51.80-203-76.nextgentel.com)
  271. # [17:22] * Quits: Steve_f (n=chatzill@82-44-69-8.cable.ubr02.nmal.blueyonder.co.uk) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]")
  272. # [17:50] * Quits: virtuelv (n=virtuelv@51.80-203-76.nextgentel.com) ("Leaving")
  273. # [18:07] * Quits: Lachy (n=Lachy@124-170-128-10.dyn.iinet.net.au) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072518]")
  274. # [18:07] * Joins: Lachy (n=Lachy@124-170-128-10.dyn.iinet.net.au)
  275. # [18:13] * Quits: Lachy (n=Lachy@124-170-128-10.dyn.iinet.net.au) ("ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072518]")
  276. # [18:14] * Joins: Lachy (n=Lachy@124-171-26-6.dyn.iinet.net.au)
  277. # [18:20] * Joins: Ducki_ (n=Ducki@nrdh-d9b98055.pool.mediaWays.net)
  278. # [18:25] <hsivonen> does IE parse and apply the contents of <style> elements inserted to the DOM via script after onload has long since been fired?
  279. # [18:27] <hsivonen> more to the point: what's the best practice for introducing and later removing a class selector-based style rule?
  280. # [18:27] <hsivonen> or changing the class selector on a single rule_
  281. # [18:27] <hsivonen> ?
  282. # [18:36] * Quits: Kuruma (n=Kuruman@h123-176-107-050.catv01.catv-yokohama.ne.jp) (Read error: 110 (Connection timed out))
  283. # [18:38] * Quits: Ducki__ (n=Ducki@nrdh-d9b980ce.pool.mediaWays.net) (Read error: 113 (No route to host))
  284. # [18:42] <hsivonen> http://developer.mozilla.org/en/docs/DOM:style Do Opera and WebKit support that stuff?
  285. # [18:46] <hsivonen> is there some perf badness if I modify the first rule? should I make sure to modify the last rule to avoid recascade?
  286. # [18:47] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  287. # [18:53] * Joins: virtuelv (n=virtuelv@51.80-203-76.nextgentel.com)
  288. # [19:04] <hsivonen> zcorpan: whole-line messages now highlight the associated line as a whole
  289. # [19:20] * Joins: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  290. # [19:25] <zcorpan> hsivonen: cool
  291. # [19:25] <zcorpan> hsivonen: in the case of direct input, i guess you could default to using the html parser if the user didn't choose
  292. # [19:26] <hsivonen> zcorpan: ok
  293. # [19:27] <zcorpan> hsivonen: is the whole-line highlighting deployed? i don't see it
  294. # [19:28] <hsivonen> zcorpan: http://validator.nu/?doc=http%3A%2F%2Fwww.accessifyforum.com%2F&showsource=yes#l151
  295. # [19:28] <hsivonen> zcorpan: please reload css
  296. # [19:28] <zcorpan> hsivonen: ah
  297. # [19:28] <zcorpan> sorry :)
  298. # [19:30] * Joins: billmason (n=billmaso@ip156.unival.com)
  299. # [19:31] * Quits: gavin (n=gavin@firefox/developer/gavin) (Read error: 104 (Connection reset by peer))
  300. # [19:31] * Parts: billmason (n=billmaso@ip156.unival.com)
  301. # [19:32] * Joins: gavins (n=gavin@firefox/developer/gavin)
  302. # [19:32] * jgraham grumbles that different people are on #what-wg and #html-wg
  303. # [19:32] <jgraham> Does anyone have a good use case for tables with no headers?
  304. # [19:35] <hsivonen> jgraham: sidebars
  305. # [19:35] * hsivonen hides
  306. # [19:36] <hsivonen> jgraham: form grid layout
  307. # [19:36] <zcorpan> jgraham: genealogical table
  308. # [19:38] * Parts: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  309. # [19:39] * Joins: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  310. # [19:44] <zcorpan> hsivonen: http://www.quirksmode.org/dom/changess.html
  311. # [19:50] <zcorpan> hsivonen: an idea: have the error message as title="" in the show source. would that be possible?
  312. # [19:51] <hsivonen> zcorpan: thanks
  313. # [19:51] <hsivonen> zcorpan: possible but hard
  314. # [19:52] <hsivonen> zcorpan: there can be more than one message per position.
  315. # [19:53] <zcorpan> hsivonen: true
  316. # [19:53] <hsivonen> zcorpan: I wonder if doing some fancy JS backlinking would be smarter than putting a lot of content in attributes
  317. # [19:53] <zcorpan> perhaps
  318. # [19:54] <Dashiva> Make an error attribute as a comma-separated list of errors, and put all the errors in an array somewhere. Use JS to build tooltips or whatnot from it.
  319. # [19:54] <Dashiva> ^ Something like that?
  320. # [19:55] <hsivonen> Dashiva: I was thinking of augmenting the highlight element DOM nodes with an array or references to the list item DOM nodes in the message list and doing fake tooltips as divs
  321. # [19:59] * Quits: grimeboy (n=grimboy@85-211-247-155.dsl.pipex.com) (Read error: 110 (Connection timed out))
  322. # [20:00] * Joins: grimeboy (n=grimboy@85.211.239.146)
  323. # [20:02] * Joins: Ducki__ (n=Ducki@nrdh-d9b980cf.pool.mediaWays.net)
  324. # [20:11] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http:/www.csarven.ca")
  325. # [20:11] <jgraham> hsivonen: Ignoring the tables for layout cases (which we'll temporarily pretend are obviously bad) what does a genealogical table look like?
  326. # [20:13] <jgraham> ah, sorry, that was zcorpan
  327. # [20:17] <hsivonen> jgraham: http://www.pointerklubben.se/stamtavla.asp?Id=S35236/97
  328. # [20:19] <jgraham> hmm. I think that's not really a table but I'm not sure how one could do better
  329. # [20:24] * Quits: Ducki_ (n=Ducki@nrdh-d9b98055.pool.mediaWays.net) (Read error: 113 (No route to host))
  330. # [20:27] * Quits: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  331. # [20:27] * Quits: weinig (n=weinig@c-67-169-182-231.hsd1.ca.comcast.net)
  332. # [20:41] * Joins: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
  333. # [20:49] * Quits: Ducki__ (n=Ducki@nrdh-d9b980cf.pool.mediaWays.net) (Read error: 104 (Connection reset by peer))
  334. # [20:53] * Quits: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
  335. # [20:54] * Joins: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com)
  336. # [20:54] * Quits: h3h (n=w3rd@cpe-76-88-44-219.san.res.rr.com) (Client Quit)
  337. # [20:55] * Joins: weinig (n=weinig@17.203.15.140)
  338. # [21:16] * weinig is now known as weinig_food
  339. # [21:22] * Joins: dbaron (n=dbaron@c-71-204-145-103.hsd1.ca.comcast.net)
  340. # [21:25] * weinig_food is now known as weinig
  341. # [21:31] * Joins: grimboy_uk (n=grimboy@85.211.237.147)
  342. # [21:47] * Quits: grimeboy (n=grimboy@85.211.239.146) (Read error: 110 (Connection timed out))
  343. # [22:07] * Quits: virtuelv (n=virtuelv@51.80-203-76.nextgentel.com) ("Leaving")
  344. # [22:38] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  345. # [23:01] * Joins: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  346. # [23:26] * Quits: zcorpan (n=zcorpan@c-0922e353.1451-1-64736c12.cust.bredbandsbolaget.se) (Read error: 110 (Connection timed out))
  347. # [23:30] * Quits: aa (i=aa@nat/google/x-a07d158df2be9d04) (Read error: 110 (Connection timed out))
  348. # [23:34] * Quits: dbaron (n=dbaron@c-71-204-145-103.hsd1.ca.comcast.net) ("8403864 bytes have been tenured, next gc will be global.")
  349. # Session Close: Sun Sep 30 00:00:00 2007

The end :)