/irc-logs / freenode / #whatwg / 2007-11-14 / end

Options:

  1. # Session Start: Wed Nov 14 00:00:01 2007
  2. # Session Ident: #whatwg
  3. # [00:09] * Quits: mpt__ (n=mpt@222-152-133-36.jetstream.xtra.co.nz) ("This computer has gone to sleep")
  4. # [00:10] * Joins: jgraham (n=james@81-86-216-175.dsl.pipex.com)
  5. # [00:11] <jgraham> mitsuhiko: it turns out that there's an issue with the patch to make html5lib work with lxml trunk so it's not sutiable for checkin yet. I'll try and make some time to work on it in the next few days
  6. # [00:12] <jgraham> in the meantime, I believe we work with lxml 1.3.6, if that has the features you need
  7. # [00:30] * Quits: jgraham (n=james@81-86-216-175.dsl.pipex.com) ("This computer has gone to sleep")
  8. # [00:39] * Joins: mpt__ (n=mpt@222-152-133-36.jetstream.xtra.co.nz)
  9. # [00:59] * Quits: othermaciej (n=mjs@17.255.101.77)
  10. # [00:59] * Joins: csarven- (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  11. # [01:00] * Joins: othermaciej (n=mjs@17.255.101.77)
  12. # [01:04] * Joins: othermaciej_ (n=mjs@17.255.101.77)
  13. # [01:05] * Quits: othermaciej (n=mjs@17.255.101.77) (Connection reset by peer)
  14. # [01:16] * Quits: tndH_ (i=Rob@adsl-87-102-42-252.karoo.KCOM.COM) ("ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  15. # [01:23] * Quits: csarven- (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http:/www.csarven.ca")
  16. # [01:33] * Quits: grimboy_uk (n=grimboy@85.211.236.85) (Connection timed out)
  17. # [01:37] * Quits: othermaciej_ (n=mjs@17.255.101.77)
  18. # [01:44] * Joins: othermaciej (n=mjs@17.255.101.77)
  19. # [01:52] * Quits: kingryan (n=kingryan@corp.technorati.com)
  20. # [02:07] * Joins: yod (n=ot@dhcp-247-106.mag.keio.ac.jp)
  21. # [02:53] * Quits: yod (n=ot@dhcp-247-106.mag.keio.ac.jp) ("This computer has gone to sleep")
  22. # [02:54] * Joins: yod (n=ot@dhcp-247-106.mag.keio.ac.jp)
  23. # [03:06] * Quits: aroben (i=aroben@unaffiliated/aroben) ("Leaving")
  24. # [03:32] * Quits: weinig (n=weinig@17.203.15.140)
  25. # [03:32] * Quits: wakaba (n=w@79.163.210.220.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  26. # [03:33] * Joins: wakaba (n=w@79.163.210.220.dy.bbexcite.jp)
  27. # [03:34] * Quits: othermaciej (n=mjs@17.255.101.77)
  28. # [03:41] * Joins: jwalden (n=waldo@RANDOM-THREE-FORTY-ONE.MIT.EDU)
  29. # [03:41] * Quits: wakaba (n=w@79.163.210.220.dy.bbexcite.jp) (Read error: 104 (Connection reset by peer))
  30. # [03:42] * Joins: wakaba (n=w@79.163.210.220.dy.bbexcite.jp)
  31. # [04:14] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  32. # [04:29] * Joins: weinig (n=weinig@c-71-198-185-169.hsd1.ca.comcast.net)
  33. # [04:29] * Quits: weinig (n=weinig@c-71-198-185-169.hsd1.ca.comcast.net) (Remote closed the connection)
  34. # [04:30] * Joins: weinig (n=weinig@c-71-198-185-169.hsd1.ca.comcast.net)
  35. # [04:49] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  36. # [05:46] * Quits: roc (n=roc@202.180.114.137)
  37. # [06:07] * Quits: doublec (n=doublec@202.180.114.137)
  38. # [06:18] * Quits: yod (n=ot@dhcp-247-106.mag.keio.ac.jp) ("Leaving")
  39. # [06:19] * Joins: auk (n=scott@h-68-165-233-25.lsanca54.dynamic.covad.net)
  40. # [07:02] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  41. # [07:05] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  42. # [07:22] * Joins: aroben (n=aroben@unaffiliated/aroben)
  43. # [07:40] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  44. # [07:51] * Quits: auk (n=scott@h-68-165-233-25.lsanca54.dynamic.covad.net) (Read error: 104 (Connection reset by peer))
  45. # [07:52] * Joins: auk (n=scott@h-68-165-18-40.lsanca54.dynamic.covad.net)
  46. # [07:57] * Joins: roc (n=roc@121-72-52-215.dsl.telstraclear.net)
  47. # [08:00] * Joins: MikeSmith (n=MikeSmit@EM117-55-25-88.pool.emnet.ne.jp)
  48. # [08:19] * Quits: jwalden (n=waldo@RANDOM-THREE-FORTY-ONE.MIT.EDU) (Remote closed the connection)
  49. # [08:26] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  50. # [08:28] * Quits: auk (n=scott@h-68-165-18-40.lsanca54.dynamic.covad.net) ("Ex-Chat")
  51. # [08:36] <mitsuhiko> is there a way to tell the html5lib sanitizer to strip script tags instead of escaping them?
  52. # [08:36] <mitsuhiko> i have to aggregate some blog posts that are using digg/reddit buttons .)
  53. # [08:56] * Joins: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net)
  54. # [09:12] * Joins: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl)
  55. # [09:21] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  56. # [09:22] * Joins: tndH_ (i=Rob@adsl-87-102-42-252.karoo.KCOM.COM)
  57. # [09:22] * tndH_ is now known as tndH
  58. # [09:26] <zcorpan> hello internet
  59. # [09:30] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (devel) (IRC client for Emacs)")
  60. # [09:32] <hsivonen> zcorpan: hello!
  61. # [09:33] <zcorpan> hi hsivonen
  62. # [09:33] <zcorpan> what have i missed?
  63. # [09:50] <hsivonen> zcorpan: ARIA discussion for starters
  64. # [09:51] <hsivonen> zcorpan: also, FPWD publication has been delayed over charter and patent policy concerns
  65. # [09:54] <zcorpan> fun
  66. # [09:57] * Quits: webben (n=benh@91.84.238.73)
  67. # [10:02] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 110 (Connection timed out))
  68. # [10:14] * Joins: jruderman_ (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  69. # [10:24] * mpt__ is now known as mpt
  70. # [10:28] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  71. # [10:42] <mitsuhiko> is the conversion between <font size="..."> to css em/% defined somewhere?
  72. # [10:44] <zcorpan> css2.1 has something informative, i think
  73. # [10:45] <mitsuhiko> zcorpan: thanks a lot
  74. # [10:45] <mitsuhiko> found it
  75. # [10:45] * Parts: Lachy_ (n=Lachlan@ti200710a340-2269.bb.online.no) ("Leaving")
  76. # [10:54] * Joins: ROBOd (n=robod@89.122.216.38)
  77. # [10:57] * Quits: Lachy (n=Lachy@pat-tdc.opera.com) ("Leaving")
  78. # [10:57] * Joins: webben (i=benh@nat/yahoo/x-ddecd6a4889768dc)
  79. # [11:01] * Quits: MikeSmith (n=MikeSmit@EM117-55-25-88.pool.emnet.ne.jp) ("Less talk, more pimp walk.")
  80. # [11:15] * Joins: jgraham (n=james@81-86-216-175.dsl.pipex.com)
  81. # [11:38] * Joins: MikeSmith (n=MikeSmit@58.157.21.205)
  82. # [11:49] * Quits: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl) (Read error: 104 (Connection reset by peer))
  83. # [11:52] * Quits: jgraham (n=james@81-86-216-175.dsl.pipex.com) ("This computer has gone to sleep")
  84. # [11:57] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) (Remote closed the connection)
  85. # [11:57] * Joins: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de)
  86. # [12:03] * Quits: Oeighty (n=polx@ip-58-28-198-85.ubs-dsl.xnet.co.nz) (Read error: 110 (Connection timed out))
  87. # [12:05] * Joins: Lachy (n=Lachy@pat-tdc.opera.com)
  88. # [12:06] * Joins: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl)
  89. # [12:20] * Quits: roc (n=roc@121-72-52-215.dsl.telstraclear.net)
  90. # [12:29] <mitsuhiko> anyone has a "powered by html5lib" logo? :D
  91. # [12:32] * Joins: vant (n=vant@p2003-ipbf4401marunouchi.tokyo.ocn.ne.jp)
  92. # [12:45] * Joins: kfish (n=conrad@61.194.21.25)
  93. # [12:49] * hsivonen is very unhappy about the effects of upgrading to Leopard
  94. # [12:49] * hsivonen seeks to do something productive now
  95. # [13:05] <mitsuhiko> hsivonen: i'm switching to the ubuntu ltls soon :)
  96. # [13:05] <mitsuhiko> (next february. until then tiger)
  97. # [13:06] <hsivonen> mitsuhiko: yeah, the point of using Mac OS X is not having to do the kind of tweaking one would do on Ubuntu
  98. # [13:07] <hsivonen> mitsuhiko: so when Leopard starts requiring tweaking, one might as well tweak Ubuntu
  99. # [13:07] <mitsuhiko> i have to tweak my os x more than i tweak my ubuntu
  100. # [13:07] <mitsuhiko> i just say port, mysql, and mud-mousing
  101. # [13:08] <hsivonen> (I'm most unhappy about calendar changes made on my phone no longer syncing to the Mac despite numerous troubleshooting attempts)
  102. # [13:08] <hsivonen> this is the first OS X release that is a step backwards
  103. # [13:09] <hsivonen> looks like the UI fashion reached its peak in Tiger
  104. # [13:09] <hsivonen> the new menubar, folder icons and Dock appearance are all worse than what Tiger had
  105. # [13:30] <virtuelv> does this mean that operating systems have a half-life, where every subsequent release only gets worse?
  106. # [13:30] <virtuelv> Windows peaked with Windows 2000
  107. # [13:30] <virtuelv> XP was a giant step backwards, and I never installed it
  108. # [13:31] <OmegaJunior> It's an iterative cycle: up, down, up, down, needing continuous feedback.
  109. # [13:35] <hsivonen> virtuelv: I think the data isn't sufficient for predicting a trend
  110. # [13:36] <virtuelv> might be, but both versions of windows since 2k has been downhill
  111. # [13:42] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Remote closed the connection)
  112. # [13:46] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  113. # [13:48] * Quits: vant (n=vant@p2003-ipbf4401marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  114. # [13:56] <zcorpan> http://james.html5.org/cgi-bin/parsetree/parsetree.py?source=%3Cdiv%3E%3Cb%3Ex%3C%2Fdiv%3Ey -- i can't find in the spec where it says that the B element should be reopened
  115. # [14:15] * Joins: grimboy_uk (n=grimboy@85.211.236.85)
  116. # [14:17] <zcorpan> 475 emails to go... from 914 this morning
  117. # [14:23] <zcorpan> no wait, i have more emails left
  118. # [14:24] <zcorpan> 660
  119. # [14:25] <zcorpan> plus the html5 log i just marked as read without reading it (will use the tracker)
  120. # [14:27] <Lachy> hey zcorpan
  121. # [14:28] <Lachy> zcorpan, where have you been lately? On holidays or something?
  122. # [14:29] <zcorpan> hi Lachy
  123. # [14:29] <zcorpan> yeah, thailand
  124. # [14:29] <Lachy> oh, cool
  125. # [14:30] <Lachy> I made those test case videos you asked for while you were gone, you should have an email about them somewhere
  126. # [14:30] <zcorpan> yep, replied
  127. # [14:31] <zcorpan> they're perfect :)
  128. # [14:31] <Lachy> yeah, almost. There's a few things I need to change in them
  129. # [15:10] * Quits: MikeSmith (n=MikeSmit@58.157.21.205) ("Less talk, more pimp walk.")
  130. # [15:14] * Quits: csarven (n=nevrasc@81-5-133-33.static.nfwebsolutions.com) (Read error: 110 (Connection timed out))
  131. # [15:21] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  132. # [15:33] * Quits: webben (i=benh@nat/yahoo/x-ddecd6a4889768dc)
  133. # [15:35] * Quits: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl) ("Trillian (http://www.ceruleanstudios.com")
  134. # [15:44] <zcorpan> Hixie: about <bdo>, "For example, an HTML+CSS user agent should implement these requirements by implementing the CSS unicode-bidi property." -- is that intended to be a SHOULD?
  135. # [16:09] <hsivonen> oh great. XML 1.0, CSS and HTML5 all have different notions of whitespace
  136. # [16:48] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) ("The computer fell asleep")
  137. # [17:19] * Joins: aroben (n=aroben@unaffiliated/aroben)
  138. # [17:41] * Joins: Lachy_ (n=Lachlan@ti200710a340-2269.bb.online.no)
  139. # [17:50] * Quits: maikmerten (n=merten@ls5laptop14.cs.uni-dortmund.de) ("Verlassend")
  140. # [17:53] * Joins: dglazkov (n=dglazkov@adsl-065-081-081-030.sip.bhm.bellsouth.net)
  141. # [17:55] <dglazkov> hello whatwg
  142. # [17:55] <dglazkov> have a question about client-side storage section
  143. # [17:57] <zcorpan> hello dglazkov
  144. # [17:58] <dglazkov> hello zcorpan
  145. # [17:58] <dglazkov> actually, it's about async execution
  146. # [17:58] <dglazkov> specifically, the degree of async execution
  147. # [17:59] <dglazkov> does tx run in:
  148. # [17:59] <dglazkov> a) separate thread
  149. # [17:59] <dglazkov> b) uses setTimeout-style continuation model
  150. # [18:03] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 110 (Connection timed out))
  151. # [18:15] * zcorpan doesn't really know
  152. # [18:15] <dglazkov> :) me neither
  153. # [18:18] * Joins: aroben (i=aroben@unaffiliated/aroben)
  154. # [18:18] * Quits: aroben (i=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  155. # [18:19] * Joins: aroben (i=aroben@unaffiliated/aroben)
  156. # [18:45] <Hixie> dglazkov:b)
  157. # [18:45] <Hixie> dglazkov: it uses a callback
  158. # [18:45] <dglazkov> great!
  159. # [18:46] <dglazkov> that's easy
  160. # [18:47] <Hixie> yup
  161. # [18:47] <dglazkov> but what about "long epilogue" problem? what if there's a long-running bit of code right after the .transaction is called?
  162. # [18:47] <Hixie> then the sql takes a while to run
  163. # [18:48] <dglazkov> that kind of stinks, don't it?
  164. # [18:51] <Hixie> having any script that takes a long time is likely to block the user's UI, which is far worse anyway
  165. # [18:52] <dglazkov> right
  166. # [18:53] <dglazkov> ok, another quick question:
  167. # [18:54] <dglazkov> what's the utility of having the tx callback? Because it runs asynchronously and calls in turn asynchronous method(s), you can't really control the flow based on the data you're receiving. Couldn't an array of prepared statements be more logical?
  168. # [18:55] <dglazkov> Couldn't => Wouldn't
  169. # [18:58] <dglazkov> this is because of the chaining, isn't it?
  170. # [18:59] <dglazkov> i.e. function(tx) { tx.executeSql(..., function(tx, rs) { .. tx.executeSql() } }
  171. # [19:03] <Hixie> the only reason it's asynchronous is because the method might take a long time, and we don't want to block the UI while the method runs
  172. # [19:03] <Hixie> same reason executeSql() is async
  173. # [19:04] <dglazkov> what would you put in tx callback, other than a list of tx.executeSql statements?
  174. # [19:05] <Hixie> not much
  175. # [19:05] <dglazkov> here's where I am going with this
  176. # [19:06] <dglazkov> if tx callback is replaced with an array of prepared statements, I can execute statements truly asynchronously, without waiting on the main thread to finish
  177. # [19:07] <dglazkov> granted, the results will still be delivered via a queue
  178. # [19:07] <dglazkov> when the thread is done
  179. # [19:07] <Hixie> you could, but i'm not convinced the loss of expressibility is worth the potential performance gain
  180. # [19:08] <dglazkov> me neither -- just providing feedback
  181. # [19:08] * dglazkov has a partially working implementation of the updated HTML5 spec
  182. # [19:08] * Joins: virtuelv (n=virtuelv@51.80-203-76.nextgentel.com)
  183. # [19:08] <dglazkov> I will try to share it with the list later this week
  184. # [19:10] <dglazkov> Hixie, are you planning to add workerPool stuff to the HTML5 spec?
  185. # [19:11] <Hixie> yeah, eventually. right now the spec has so many new features I don't want to add stuff, for fear of the browsers getting lost and either giving up or implementing random stuff instead of staying mostly in sync.
  186. # [19:11] <dglazkov> good
  187. # [19:12] <Hixie> worker pools and communication pipes that can carry communication pipes are the two features i'm aware of that are currently waiting
  188. # [19:12] * Joins: maikmerten (n=maikmert@T759c.t.pppool.de)
  189. # [19:13] <dglazkov> .. and they are --- by far -- the coolest, IMHO
  190. # [19:14] <Hixie> possibly
  191. # [19:14] <Hixie> offline is probably better imho :-)
  192. # [19:15] <dglazkov> everybody has a favorite pet in the zoo that is HTML5 spec
  193. # [19:16] <Hixie> :-)
  194. # [19:18] <dglazkov> do you have a feeling that a lot of HTML5 spec is really a DOM API?
  195. # [19:18] <dglazkov> I mean, there is a format, and there is a set of APIs
  196. # [19:18] <dglazkov> all in one big pile
  197. # [19:19] * dglazkov wants everything neatly in their proper partitions
  198. # [19:19] <Hixie> HTML5 as a platform
  199. # [19:20] <Hixie> which involves two syntaxes, a language, and APIs for that language
  200. # [19:20] <Hixie> splitting the API from the language is artificial and just leads to ambiguities
  201. # [19:20] <Hixie> just look at DOM2 HTML
  202. # [19:20] <Hixie> the spec was originally called Web Applications 1.0, which is probably a more accurate name
  203. # [19:20] <dglazkov> right
  204. # [19:21] <dglazkov> what's wrong with DOM2?
  205. # [19:22] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (Read error: 110 (Connection timed out))
  206. # [19:22] <dglazkov> what I see is a lot of tension on public-html between people who came to work on the format and people who came to work on the APIS
  207. # [19:23] <Hixie> look at the definition of things in DOM2 HTML and then compare them to the detail we have in HTML5
  208. # [19:23] <Hixie> the DOM2 HTML and HTML4 specs were written by groups of people who didn't want to write markup languages and didn't want to write APIs, respectively
  209. # [19:24] <Hixie> and we ended up with poor APIs and a poor markup language
  210. # [19:24] <Hixie> the two absolutely have to be designed in tandem
  211. # [19:24] * Joins: jgraham (n=james@81-86-216-175.dsl.pipex.com)
  212. # [19:26] <othermaciej> hey y'all
  213. # [19:26] <alp> heya othermaciej
  214. # [19:26] <Lachy_> hi
  215. # [19:27] <othermaciej> to be effective for applications, HTML5 has to include a rich API
  216. # [19:27] <othermaciej> much of the API is tied to the markup
  217. # [19:27] <othermaciej> the idea of separating them does not make sense
  218. # [19:27] <othermaciej> and the charter requires us to do both
  219. # [19:27] <othermaciej> so I don't think it is even really worth thinking about
  220. # [19:28] * Lachy_ challenges those who think APIs should be specified in a separate spec from markup, to explain how they would even consider doing that for video, audio and canvas
  221. # [19:29] <dglazkov> ok, how does Web API WG fit into this, then?
  222. # [19:29] <Lachy_> they work together with us where appropriate
  223. # [19:29] <dglazkov> but.. aren't they an attempt to do exactly what you're advocating not to do?
  224. # [19:29] <Lachy_> in fact, we share some of the same members and some web api specs have been taken from older versions of HTML5 spec
  225. # [19:30] <Lachy_> dglazkov, not all APIs need to be specified with markup
  226. # [19:30] <Lachy_> some APIs aren't related to specific markup at all
  227. # [19:30] <Lachy_> like XHR or Window
  228. # [19:30] <dglazkov> like client-side storage spec?
  229. # [19:31] <Lachy_> maybe, but there's also the problem of finding competent editors in webapi to do it
  230. # [19:33] <dglazkov> ah..
  231. # [19:34] <dglazkov> maybe they can borrow a certain part of Hixie's brain? :)
  232. # [19:35] <Hixie> i don't have the bandwidth to work on two specs
  233. # [19:35] <Lachy_> there's another advantage with doing it within the HTML spec though. a lot more people will review it there
  234. # [19:35] * Joins: hober (n=ted@unaffiliated/hober)
  235. # [19:35] <dglazkov> definitely true, Lachy_
  236. # [19:39] <dglazkov> thanks for the primer, folks.
  237. # [19:40] * Quits: jgraham (n=james@81-86-216-175.dsl.pipex.com) ("This computer has gone to sleep")
  238. # [19:48] * Quits: weinig (n=weinig@c-71-198-185-169.hsd1.ca.comcast.net)
  239. # [19:52] * Joins: kingryan (n=kingryan@corp.technorati.com)
  240. # [20:02] * Joins: roc (n=roc@121-72-24-149.dsl.telstraclear.net)
  241. # [20:05] * Quits: mitsuhiko (n=mitsuhik@ubuntu/member/mitsuhiko) ("Terminated with extreme prejudice - dircproxy 1.0.5")
  242. # [20:13] * Joins: jgraham (n=james@81-86-216-175.dsl.pipex.com)
  243. # [20:21] * Quits: roc (n=roc@121-72-24-149.dsl.telstraclear.net)
  244. # [20:25] * Joins: weinig (n=weinig@17.203.15.140)
  245. # [20:36] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  246. # [20:38] * Quits: jgraham (n=james@81-86-216-175.dsl.pipex.com) ("This computer has gone to sleep")
  247. # [20:48] * Joins: jgraham (n=james@81-86-216-175.dsl.pipex.com)
  248. # [21:06] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  249. # [21:06] * Quits: jgraham (n=james@81-86-216-175.dsl.pipex.com) ("This computer has gone to sleep")
  250. # [21:24] * Joins: heycam` (n=cam@124-168-2-82.dyn.iinet.net.au)
  251. # [21:29] * Joins: roc (n=roc@202.180.114.137)
  252. # [21:35] * Quits: heycam (n=cam@124-168-2-82.dyn.iinet.net.au) (Read error: 110 (Connection timed out))
  253. # [21:43] * Quits: maikmerten (n=maikmert@T759c.t.pppool.de) (Remote closed the connection)
  254. # [21:43] * Joins: dglazkov_ (n=dglazkov@adsl-065-081-081-030.sip.bhm.bellsouth.net)
  255. # [21:43] * Quits: dglazkov (n=dglazkov@adsl-065-081-081-030.sip.bhm.bellsouth.net) (Read error: 104 (Connection reset by peer))
  256. # [21:47] * Quits: dglazkov_ (n=dglazkov@adsl-065-081-081-030.sip.bhm.bellsouth.net) (Remote closed the connection)
  257. # [21:48] * Joins: dglazkov (n=dglazkov@adsl-065-081-081-030.sip.bhm.bellsouth.net)
  258. # [22:03] * Hixie summons othermaciej
  259. # [22:05] * gsnedders watches othermaciej appear from a lantern
  260. # [22:05] <gsnedders> (slowly)
  261. # [22:05] * Joins: KevinMarks (i=KevinMar@nat/google/x-e8715722315d846e)
  262. # [22:06] * Joins: othermaciej (n=mjs@17.255.100.187)
  263. # [22:07] <Hixie> woot, it worked
  264. # [22:07] <gsnedders> :D
  265. # [22:08] <Hixie> othermaciej: so, what's wrong with ES ed 3 proposals? I need technical details to do my mojo here.
  266. # [22:08] * Joins: doublec (n=doublec@202.180.114.137)
  267. # [22:10] <Lachy_> Hixie, apparently there are some problems with it degrading gracefully in current implemnetations
  268. # [22:11] <gavin__> what ES ed 3 proposals? do you mean ed 4?
  269. # [22:11] * Parts: othermaciej (n=mjs@17.255.100.187)
  270. # [22:11] * Joins: othermaciej (n=mjs@17.255.100.187)
  271. # [22:11] <Lachy_> I don't know much though, I just spoke to him about it briefly earlier and that's what othermaciej said
  272. # [22:11] * gavin__ is now known as gavin
  273. # [22:11] <Hixie> er right, ed 4
  274. # [22:11] <othermaciej> Hixie: I'm about to send a review of the language overview whitepaper
  275. # [22:11] <Hixie> ok cool
  276. # [22:12] <othermaciej> Hixie: I am still trying to figure out all the technical issues worth pursuing
  277. # [22:12] <othermaciej> the ones that worry me are:
  278. # [22:12] <roc> http://www.ecmascript.org/es4/spec/incompatibilities.pdf for what it's worth
  279. # [22:12] <othermaciej> 1) does not address compatibility from the "degrades gracefully" perspective
  280. # [22:12] <othermaciej> (easily fixable, I will make a concrete proposal)
  281. # [22:12] <othermaciej> 2) slightly excessive in feature additions, some seem redundant
  282. # [22:13] <othermaciej> (unneeded features are bad for developers, bad for interop, and bad for small devices)
  283. # [22:13] <othermaciej> 3) unclear if it will hurt or improve performance in online implementations (I think this can probably be determined better with some experimentation and maybe some modest spec changes)
  284. # [22:13] <othermaciej> mainly I am worried about wether Brendan will be open to change proposals at all, since he seems to be in defensive mode
  285. # [22:14] <gavin> I'm sure he will be open to concret change proposals
  286. # [22:14] <othermaciej> anyway, I am going to turn this into real specific points
  287. # [22:14] <othermaciej> and proposals
  288. # [22:14] <othermaciej> and we'll see what happens
  289. # [22:14] <othermaciej> I do think the objections so far have not been concrete enough
  290. # [22:15] <othermaciej> anyway, I'm gonna go back to typing in my margin comments on the whitepaper
  291. # [22:15] <Hixie> ok
  292. # [22:15] * gavin awaits othermaciej's comments with great anticipation :)
  293. # [22:16] <Hixie> othermaciej: i'm happy to persue very specific technical concerns, i just don't have the bandwidth to figure out what they are myself
  294. # [22:16] <othermaciej> gavin: they are very rough so far - I almost literally typed in my notes in the margins from a printed copy I read on the plane
  295. # [22:16] <Hixie> othermaciej: i look forward to further e-mail
  296. # [22:16] <othermaciej> Hixie: roger that
  297. # [22:17] <gavin> othermaciej: that's fine, I'm still looking forward to seeing them :)
  298. # [22:20] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  299. # [22:26] <Hixie> othermaciej: btw does ES4 define the semantics of 'replaceable' properties?
  300. # [22:27] <othermaciej> Hixie: I don't think so - I am not sure ES4 would be the right level to define that in any case
  301. # [22:28] <othermaciej> Hixie: actually, I'm not up to speed on how exactly they act in various browsers
  302. # [22:28] <othermaciej> but it seems like they can be modelled at the ES4 level as an untyped read-write property even though the IDL makes them a typed read-only attribute
  303. # [22:28] <othermaciej> Hixie: investigating how replaceable properties (and shadowing a window property with var) is high on our agenda to investigate though
  304. # [22:29] <othermaciej> I think ggaren is working on it
  305. # [22:29] <othermaciej> I will try to make sure the right thing ends up in the right spec (whether that is Bindings4DOM or ES4)
  306. # [22:39] <Hixie> ,
  307. # [22:40] <Hixie> er, "k" even
  308. # [22:42] <gsnedders> similar is meaning really.
  309. # [22:47] * Quits: dglazkov (n=dglazkov@adsl-065-081-081-030.sip.bhm.bellsouth.net)
  310. # [22:47] <Hixie> so does ES4 require an explicit flag right now to enable it?
  311. # [22:47] <Hixie> as in, type="text/javascript;es4=1" or something?
  312. # [22:47] <Hixie> like e4x in firefox?
  313. # [22:47] * Joins: jgraham (n=james@81-86-216-175.dsl.pipex.com)
  314. # [22:47] <Hixie> cos the whole e4x=1 thing was clearly a failure...
  315. # [22:48] <Lachy_> if there needs to be some switch to turn on es4 features, it should be within the script itsself, not the mime type
  316. # [22:48] <Philip`> Firefox does all the JS1.8 features without an explicit flag, so I assume that's at least part of ES4
  317. # [22:49] <gavin> there's a proposal for a flag for certain incompatible features to be enabled
  318. # [22:49] <gavin> aiui
  319. # [22:49] <Lachy_> HTML5 fixed the issue with the required <script type=> in HTML4, it would be terrible if it were required anyway just to use es4
  320. # [22:49] <gavin> it's not required to use es4
  321. # [22:50] <Lachy_> AIUI, there are problems with hiding the new syntax features from current es3 implementations
  322. # [22:50] <Philip`> Oh, I'm wrong, FF doesn't do 'let' expressions without an explicit flag
  323. # [22:52] <Hixie> gavin: so how does the implementation know whether "yield" is a keyword or not?
  324. # [22:56] <gavin> I don't really know the details
  325. # [22:56] <gavin> https://bugzilla.mozilla.org/show_bug.cgi?id=336376 was landed for Firefox 2, it allows reserved keywords as property names
  326. # [22:56] <Hixie> what i've heard from other people on the committee is that you'd need a flag like type=""
  327. # [22:57] <Hixie> i don't see how else you'd handle something like: function () { var yield = 1; yield; }
  328. # [22:59] <gavin> I really don't know enough about the ES4 proposals to comment
  329. # [22:59] <gavin> http://wiki.ecmascript.org/doku.php?id=discussion:versioning and http://wiki.ecmascript.org/doku.php?id=proposals:versioning seem relevant
  330. # [23:01] <gavin> (I'm not sure whether those accurately reflect current thinking)
  331. # [23:01] * Quits: jgraham (n=james@81-86-216-175.dsl.pipex.com) ("This computer has gone to sleep")
  332. # [23:01] <gavin> they seem to be fairly recent
  333. # [23:01] <Hixie> k
  334. # [23:03] <Philip`> http://philip.html5.org/demos/js/jsversion.html - oh, quite a few things need the flag, though quite another few don't
  335. # [23:04] <othermaciej> gavin: giant email sent
  336. # [23:04] <othermaciej> Hixie: it requires a version=4 flag
  337. # [23:04] <Hixie> that sucks giant, and i mean giant, ass
  338. # [23:04] <othermaciej> Lachy_: agreed on in-script switches, I have a specific proposal for that comming semi-shortly
  339. # [23:05] <Hixie> that would basically make it impossible for cross-domain APIs to ever upgrade
  340. # [23:05] <Hixie> brb, cycling to the other building
  341. # [23:05] <othermaciej> Hixie: basically you have to write your script twice if you want to use ES4 features and still work in ES3 browsers
  342. # [23:06] * Quits: othermaciej (n=mjs@17.255.100.187)
  343. # [23:06] * Joins: othermaciej (n=mjs@17.255.100.187)
  344. # [23:06] * Quits: othermaciej (n=mjs@17.255.100.187) (Remote closed the connection)
  345. # [23:06] * Joins: othermaciej (n=mjs@17.255.100.187)
  346. # [23:09] * Quits: virtuelv (n=virtuelv@51.80-203-76.nextgentel.com) ("Leaving")
  347. # [23:13] <Hixie> othermaciej: that's not gonna fly
  348. # [23:13] <othermaciej> Hixie: what's not gonna fly? the Big Switch model of compatibility?
  349. # [23:14] <othermaciej> Hixie: I agree that it won't fly and have told Brendan that in so many words on multiple occasions
  350. # [23:14] <Hixie> othermaciej: yes
  351. # [23:14] <Hixie> e4x showed that
  352. # [23:14] <Hixie> though the lack of easy conversion to/from DOM nodes also killed that
  353. # [23:18] <Philip`> E4X almost entirely works without any switch, so that doesn't seem relevant to its success
  354. # [23:20] <roc> I don't think we can draw any conclusions from E4X
  355. # [23:20] <hsivonen> Hixie: was the DOM integration problem a spec problem or an impl problem?
  356. # [23:20] <Hixie> impl
  357. # [23:31] * takkaria_ is now known as takkaria
  358. # [23:56] * Quits: Hixie (n=ianh@trivini.no) ("restarting irsii to get new config")
  359. # [23:56] * Joins: Hixie (i=ianh@trivini.no)
  360. # Session Close: Thu Nov 15 00:00:01 2007

The end :)