/irc-logs / freenode / #whatwg / 2008-03-18 / end

Options:

  1. # Session Start: Tue Mar 18 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:02] * Joins: othermaciej_ (n=mjs@nat/apple/x-2fb07ca726ba2ba6)
  4. # [00:03] * Quits: qwert666_ (n=qwert666@acbg89.neoplus.adsl.tpnet.pl) ("Leaving")
  5. # [00:04] <gsnedders> 'I have a hard time dealing with these "il formed xml" excuses, when regular feed readers
  6. # [00:04] <gsnedders> show these feeds flawlessly...'
  7. # [00:05] * Philip` wonders where that is from
  8. # [00:05] <gsnedders> Philip`: mid:frmsa0+gamt@eGroups.com
  9. # [00:05] * gsnedders looks up archive of it
  10. # [00:06] <gsnedders> http://tech.groups.yahoo.com/group/simplepie-support/message/482
  11. # [00:07] <gsnedders> annevk: you see my email a few weeks ago about XML5?
  12. # [00:07] <annevk> yes
  13. # [00:07] <annevk> i was going to say no to the first
  14. # [00:07] <Philip`> gsnedders: Aha
  15. # [00:07] <annevk> and at some point to the second question
  16. # [00:08] <annevk> but you could assume "yes" for your first question as reparsing doesn't have any side effects if you don't execute scripts
  17. # [00:08] <jwalden> btw, Hixie, did you see my comment here on Saturday or so?
  18. # [00:09] <gsnedders> annevk: why would I be executing scripts as I parse with XML?
  19. # [00:09] <Hixie> jwalden: no idea. i don't always read scrollback, it's far better to e-mail me :-)
  20. # [00:10] <Philip`> "Only "UTF-8" is supported by the router." - alas, Cisco routers are not conforming XML processors :-(
  21. # [00:10] <jwalden> <jwalden> Hixie: I'm not sure that Unicode clearly defines replacement-character behavior for <high-surrogate not-low-surrogate> with UTF-16; arguably, either <U+FFFD> or <U+FFFD not-low-character> are valid interpretations, given the vagueness of the wording in the Unicode spec in 3.2 C10
  22. # [00:10] <Philip`> (unless their documentation wrong, which is not entirely impossible)
  23. # [00:11] <Philip`> s//is /
  24. # [00:11] <jwalden> <jwalden> easy enough to fix, and changing to the latter seems to agree with other browsers, but still, it's not quite clear-cut to me
  25. # [00:11] <Hixie> jwalden: ah, yes, i saw that
  26. # [00:11] <Hixie> jwalden: what about it?
  27. # [00:11] <annevk> Hixie, the XML encoding test in Acid3, nr 70, has the wrong checks for 2/3
  28. # [00:11] <Hixie> annevk: still? i thought i fixed that when you reported it earlier
  29. # [00:11] <annevk> oh ok
  30. # [00:11] * annevk didn't check
  31. # [00:12] <gsnedders> annevk: I don't think you can remain compatible with XML 1.0 docs without saying yes to the first question, actually, though I expect you could do things like placing a specific limit to avoid the billion laughs attack which is different to what, say, libxml2 already uses
  32. # [00:12] <jwalden> Hixie: nothing particular, just that it seems halfway-reasonable to allow the <U+FFFD>-only behavior
  33. # [00:13] * gsnedders waves g'nite
  34. # [00:14] <annevk> gsnedders, if you have <html xmlns="http:...xhtml"><script> alert(1) </script> as document (missing </html>) you don't want the script to execute twice
  35. # [00:14] * Quits: othermaciej (n=mjs@17.203.15.201) (Read error: 110 (Connection timed out))
  36. # [00:18] <Hixie> jwalden: is there anything in the html5 spec that doesn't allow that? i thought i just left it up to the encoding specs to define "sequence of incorrectly encoded bytes" or whatever term it is i use
  37. # [00:22] <gsnedders> annevk: ya, sure. But you don't execute on element add in XHTML, do you?
  38. # [00:24] * Joins: sayrer (n=chatzill@user-1087kf0.cable.mindspring.com)
  39. # [00:28] <Philip`> I don't entirely like it when people use XML Schemas as an alternative to documentation
  40. # [00:29] <Hixie> btw i was speaking to one of our language guys internally here and he introduced me to an interesting concept that would dramatically simplify the way async programming works
  41. # [00:30] <Hixie> instead of doing: asyncFunction(arguments, function (data) { ...callback... });
  42. # [00:30] <Hixie> he suggests: var promise = asyncFunction(arguments); promise.callback(function (data) { ... });
  43. # [00:30] <Philip`> Sounds (so far) quite like Deferred objects in Twisted
  44. # [00:31] <Hixie> where |promise| is an object with one method, which takes a method, and which calls that method as soon as it has a value
  45. # [00:31] <Philip`> (which let you add callback and errback functions, which either get called synchronously (if the result is available) or at some point in the future)
  46. # [00:31] <Hixie> in the simple case it becomes asyncFunction(arguments).callback(function (data) { ... });
  47. # [00:31] <Hixie> yeah
  48. # [00:32] <Hixie> (though i'd always do it async, to avoid subtle timing bugs)
  49. # [00:32] <sayrer> MochiKit does this with partial functions
  50. # [00:32] <sayrer> it's not bad
  51. # [00:32] <sayrer> http://mochikit.com/doc/html/MochiKit/Async.html#fn-deferred
  52. # [00:32] <Hixie> probably too late for the database API, but it would be an interesting pattern for the messages/workers stuff
  53. # [00:45] <dglazkov> this sounds pretty interesting
  54. # [00:45] <dglazkov> but now there needs to be polling on the other thread, looking for that method.
  55. # [00:46] <dglazkov> doesn't need to be on other thread, but still need to poll
  56. # [00:46] <Hixie> why polling?
  57. # [00:47] <dglazkov> ah, store results, and only invoke callback when assigned, sorry, didn't read properly
  58. # [00:48] <dglazkov> invocation of callback checks the results and invokes the callback, if op completed
  59. # [00:48] <Hixie> right
  60. # [00:48] <dglazkov> otherwise, we wait for completion and then invoke callback
  61. # [00:48] <dglazkov> neat!
  62. # [00:48] <dglazkov> let's change the db spec!
  63. # [00:49] <Hixie> heh
  64. # [00:49] <Hixie> probably too late for the db spec at this point, unless you can get everyone on board
  65. # [00:49] <vlad_> er, I hope you don't really mean "wait for completion" in there
  66. # [00:49] <vlad_> like, token.callback() shouldn't block, right?
  67. # [00:50] <Hixie> right
  68. # [00:50] <dglazkov> right
  69. # [00:50] <vlad_> (though token should have a method that -will- make it block)
  70. # [00:50] <vlad_> because then you can choose whether to do something async or sync
  71. # [00:50] <Philip`> It's perhaps bad in the non-callback case like void(asyncFunction(args)), because it has to keep the results around in case somebody sets .callback() in the future, until the GC realises the return value from asyncFunction was lost
  72. # [00:51] <dglazkov> just keep it until token is alive
  73. # [00:51] <dglazkov> don't think it's that big of a deal
  74. # [00:52] * dglazkov imagines a Gb of results sitting on the token
  75. # [00:54] <Philip`> (Twisted allows reasonably nice things like callback chaining, so you can say db.fetch("select * from wherever").addCallback(remote.twiddle).addCallback(print_results) where db.fetch returns a Deferred object, and remote.twiddle receives results from the previous stage and returns a new Deferred object)
  76. # [00:55] <Philip`> (instead of db.fetch(...).addCallback(lambda r: remote.twiddle(r).addCallback(print_results)))
  77. # [00:55] <Philip`> (but Python's lambda support is rubbish, so it's more painful than it should be)
  78. # [00:58] * Joins: MikeSmith (n=MikeSmit@eM60-254-245-134.pool.emnet.ne.jp)
  79. # [01:02] * Parts: franksalim (n=franksal@cpe-72-130-134-143.san.res.rr.com)
  80. # [01:02] * Joins: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca)
  81. # [01:19] * Quits: psa (n=yomode@71.93.19.66) (Remote closed the connection)
  82. # [01:21] * Joins: psa (n=yomode@71.93.19.66)
  83. # [01:23] * Quits: tndH (i=Rob@adsl-83-100-138-73.karoo.KCOM.COM) ("ChatZilla 0.9.81-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  84. # [01:27] * Quits: jgraham (n=james@81-86-216-20.dsl.pipex.com) ("I get eaten by the worms")
  85. # [01:28] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  86. # [01:29] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  87. # [01:29] <Hixie> annevk: yt?
  88. # [01:31] * Quits: psa (n=yomode@71.93.19.66) (Remote closed the connection)
  89. # [01:35] * Joins: psa (n=yomode@71.93.19.66)
  90. # [01:45] * Quits: KevinMarks (n=KevinMar@nat/google/x-8715b15365e51ae4) ("The computer fell asleep")
  91. # [01:46] * othermaciej_ is now known as othermaciej
  92. # [01:53] * Quits: eseidel (n=eseidel@nat/google/x-287090dfbe60288d)
  93. # [02:07] * Quits: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca")
  94. # [02:27] * Quits: MikeSmith (n=MikeSmit@eM60-254-245-134.pool.emnet.ne.jp) ("Less talk, more pimp walk")
  95. # [02:36] * Quits: othermaciej (n=mjs@nat/apple/x-2fb07ca726ba2ba6) (Read error: 110 (Connection timed out))
  96. # [02:41] * Joins: othermaciej (n=mjs@17.203.15.201)
  97. # [02:59] <Hixie> huh
  98. # [02:59] <Hixie> there's exactly one IDREFS attribute in HTML4
  99. # [02:59] <Hixie> how annoying
  100. # [03:00] * Quits: jwalden (n=waldo@STRATTON-FOUR-THIRTY-ONE.MIT.EDU) (Remote closed the connection)
  101. # [03:07] <Hixie> http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02996.pdf may be the reason behind microsoft's proposal against XXX
  102. # [03:08] <Hixie> or at least, that mindset
  103. # [03:15] <Philip`> "... CSS (which is essentially an IE-specific feature)" - I'm glad it's no longer 1998 and there's more than one decent browser
  104. # [03:23] * Joins: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca)
  105. # [03:25] <othermaciej> certainly no one would call CSS an IE-specific feature nowadays
  106. # [03:30] * Quits: weinig (n=weinig@17.203.15.180)
  107. # [03:35] * Joins: othermaciej_ (n=mjs@17.203.15.201)
  108. # [03:35] * Quits: othermaciej (n=mjs@17.203.15.201) (Read error: 104 (Connection reset by peer))
  109. # [03:45] * Parts: dveditz (n=dveditz@corp-241.mountainview.mozilla.com)
  110. # [03:46] * Joins: dveditz (n=dveditz@corp-241.mountainview.mozilla.com)
  111. # [03:46] * Parts: dveditz (n=dveditz@corp-241.mountainview.mozilla.com)
  112. # [03:59] * othermaciej_ is now known as othermaciej
  113. # [03:59] * Quits: othermaciej (n=mjs@17.203.15.201)
  114. # [04:00] * Joins: eseidel (n=eseidel@adsl-76-203-74-21.dsl.pltn13.sbcglobal.net)
  115. # [04:01] * Joins: MikeSmith (n=MikeSmit@EM117-55-76-109.pool.emnet.ne.jp)
  116. # [04:05] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  117. # [04:09] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  118. # [04:17] * Joins: eseidel_ (n=eseidel@adsl-76-203-74-21.dsl.pltn13.sbcglobal.net)
  119. # [04:17] * Quits: eseidel (n=eseidel@adsl-76-203-74-21.dsl.pltn13.sbcglobal.net) (Read error: 104 (Connection reset by peer))
  120. # [04:21] * Quits: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  121. # [04:21] * Joins: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  122. # [04:23] * Quits: eseidel_ (n=eseidel@adsl-76-203-74-21.dsl.pltn13.sbcglobal.net) (Read error: 104 (Connection reset by peer))
  123. # [04:23] * Joins: eseidel (n=eseidel@adsl-76-203-74-21.dsl.pltn13.sbcglobal.net)
  124. # [04:39] * Quits: eseidel (n=eseidel@adsl-76-203-74-21.dsl.pltn13.sbcglobal.net) (Read error: 104 (Connection reset by peer))
  125. # [04:40] * Joins: eseidel (n=eseidel@adsl-76-203-74-21.dsl.pltn13.sbcglobal.net)
  126. # [04:48] * Quits: MikeSmith (n=MikeSmit@EM117-55-76-109.pool.emnet.ne.jp) ("Less talk, more pimp walk")
  127. # [04:52] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  128. # [05:05] * Quits: mpt (n=mpt@canonical/launchpad/mpt) (Remote closed the connection)
  129. # [05:15] * Joins: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net)
  130. # [05:27] * Joins: mpt (n=mpt@222-152-139-221.jetstream.xtra.co.nz)
  131. # [05:37] * Quits: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  132. # [05:52] * Quits: roc (n=roc@202.0.36.64)
  133. # [05:57] * Joins: Thezilch (n=fuz007@cpe-76-170-23-107.socal.res.rr.com)
  134. # [05:57] * Joins: dveditz (n=dveditz@dsl-63-249-104-137.cruzio.com)
  135. # [06:01] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  136. # [06:06] * Quits: mpt (n=mpt@222-152-139-221.jetstream.xtra.co.nz) ("Leaving")
  137. # [06:07] * Quits: csarven (n=csarven@modemcable130.251-202-24.mc.videotron.ca) ("http://www.csarven.ca")
  138. # [06:09] * Quits: eseidel (n=eseidel@adsl-76-203-74-21.dsl.pltn13.sbcglobal.net)
  139. # [06:22] * Joins: MikeSmith (n=MikeSmit@dhcp-246-168.mag.keio.ac.jp)
  140. # [06:42] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net) (Remote closed the connection)
  141. # [06:42] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  142. # [07:27] * Joins: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
  143. # [07:38] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  144. # [07:44] <annevk> Hixie, am now
  145. # [07:55] * Joins: jgraham (n=james@81-86-216-20.dsl.pipex.com)
  146. # [07:55] * Quits: virtuelv (n=virtuelv@109.80-202-65.nextgentel.com) ("Ex-Chat")
  147. # [07:56] * Quits: jgraham (n=james@81-86-216-20.dsl.pipex.com) (Client Quit)
  148. # [07:59] <annevk> omg, the Microsoft stream of FUD continues
  149. # [08:00] <annevk> http://lists.w3.org/Archives/Public/public-appformats/2008Mar/0043.html
  150. # [08:07] * Joins: jgraham (n=james@81-86-216-20.dsl.pipex.com)
  151. # [08:09] * Quits: jgraham (n=james@81-86-216-20.dsl.pipex.com) (Client Quit)
  152. # [08:10] * Joins: jgraham (n=james@81-86-216-20.dsl.pipex.com)
  153. # [08:10] * Quits: jgraham (n=james@81-86-216-20.dsl.pipex.com) (Client Quit)
  154. # [08:15] <hsivonen> http://lists.w3.org/Archives/Public/public-xhtml2/2008Mar/0036.html
  155. # [08:17] <webben> wha?
  156. # [08:17] <webben> I wonder if he's only talking about 1.1 revisions
  157. # [08:18] <hsivonen> webben: I pretty sure he is talking more generally
  158. # [08:18] <othermaciej> does Sunava not understand what the word "specific" means?
  159. # [08:19] <othermaciej> annevk: I'm pretty tired of repeatedly asking for a description of a specific vulnerability
  160. # [08:20] <othermaciej> annevk: do you think they really have one?
  161. # [08:20] <webben> can TBL not sort this out one way or the other? ; we can't both have HTML5 defining how to process a the XHTML1 namespace and text/html and XHTML2 using the same namespace (they're still doing that, are they not) and trying to subset text/html.
  162. # [08:21] <annevk> I have the feeling it's a bunch of FUD and Microsoft doesn't try very hard to provide proof to the contrary
  163. # [08:21] <hsivonen> webben: be careful what you ask for when it comes to sending issues to TAG
  164. # [08:21] <othermaciej> it could just be that Sunava is not a very good analyst or communicator
  165. # [08:25] * Joins: roc (n=roc@121-72-182-38.dsl.telstraclear.net)
  166. # [08:27] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  167. # [08:29] <annevk> Yeah, could be. I believe he's a manager and doesn't work on the code himself.
  168. # [08:38] * Quits: dbaron (n=dbaron@c-67-160-251-228.hsd1.ca.comcast.net) ("g'night")
  169. # [09:11] * Quits: MikeSmith (n=MikeSmit@dhcp-246-168.mag.keio.ac.jp) ("Less talk, more pimp walk")
  170. # [09:14] <Hixie> webben: i wouldn't worry about it
  171. # [09:15] <Hixie> webben: if it's impossible to implement both html4/xhtml1 and xhtml2 at the same time (as will be the case if xhtml2 continues along its present vector) then the issue of whether browsers should implement xhtml2 or not will be neatly solved.
  172. # [09:20] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  173. # [09:21] * Joins: virtuelv (n=virtuelv@109.80-202-65.nextgentel.com)
  174. # [09:21] * Quits: Thezilch (n=fuz007@cpe-76-170-23-107.socal.res.rr.com) (Read error: 104 (Connection reset by peer))
  175. # [09:26] <Hixie> hodeehum, the idrefs problem isn't such a big problem after all
  176. # [09:37] <annevk> which idref problem?
  177. # [09:40] * Joins: MikeSmith (n=MikeSmit@dhcp-246-168.mag.keio.ac.jp)
  178. # [09:42] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  179. # [09:50] <hsivonen> http://realtech.burningbird.net/standards/joel-spolsky-crap-is-good/
  180. # [09:56] * annevk looks forward to “Standards are tough! Let’s go shopping!”
  181. # [09:56] <othermaciej> shopping is tough
  182. # [09:57] <hsivonen> indeed. with all the Flash in the way of mobile shopping support use cases
  183. # [09:58] <roc> annevk: http://ejohn.org/blog/getboundingclientrect-is-awesome/
  184. # [09:59] <vlad_> yes, it's very awesome
  185. # [10:01] <hsivonen> I think what Joel is missing is what Dean Edwards points out: today the Web works without IE
  186. # [10:01] <hsivonen> the IE legacy is now hurting IE8--not helping it
  187. # [10:01] * Hixie finds suspicious &-related syntax in office open xml that may in fact be non-xml
  188. # [10:01] * Hixie investigates
  189. # [10:01] * Quits: webben (n=benh@dip5-fw.corp.ukl.yahoo.com)
  190. # [10:02] * hsivonen notes that OOXML can store non-XML Char code points in a really ugly and inefficient way but doesn't explain the semantics of those code points when found in a document
  191. # [10:02] * Joins: ROBOd (n=robod@89.122.216.38)
  192. # [10:04] <roc> because of their "embed the legacy engine" technique, the IE legacy is going to hurt them forever
  193. # [10:06] <hsivonen> given the current Web environment (intranets and CD-ROM are not part of the Web), modeling the way Safari entered the market would seem like smarter move
  194. # [10:08] <hsivonen> is cross-site XHR in Firefox 3 dead for good or is the issue still up in the air?
  195. # [10:09] <Pavlov> pretty dead
  196. # [10:09] <roc> looks pretty dead
  197. # [10:09] <Pavlov> working group took too long ;(
  198. # [10:09] <hsivonen> :-(
  199. # [10:09] <Hixie> actually it is dead because dveditz and a couple of other people were scared to send cookies with the request
  200. # [10:09] <annevk> roc, cool, any updates on ClientRect.width/height? :)
  201. # [10:09] <Hixie> (not because the working group "took too long")
  202. # [10:10] <roc> annevk: not really on my list for 1.9
  203. # [10:10] <annevk> kk
  204. # [10:10] <Pavlov> Hixie: it was getting cut because of the working group taking too long
  205. # [10:10] <roc> which doesn't really matter since IE doesn't have them so authors have to be able to deal with that anyway
  206. # [10:10] <roc> for now
  207. # [10:10] <annevk> Pavlov, no, that was not the primary reason
  208. # [10:10] <Pavlov> um
  209. # [10:10] <Pavlov> i sit next to jonas?
  210. # [10:10] <Pavlov> the nail in the coffin was security
  211. # [10:10] <annevk> Pavlov, also, if the WG took too long that's because Mozilla was asking for changes when we thought we were almost done
  212. # [10:11] <vlad_> er, I thought the issue was the opposite
  213. # [10:11] <vlad_> that we thought that we were done, but that the wg was asking for changes
  214. # [10:11] <hsivonen> hmm. I guess the "Ajax mashup" aspect of Validator.nu is then dead is the XTech timeframe :-(
  215. # [10:11] <vlad_> not being able to come to consensus about the cookie issues was definitely the nail in the coffin, though
  216. # [10:12] <vlad_> (even though I still think that we should just send cookies, because it's not any different than what the web does today for all sorts of stuff)
  217. # [10:12] <othermaciej> I'm surprised cross-site XHR is dropped, but at least there is postMessage for controlled cross-site communication
  218. # [10:12] <othermaciej> which should be available in a cross-browser way soon
  219. # [10:12] <Pavlov> annevk: everyone really wanted it in, which is the only reason it got cut so late
  220. # [10:12] <Pavlov> it should have been cut much earlier
  221. # [10:12] <vlad_> othermaciej: yeah, that was presented as a viable alternative
  222. # [10:12] <annevk> it's still in nightlies afaict
  223. # [10:12] <hsivonen> It sucks that now IE8 can be the first-mover in scripted cross-site requests
  224. # [10:13] <vlad_> hsivonen: well, you can emulate things with postMessage pretty well
  225. # [10:13] <othermaciej> it can't be the first mover in a beta release
  226. # [10:13] <Hixie> yeah, if firefox3 doesn't ship with xhr done right, we may well be presented with the microsoft treadmill in the form of their xdr nonsense
  227. # [10:13] <othermaciej> whether it will be first in a non-beta remains to be seen
  228. # [10:13] <annevk> Pavlov, the WG did make some changes, but every change I've made sure Jonas was ok with it; Jonas himself also requested several simplifications that he had already implemented
  229. # [10:13] <vlad_> Hixie: yeah, at this point fx3 won't =/
  230. # [10:13] <vlad_> whatever's next certainly will, though
  231. # [10:14] <Hixie> vlad_: yeah, it's sad. might be more expensive for mozilla (and the other vendors) on the long run. luckily for me, xhr isn't my problem any more :-)
  232. # [10:14] <hsivonen> vlad_: I had a RESTful Web service API design. It wasn't designed for Firefox. Access-control made it easy for me to CS-XHR-enable it my editing one servlet class
  233. # [10:14] <vlad_> hsivonen: I agree
  234. # [10:14] <vlad_> I quite liked the XD-XHR model
  235. # [10:14] <hsivonen> vlad_: with postMessage, I now would have to serve up an iframeable JS API specifically
  236. # [10:15] <vlad_> right
  237. # [10:15] <vlad_> like I said, the final issue was the cookies problem
  238. # [10:15] <annevk> It's too bad people always refer to it as cross-site XMLHttpRequest while it also enables cross-site XSLT, XBL, <event-source>, etc.
  239. # [10:15] <vlad_> because you're damned if you do and damned if you don't
  240. # [10:15] <Hixie> vlad_: convince dveditz to change his mind :-)
  241. # [10:16] <hsivonen> moreover, for moving a DOM tree across postMessage will suck big time
  242. # [10:16] <vlad_> Hixie: afaik, we did, but it was already too late to change back (again)
  243. # [10:16] <Hixie> i suppose if ff3 ships soon enough, mozilla could switch to a more rapid dev cycle and release ff3.1 before ie8 comes out
  244. # [10:16] <Hixie> (a more rapid dev cycle would solve several problems mozilla is having)
  245. # [10:16] <annevk> you changed his mind and now it's too late? :(
  246. # [10:16] <annevk> man, that's a sad story
  247. # [10:17] <vlad_> annevk: nah, life goes on
  248. # [10:17] <vlad_> it's not the last firefox release :p
  249. # [10:17] <vlad_> I also made an argument that perhaps the spec should handle cookies explicitly
  250. # [10:17] <Hixie> might be the last one this decade though :-P
  251. # [10:17] <vlad_> and require sites to indicate whether they want cookies or not
  252. # [10:17] <annevk> I'm glad I hear all this just before I leave for a long weekend in Spain
  253. # [10:17] <Pavlov> Hixie: very very very doubtful
  254. # [10:18] <hsivonen> I guess I'll send email about the Validator.nu scenario in response to XDR, though
  255. # [10:19] <vlad_> zzz time
  256. # [10:19] <Hixie> Pavlov: i hope you're right
  257. # [10:20] <Hixie> but there's less than 2 years left this decade, and that doesn't leave long for a whole cycle at the current rate
  258. # [10:20] <sayrer> the next one will be faster
  259. # [10:20] <roc> everyone knows that 2010 is part of this decade
  260. # [10:20] <sayrer> in fact, several of the features are already done :)
  261. # [10:21] <Hixie> that's what was said after 1.5 and after 2.0, too :-)
  262. # [10:21] <sayrer> things are different now
  263. # [10:21] <roc> 2.0 WAS a fast cycle
  264. # [10:22] <Hixie> ah, my memory must be failing me. it was so long ago. :-P
  265. # [10:22] <Pavlov> 2-3 wasn't that long of a cycle either, really, except for those of us who were working on it for 1.5 years before everyone else
  266. # [10:22] <Pavlov> :/
  267. # [10:23] <Hixie> (btw https://bugzilla.mozilla.org/show_bug.cgi?id=408098 doesn't at all convey the cutting of xxx as being a done deal, other than in the flags)
  268. # [10:23] <Pavlov> a little long
  269. # [10:23] <sayrer> main problem was the planning process
  270. # [10:23] <Pavlov> Hixie: yeah, we stoppe dtaking -'d things last week
  271. # [10:23] <sayrer> in that we had one
  272. # [10:24] <sayrer> what a waste of time
  273. # [10:24] * Pavlov rolls his eyes at sayrer
  274. # [10:24] * Joins: hallvors (n=hallvord@softbank221089079197.bbtec.net)
  275. # [10:25] * Quits: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no) ("This computer has gone to sleep")
  276. # [10:26] <sayrer> yes, I would like to change my position. Pavlov is right. The Firefox 3 planning process was a great success.
  277. # [10:27] <Pavlov> it turned out pretty well i'd say
  278. # [10:28] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  279. # [10:28] <sayrer> except for all time we wasted on irrelevant shit
  280. # [10:28] <Pavlov> like?
  281. # [10:28] <Pavlov> i'm pretty sure I haven't wasted any time on "irrelevant shit" in the last 3 years
  282. # [10:28] <sayrer> I don't think you did
  283. # [10:29] <Pavlov> and i can say that planning out much of the thigns i did was useful
  284. # [10:29] <sayrer> we also landed like 2 megs of security theater code in NSS
  285. # [10:29] <sayrer> as planned!
  286. # [10:29] <Pavlov> so, if you want to give the UI guys crap go for it
  287. # [10:29] * Parts: annevk (n=annevk@77.163.243.203)
  288. # [10:31] <sayrer> no, it takes a village for something like that
  289. # [10:31] <Pavlov> i don't think so. specifically the platform team took a very different approach to planning than the frontend team did
  290. # [10:32] * Joins: tndH (i=Rob@adsl-83-100-138-73.karoo.KCOM.COM)
  291. # [10:35] <roc> now now
  292. # [10:36] * Joins: Camaban (n=adrianle@81.133.236.188)
  293. # [10:36] * Philip` notices that http://www.joelonsoftware.com/items/2008/03/17.html appears to have quite good <img alt> text
  294. # [10:39] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  295. # [10:42] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) (Client Quit)
  296. # [10:42] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  297. # [10:47] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  298. # [10:47] * Joins: webben (n=benh@nat/yahoo/x-09d55b09b94c74eb)
  299. # [10:56] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  300. # [10:57] <shepazu> Hixie: http://www.viruscomix.com/page433.html
  301. # [11:11] * Joins: bzed_ (n=bzed@devel.recluse.de)
  302. # [11:11] * Quits: bzed (n=bzed@debian/developer/bzed) (Read error: 104 (Connection reset by peer))
  303. # [11:11] * bzed_ is now known as bzed
  304. # [11:19] * Quits: MikeSmith (n=MikeSmit@dhcp-246-168.mag.keio.ac.jp) ("Less talk, more pimp walk")
  305. # [11:19] * Quits: heycam (n=cam@124-168-8-145.dyn.iinet.net.au) ("bye")
  306. # [11:24] * Joins: heycam (n=cam@124-168-8-145.dyn.iinet.net.au)
  307. # [11:27] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  308. # [11:28] * Quits: heycam (n=cam@124-168-8-145.dyn.iinet.net.au) (Remote closed the connection)
  309. # [11:30] * Joins: heycam (n=cam@124-168-8-145.dyn.iinet.net.au)
  310. # [11:31] * Joins: MikeSmith (n=MikeSmit@eM60-254-232-85.pool.emnet.ne.jp)
  311. # [11:41] * Quits: heycam (n=cam@124-168-8-145.dyn.iinet.net.au) ("bye")
  312. # [11:42] * Joins: heycam (n=cam@124-168-8-145.dyn.iinet.net.au)
  313. # [11:45] * Quits: MikeSmith (n=MikeSmit@eM60-254-232-85.pool.emnet.ne.jp) ("Less talk, more pimp walk")
  314. # [11:52] * Joins: qwert666 (n=qwert666@acat96.neoplus.adsl.tpnet.pl)
  315. # [11:56] * Joins: annevk (n=annevk@dynip225st237.kpn-cc.nl)
  316. # [12:00] <hsivonen> shepazu: the science guy looks like Dawkins but who are the other three faces?
  317. # [12:05] <shepazu> hsivonen: I think the last guy may be Hitchens
  318. # [12:07] <hsivonen> shepazu: could be, yeah
  319. # [12:09] <roc> wild guess: Hitchens, Dawkins, Dennett, and Harris
  320. # [12:11] <hsivonen> roc: thanks
  321. # [12:23] * Parts: annevk (n=annevk@dynip225st237.kpn-cc.nl)
  322. # [12:34] * Joins: qwert666_ (n=qwert666@dax146.neoplus.adsl.tpnet.pl)
  323. # [12:35] * Joins: myakura (n=myakura@p1215-ipbf3008marunouchi.tokyo.ocn.ne.jp)
  324. # [12:35] <shepazu> lol... funny that roc would be the one to know it :)
  325. # [12:35] <shepazu> that's irony for you
  326. # [12:40] <roc> of course I'm interested in their activities :-)
  327. # [12:41] * Joins: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  328. # [12:42] * Quits: roc (n=roc@121-72-182-38.dsl.telstraclear.net)
  329. # [12:50] * Quits: qwert666 (n=qwert666@acat96.neoplus.adsl.tpnet.pl) (Read error: 110 (Connection timed out))
  330. # [13:00] * Joins: qwert666__ (n=qwert666@acab51.neoplus.adsl.tpnet.pl)
  331. # [13:07] * Quits: heycam (n=cam@124-168-8-145.dyn.iinet.net.au) ("bye")
  332. # [13:17] * Quits: qwert666_ (n=qwert666@dax146.neoplus.adsl.tpnet.pl) (Connection timed out)
  333. # [13:26] * Quits: webben (n=benh@nat/yahoo/x-09d55b09b94c74eb)
  334. # [13:32] * Joins: qwert666_ (n=qwert666@acdg129.neoplus.adsl.tpnet.pl)
  335. # [13:33] <hsivonen> wow. a Danish bank manages to be even more idiotic about Web banking than American or Korean banks:
  336. # [13:33] <hsivonen> Danske Bank acquired Sampo Pankki
  337. # [13:34] <hsivonen> then proceeded to switch the Web bank UI to require client-side Java
  338. # [13:34] <hsivonen> the result doesn't work for thousands of customers
  339. # [13:34] <hsivonen> do these bank system architects live in 1995 or something?
  340. # [13:34] <zcorpan> lol
  341. # [13:35] <Dashiva> They're used to mainframe systems :)
  342. # [13:35] <Camaban> it *works* for them, thereofre it must work for everyone else ;)
  343. # [13:36] <hsivonen> the other banks operating in Finland have Web banks that work on just about anything from Lynx to random mobile devices
  344. # [13:40] <didymos> hsivonen, oh yeah, but Danske Bank's solution is very secure!
  345. # [13:40] <didymos> sigh
  346. # [13:41] <shepazu> hsivonen: you assume this was an accident
  347. # [13:41] <shepazu> perhaps Denmark is preparing an invasion of Finland?
  348. # [13:42] <didymos> shepazu, we have a plan in the making
  349. # [13:42] <shepazu> I would see the use of Java as a hostile act, certainly
  350. # [13:42] <didymos> shepazu, yeah, maybe someone ought to attack Denmark to free us from Java
  351. # [13:43] <Camaban> not an invasion, a liberation? :)
  352. # [13:43] <shepazu> you could print a cartoon of Mohammed drinking a cup of coffee under a shining Sun, and have the terrorists take care of the problem
  353. # [13:43] <hsivonen> didymos: reportedly, they use an outdated server version...
  354. # [13:44] <shepazu> jihad on Sun Microsystems!!!
  355. # [13:44] <shepazu> or fatwa, maybe
  356. # [13:45] <Camaban> ah, surely using client side java is jsut the pragmatic solution, all this cross browser stuff is too idealistic
  357. # [13:46] <virtuelv> Camaban: yeah, like even sun isn't doing
  358. # [13:46] <virtuelv> the front page of java.com uses Flash, but no Java
  359. # [13:46] <Camaban> heh
  360. # [13:47] <virtuelv> hsivonen: my old bank used to have a Lynx-compatible solution
  361. # [13:47] <virtuelv> these days, I need a stupid java applet to log in
  362. # [13:49] * Quits: qwert666__ (n=qwert666@acab51.neoplus.adsl.tpnet.pl) (Connection timed out)
  363. # [13:51] <hsivonen> virtuelv: that sucks. how can they stay in business with stuff like that?
  364. # [13:51] <hsivonen> surely there are other Norwegian banks with clue?
  365. # [13:52] <virtuelv> hsivonen: I think most of them require Java for the login these days
  366. # [13:52] <Dashiva> Not postbanken!
  367. # [13:52] * Dashiva dances
  368. # [13:52] <virtuelv> Dashiva: are you still using one-time code pads then?
  369. # [13:53] <Dashiva> Yes
  370. # [13:53] <virtuelv> that's what my local bank used to do as well
  371. # [13:53] <hsivonen> hmm. with my bank, the top compat problem is that they are scared of Opera acting as a man-in-the-middle with Mini, so they block Mini even though they otherwise allow browser choice
  372. # [13:53] <virtuelv> now they switched to Bank-ID and that RSA-gadget
  373. # [13:54] <Dashiva> I don't get why they voluntarily reduce security like that
  374. # [13:54] <hsivonen> a one-time pad of pass numbers works great
  375. # [13:54] <hsivonen> no special hardware required
  376. # [13:54] <didymos> Dashiva, because it has fancy acronyms
  377. # [13:54] <hsivonen> works even over a phone interface
  378. # [13:54] <hsivonen> secure
  379. # [13:54] <Dashiva> "Something you have, something you know"
  380. # [13:54] <hsivonen> all these hardware dongles are dumb
  381. # [13:54] * Philip` hasn't encountered any UK banks with anything other than an HTML form asking for password and PIN number (or a random selection of letters/digits from them)
  382. # [13:55] <hsivonen> Philip`: didn't Barclay's just introduce something incredibly stupid?
  383. # [13:55] <hsivonen> hendry has blogged about it
  384. # [13:56] <Camaban> Lloyds ask for a number, a password, and a random selection of characters from a 'memorable word'
  385. # [13:56] <Philip`> hsivonen: I've heard people talking in the past few days about getting card reader devices from various banks, so I guess they're changing now
  386. # [13:57] * jgraham__ has been told that some kind of number-entering keypad device thing is being rolled out
  387. # [13:57] <virtuelv> if my bank switches to hardware I actually have to attach to my computer, I'll switch
  388. # [13:57] <Philip`> http://www.barclays.co.uk/pinsentry/
  389. # [13:57] <Philip`> I've seen someone with a similar thing from Nationwide
  390. # [13:57] <virtuelv> the RSA gadget I have just has a button and displays random digits
  391. # [13:58] <Philip`> Also http://natwest.com/reader
  392. # [13:58] <jgraham__> http://www.nationwide.co.uk/rca/Introduction/why.htm
  393. # [14:00] <Philip`> It seems like quite a coordinated action between all the banks
  394. # [14:00] <Philip`> since I don't think I'd heard of any of this a month ago
  395. # [14:00] * jgraham__ isn't quite sure what type of attack this is designed to mitigate
  396. # [14:01] <hsivonen> it mitigates mobile use of banking when the dongle is too inconvenient to carry
  397. # [14:01] <virtuelv> jgraham__: replay attacks
  398. # [14:01] <Philip`> Sounds like it requires you to physically have the card, rather than merely knowing the password
  399. # [14:01] <virtuelv> it also mitigates the use on infected computers
  400. # [14:02] * hsivonen thought the low-tech one-time pad mitigated replay attacks especially if the pad is needed both for login and trasaction confirmation
  401. # [14:02] <virtuelv> it does
  402. # [14:02] <Philip`> (Also sounds like it's only for certain relatively rare actions, like setting up a new third party payment, and not for normal logging in and checking balances and sending payments and whatever)
  403. # [14:03] <virtuelv> so there is no added benefit over the one-time pad, but these solutions are cheaper
  404. # [14:03] <hsivonen> on a completely different topic: if browsers know about an unregistered charset x-foo, do they always also recognize foo in case it gets registered later?
  405. # [14:03] <svl> We've had similar card-readers for internet banking in the Netherlands for years.
  406. # [14:03] <svl> No passwords at all - just the pin for your debit card to generate a response to the constantly changing challenges.
  407. # [14:03] <hsivonen> virtuelv: how is a hardware dongle cheaper than a piece of paper?
  408. # [14:04] <virtuelv> hsivonen: when I was using the one-time pads, I had to have them shipped about 12 times a year
  409. # [14:04] <svl> Needed for logging in, and making transactions or adding accounts to your address book - and then an additional time if the transaction is higher than x-thousand euro.
  410. # [14:04] <hsivonen> I get a new one about once or twice a year
  411. # [14:05] <hsivonen> I guess I'm not a heavy user of banking
  412. # [14:05] <hsivonen> the bank sends me other paper mail much more often
  413. # [14:09] * jgraham__ wonders if fake card readers that e.g. steal your pin will begin to appear
  414. # [14:09] <Dashiva> I'm still on my first onetime pad
  415. # [14:10] <svl> jgraham__: how would they transmit the pin?
  416. # [14:11] <Philip`> You could just reuse the one-time pad if it runs out too quickly
  417. # [14:12] <jgraham__> svl: I don't know; I'm not really sure what the possibilities are (or the requirements for successful fraud)
  418. # [14:12] * Joins: aroben (n=aroben@unaffiliated/aroben)
  419. # [14:12] <Philip`> http://www.cl.cam.ac.uk/research/security/banking/ped/ made people a bit unhappy about Chip & PIN
  420. # [14:13] * Joins: phsiao (n=shawn@c-71-232-12-131.hsd1.ma.comcast.net)
  421. # [14:14] <Philip`> (Also http://www.cl.cam.ac.uk/research/security/banking/tamper/tetris.jpg playing Tetris on a 'tamper resistant' PIN-entry terminal)
  422. # [14:17] <hsivonen> one-time pads can easily be made to have tamper evidence even if resistence would be hard
  423. # [14:21] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  424. # [14:25] * Joins: webben (n=benh@nat/yahoo/x-6f141f9608076611)
  425. # [14:31] * Quits: dglazkov (n=dglazkov@adsl-074-229-248-021.sip.bhm.bellsouth.net)
  426. # [14:33] <hsivonen> http://mxr.mozilla.org/seamonkey/source/intl/uconv/src/charsetalias.properties is sad reading
  427. # [14:33] <hsivonen> "x-x-big5 is not really a alias for Big5, add it only for MS FrontPage
  428. # [14:33] <hsivonen> "
  429. # [14:41] <hsivonen> is there an MXR kind of thing for WebKit?
  430. # [14:41] * hsivonen finds http://trac.webkit.org/projects/webkit/browser
  431. # [14:45] <hsivonen> does WebKit rely purely on ICU charset alias data? or is there a layer of Web reality craziness somewhere?
  432. # [14:47] * Joins: itpastorn (n=itpastor@ne.keryx.se)
  433. # [14:54] <Philip`> hsivonen: http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/platform/text/TextCodecICU.cpp#L110
  434. # [14:54] <Philip`> plus some other TextCodec* files
  435. # [14:57] * Joins: qwert666__ (n=qwert666@acdi241.neoplus.adsl.tpnet.pl)
  436. # [14:59] * Joins: Lachy (n=Lachlan@cm-84.215.54.100.getinternet.no)
  437. # [15:01] <hsivonen> Philip`: thanks
  438. # [15:02] <hsivonen> "xxbig5" I wonder if WebKit or the pre-ICU lib removed hyphens before doing alias matching
  439. # [15:07] * hsivonen smiles at #include <wtf/unicode/Unicode.h>
  440. # [15:10] * qwert666__ is now known as qwert666
  441. # [15:13] * Joins: qwert666__ (n=qwert666@etr101.neoplus.adsl.tpnet.pl)
  442. # [15:14] * Quits: qwert666_ (n=qwert666@acdg129.neoplus.adsl.tpnet.pl) (Connection timed out)
  443. # [15:15] <hsivonen> who actually uses "x-user-defined"?
  444. # [15:17] <Philip`> http://philip.html5.org/data/charsets.html#charset-x-user-defined
  445. # [15:18] * Joins: MikeSmith (n=MikeSmit@eM60-254-221-81.pool.emnet.ne.jp)
  446. # [15:21] <hsivonen> it seems to me that ICU and IANA are failing if both WebKit and Validator.nu HTML parser end up needing an ICU fooling layer
  447. # [15:22] <Philip`> It's only failing if its goal is to be compatible with broken web content
  448. # [15:30] * Quits: qwert666 (n=qwert666@acdi241.neoplus.adsl.tpnet.pl) (Connection timed out)
  449. # [15:45] * Philip` tries that chardet thing
  450. # [15:50] <Philip`> Uh, it says it's finding a lot of UTF-16, which is odd because there isn't any
  451. # [15:53] <Philip`> It doesn't seem especially reliable at detecting encodings
  452. # [15:54] <hsivonen> Philip`: have you tried the ICU detector? is it any better?
  453. # [15:54] <hsivonen> (not that it matter since Mozilla chardet is the de facto standard that gets ported to Python, Java, etc.)
  454. # [15:54] <Philip`> I'm not sure how to judge betterness
  455. # [15:55] <Philip`> http://philip.html5.org/data/chardet-bytes.svg is how many bytes jchardet takes before making a decision
  456. # [15:56] <Philip`> (In about 85% of cases where it makes a decision, it makes the decision before reaching the end of the document)
  457. # [15:57] <Philip`> (i.e. this isn't just a graph of page length)
  458. # [15:57] <hsivonen> thank you.
  459. # [15:57] <hsivonen> those numbers look rather discouraging
  460. # [15:57] <hsivonen> I was hoping to see almost definite answers after 2 KB or 4 KB
  461. # [15:59] <hsivonen> did you test involve letting chardet decide when it is fully confident or did you measure how much data it needs not to actually change its mind?
  462. # [16:06] <Philip`> I just recorded how many bytes I had to give it until it first made a decision (returned true from DoIt(...))
  463. # [16:07] <Philip`> (passing in a single byte at a time)
  464. # [16:07] <hsivonen> but not fooling the stream ended, I presume?
  465. # [16:08] <Philip`> (since it splits n byte buffers into effectively n 1-byte calls, so it doesn't mind how much you give it at once, unless I'm horribly mistaken)
  466. # [16:08] <Philip`> No
  467. # [16:09] <Philip`> so there would be different results if you gave it 4KB and then called Done()
  468. # [16:10] <Philip`> (I could try it with something like that, but I think only for a small predefined set of buffer sizes)
  469. # [16:10] <hsivonen> perhaps trying with 512 byte increments would make sense
  470. # [16:11] <Philip`> (Also the set should be finite)
  471. # [16:11] <Philip`> 512 byte increments up to 4KB?
  472. # [16:12] <hsivonen> that would be good
  473. # [16:14] <Philip`> Should I record whether it makes any decision at all, or whether it makes the same decision as with the entire buffer?
  474. # [16:14] <hsivonen> whether it makes the same decision as with the entire buffer seems to be the right thing to measure
  475. # [16:15] <Philip`> Including cases where it never makes any decision at all?
  476. # [16:16] <hsivonen> yeah
  477. # [16:17] * qwert666__ is now known as qwert666
  478. # [16:19] * Quits: hallvors (n=hallvord@softbank221089079197.bbtec.net)
  479. # [16:22] <Philip`> It's pretty indecisive on http://www.trivus.com
  480. # [16:22] <Philip`> 512 bytes, 1024, 1536: Big5
  481. # [16:22] <Philip`> 2048: GB18030
  482. # [16:22] <Philip`> 2560: Shift_JIS
  483. # [16:22] <Philip`> 3072: Big5
  484. # [16:22] <Philip`> 3584, ...: GB18030
  485. # [16:22] * Quits: phsiao (n=shawn@c-71-232-12-131.hsd1.ma.comcast.net)
  486. # [16:22] <Philip`> (Correct answer: iso-8859-1)
  487. # [16:26] <hsivonen> ouch
  488. # [16:38] <Philip`> So... For each length 'n', I'm counting the number of pages which, when prefixes of length (n, n+512, n+1024, ...) (actually not really that sequence, but similar) are chardetted, consistently give the same answer (including 'unknown') as when the whole document is chardetted
  489. # [16:39] <Philip`> which gives http://philip.html5.org/data/chardet-lengths.txt
  490. # [16:39] <Philip`> for the first ~40K pages
  491. # [16:39] * Joins: phsiao (n=shawn@nat/ibm/x-b5af8908e9956ab8)
  492. # [16:39] <Philip`> where the first unlabelled row is pages that weren't consistent at 64KB
  493. # [16:40] <Philip`> Oops
  494. # [16:41] <Philip`> Now updated, so it does include those with 'unknown'
  495. # [16:41] <Philip`> (About 80% of pages give 'unknown')
  496. # [16:44] <Philip`> (Gah, my output file is now a hundred megabytes of XML...)
  497. # [16:49] * Quits: myakura (n=myakura@p1215-ipbf3008marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  498. # [16:56] * Philip` updates it again, to have all 130K pages and to maybe make more sense
  499. # [17:01] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) ("The computer fell asleep")
  500. # [17:04] * Joins: jwalden (n=waldo@RANDOM-THREE-O-EIGHT.MIT.EDU)
  501. # [17:05] * Quits: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk) (Read error: 104 (Connection reset by peer))
  502. # [17:32] * Quits: itpastorn (n=itpastor@ne.keryx.se) ("Leaving.")
  503. # [17:32] <Lachy> jgraham__, yt?
  504. # [17:33] <jgraham__> Yeah
  505. # [17:33] <Lachy> there seems to be a bug in html5lib
  506. # [17:33] <Lachy> http://james.html5.org/cgi-bin/parsetree/parsetree.py?source=%3Cdiv%3E%3Ctable%3E%3Ca%3Ethe+following+whitespace+should+be+directly+in+the+div%3C%2Fa%3E+%3Ctbody%3E%3Ctr%3E%3Ctd%3Ebut+what+about+the+following+whitespace%3F%3C%2Ftd%3E+%3C%2Ftable%3E%3C%2Fdiv%3E
  507. # [17:33] <Lachy> according to the spec, the whitespace should not be added as a child of the table
  508. # [17:33] <Lachy> in that case
  509. # [17:34] <jgraham__> Was that one of the recent spec changes?
  510. # [17:34] <Lachy> I'm not sure, it's in this section http://www.whatwg.org/specs/web-apps/current-work/multipage/section-tree-construction.html#parsing-main-intable
  511. # [17:35] <Lachy> since the table is tainted, the whitespace should be processed according to the anything else rules
  512. # [17:35] <jgraham__> Oh, if it involves the tainted stuff than it's a recent change
  513. # [17:35] <Lachy> ah, ok
  514. # [17:36] <jgraham__> Anne did some work on that but I don't know if he covered everything
  515. # [17:39] <jgraham__> Lachy: Of course it could just be that the parse tree viewer isn't up to date; did you check in a standalone copy?
  516. # [17:40] <Philip`> Could the parse tree viewer show which SVN revision it's running?
  517. # [17:40] <Lachy> no
  518. # [17:40] <jgraham__> Philip`: I'm sure it could somehow
  519. # [17:41] <Lachy> jgraham__, couldn't the viewer automatically update itself whenever there's a new version?
  520. # [17:42] * Philip` accidentally commits 'system("rm -rf /");' into the html5lib repository
  521. # [17:42] <jgraham__> I guess I could use cron to try pulling from the source at regular intervals, but as Philip`so nicely points out it might not be a great idea
  522. # [17:43] <jgraham__> Philip`: Did you have a state transition diagram for the treebuilder somewhere?
  523. # [17:43] * jgraham__ was wondering if we could check testcase coverage for all transitions
  524. # [17:43] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  525. # [17:44] <jgraham__> Lachy: I think the behaviour has changed now; I haven't checked if it is right or not yet
  526. # [17:44] <Philip`> jgraham__: http://philip.html5.org/misc/insertion-modes-3.svg
  527. # [17:45] <Philip`> (Also -2.svg and .svg - I can't remember what I changed)
  528. # [17:45] <Philip`> Maybe I can regenerate that for the new spec...
  529. # [17:46] <jgraham__> What do the colours mean?
  530. # [17:46] <Philip`> http://philip.html5.org/misc/insertion-modes-4.svg should match the current spec
  531. # [17:47] <Philip`> except for some quite likely errors
  532. # [17:48] <Lachy> it doesn't appear to be entirely correct, whitespace in within <tr> should be processed according to the rules for the in table mode, which would be the anything else section
  533. # [17:49] <Philip`> jgraham__: If a transition only happens after a parse error, then it's red; otherwise it's blue for reprocess-as-if, and black for set-insertion-mode
  534. # [17:49] <Lachy> it's currently putting it as a child of the tr, but, AIUI, it should be as a child of the div
  535. # [17:49] <Lachy> (in that above demo I linked to)
  536. # [17:49] <jgraham__> Lachy: That's the same conclusion I had reached
  537. # [17:49] <Lachy> ok
  538. # [17:49] <jgraham__> Philip`: Thanks
  539. # [17:49] <Lachy> jgraham__, see the PM i sent you
  540. # [17:50] <jgraham__> Lachy: Dunno if I can reply to PMs on freenode
  541. # [17:50] <Lachy> oh, isn't your nick registered?
  542. # [17:53] <jgraham__> No. I think technically someone else owns it which means I'm being really bad by using it but otoh, no one has ever complained
  543. # [17:54] * Philip` avoids the name reuse problem by appending random significant punctuation
  544. # [17:55] * zcorpan doesn't have that problem :)
  545. # [17:57] * Quits: gsnedders (n=gsnedder@host86-138-199-53.range86-138.btcentralplus.com) ("Partying in teh intarwebs")
  546. # [18:04] * Joins: gsnedders (n=gsnedder@host86-138-199-53.range86-138.btcentralplus.com)
  547. # [18:07] * Joins: annevk (n=annevk@84.77.16.68)
  548. # [18:16] * Quits: sayrer (n=chatzill@user-1087kf0.cable.mindspring.com) (Remote closed the connection)
  549. # [18:48] <jgraham__> Lachy: The whitespace thing should be fixed now
  550. # [18:49] * jgraham__ has discovered a bunch of lxml-related breakage that needs to be fixed
  551. # [18:57] * Joins: sayrer (n=chatzill@user-1087kf0.cable.mindspring.com)
  552. # [19:01] * Quits: webben (n=benh@nat/yahoo/x-6f141f9608076611)
  553. # [19:01] * Joins: dbaron (n=dbaron@guest-228.mountainview.mozilla.com)
  554. # [19:02] * Parts: Camaban (n=adrianle@81.133.236.188)
  555. # [19:02] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  556. # [19:04] * Joins: aguai (n=aguai@host86-141-63-177.range86-141.btcentralplus.com)
  557. # [19:08] * Joins: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  558. # [19:25] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (Read error: 145 (Connection timed out))
  559. # [19:37] * Joins: KevinMarks (n=KevinMar@nat/google/x-f599a3981b27b305)
  560. # [19:44] * Joins: eseidel (n=eseidel@nat/google/x-9b2b35c763dc081b)
  561. # [19:47] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  562. # [19:51] * Quits: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  563. # [19:53] * Joins: a-ja (n=chatzill@adsl-70-237-243-169.dsl.stlsmo.sbcglobal.net)
  564. # [19:56] * eseidel is now known as eseidelAFK
  565. # [19:57] <annevk> whoa, @microsoft.com on @whatwg.org
  566. # [19:57] <annevk> oh wait, that was not a first
  567. # [19:58] <a-ja> anyone been doing any testing with betas regarding how figure/legend (or unknownelement/legend) works?
  568. # [19:59] <annevk> last i heard it didn't work wel
  569. # [19:59] <annevk> l
  570. # [19:59] <a-ja> gecko now is generating a fieldset :(
  571. # [20:01] <a-ja> whole doc after gets included in the fieldset....ouch!
  572. # [20:02] * Joins: jruderman (n=jruderma@guest-228.mountainview.mozilla.com)
  573. # [20:04] <a-ja> should there end up being a legend element in the DOM, or should it just generate a text child of figure? (sounded like the latter last i read the spec closely)
  574. # [20:05] <annevk> the former
  575. # [20:06] <a-ja> that makes more sense to me
  576. # [20:07] <a-ja> opera seems to do the latter?
  577. # [20:08] <a-ja> looked that way anyway....though i couldn't get the dev toolbar working for some reason...to view the dom
  578. # [20:08] <annevk> could be, we're not doing what HTML5 wants at this point
  579. # [20:09] <annevk> anyway, got to go
  580. # [20:09] <a-ja> take care
  581. # [20:09] * Parts: annevk (n=annevk@84.77.16.68)
  582. # [20:29] * Joins: deltab (n=deltab@82-36-30-34.cable.ubr02.smal.blueyonder.co.uk)
  583. # [20:38] * Joins: weinig (n=weinig@17.203.15.180)
  584. # [20:44] * Quits: dbaron (n=dbaron@guest-228.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  585. # [20:44] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  586. # [20:47] <Hixie> there is some irony to the way that microsoft suggests xxx has a security problem when in fact xdr is the one increasing the attack surface
  587. # [20:54] <Hixie> Philip`: there's a line missing from InFrameset to AfterFrameset
  588. # [20:54] <Hixie> unless the spec itself is wrong somehow
  589. # [20:54] <Hixie> let me know if i'm being inconsistent or something
  590. # [20:55] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  591. # [20:55] * zcorpan_ notes that #writing is not in sync with #parsing
  592. # [20:55] <Philip`> Hixie: Oops, that's because my spec-to-code regexp thing is incomplete and fails to understand that bit of text
  593. # [20:56] <Philip`> It's missing after-after-(body|frameset) -> in-\1 for the same reason
  594. # [20:56] * jwalden is sad that <http://my.opera.com/desktopteam/blog/2008/03/18/happy-easter> kinda-sorta-half-updated postMessage
  595. # [20:56] <Hixie> ah
  596. # [20:56] <jwalden> it's on window
  597. # [20:56] <Hixie> zcorpan_: oh?
  598. # [20:57] <jwalden> but it uses uri/domain
  599. # [20:57] <Philip`> Hixie: It would be much easier for me if you wrote the spec in OCaml instead of English
  600. # [20:57] <jwalden> Philip`: that's your objective opinion?
  601. # [20:57] <jwalden> ba-dum-ch
  602. # [20:58] <Hixie> Philip`: i believe you
  603. # [20:58] <zcorpan_> namely entities in escaping text spans (in rcdata)
  604. # [20:59] <Hixie> Philip`: i'm happy to make my text more self-consistent (i did a lot of changes to that effect recently so you should be able to simplify your regexps) but it's staying in english :-)
  605. # [21:01] <zcorpan_> i also found that #writing didn't say anything about the LF and <listing>, but then i remembered that <listing> is not valid in the first place :)
  606. # [21:02] <zcorpan_> but #serialising should talk about that
  607. # [21:04] <zcorpan_> speaking of serializing, i think the algorithm should change for (r)cdata elements to only emit the children text and cdata nodes
  608. # [21:04] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  609. # [21:04] <zcorpan_> s/ren//
  610. # [21:05] <zcorpan_> (including plaintext)
  611. # [21:06] <zcorpan_> less checking (hence better perf) and better roundtripping (comments are not turned into text but are instead just dropped)
  612. # [21:06] <zcorpan_> and it's what firefox does, i think
  613. # [21:08] <Hixie> zcorpan_: please send e-mail, i'm working on tables at the moment
  614. # [21:14] * Joins: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net)
  615. # [21:27] <Hixie> (othermaciej: is the windows safari 3.1 still labelled a beta?)
  616. # [21:27] <othermaciej> Hixie: no
  617. # [21:32] <Hixie> cool
  618. # [21:33] <Hixie> zcorpan_: the perf aspect is purely an implementation detail
  619. # [21:34] <Hixie> zcorpan_: how should the XML "<textarea><div> text</div></textarea>" be serialised by this algorithm?
  620. # [21:38] * eseidelAFK is now known as eseidel
  621. # [21:39] * Quits: MikeSmith (n=MikeSmit@eM60-254-221-81.pool.emnet.ne.jp) (Read error: 110 (Connection timed out))
  622. # [21:43] <zcorpan_> <textarea></textarea>
  623. # [21:45] <a-ja> for anyone interested in tracking: gecko figure/legend bug is 423721
  624. # [21:46] <zcorpan_> (assming the elements are in the HTML namespace :) )
  625. # [21:48] <zcorpan_> a-ja: doesn't <legend> only imply fieldset if it's foudn directly in body?
  626. # [21:49] <zcorpan_> a-ja: and is otherwise just dropped?
  627. # [21:49] * jwalden wants <myth>
  628. # [21:51] <a-ja> zcorpan: well....i think it used to be that way....in body or unknown element...but since the post-b4 parser update to allow unknown (e.g. html5) elements to contains blocks, this has cropped up
  629. # [21:52] <zcorpan_> ah. haven't tested a build with the other fix in
  630. # [21:52] <a-ja> grab latest nitely if you wanna test....there was a related checkin yesterday
  631. # [21:53] <Philip`> Maybe someone should run the HTML5 parser tests in Firefox to try to find unintended consequences of that patch
  632. # [21:54] <a-ja> little late in beta cycle to replace ff's html parser with html5lib, i'd think :)
  633. # [21:55] <a-ja> sounds like a good idea though...since it hasn't made it to a beta release yet. though code freeze for "last" beta is tonite
  634. # [21:56] <Philip`> I'm not suggesting trying to make FF pass the tests - they're just a useful source of occasionally obscure HTML code that could be compared before/after the patch
  635. # [21:58] * Joins: andersca (n=andersca@nat/apple/x-80b43940912f18c3)
  636. # [21:59] <andersca> Hixie: ping
  637. # [21:59] <Hixie> yo
  638. # [21:59] <andersca> hey
  639. # [21:59] <a-ja> pretty much, unknown elements can now have block children....instead of having to wrap them in an inline (e.g. span) to get em in DOM
  640. # [21:59] <andersca> Hixie: so I'm looking at the application cache spec
  641. # [22:01] <Hixie> i'm assuming you have a question related to this section? :-)
  642. # [22:02] <andersca> Hixie: actually, I have two! :)
  643. # [22:02] <andersca> Hixie: first, I didn't see an applicationCache property on the window interface
  644. # [22:02] <Hixie> yeah, known bug
  645. # [22:02] <andersca> OK
  646. # [22:03] <andersca> Hixie: and a small nit in 4.6.4, could p3 and p4 switch places?
  647. # [22:03] * Quits: eseidel (n=eseidel@nat/google/x-9b2b35c763dc081b)
  648. # [22:04] <Hixie> p3 and p4?
  649. # [22:04] * Quits: itpastorn (n=itpastor@139.57.227.87.static.th.siw.siwnet.net) (Read error: 110 (Connection timed out))
  650. # [22:04] <andersca> Hixie: step 3 and step 4
  651. # [22:05] <Hixie> what difference does it make?
  652. # [22:05] * Joins: eseidel (n=eseidel@nat/google/x-522726917100f7f2)
  653. # [22:06] <Hixie> step 3 doesn't have any visible side-effects
  654. # [22:06] <andersca> Hixie: none really, it's just that you don't need to define what the cache is until after step 4
  655. # [22:06] <andersca> right
  656. # [22:06] <Hixie> i prefer to have all the definitions together
  657. # [22:06] <Hixie> makes it easier to find them
  658. # [22:06] <Hixie> blame my pascal upbringing :-)
  659. # [22:07] <andersca> OK, told you it was a small nit :)
  660. # [22:07] <Hixie> :-)
  661. # [22:09] <Philip`> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Ca%20href%3Da%3Eaa%3Cmarquee%3Eaa%3Ca%20href%3Db%3Ebb%3C%2Fmarquee%3Eaa is different in FF3 vs FF2
  662. # [22:13] * Quits: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  663. # [22:13] * Joins: zcorpan_ (n=zcorpan@c-cb21e353.1451-1-64736c12.cust.bredbandsbolaget.se)
  664. # [22:16] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  665. # [22:20] * Quits: KevinMarks (n=KevinMar@nat/google/x-f599a3981b27b305)
  666. # [22:25] <othermaciej> looks like every single news article about Safari 3.1 mentions HTML 5
  667. # [22:26] <jruderman> what HTML 5 features does 3.1 have (over 3.0)?
  668. # [22:26] <othermaciej> the biggest are the video and audio elements and (nearly all of) their APIs
  669. # [22:27] <othermaciej> (also some smaller things like getElementsByClassName)
  670. # [22:29] <othermaciej> (of course, getElementsByClassName will probably get a lot more use in the near term)
  671. # [22:30] * Joins: mpt (n=mpt@canonical/launchpad/mpt)
  672. # [22:37] <zcorpan_> hmm... SSML?
  673. # [22:37] <othermaciej> what's SSML?
  674. # [22:38] <zcorpan_> http://www.w3.org/TR/speech-synthesis/
  675. # [22:38] * Joins: KevinMarks (n=KevinMar@nat/google/x-eb21c0231dbd20b6)
  676. # [22:38] <zcorpan_> looks like a weird version of HTML to me
  677. # [22:38] * Quits: eseidel (n=eseidel@nat/google/x-522726917100f7f2)
  678. # [22:40] * Joins: eseidel (n=eseidel@nat/google/x-fdf1431ed730ee4d)
  679. # [22:41] <andersca> 3.1 also implements the Database spec
  680. # [22:48] <othermaciej> oh yeah
  681. # [22:52] <virtuelv> hehe, http://diveintomark.org/archives/2008/03/18/translation-from-ms-speak-to-english-of-selected-portions-of-joel-spolskys-martin-headsets
  682. # [22:55] * Philip` wonders if he's intentionally misinterpreting "nobody has a way to test against the standard" as meaning testing browsers against standards, rather than testing web pages against standards
  683. # [22:58] <zcorpan_> hsivonen: when validating xhtml with resolving external entities, v.nu complains about shape attributes on <a>, even though the markup didn't have shape=''. i understand that the dtd resolves them, but it's probably confusing and unhelpful for authors...
  684. # [23:04] <andersca> Hixie: what happens if I setAttribute('manifest', ...) on the HTML element?
  685. # [23:04] <Hixie> nothing
  686. # [23:04] <Hixie> (as per the spec)
  687. # [23:04] <Hixie> the manifest attribute is only handled during parse time
  688. # [23:07] <andersca> great
  689. # [23:07] <andersca> :)
  690. # [23:07] <andersca> Hixie: oh, you are right - now why didn't I notice that
  691. # [23:08] <Hixie> search for "run the application cache selection algorithm"
  692. # [23:08] <Hixie> those are the only times that the attribute has any effect
  693. # [23:08] <Hixie> the spec defines the handling for XML files, text/plain files, and HTML files (in the HTML parser)
  694. # [23:09] <Hixie> oh and for images and plugins
  695. # [23:09] <Hixie> and error pages
  696. # [23:09] <Hixie> man, i was thorough
  697. # [23:10] <andersca> :)
  698. # [23:10] <andersca> that's good
  699. # [23:11] <jgraham__> Philip`: I'm not quite clear that Joel does mean "test web pages against standards", but he seems somewhat incoherent on that point
  700. # [23:12] * Joins: hallvors (n=hallvord@softbank221089079197.bbtec.net)
  701. # [23:12] <Hixie> i think joel doesn't understand that you can have pragmatic standards
  702. # [23:13] <Hixie> his argument seemed predicted on the concept of specs either being idealistic and unimplementable, draconian and unsuitable, or overly vague.
  703. # [23:13] <Hixie> he missed the "realistic and detailed" option
  704. # [23:13] <othermaciej> I'm not sure what his point was in his big rant
  705. # [23:13] <othermaciej> but I admit I didn't read the whole thing
  706. # [23:13] <Hixie> yeah me either
  707. # [23:13] <Pavlov> i started to read it but realized it kept going
  708. # [23:13] <Hixie> to not understanding the point
  709. # [23:13] <Hixie> (i did read it)
  710. # [23:14] <jgraham__> I think the point might have been to say he predicted in 2004 that Vista would suck
  711. # [23:15] <Hixie> his reasoning for why vista hasn't been the success that XP was seems somewhat flawed, imho
  712. # [23:18] <Hixie> jgraham__: do you have any discussion of the cell association algorithm anywhere? i'm curious to know which cases you were trying to solve
  713. # [23:18] <Pavlov> vista is in many ways nicer than XP
  714. # [23:18] <Pavlov> it just has some hickups
  715. # [23:18] <jgraham__> Hixie: I don't know if we have anything written down that's not in email
  716. # [23:19] <Hixie> i didn't see much discussion in the e-mails, mostly just algorithms :-)
  717. # [23:20] <jgraham__> Basically it's optimized for tables like http://annevankesteren.nl/2007/09/tmb-overview and http://sitesurgeon.co.uk/tables/tides/minimal.html
  718. # [23:22] <jgraham__> (which seems to be a fairly common general pattern)
  719. # [23:24] <Hixie> so a column (row) header's scope stops when it hits another header with the same width (height) and starting x (y) position?
  720. # [23:24] * Quits: phsiao (n=shawn@nat/ibm/x-b5af8908e9956ab8)
  721. # [23:25] * Quits: qwert666 (n=qwert666@etr101.neoplus.adsl.tpnet.pl) ("Leaving")
  722. # [23:25] <jgraham__> Just the same with/height iirc although I guess maybe it should also consider the starting position
  723. # [23:26] <Hixie> i guess i'm going to have to just look at a lot of tables and determine the best algorithm that covers those tables
  724. # [23:26] <Hixie> yay for ben's work looking at tables
  725. # [23:27] <Hixie> k. bbiab.
  726. # [23:27] <hallvors> On Joel's article: http://my.opera.com/hallvors/blog/show.dml/1818385
  727. # [23:27] <jgraham__> Hixie: Yeah.
  728. # [23:29] * jgraham__ feels sorry for Hixie having to wade through all the crap in the table-related discussion
  729. # [23:55] * Quits: eseidel (n=eseidel@nat/google/x-fdf1431ed730ee4d)
  730. # [23:55] * Quits: hallvors (n=hallvord@softbank221089079197.bbtec.net)
  731. # [23:56] * Quits: gsnedders (n=gsnedder@host86-138-199-53.range86-138.btcentralplus.com) ("Partying in teh intarwebs")
  732. # Session Close: Wed Mar 19 00:00:00 2008

The end :)