/irc-logs / freenode / #whatwg / 2008-10-16 / end

Options:

  1. # Session Start: Thu Oct 16 00:00:00 2008
  2. # Session Ident: #whatwg
  3. # [00:01] * Quits: virtuelv (n=virtuelv@163.80-202-65.nextgentel.com) ("Leaving")
  4. # [00:02] * Joins: franksalim (n=frank@adsl-76-202-78-147.dsl.pltn13.sbcglobal.net)
  5. # [00:11] * Quits: gsnedders (n=gsnedder@lal69-1-82-67-11-148.fbx.proxad.net)
  6. # [00:17] * Quits: smerp (n=smerp@66.192.95.199) ("Jesus Built My Workstation")
  7. # [00:30] * Quits: sicking (n=chatzill@corp-241.mountainview.mozilla.com) (Read error: 104 (Connection reset by peer))
  8. # [00:44] * Quits: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  9. # [00:45] * Joins: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  10. # [00:45] * Quits: jruderman (n=jruderma@corp-241.mountainview.mozilla.com) (Client Quit)
  11. # [00:46] * Quits: webben (n=benh@nat/yahoo/x-54607ac6f4146f31) (Read error: 104 (Connection reset by peer))
  12. # [00:46] * Joins: webben (n=benh@nat/yahoo/x-014f3753033486b2)
  13. # [00:49] * Joins: sicking (n=chatzill@corp-241.mountainview.mozilla.com)
  14. # [00:52] * Joins: famicom_ (i=famicom@5ED2F98E.cable.ziggo.nl)
  15. # [00:55] * Quits: tndH (n=Rob@james-baillie-pc083-058.student-halls.leeds.ac.uk) ("ChatZilla 0.9.83-rdmsoft [XULRunner 1.9.0.1/2008072406]")
  16. # [00:59] * Joins: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  17. # [01:04] * Joins: aboodman (n=aboodman@nat/google/x-cae5ca44f4d2e1de)
  18. # [01:06] * Quits: othermaciej (n=mjs@17.244.17.22)
  19. # [01:06] * Quits: mstange (n=markus@pD957A226.dip0.t-ipconnect.de) ("ChatZilla 0.9.83 [Firefox 3.1b2pre/20081014020405]")
  20. # [01:07] * Quits: webben (n=benh@nat/yahoo/x-014f3753033486b2) (Connection timed out)
  21. # [01:08] * Quits: famicom_ (i=famicom@5ED2F98E.cable.ziggo.nl) ("Leaving")
  22. # [01:08] * Joins: famicom_ (i=famicom@5ED2F98E.cable.ziggo.nl)
  23. # [01:09] * Quits: famicom (i=famicom@5ED2F98E.cable.ziggo.nl) (Connection timed out)
  24. # [01:18] * Quits: erlehmann (n=nils@echelon.ext.c-base.org) (Read error: 110 (Connection timed out))
  25. # [01:20] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  26. # [01:27] * Joins: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  27. # [01:31] * Quits: onitunes (n=onitunes@cpe-76-87-109-106.socal.res.rr.com)
  28. # [01:34] * Quits: tantek (n=tantek@dsl001-150-252.sfo1.dsl.speakeasy.net)
  29. # [01:38] * Joins: onitunes (n=onitunes@cpe-76-87-109-106.socal.res.rr.com)
  30. # [01:40] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  31. # [01:46] * Hixie considers whether to not bother supporting the multipage apps like flickr and bugzilla in the offline cache mode
  32. # [01:47] <Hixie> or rather, not support having a fallback page if you follow a link to a page that isn't cached yet
  33. # [01:52] * Joins: othermaciej (n=mjs@17.203.15.173)
  34. # [01:55] * Quits: franksalim (n=frank@adsl-76-202-78-147.dsl.pltn13.sbcglobal.net) ("Leaving")
  35. # [01:55] * Quits: dglazkov (n=dglazkov@nat/google/x-63f3bf670aee9510)
  36. # [02:14] * Quits: famicom_ (i=famicom@5ED2F98E.cable.ziggo.nl) ("Leaving")
  37. # [02:14] * Joins: famicom (i=famicom@5ED2F98E.cable.ziggo.nl)
  38. # [02:16] * Quits: weinig (n=weinig@17.244.17.251)
  39. # [02:25] * Joins: erlehmann (n=nils@dslb-088-074-222-032.pools.arcor-ip.net)
  40. # [02:26] * Joins: hdh (n=hdh@58.187.62.19)
  41. # [02:32] * Joins: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  42. # [02:41] * Quits: famicom (i=famicom@5ED2F98E.cable.ziggo.nl) ("Leaving")
  43. # [02:47] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  44. # [02:53] * Quits: billmason (n=billmaso@ip199.unival.com) (".")
  45. # [02:57] * Quits: erlehmann (n=nils@dslb-088-074-222-032.pools.arcor-ip.net)
  46. # [03:01] * Joins: webben (n=benh@91.84.226.101)
  47. # [03:03] * Quits: ojan (n=ojan@nat/google/x-e8fbff5aa0ac7ab0) ("Leaving")
  48. # [03:06] * Joins: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com)
  49. # [03:06] * Joins: MikeSmith (n=MikeSmit@EM114-48-3-183.pool.e-mobile.ne.jp)
  50. # [03:08] * Quits: webben_ (n=benh@dip5-fw.corp.ukl.yahoo.com) (Client Quit)
  51. # [03:14] <kingryan> Hixie: you around?
  52. # [03:17] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  53. # [03:18] * Quits: fishd (n=Darin@nat/google/x-1abae20a6f70477b) ("Leaving")
  54. # [03:18] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net) (Client Quit)
  55. # [03:19] * Quits: Dashiva (i=Dashiva@wikia/Dashiva) (Read error: 110 (Connection timed out))
  56. # [03:22] * Quits: webben (n=benh@91.84.226.101) (Success)
  57. # [03:22] * gavin__ is now known as gavin
  58. # [03:30] * Quits: othermaciej (n=mjs@17.203.15.173)
  59. # [03:41] * Quits: MikeSmith (n=MikeSmit@EM114-48-3-183.pool.e-mobile.ne.jp) ("Less talk, more pimp walk.")
  60. # [03:57] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  61. # [03:58] <Hixie> kingryan: yo
  62. # [03:58] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  63. # [03:58] <kingryan> i have parsing question,if you have a minute
  64. # [03:59] <kingryan> so, i'm under the impression that a <title> found in a <body> should get moved to the <head>, is that right?
  65. # [04:00] * Hixie checks
  66. # [04:01] <Hixie> doesn't seem that way, no
  67. # [04:01] <Hixie> what makes you think that?
  68. # [04:01] <kingryan> some test cases in html5lib
  69. # [04:01] <kingryan> and vague memories of hearing that before
  70. # [04:01] <Hixie> i recommend basing your understanding of the spec on the spec itself
  71. # [04:01] <kingryan> of course
  72. # [04:02] <kingryan> but I sometimes i have trouble understanding and following the spec, so its useful to look at other sources
  73. # [04:03] <WulfTheSaxon> Heh. Reminds me of how 90% of questions my channel ( #webdev ) on DALnet can be resolved with a single link the HTML or CSS specs :P
  74. # [04:04] <Hixie> kingryan: if you have trouble with any part of the spec, let us know so i can make it clearer :-)
  75. # [04:04] <kingryan> sure
  76. # [04:04] * WulfTheSaxon reads what he just wrote, notices there are entire words missing, and decides to go grab a coffee >.>
  77. # [04:05] <Hixie> hm, i should go grab dinner
  78. # [04:14] * Joins: tantek (n=tantek@c-67-161-5-143.hsd1.ca.comcast.net)
  79. # [04:15] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  80. # [04:36] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  81. # [04:42] * Quits: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  82. # [04:42] * Quits: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com) (Read error: 60 (Operation timed out))
  83. # [04:44] * Joins: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net)
  84. # [04:44] * Quits: dglazkov (n=dglazkov@c-24-130-144-56.hsd1.ca.comcast.net) (Remote closed the connection)
  85. # [04:47] * Quits: tantek (n=tantek@c-67-161-5-143.hsd1.ca.comcast.net)
  86. # [04:57] * Joins: MikeSmith (n=MikeSmit@dhcp-247-174.mag.keio.ac.jp)
  87. # [04:58] <MikeSmith> wow -- no opportunistic caching in offline-apps any more
  88. # [04:58] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  89. # [04:58] <MikeSmith> is that because nobody implemented opportunistic caching, or because it wasn't a good idea?
  90. # [05:02] <olliej> MikeSmith: hixie knows all
  91. # [05:03] <MikeSmith> olliej: yeah, was just wondering if there might have been discussion here before I rejoined this morning
  92. # [05:04] <olliej> MikeSmith: yeah, i just looked through the scrollback and couldn't immediately see anything
  93. # [05:04] <MikeSmith> OK
  94. # [05:04] <olliej> MikeSmith: except a brief comment by Hixie on multipage apps like flickr
  95. # [05:04] <MikeSmith> ah
  96. # [05:05] <olliej> MikeSmith: but i'm not sure if it was relevant to this
  97. # [05:06] <olliej> MikeSmith: i only really follow the canvas stuff
  98. # [05:06] <MikeSmith> well, I know you guys hadn't implemented opportunistic caching and Mozilla hadn't either, so I'd reckon that probably had some influence over the decision about it
  99. # [05:06] <olliej> not necessarily
  100. # [05:07] <MikeSmith> olliej: about canvas, is that because you're responsible for canvas code in Webkit?
  101. # [05:07] <olliej> MikeSmith: generally things only seem to be pulled when multiple engines say "no"
  102. # [05:07] <olliej> MikeSmith: yup
  103. # [05:07] <MikeSmith> yeah
  104. # [05:07] <MikeSmith> did you do the original implementation?
  105. # [05:07] <olliej> MikeSmith: no
  106. # [05:08] <olliej> MikeSmith: if i had there would have been a distinct Path object
  107. # [05:08] <MikeSmith> heh
  108. # [05:08] <olliej> MikeSmith: that was not attached to the context
  109. # [05:08] <olliej> stab stab stab
  110. # [05:08] <olliej> ;D
  111. # [05:08] <MikeSmith> :)
  112. # [05:08] * Joins: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  113. # [05:08] <olliej> canvas path behaviour is hideous it's the result of a poor design in the original implementation that was then misinterpreted by mozilla
  114. # [05:09] <olliej> leading to the current excitement wherein a Path retains its visible screen location across context save/restore points
  115. # [05:09] <olliej> yo othermaciej
  116. # [05:09] <othermaciej> hi olliej
  117. # [05:10] <Hixie> MikeSmith: i will be sending a long mail about caching stuff
  118. # [05:10] <MikeSmith> Hixie: Ok
  119. # [05:10] * Quits: nessy (n=nessy@124-171-22-123.dyn.iinet.net.au) ("This computer has gone to sleep")
  120. # [05:13] <MikeSmith> olliej: I suppose there's general agreement that the way canvas ended up being standardized is not the ideal way, and would be nice to not have been stuck with some of what it ended up with. But I guess some might say the end result is not much worse that other things -- parts of the DOM, whatever -- that we're also stuck with now
  121. # [05:14] * Joins: onitunes_ (n=onitunes@cpe-76-87-109-106.socal.res.rr.com)
  122. # [05:14] <olliej> MikeSmith: alas it came into existence (afaict) prior to the "standardisation" of vendor prefixes, etc
  123. # [05:28] * Quits: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  124. # [05:32] * Quits: onitunes (n=onitunes@cpe-76-87-109-106.socal.res.rr.com) (Read error: 113 (No route to host))
  125. # [05:33] <roc> we have implemented opportunistic caching on trunk
  126. # [05:50] * Joins: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  127. # [06:01] * Joins: Thezilch (n=fuz007@cpe-76-171-111-7.socal.res.rr.com)
  128. # [06:05] <MikeSmith> roc: was that a pretty recent change? last I had heard (a couple months back, I guess), you hadn't yet
  129. # [06:06] <roc> Sep 30
  130. # [06:07] <roc> https://bugzilla.mozilla.org/show_bug.cgi?id=442813
  131. # [06:08] * roc mumbles something about fast-paced development
  132. # [06:10] * Quits: aboodman (n=aboodman@nat/google/x-cae5ca44f4d2e1de) (Read error: 110 (Connection timed out))
  133. # [06:24] * olliej is now known as fakeolliej
  134. # [06:35] * Joins: othermaciej_ (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  135. # [06:35] * Quits: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net) (Read error: 54 (Connection reset by peer))
  136. # [06:57] * Quits: othermaciej_ (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net) (Connection reset by peer)
  137. # [06:57] * Joins: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  138. # [07:03] * Joins: paulymer (n=pknight@unaffiliated/paulymer)
  139. # [07:15] * Joins: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  140. # [07:20] * Quits: roc (n=roc@202.0.36.64)
  141. # [07:31] * Joins: famicom (i=famicom@5ED2F98E.cable.ziggo.nl)
  142. # [07:45] * Quits: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  143. # [07:46] * Joins: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  144. # [07:47] * Quits: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  145. # [08:03] * Quits: hdh (n=hdh@58.187.62.19) (Read error: 104 (Connection reset by peer))
  146. # [08:09] * Quits: Maghnus (n=Maghnus@68-190-147-184.dhcp.eucl.wi.charter.com) (Read error: 60 (Operation timed out))
  147. # [08:12] * Parts: weinig (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  148. # [08:13] * onitunes_ is now known as onitunes
  149. # [08:30] * Joins: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  150. # [08:31] * paulymer is now known as Paulymer
  151. # [08:55] * Joins: peter-proc (n=retep@procurios.xs4all.nl)
  152. # [09:00] <annevk3> http://www.mnot.net/blog/2008/10/16/site-meta
  153. # [09:04] * Quits: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  154. # [09:05] <annevk3> othermaciej, you around? should I e-mail es-discuss about ByteArray instead?
  155. # [09:05] <othermaciej> annevk3: I'm around
  156. # [09:05] <othermaciej> annevk3: I can probably do it later tonight or tomorrow, but you should feel free to do it instead if you want
  157. # [09:05] * Joins: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net)
  158. # [09:06] <annevk3> k, I think I'll just do it and then you can jump in :)
  159. # [09:15] <othermaciej> ok
  160. # [09:21] * Quits: Paulymer (n=pknight@unaffiliated/paulymer)
  161. # [09:36] * Quits: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  162. # [09:36] * Quits: jruderman (n=jruderma@c-67-180-39-55.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  163. # [09:38] * Joins: nessy (n=nessy@124-171-22-123.dyn.iinet.net.au)
  164. # [09:40] * Joins: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  165. # [09:40] * Parts: MikeSmith (n=MikeSmit@dhcp-247-174.mag.keio.ac.jp) ("Less talk, more pimp walk.")
  166. # [09:40] * Joins: MikeSmith (n=MikeSmit@dhcp-247-174.mag.keio.ac.jp)
  167. # [09:44] * Joins: roc (n=roc@121-72-197-52.dsl.telstraclear.net)
  168. # [10:05] <hsivonen> hmm. kingryan is here only when I am asleep
  169. # [10:11] * Joins: Dashiva (i=Dashiva@wikia/Dashiva)
  170. # [10:11] * Parts: BenMillard (i=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  171. # [10:13] * Joins: gsnedders (n=gsnedder@lal69-1-82-67-11-148.fbx.proxad.net)
  172. # [10:18] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  173. # [10:36] <hsivonen> is it intentional that the issues graph no longer reacts to hover?
  174. # [10:39] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  175. # [10:39] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Client Quit)
  176. # [10:42] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  177. # [10:48] * Joins: ROBOd (n=robod@89.122.216.38)
  178. # [10:57] <hsivonen> Would you say this is an accurate statement: "The HTML5 work on the other hand uses a centralized extensibility mechanism based on formalized tagsoup parsing."
  179. # [10:58] <Hixie> not really
  180. # [10:58] <Hixie> and yes, i removed the hover effect
  181. # [10:59] <hsivonen> Hixie: how would you fix the statement?
  182. # [10:59] <hsivonen> ok. (re: hover)
  183. # [10:59] <hsivonen> (I prefer the term "text/html" over "tagsoup".)
  184. # [11:00] <Hixie> "The HTML5 language has a variety of extension mechanisms." for the first part; I've no idea what the second part is trying to say
  185. # [11:01] <hsivonen> do we have a wiki page enumerating all the extension mechanisms? meta[name], [rel], [class], data-* off the top of my head
  186. # [11:01] <Hixie> the faq lists them iirc
  187. # [11:02] <hsivonen> so it does
  188. # [11:02] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  189. # [11:04] <hsivonen> as far as I can tell, the sentence is trying to make the point that a random group can't add a feature like SVG or MathML to text/html unilaterally
  190. # [11:05] <Hixie> yeah
  191. # [11:05] <Hixie> well
  192. # [11:05] <Hixie> that's mostly up the browser vendors
  193. # [11:05] <Hixie> i mean, you can't add any feature to the web platform cross-browser unilaterally
  194. # [11:05] <hsivonen> in XML, they can syntactically, but they still need the buy-in of people who can commit code to Gecko, WebKit, Trident and Presto in order to get their stuff in the hands of users
  195. # [11:06] <othermaciej> I think people sometimes think making their own tags that browsers don't do anything special with is somehow really useful and important
  196. # [11:06] * Joins: webben (n=benh@nat/yahoo/x-965003ac29c5ade1)
  197. # [11:06] <othermaciej> and other people just don't understand how browsers work and imagine defining their own extension with rendering and behavior and such will magically work
  198. # [11:06] <Hixie> the whatwg "unilaterally" (i.e. without w3c approval) invented a whole bunch of new tags
  199. # [11:06] <Hixie> so clearly it is possible even in text/html
  200. # [11:07] <othermaciej> in WebKit we invented some new tags and attributes
  201. # [11:07] <Hixie> similarly, microsoft invented <marquee>, apple invented <canvas>, netscape invented <blink> and <keygen>, etc
  202. # [11:08] <Hixie> in general, the web platform is better off without unilateral browser-implemented extensions, though
  203. # [11:08] <othermaciej> I think people want to be able to invent tags and have a validator call it correct
  204. # [11:08] <hsivonen> which reminds me that keygen is still missing from the spec
  205. # [11:08] <othermaciej> keygen is such a ridiculous feature
  206. # [11:08] <hsivonen> surely it has to be "specified" somewhere in the bowels of mxr.mozilla.org
  207. # [11:08] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  208. # [11:08] <Hixie> keygen feedback is pending
  209. # [11:08] <Hixie> along with all of wf2 feedback
  210. # [11:09] <Hixie> i think othermaciej is right, people want to be able to be told that making up their own thing is ok
  211. # [11:09] <Hixie> but it's not clear why their desire is valid
  212. # [11:09] <Hixie> (for lack of a better term)
  213. # [11:09] <hsivonen> othermaciej: it's really simple to make a validator that calls stuff correct... function isInputValid(input) { return true; }
  214. # [11:10] <othermaciej> hsivonen: yes, but it should still tell the bad people who don't use double quotes or make syntax errors or invent tags in an unapproved way that they are bad
  215. # [11:10] * Hixie wonders what hsivonen is responding to
  216. # [11:10] <gsnedders> Hixie: Can we not have a similar vendor prefix thing to CSS?
  217. # [11:10] <othermaciej> hsivonen: otherwise, the good people who make unilateral extensions in the Official Approved way cannot feel better than other people
  218. # [11:11] <Hixie> gsnedders: doesn't really work for elements. for attributes we somewhat could, though it doesn't really work very well there either.
  219. # [11:11] <gsnedders> Hixie: Doesn't work why?
  220. # [11:11] <Hixie> gsnedders: html has different characteristics than css
  221. # [11:11] <othermaciej> for attributes it might be plausible
  222. # [11:11] <gsnedders> Hixie: I think I might have just noticed :)
  223. # [11:11] <othermaciej> for elements I don't think it works
  224. # [11:11] <gsnedders> Lack of fallback, etc.?
  225. # [11:11] <othermaciej> for attributes it is a pain since desire to dynamically change attribute values is likely to be much higher
  226. # [11:11] <Hixie> gsnedders: e.g. even in css it doesn't make sense for some things; e.g. you couldn't really make up an alternative to 'display' and call it '-foo-display', because then you'd have unclear precedence models, etc
  227. # [11:11] <gsnedders> Anything else will still notice iit?
  228. # [11:11] <othermaciej> also vendor prefix doesn't work very well for scripting interfaces
  229. # [11:12] <hsivonen> Hixie: I find it interesting that often people tend to care more about validator passing their stuff than about validator informing them about their mistakes
  230. # [11:12] <Hixie> othermaciej: it works ok for scripting stuff
  231. # [11:12] <hsivonen> Hixie: I think othermaciej's observation is correct, though
  232. # [11:12] <Hixie> hsivonen: i think it's actually a very small group of people to be honest
  233. # [11:12] <othermaciej> Hixie: well, it's not completely untenable, just painful; I guess you could check for every vendor prefixed version as prologue and rename them to a common name
  234. # [11:12] <Hixie> hsivonen: relative to the total html authoring population
  235. # [11:13] <gsnedders> hsivonen: That entire group is minute though
  236. # [11:13] <gsnedders> Ooo… nice weather when I get to Cannes!
  237. # [11:13] <othermaciej> Hixie: but that doesn't really work for IDL attributes (i.e. JS properties) as opposed to methods
  238. # [11:13] <Hixie> othermaciej: typically since the features will be different in each implementation, you'd do something like if (window.fooBar) { } else if (window.bazBar) { } else { }
  239. # [11:13] <othermaciej> Hixie: see, even you can't code it right
  240. # [11:13] <Hixie> othermaciej: e.g. attachEvent vs addEventListener
  241. # [11:13] <othermaciej> what you wrote fails if fooBar happens to have a false value
  242. # [11:14] <Hixie> well i'm assuming it's a function in this case
  243. # [11:14] <Hixie> but sure, it depends on what you're doing
  244. # [11:14] <othermaciej> for functions it is easier since you can make a common wrapper or copy to a common name
  245. # [11:14] <Hixie> depends on the function
  246. # [11:14] <othermaciej> for attributes (in the IDL sense) it doesn't really work
  247. # [11:14] <Hixie> but sure
  248. # [11:14] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Remote closed the connection)
  249. # [11:15] <othermaciej> I mean, it doesn't fail quite as hard as vendor prefix on elements but it is IMO pretty bad
  250. # [11:15] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  251. # [11:16] <Hixie> well it's a bit worse than css, sure
  252. # [11:16] <Hixie> it's not like it's that awesome in css either
  253. # [11:16] <othermaciej> well, you don't need control structures to repeat yourself without breakage in CSS
  254. # [11:16] <hsivonen> "Adobe will allow over-the-air updates of the Flash player. Providers and carriers can push out new player versions to their users." Huh? Has Adobe previously forbidden updates??
  255. # [11:17] <othermaciej> (and fairly obscure ones to be correct)
  256. # [11:17] <Hixie> at the end of the day, it's better for vendor-specific extensions to be prefixed wherever they are, but it's even better for the vendor-specific extensions to be discussed before shipping in public so that a multilateral agreement can be formed first
  257. # [11:17] <othermaciej> the normal pre-iPhone model for mobile phone software is that you essentially never update it
  258. # [11:18] <othermaciej> in theory you can for some "smartphones" when tethered but afaict hardly anyone does
  259. # [11:18] <othermaciej> we have done some prefixing and try to form agreement when we can
  260. # [11:19] <othermaciej> but I do think that multiple prefixed versions of a method or attribute would be a greater lose than multiple prefixed versions of a CSS property
  261. # [11:19] <othermaciej> fortunately, coordination around HTML and around miscellaneous APIs seems easier than for new CSS stuff
  262. # [11:19] <MikeSmith> othermaciej: "the normal pre-iPhone model for mobile phone software is that you essentially never update it" is patently untrue at least as far as Japan is concerned
  263. # [11:19] <othermaciej> MikeSmith: it's certainly true in the US - I am not really familiar with Japan
  264. # [11:20] <MikeSmith> the US is the last place in the world to be looking at for precedents around mobile data services
  265. # [11:20] <othermaciej> my impression is that the major handset vendors in Europe don't exactly push updates too widely either - for many phones the only way to update the firmware would be at the carrier's brick and mortar store
  266. # [11:21] <othermaciej> I don't know of any phone that will update system software over the air
  267. # [11:21] <MikeSmith> also as far as mobile software in Japan, the App Store is also not particularly novel in any way
  268. # [11:21] <MikeSmith> othermaciej: I do
  269. # [11:21] <othermaciej> MikeSmith: seriously?
  270. # [11:21] <othermaciej> because that is kind of terrifying even to me
  271. # [11:22] <othermaciej> MikeSmith: anyway I am sure Japan is cool and technologically superior and everything but I think most US-based companies still have a US-centric point of view
  272. # [11:25] <MikeSmith> othermaciej: I don't think Japan is all that technologically superior as far as mobile technologies go. it's just that we have more real use cases for the technology here and a thriving market.
  273. # [11:26] <othermaciej> apparently over-the-air mobile firmware updates are not all that uncommon now (as far as I can tell from googling), so I guess my impression of how things work was slightly out of date
  274. # [11:27] <zcorpan> "User agents that cannot render the video may instead make the element represent a link to an external video playback utility or to the video data itself." -- this makes me wonder if someone's working on a text-based browser that follows the html5 spec
  275. # [11:27] <hendry> MikeSmith: what mobiles update? I thought the Japanese market pushed new series phones every 6 months 8x 9x with new APIs
  276. # [11:27] <othermaciej> MikeSmith: I have heard many times that Japan (and Europe) have broader deployment than the US of relatively high-bandwidth wireless service and higher market penetration of "smartphones" relative to "feature phones"
  277. # [11:27] <MikeSmith> we basically don7t have anything but smartphones and features phones in Japan
  278. # [11:27] <MikeSmith> there is nothing else
  279. # [11:28] <hsivonen> what's a "feature phone"?
  280. # [11:28] <hendry> hsivonen: what's a mobile? :)
  281. # [11:28] <othermaciej> my impression is that Japan has various kinds of interesting software innovation going on but as far as I can tell, most of it doesn't really make it out of Japan other than console games and Ruby
  282. # [11:28] <othermaciej> a "feature phone" is what is currently a low-end phone
  283. # [11:29] <othermaciej> the category below "smartphone"
  284. # [11:29] <MikeSmith> oh
  285. # [11:29] <othermaciej> they are called that because (as I just learned recently) they used to be high end
  286. # [11:29] <hsivonen> othermaciej: ok. New term to me.
  287. # [11:29] <othermaciej> they tend to have things like a camera, a primitive browser, etc
  288. # [11:29] <MikeSmith> well, I take back what I said then -- we don't have "feature phones" -- we have only one class of handset
  289. # [11:30] <othermaciej> but not, typically, fancy installable software, a large screen, major league internet capabilites, etc
  290. # [11:30] <hendry> MikeSmith: what's a popular Web site for Japanese mobile users?
  291. # [11:30] <othermaciej> apparently they used to be the high end relative to phones that just made calls and that's it
  292. # [11:31] <MikeSmith> hsivonen: new handsets for KDDI/Au and DoCoMo and Softbank Mobile get released here every 3 months -- and no, they do not deploy new APIs every time the release new devices. The APIs are quite stable.
  293. # [11:31] * Joins: Lachy_ (n=Lachlan@pat-tdc.opera.com)
  294. # [11:32] <hendry> i was under the impression they launch new APIs and new services and hence drive sales that way
  295. # [11:32] <othermaciej> even though I am biased, I will say anyway that regardless how innovative it is or not, I find the App Store really impressive
  296. # [11:32] <MikeSmith> hendry: mobile version the Mixi social-networking service, mobile versions of restaurant-information sites, mobile versions of map sites that rely on location-awareness in browsers and markup extensions that expose location information to Web apps, ...
  297. # [11:32] <othermaciej> because normally I hate everything about obtaining new software
  298. # [11:32] <othermaciej> but not with the App Store
  299. # [11:32] <MikeSmith> hendry: they do, but not at the kind of rate
  300. # [11:32] <othermaciej> I want an App Store for the Mac now
  301. # [11:33] * Joins: BenMillard (n=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  302. # [11:33] <hendry> MikeSmith: there is even a series number across sharp, nec phones if i remember correctly that correspond the api/service generation
  303. # [11:35] <Hixie> othermaciej: four major features missing on the app store that kill it for me: it's not an open market place, it doesn't support open source software, i can't filter by price, and i can't try before paying.
  304. # [11:36] <othermaciej> Hixie: I would like to try before I buy, though with the free apps it is not a problem, and with commercial apps that's not the norm in any case
  305. # [11:37] <Hixie> with commercial apps one can find the app on bittorrent and try it before buying
  306. # [11:37] <hsivonen> othermaciej: I can try the apps from Omni, etc. before I buy. Even iWork from Apple.
  307. # [11:37] <Hixie> (not that i've actually used a "commercial" app that didn't have a demo or that i hadn't tried in some other legitimate way in years)
  308. # [11:37] <othermaciej> I have heard the App Store terms make it impossible to publish open source software, but I am not sure what aspect of the terms makes that impossible
  309. # [11:38] <MikeSmith> hendry: there are consistent series numbers or prefixes across all devices that are deployed for a particular carrier's service
  310. # [11:38] <othermaciej> some iPhone apps do have both free and pay versions (often with ads in the free version though)
  311. # [11:38] <MikeSmith> e.g., for DoCoMo, current series is "906"
  312. # [11:38] <Hixie> othermaciej: LGPL requires that the redistributor allow the user to link with another library. There's no way to do that on the iPhone platform.
  313. # [11:38] <othermaciej> personally I decide what software to get by word of mouth, if it costs money
  314. # [11:39] <othermaciej> Hixie: I would think posting the full source of your app in an alternate online location would be sufficient
  315. # [11:39] <Hixie> (which e.g. means that certain parts of safari can't ship on the iphone, but don't tell your lawyers)
  316. # [11:39] <MikeSmith> hendry: previous one was 706
  317. # [11:39] <BenMillard> othermaciej, my mum and dad's phone can be updated by installing the vendor's update software onto your PC, using that to download the phone's updates to your PC, then transferring the updates to your phone, then rebooting the phone
  318. # [11:39] <BenMillard> *phones
  319. # [11:39] <Hixie> othermaciej: no, because i can't recompile the app and put it on the device. at least, that's the problem as i understand it.
  320. # [11:40] <othermaciej> Hixie: I don't believe the LGPL requires the developer to provide the user with the relevant dev tools
  321. # [11:40] <MikeSmith> Hixie: at Au, it's 60 series, 50 series before that, etc.
  322. # [11:40] <othermaciej> Hixie: otherwise, how could open source GUI software for Windows exist (since afaik only proprietary compilers can build such)?
  323. # [11:41] <Hixie> there are a number of free software compilers for windows.
  324. # [11:41] <Hixie> but the problem is that given the iphone platform, one can't change the software.
  325. # [11:41] <Hixie> since it is a closed platform.
  326. # [11:42] <othermaciej> the only free software compilers I know of for Windows can only build command-line tools
  327. # [11:42] <othermaciej> I don't think the LGPL has any requirements about enabling you to run the software on any particular platform once you change and build it
  328. # [11:43] <othermaciej> I think the problem before was that the NDA made it effectively illegal to distribute the source of anything that used iPhone OS APIs
  329. # [11:43] <othermaciej> because that would ispo facto violate the NDA on said APIs
  330. # [11:43] <othermaciej> I believe that problem is now solved
  331. # [11:44] <othermaciej> I will say for the record that I would much prefer if the iPhone let me put any software I want without having to be approved as a developer by Apple and paying them extra money for the privilege
  332. # [11:44] <othermaciej> so I am not going to defend the policy
  333. # [11:44] <Hixie> "For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies
  334. # [11:45] <Hixie> i don't believe that the $79 i have to pay apple to run code on the iphone can be said to be "normally distributed with the major components of the operating system on which the executable runs"
  335. # [11:45] <othermaciej> well under that interpretation Safari for Windows and Chrome are equally in violation
  336. # [11:45] <Hixie> like i said
  337. # [11:45] <othermaciej> since they require Visual Studio to build
  338. # [11:46] <Hixie> anyway
  339. # [11:46] <othermaciej> indeed Mac OS X does not come with dev tools, you need a separate DVD
  340. # [11:46] <Hixie> i'll let the lawyers worry about this one
  341. # [11:46] <othermaciej> (which you can download or get for free, but ok)
  342. # [11:47] <Hixie> at the end of the day, the practical problems with the iphone and the app store being locked down are real problems for me regardless of whether the issue is technically legally ok or not
  343. # [11:47] <othermaciej> I think the fact that "compiler" counts as a "major component of the OS" means it is ok to rely on anything distribtued with the compiler, even if the compiler and the kernel areobtained separately
  344. # [11:47] <Hixie> the compiler for the iphone is separate from the $79 i have to pay to actually get code onto my device
  345. # [11:48] <othermaciej> "reproducing the executable" is also separate from getting it onto your device
  346. # [11:49] <Hixie> well like i said, at the end of the day, the practical problems with the iphone and the app store being locked down are real problems for me regardless of whether the issue is technically legally ok or not
  347. # [11:49] <othermaciej> I agree in principle that it is bogus that you have to pay extra to get code on the device, whether it is open source or not though
  348. # [11:50] <othermaciej> in practice, I like my iPhone more since the App Store came out than before
  349. # [11:50] <othermaciej> I could imagine liking it even more
  350. # [11:51] <othermaciej> I continue to feel that the process of obtaining sofware for my iPhone feels more convenient than getting software for my Mac, even though the process in other ways is restricted in ways I think are wrong
  351. # [11:51] <Hixie> i agree that the actual process of getting software on the iphone is nice
  352. # [11:51] <Hixie> it's quite similar to the process of getting software on a linux distro
  353. # [11:51] <Hixie> though with a nicer ui, to be sure
  354. # [11:51] <roc> for the record, free compilers for Windows are quite capable; you can build Firefox with mingw-gcc
  355. # [11:52] <othermaciej> I can only hope that Apple continues to reduce the restrictions on the iPhone over time, and in the meantime I will continue to contribute to the one fully open platform that the iPhone supports
  356. # [11:52] <othermaciej> roc: I have heard from multiple sources that mingw can't generate code that can successfully link to windows system DLLs
  357. # [11:53] <othermaciej> maybe that is wrong
  358. # [11:53] <othermaciej> or maybe it is limited to C++ or COM interfaces
  359. # [11:54] <othermaciej> or maybe it is not really a problem
  360. # [11:54] <roc> http://gemal.dk/mozilla/build.html
  361. # [11:55] <hsivonen> Hixie: IANAL, but I believe the canonical interpretation of "kernel" and "compiler" in GPLv2 series is that you don't need to distribute the compiler--even if it's non-Free
  362. # [11:55] * gsnedders votes MIT license ftw
  363. # [11:57] <hsivonen> Hixie: I think the status of the portability layer under Apple's WebKit is a more interesting case than the compiler
  364. # [11:57] <othermaciej> roc: interesting
  365. # [11:58] <othermaciej> hsivonen: you mean the proprietary libraries that the Apple Windows port of WebKit link to as DLLs?
  366. # [11:59] <hsivonen> othermaciej: those and the thin layer on Mac if it's still there
  367. # [11:59] <othermaciej> I do not believe that dynamically linking to anything can be an LGPL violation regardless of license terms
  368. # [11:59] <roc> as for LGPL2, all you're required to do in section 6 is ensure that the user can relink your executable against their own version of the LGPL'ed library.
  369. # [11:59] <othermaciej> the Mac non-open-source .a is linked by a purely BSD-licensed dylib
  370. # [12:00] <othermaciej> (it is also shrinking)
  371. # [12:00] <roc> AFAIK you're not required to make sure that that executable can be run on a specific device, so signing and/or other restrictions do not violate LGPL2
  372. # [12:00] <roc> which is one reason why GPL3 (and LGPL3) were created
  373. # [12:00] <roc> (which are anathema to Apple)
  374. # [12:02] <hsivonen> I wonder if Apple is going to implement a C++ compiler, too, in addition to clang
  375. # [12:03] <roc> clang is intended to be a C++ compiler eventually
  376. # [12:03] <gsnedders> hsivonen: I think the aim is for clang to be C++ too
  377. # [12:03] <hsivonen> ok
  378. # [12:03] <othermaciej> having looked a fair bit at LLVM internals, I expect it to become a genuinely better compiler than GCC
  379. # [12:03] <othermaciej> but anything could happen
  380. # [12:04] <gsnedders> othermaciej: Is there any reason why LLVM wasn't used for SF?
  381. # [12:05] <othermaciej> gsnedders: we think the way we did it is a good approach
  382. # [12:05] <othermaciej> I can give you a slightly less vague answer on #squirrelfish where it is less off-topic, if you really care to know
  383. # [12:06] <hsivonen> which reminds me that I should go and learn why stack-based VMs are the common VM design
  384. # [12:06] <othermaciej> probably because most people thought of it as the obvious way to do it back in the day
  385. # [12:07] <othermaciej> I think it is now uncontroversial that register-based is better, to anyone who has studied the topic
  386. # [12:07] <othermaciej> though with a strong JIT it does not matter as much
  387. # [12:07] <hsivonen> I've always had a hard time understanding why it would be the obvious way when CPUs are register-based
  388. # [12:07] <othermaciej> unless your JIT kicks in only part of the time
  389. # [12:07] <roc> stack-based VMs are the common VM design because VM designers are silly
  390. # [12:07] <othermaciej> CPUs having lots of registers is a fairly recent development in the history of VMs
  391. # [12:08] <Philip`> Hooray for Parrot
  392. # [12:08] <othermaciej> and a register-based VM doesn't really work like a register-based CPU anyway; it has infinite virtual registers
  393. # [12:08] <Philip`> (What other register-based VMs exist now?)
  394. # [12:08] <Philip`> Parrot had finite (32) registers for quite a while, and that was still a register-based VM back then
  395. # [12:09] <Philip`> (but then they realised that limit was silly since they could easily make it unbounded)
  396. # [12:09] <roc> this was obvious in 1996 if not earlier. The remarkable thing was the .NET designers didn't learn the lesson
  397. # [12:11] <othermaciej> I don't know why you would make a register VM with finite registers
  398. # [12:11] * roc spent a lot of time wrestling with Java (stack based) bytecode over the years
  399. # [12:11] <othermaciej> roc: I am a bit curious why both SpiderMonkey and Tamarin are stack-based
  400. # [12:11] <roc> because Spidermonkey was designed before 1996 :-)
  401. # [12:11] <roc> Tamarin, I dunno
  402. # [12:12] <othermaciej> I will also reveal that the architect of LLVM advised us to go stack-based instead of register-based for SquirrelFish
  403. # [12:12] <othermaciej> (fortunately we didn't listen)
  404. # [12:12] <roc> wow
  405. # [12:12] <othermaciej> roc: so spidermonkey was never really rearchitected from the original JavaScript implementation?
  406. # [12:13] <roc> not from scratch, no
  407. # [12:13] <roc> AFAIK
  408. # [12:13] <roc> I'm no expert
  409. # [12:14] <othermaciej> JavaScript was creaed in 1995 according to wikipedia
  410. # [12:14] <othermaciej> *created
  411. # [12:14] <roc> sounds right
  412. # [12:16] <othermaciej> I think wide, quantified knowledge of the superiority of register machines may be more recent than 1996
  413. # [12:17] <othermaciej> all the papers I have saved on the topic date to the 2000's
  414. # [12:18] <gsnedders> othermaciej: s/'// plz. :P
  415. # [12:19] <othermaciej> (oddly, v8 even though it has no bytecode and so could be argued not to be a VM, appears to have implicit stack machine semantics in the code it generates)
  416. # [12:19] <roc> well
  417. # [12:19] <doublec> regarding bufferedBytes, totalBytes, etc on the list. For Ogg files, it's easier to get values for those than buffered/duration
  418. # [12:19] <doublec> since duration requires multiple seeks
  419. # [12:20] <doublec> and getting the ranges of the buffered data requires having decoded that data
  420. # [12:20] <roc> OmniVM appeared in 1995, and it was a register VM ... e.g. http://www.w3.org/Conferences/WWW4/Papers/165/
  421. # [12:20] <gsnedders> I do like how I get on lastweekinhtml5 despite not posting to whatwg since July and public-html since September
  422. # [12:21] <gsnedders> I guess lurking here causing chaos is enough :)
  423. # [12:21] <roc> OK, it was obscure, and I mostly know about it because Steve Lucco joined the CMU faculty the same year I arrived as a grad student, and some of my friends worked on it for him
  424. # [12:22] <othermaciej> I see, it is a virtual RISC architecture
  425. # [12:22] <roc> we thought the uniform ISA was better than Java bytecodes
  426. # [12:22] <roc> registers were part of that uniformity
  427. # [12:23] <othermaciej> I guess there would have been many other hypothetical simulator-only RISC architectures though intended for pedagogy rather than deployment
  428. # [12:23] <othermaciej> indeed I recall using one in college
  429. # [12:23] <roc> it's true that there was no work done to quantify ISA design choices. Steve probably designed it that way because it was easier to target with existing C compilers
  430. # [12:24] <othermaciej> (would have been around 96 or so but I think they'd been using it a while)
  431. # [12:24] <roc> the funny thing is that Microsoft bought his company and either buried the technology, or according to some sources, put some of it in .NET
  432. # [12:24] <othermaciej> wow, I realize now that I once actually vaguely knew something about how a CPU works internally
  433. # [12:25] <othermaciej> enough that I could explain what a "pipeline hazard" was
  434. # [12:25] <roc> too bad the register design didn't make it
  435. # [12:25] <othermaciej> the only excuses I can think of for .NET to be a stack machine would be (a) to copy JVM more thoroughly and (b) if you JIT, it doesn't matter as much
  436. # [12:27] * Quits: Lachy_ (n=Lachlan@pat-tdc.opera.com) ("Leaving")
  437. # [12:27] * Joins: hdh (n=hdh@58.187.60.21)
  438. # [12:27] <othermaciej> it is interesting that the existince of JavaScript in the browser has beaten down nearly every add-on execution environment for the Web
  439. # [12:27] <othermaciej> other than Flash
  440. # [12:27] <roc> yeah
  441. # [12:27] <BenMillard> damn, I have a folder at /web/study/2008/tables/ but also want a web page at /web/study/2008/tables :(
  442. # [12:28] <roc> The bibliography for that Omniware paper is a scary flashback to a world of walking-dead wannabe execution environments
  443. # [12:28] <othermaciej> very interesting stuff
  444. # [12:28] <othermaciej> this channel is educational!
  445. # [12:29] <gsnedders> BenMillard: n00b.
  446. # [12:29] <gsnedders> othermaciej: Apart from me, I'm not.
  447. # [12:30] <MikeSmith> This channel is definitely educational.
  448. # [12:31] <BenMillard> othermaciej, our downstairs PC has the Java thing from Sun for a couple of the online word games my mum plays in IE7
  449. # [12:31] <BenMillard> gsnedders, what would you do?
  450. # [12:32] <gsnedders> BenMillard: index.html?
  451. # [12:32] <BenMillard> gsnedders, hang on I'll give you actual links
  452. # [12:32] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  453. # [12:32] <Hixie> othermaciej: re v8 having stack-based semantics... don't all c++ compilers also have stack-based semantics in that sense? or am i mixing up different concepts called "stack" here
  454. # [12:33] <othermaciej> Hixie: you are mixing up two different concepts of "stack"
  455. # [12:33] <Hixie> ah ok
  456. # [12:33] <Hixie> what's the stack in a stack vm used for then?
  457. # [12:33] <othermaciej> C/C++ compilers have a stack but access things that live on the stack by reading an offset from the stack pointer rather than with push/pop semantics, most of the time
  458. # [12:33] <roc> one thing Steve realized, and published in 1997 ( http://portal.acm.org/citation.cfm?id=349307 ), is that general-purpose compressors, plus intelligent stream splitting, applied to a nice regular data format, get much better compression than trying to design a nice "compact" format (which blows away a big chunk of the "rationale" for stack-based bytecodes)
  459. # [12:33] <othermaciej> in a stack VM, you're almost always operating on the top few items on the stack
  460. # [12:34] <othermaciej> it's like forth
  461. # [12:34] <othermaciej> if you know forth at all
  462. # [12:34] * doublec is a forth fan
  463. # [12:34] <roc> doublec is evil
  464. # [12:34] <doublec> :-)
  465. # [12:35] <othermaciej> roc: in-memory compactness might still be valuable in some cases, and you would not want to use general-purpose compression there
  466. # [12:35] <Hixie> oh you mean like if you want to add two numbers you push push add and have the result on the stack, as opposed to anything to do with recursion?
  467. # [12:35] <othermaciej> but a register bytecode can be made fairly compact too
  468. # [12:35] <othermaciej> Hixie: yeah, basically
  469. # [12:36] <Hixie> weird that v8 would do things using a stack-like approach
  470. # [12:36] <Hixie> seems counterintuitive
  471. # [12:36] <roc> Hixie: a stack-based add looks like "push 77; push 33; add; print;". Register based add looks more like 'load r0,77; load r1,33; add r2,r0,r1; print r2;"
  472. # [12:36] <Hixie> right
  473. # [12:36] <othermaciej> the SquirrelFish virtual register file is in a sense a stack too, but it's always accessed with random access rather than with push/pop/dup/etc
  474. # [12:37] <othermaciej> but it does push new frames for calls and such
  475. # [12:37] <othermaciej> register generally wins when your local variables are in registers and you operate on vars
  476. # [12:38] <roc> othermaciej: yeah, in-memory compactness might be valuable in some cases, but it's not clear what those cases are :-)
  477. # [12:38] <othermaciej> since instead of loadvar 1; loadvar2; add; print; you can just say add r3, r1, r2; print r3;
  478. # [12:38] <BenMillard> (Off-topic) Apparently this is "by design" for SmartFTP: http://www.smartftp.com/forums/UI-Preferences-Clobbered-by-Upgrade-t15546.html
  479. # [12:39] <gsnedders> BenMillard: Nothing is off-topic. Expecting anything on-topic would be logical.
  480. # [12:39] <roc> if your programs are big, you probably win by caching decompressed instruction blocks. If your programs are small, none of it matters. The sweet spot for tricky "compact" formats is somewhere in between, if indeed it exists at all
  481. # [12:40] <roc> this lesson actually applies to more than just instruction formats. I have seen far too many complex tricky "compact" data formats
  482. # [12:40] <othermaciej> clearly the Android folks did not think any compactness win from a stack VM was worth it
  483. # [12:40] <othermaciej> despite being driven so much by memory constraints
  484. # [12:40] <doublec> i got rickrolled via <video> earlier today. someone sent a link to an ogg file they said was crashing. You can guess what it was.
  485. # [12:41] <othermaciej> yeah designing a data format for compactness is almost certain to be wrong
  486. # [12:41] <roc> well
  487. # [12:41] <othermaciej> (unless it is for truly gargantuan data sets)
  488. # [12:41] <gsnedders> doublec: Don't fix video bugs :)
  489. # [12:42] <roc> another funny thing ... the RISC designers always touted their regular instruction sets as a great thing
  490. # [12:43] <roc> turns out they were wrong, and the bizarre irregular tricky "compact" x86 instruction set actually wins
  491. # [12:43] <roc> because code cache footprint matters and the horrible decode logic, in the end, doesn't matter
  492. # [12:44] <othermaciej> I think x86 might win mainly because of volume and therefore ability to apply extreme engineering resources
  493. # [12:44] <othermaciej> not because anything about the instruction set is good
  494. # [12:45] <roc> oh, absolutely
  495. # [12:45] <othermaciej> though I think the worst thing is not the tricky encoding but rather the paucity of general-purpose registers
  496. # [12:45] <roc> I just mean that the instruction set """design""" in the end turned out to be an advantage, not a disadvantage
  497. # [12:45] <othermaciej> you can just as easily devote more silicon to cache instead of decode logic
  498. # [12:46] <othermaciej> and x86_64 can often be faster just on the back of extra registers despite torturing at least your dcache (dunno enough about it to say as to icache)
  499. # [12:46] <roc> I don't think the silicon devoted to decode logic is comparable to cache
  500. # [12:47] <roc> I remember some architect talking about this. One of the pain points for x86 is decoding multiple instructions per cycle. It's hard when you don't even know where the second instruction *starts*
  501. # [12:48] <othermaciej> heh
  502. # [12:48] <roc> so they just have several decoders, which decode starting at PC, PC+1, PC+2, etc
  503. # [12:48] <othermaciej> so anyway I think ARM goes further towards compactness and yet is quite RISCy
  504. # [12:48] <roc> and they throw away the results that they don't need
  505. # [12:48] <othermaciej> wonder how fast code would go on an ARM CPU that was designed more for speed than power consumption
  506. # [12:49] <roc> oh, and only the first decoder is capable of decoding the "rare" instructions
  507. # [12:49] <othermaciej> but yes, Intel has proven that orthogonality and regularity are way overrated in an instruction set
  508. # [12:51] <othermaciej> ok I know this is even more wildly off-topic but these mccain tongue pictures are freaking me right out
  509. # [12:51] <othermaciej> did he really do that?
  510. # [12:51] <othermaciej> did anyone here watch the us presidential debate?
  511. # [12:51] * BenMillard publically acknowledges that gsnedders won the URL problem.
  512. # [12:51] * gsnedders has leet mod_rewrite skillz
  513. # [12:51] <gsnedders> but is still beaten by DrBacchus
  514. # [12:58] <gsnedders> (who wrote the book)
  515. # [13:03] * Quits: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  516. # [13:05] * Joins: mstange (n=markus@pD957A047.dip0.t-ipconnect.de)
  517. # [13:09] * Quits: webben (n=benh@nat/yahoo/x-965003ac29c5ade1)
  518. # [13:09] <Philip`> "designing a data format for compactness is almost certain to be wrong" - that's something that XML has usefully demonstrated, e.g. it's apparent you can store 3D meshes in ASCII XML files and it won't actually be totally insane, and then you can benefit from the readability and extensibility and whatnot without having to constantly worry about file size
  519. # [13:10] <roc> well
  520. # [13:10] <roc> XML would have demonstrated that, had XML not been poorly designed in other ways
  521. # [13:12] <Philip`> It demonstrates it despite being poorly designed in other ways, because people (who usually care greatly about performance) do use it for that
  522. # [13:13] <roc> in many situations, people who care about performance avoid XML and are right to do so
  523. # [13:13] * Joins: othermaciej (n=mjs@c-69-181-43-20.hsd1.ca.comcast.net)
  524. # [13:15] * Philip` is thinking of COLLADA in particular, which it seems real people do really use (and are relatively happy to do so, compared to all the other obscure proprietary binary formats and the very feature-limited sort-of-open formats)
  525. # [13:16] <gsnedders> I dislike having to write a second personal statement
  526. # [13:16] * Quits: famicom (i=famicom@5ED2F98E.cable.ziggo.nl) ("Leaving")
  527. # [13:16] <Philip`> gsnedders: That's what copy-and-paste is for
  528. # [13:17] <gsnedders> Philip`: I don't think that'll bode well when they have both
  529. # [13:17] <gsnedders> "We would be particularly interested to know what aspects of the Cambridge course attracted you to apply here."
  530. # [13:18] * Philip` doesn't remember having to write anything like that
  531. # [13:18] <Philip`> Just say "I was attracted because I love maths" and that should be fine :-)
  532. # [13:19] <gsnedders> Philip`: The application system has totally changed since last year :)
  533. # [13:22] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  534. # [13:23] * Quits: Thezilch (n=fuz007@cpe-76-171-111-7.socal.res.rr.com) (Read error: 104 (Connection reset by peer))
  535. # [13:24] <annevk3> via Lachy, http://nocleanfeed.com/ wow
  536. # [13:24] * Joins: webben (n=benh@nat/yahoo/x-2a089fb47736227d)
  537. # [13:25] * Joins: hdh0 (n=hdh@58.187.60.21)
  538. # [13:25] <Lachy> annevk3, apparently that's been around since March, but I only just heard about it today when the news hit slashdot
  539. # [13:29] * Joins: famicom (i=famicom@5ED2F98E.cable.ziggo.nl)
  540. # [13:33] <hsivonen> how is Australian Internet censorship implmented?
  541. # [13:34] <hsivonen> IIRC, Saudi censorship is in an HTTP proxy, Finnish censorship is in DNS and Chinese in routers tricking TCP
  542. # [13:35] <annevk3> that page says that it's only a plan and that the minister has not released details and that "local" experts have all said it was technically not feasible
  543. # [13:36] * othermaciej is now known as om_sleep
  544. # [13:36] <Hixie> i'm continuously baffled by people who post to lists like ac-forum or tag saying things like "we should design our standards carefully to be technically sound and architecturally solid"
  545. # [13:37] <Hixie> i mean, does anyone think we should design our standards slap dash and haphazardly without any thought given to technical design?
  546. # [13:38] <annevk3> no, but they might have the feeling that e.g. HTML5 does not meet those requirements
  547. # [13:38] <zcorpan> http://simon.html5.org/specs/html-color-attributes
  548. # [13:39] * om_sleep is now known as othermaciej
  549. # [13:39] <othermaciej> Hixie: that reminds me of a story that Darin likes to tell
  550. # [13:39] <othermaciej> back in the day when he was working at Apple in the System 7 days
  551. # [13:39] <othermaciej> he was arguing with someone else over some fine point of UI design
  552. # [13:39] <othermaciej> and the other person said:
  553. # [13:39] <Hixie> annevk3: and i might think that technologies like xmlns or xlink don't either, but that doesn't make me say "we should design specs well!" it makes me give specific technical feedback
  554. # [13:39] <othermaciej> "I don't care what you say. I'll always take the side of the user!"
  555. # [13:40] <Hixie> who else's side are you going to take?! it's the _user interface_!
  556. # [13:40] <othermaciej> (as if anyone at Apple would think - "no, I'm against the user")
  557. # [13:40] <Hixie> seriously
  558. # [13:40] <othermaciej> he calls this form of argumentation "wrapping yourself in the flag"
  559. # [13:41] <Hixie> that's quite apt
  560. # [13:41] * Quits: hdh (n=hdh@58.187.60.21) (Read error: 110 (Connection timed out))
  561. # [13:41] <mpt> Happens a lot in Free Software too
  562. # [13:41] <Hixie> there's a lot of argumentation of that method in us politics
  563. # [13:41] <mpt> "It would be better usability if..."
  564. # [13:41] <othermaciej> sometimes literally, e.g. the flag pin controversy
  565. # [13:41] <mpt> or, even more tellingly, "It would be better useability if..."
  566. # [13:41] <Hixie> hah
  567. # [13:41] <Hixie> anyway. bed time.
  568. # [13:41] <Hixie> nn
  569. # [13:42] <annevk3> Hixie, I guess they're not like you then :p
  570. # [13:42] <othermaciej> mpt: that kind of thing could be the prelude to a valid argument
  571. # [13:42] <othermaciej> or a wrong one
  572. # [13:42] <othermaciej> but at least it is an argument
  573. # [13:42] <othermaciej> rather than a claim to believe in some universal principle, implying anyone who disagrees with you does not
  574. # [13:43] <othermaciej> which is meant to shut down argument rather than further it
  575. # [13:43] <annevk3> Hixie, just trying to find some sort of explanation for what they're doing, not encouraging it; anyway, nn
  576. # [13:43] <othermaciej> so "you don't like this change? why are you against better usability?" would be a better example
  577. # [13:44] <Philip`> zcorpan: That colour parsing algorithm is insane
  578. # [13:44] <othermaciej> or "I believe everyone has the human right to access web content"
  579. # [13:44] <mpt> right
  580. # [13:44] <mpt> It's a vague bludgeon of an argument
  581. # [13:48] <annevk3> zcorpan, 4 and 5 are in the correct order?
  582. # [13:48] * othermaciej is now known as om_sleep
  583. # [13:49] * annevk3 might have asked that question before
  584. # [13:54] <takkaria> zcorpan: nice spec
  585. # [13:54] <takkaria> zcorpan: though honestly it's a bit scary if that's what browsers do
  586. # [13:56] * Quits: roc (n=roc@121-72-197-52.dsl.telstraclear.net)
  587. # [14:04] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("Leaving")
  588. # [14:09] * Parts: BenMillard (n=cerbera@cpc1-flee1-0-0-cust285.glfd.cable.ntl.com)
  589. # [14:10] * Joins: Maghnus (n=Maghnus@68-190-147-184.dhcp.eucl.wi.charter.com)
  590. # [14:17] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  591. # [14:17] * Quits: nessy (n=nessy@124-171-22-123.dyn.iinet.net.au) ("This computer has gone to sleep")
  592. # [14:19] <zcorpan> takkaria: it is what browsers do... except IE doesn't support the three-digit syntax and firefox does different things in standards mode and quirks mode
  593. # [14:19] <zcorpan> annevk3: they are
  594. # [14:19] <zcorpan> annevk3: and i think you have :)
  595. # [14:20] <zcorpan> Philip`: see topic :P
  596. # [14:23] <annevk3> i wonder why they picked this algorithm
  597. # [14:23] <annevk3> isn't there some algorithm that does the same thing but makes more sense?
  598. # [14:23] <hsivonen> interesting. Adobe ships Speex instead of AMR
  599. # [14:27] <zcorpan> annevk3: if you come up with such an algorithm, let me know :)
  600. # [14:30] <jmb> zcorpan: thanks, I now have a headache :P
  601. # [14:42] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  602. # [14:43] <zcorpan> jmb: sorry :(
  603. # [14:43] <zcorpan> annevk3: what lead to the conclusion of 50ms?
  604. # [14:44] <zcorpan> led
  605. # [14:44] <annevk3> it looked nice
  606. # [14:44] <annevk3> according to smaug
  607. # [14:44] <zcorpan> what looks nice?
  608. # [14:44] <zcorpan> a progress bar?
  609. # [14:44] <annevk3> the progress bar for a 1MiB download
  610. # [14:44] <annevk3> see #webapps logs
  611. # [14:45] <zcorpan> ok
  612. # [14:54] * Quits: eric_carlson (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  613. # [14:55] * Quits: mstange (n=markus@pD957A047.dip0.t-ipconnect.de) (Remote closed the connection)
  614. # [14:55] * Joins: mstange (n=markus@pD957A047.dip0.t-ipconnect.de)
  615. # [14:58] * Joins: hasather (n=hasather@90-231-107-133-no62.tbcn.telia.com)
  616. # [14:59] * Quits: onitunes (n=onitunes@cpe-76-87-109-106.socal.res.rr.com)
  617. # [15:32] <MikeSmith> http://www.theregister.co.uk/2008/10/16/android_kill_switch/
  618. # [15:33] <MikeSmith> "Google may discover a product that violates the developer distribution agreement ... in such an instance, Google retains the right to remotely remove those applications from your device at its sole discretion."
  619. # [15:38] <jcranmer> o_O
  620. # [15:41] <zcorpan> it seems to me that the pixelratio attribute is the same as html-level accessibility features for video
  621. # [15:41] * Quits: MikeSmith (n=MikeSmit@dhcp-247-174.mag.keio.ac.jp) ("Less talk, more pimp walk.")
  622. # [15:42] <zcorpan> although pixelratio is a lot simpler to fix than accessibility
  623. # [15:42] <zcorpan> and maybe more likely to be fixed
  624. # [15:42] <zcorpan> but perhaps it would be better to force them to be fixed in the video itself
  625. # [15:44] <zcorpan> a service to fix pixelratio of videos could also provide adding accessibility features
  626. # [15:45] <annevk3> something about tools will save us
  627. # [15:57] * Joins: csarven (n=csarven@80.76.201.52)
  628. # [16:05] * Joins: onitunes (n=onitunes@cpe-76-87-109-106.socal.res.rr.com)
  629. # [16:06] <zcorpan> annevk3: that's the argument being used about accessibility feautes, no?
  630. # [16:06] <zcorpan> practical problems with rdfa http://www.sitepoint.com/forums/showthread.php?t=577303
  631. # [16:06] <zcorpan> (how do you style it?)
  632. # [16:08] <Dashiva> Ask the XHTML2 WG to do something? That's funny
  633. # [16:08] <annevk3> zcorpan, yeah, I argued against that position yesterday
  634. # [16:09] <zcorpan> annevk3: ok. (sorry if i don't read accessibility discussions carefully :P)
  635. # [16:09] <zcorpan> (or at all)
  636. # [16:09] <annevk3> it was just on IRC, but fair enough
  637. # [16:10] <annevk3> otoh, Hixie said that without tools including e.g. subtitles in an MPEG stream on the fly was easy
  638. # [16:10] <annevk3> I don't really know enough about it myself to judge
  639. # [16:11] * Joins: Lachy_ (n=Lachlan@213.236.208.247)
  640. # [16:12] <zcorpan> i presume fixing pixelratio is easier
  641. # [16:12] <zcorpan> than writing and including subtitles
  642. # [16:12] <zcorpan> s/writing and/
  643. # [16:13] <zcorpan> s/writing and//
  644. # [16:13] <annevk3> adding bolt-on accessibility to HTML is not an easy task, no
  645. # [16:14] <zcorpan> i mean, i presume fixing the pixelratio in the video resource is easier (or just as easy) as adding subtitles
  646. # [16:14] <annevk3> no idea
  647. # [16:15] <annevk3> I don't really see why HTML needs to provide the accessibility features though
  648. # [16:15] <annevk3> people could use SMIL
  649. # [16:16] <annevk3> otoh, SMIL is fugly
  650. # [16:17] <onitunes> SMIL: from a time when XML was cool
  651. # [16:17] <onitunes> c.f. SVG
  652. # [16:17] * Joins: eric_carlson (n=ericc@17.202.33.235)
  653. # [16:21] <hsivonen> "Use SMIL" is a good solution only if browsers support it.
  654. # [16:22] <hsivonen> I'm not convinced that supporting it outside SVG would be a good use of developer time.
  655. # [16:25] <zcorpan> so how about "use SVG"?
  656. # [16:26] <zcorpan> or "use scripting and css"
  657. # [16:26] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  658. # [16:27] <hsivonen> does an SVG file map reasonably to a timeline? with scripts and all
  659. # [16:27] <hsivonen> I don't know if SVG has an easy mechanism for overlaying captions
  660. # [16:28] <hsivonen> is there a comprehensive list of W3C working groups, incubators, etc.?
  661. # [16:29] <zcorpan> i guess an SVG file would map equally well as SMIL would
  662. # [16:29] <hsivonen> zcorpan: can SMIL have JS?
  663. # [16:30] <zcorpan> hsivonen: dunno
  664. # [16:30] <annevk3> I think so
  665. # [16:31] * Quits: zcorpan (n=zcorpan@pat.se.opera.com)
  666. # [16:32] * Joins: billmason (n=billmaso@ip199.unival.com)
  667. # [16:35] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  668. # [16:35] * Joins: MikeSmith (n=MikeSmit@EM114-48-179-142.pool.e-mobile.ne.jp)
  669. # [16:36] <hsivonen> If I link to another HTML page authored by someone else, am I responsible for making it accessible?
  670. # [16:37] * Quits: Morphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
  671. # [16:40] * Joins: Morphous (i=jan@unaffiliated/amorphous)
  672. # [16:50] * Joins: aroben (n=aroben@unaffiliated/aroben)
  673. # [16:58] * Quits: MikeSmith (n=MikeSmit@EM114-48-179-142.pool.e-mobile.ne.jp) ("Less talk, more pimp walk.")
  674. # [17:03] * Joins: myakura (n=myakura@p1226-ipbf3201marunouchi.tokyo.ocn.ne.jp)
  675. # [17:14] * Joins: aaronlev__ (n=chatzill@g226208009.adsl.alicedsl.de)
  676. # [17:14] * aaronlev__ is now known as aaronlev
  677. # [17:19] * Joins: sbublava (n=stephan@77.116.119.42.wireless.dyn.drei.com)
  678. # [17:20] * Quits: aaronlev_ (n=chatzill@e180225015.adsl.alicedsl.de) (Read error: 104 (Connection reset by peer))
  679. # [17:25] * Quits: Lachy_ (n=Lachlan@213.236.208.247) ("This computer has gone to sleep")
  680. # [17:28] * myakura is glad to see the new jplayout draft published so he can now understand and possibly comment on <ruby>
  681. # [17:29] * Joins: dglazkov (n=dglazkov@nat/google/x-22389ec849502169)
  682. # [17:29] * annevk3 regrets his last e-mail, but not too much
  683. # [17:32] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  684. # [17:35] <hsivonen> myakura: I don't find a link to a public draft on the home page of the task force. Do you have a URL?
  685. # [17:37] <myakura> hsivonen: http://www.w3.org/TR/2008/WD-jlreq-20081015/ (found via the home page)
  686. # [17:37] <myakura> also congrats for media queries lc!
  687. # [17:38] * Joins: tndH (n=Rob@james-baillie-pc083-058.student-halls.leeds.ac.uk)
  688. # [17:38] <hsivonen> myakura: I see. I thought "Requirements" was something else. thanks
  689. # [17:38] <annevk3> is media queries announced yet?
  690. # [17:38] <annevk3> anyways, thanks :)
  691. # [17:38] * annevk3 goes to fetch some food
  692. # [17:41] <myakura> not sure it's annouced, though it seems it's now publicly available http://www.w3.org/TR/2008/WD-css3-mediaqueries-20081015/
  693. # [17:41] * Quits: peter-proc (n=retep@procurios.xs4all.nl) ("( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )")
  694. # [17:54] * Joins: famicom_ (i=famicom@5ED2F98E.cable.ziggo.nl)
  695. # [17:56] * Joins: virtuelv (n=virtuelv@163.80-202-65.nextgentel.com)
  696. # [18:02] * Joins: weinig_ (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net)
  697. # [18:03] * Quits: weinig_ (n=weinig@c-71-198-176-23.hsd1.ca.comcast.net) (Read error: 104 (Connection reset by peer))
  698. # [18:07] * Joins: Lachy (n=Lachlan@85.196.122.246)
  699. # [18:08] * Quits: famicom (i=famicom@5ED2F98E.cable.ziggo.nl) (Read error: 110 (Connection timed out))
  700. # [18:18] <annevk3> eric_carlson, just loop would be unimplementable
  701. # [18:19] <eric_carlson> annevk3: why?
  702. # [18:19] <annevk3> eric_carlson, way too complex
  703. # [18:20] <annevk3> actually, I should say, way too simple
  704. # [18:21] * Joins: Maurice` (n=copyman@cc90688-a.emmen1.dr.home.nl)
  705. # [18:21] <annevk3> anyways, I should go
  706. # [18:21] <Philip`> By which you mean, you should stay?
  707. # [18:22] <eric_carlson> annevk3: ah, perhaps my sarcasm filter is dysfunctional this morning
  708. # [18:38] * Joins: famicom__ (i=famicom@5ED2F98E.cable.ziggo.nl)
  709. # [18:40] * Joins: kangax (n=kangax@74.201.136.194)
  710. # [18:44] * Quits: famicom_ (i=famicom@5ED2F98E.cable.ziggo.nl) (Read error: 60 (Operation timed out))
  711. # [18:44] * Quits: sbublava (n=stephan@77.116.119.42.wireless.dyn.drei.com)
  712. # [18:45] * Quits: webben (n=benh@nat/yahoo/x-2a089fb47736227d)
  713. # [18:49] * Quits: kangax (n=kangax@74.201.136.194)
  714. # [18:49] * Quits: myakura (n=myakura@p1226-ipbf3201marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  715. # [18:49] * Joins: kangax (n=kangax@74.201.136.194)
  716. # [18:50] * Joins: myakura (n=myakura@p1226-ipbf3201marunouchi.tokyo.ocn.ne.jp)
  717. # [18:50] * Quits: myakura (n=myakura@p1226-ipbf3201marunouchi.tokyo.ocn.ne.jp) (Client Quit)
  718. # [18:56] * Joins: smedero (n=smedero@mdp-nat251.mdp.com)
  719. # [19:00] * Joins: paulymer (n=pknight@c-76-102-160-215.hsd1.ca.comcast.net)
  720. # [19:03] * Quits: mstange (n=markus@pD957A047.dip0.t-ipconnect.de) (Remote closed the connection)
  721. # [19:12] * Joins: mstange (n=markus@pD957A047.dip0.t-ipconnect.de)
  722. # [19:17] * Quits: paulymer (n=pknight@unaffiliated/paulymer)
  723. # [19:22] * Joins: ojan (n=ojan@nat/google/x-1899d588ac3b2a27)
  724. # [19:29] * Quits: famicom__ (i=famicom@5ED2F98E.cable.ziggo.nl) ("Leaving")
  725. # [19:37] * Joins: famicom (i=famicom@5ED2F98E.cable.ziggo.nl)
  726. # [19:55] * Joins: KevinMarks (n=KevinMar@nat/google/x-c8a3254810adf810)
  727. # [19:55] * Joins: weinig (n=weinig@nat/apple/x-add599bf45193909)
  728. # [19:58] <gsnedders> BenMillard: Quelle heure arrives tu?
  729. # [19:58] <gsnedders> (Does that make sense, anyone?)
  730. # [20:00] * Joins: erlehmann (n=nils@dslb-088-074-202-183.pools.arcor-ip.net)
  731. # [20:02] * Quits: sicking (n=chatzill@corp-241.mountainview.mozilla.com) (Read error: 104 (Connection reset by peer))
  732. # [20:14] * Quits: aaronlev (n=chatzill@g226208009.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  733. # [20:20] * Joins: jruderman (n=jruderma@corp-241.mountainview.mozilla.com)
  734. # [20:25] * Quits: erlehmann (n=nils@dslb-088-074-202-183.pools.arcor-ip.net)
  735. # [20:25] * Joins: aaronlev__ (n=chatzill@g226208009.adsl.alicedsl.de)
  736. # [20:25] * aaronlev__ is now known as aaronlev
  737. # [20:37] * Joins: aboodman (n=aboodman@nat/google/x-127e5efdec3e5ab4)
  738. # [20:59] * Joins: kingryan (n=ryan@c-24-5-77-167.hsd1.ca.comcast.net)
  739. # [21:08] * Quits: KevinMarks (n=KevinMar@nat/google/x-c8a3254810adf810) ("The computer fell asleep")
  740. # [21:09] * Quits: aaronlev (n=chatzill@g226208009.adsl.alicedsl.de) (Read error: 110 (Connection timed out))
  741. # [21:17] * Joins: sbublava (n=stephan@77.117.139.188.wireless.dyn.drei.com)
  742. # [21:19] * Joins: famicom_ (i=famicom@5ED2F98E.cable.ziggo.nl)
  743. # [21:26] * Joins: fishd (n=Darin@nat/google/x-c371ee024ea71467)
  744. # [21:33] * Joins: aaronlev__ (n=chatzill@g226208009.adsl.alicedsl.de)
  745. # [21:33] * aaronlev__ is now known as aaronlev
  746. # [21:36] * Quits: famicom (i=famicom@5ED2F98E.cable.ziggo.nl) (Read error: 110 (Connection timed out))
  747. # [21:38] * fakeolliej is now known as olliej
  748. # [21:44] * Joins: renke2 (n=user@Lf403.l.pppool.de)
  749. # [21:51] <Philip`> http://tech.slashdot.org/article.pl?sid=08/10/16/1325215
  750. # [21:52] <Dashiva> 'Looks good in Internet Explorer and doesn't seem to crash Firefox or Opera' is not a standard.
  751. # [21:52] <Dashiva> ^ I disagree
  752. # [21:52] <blooberry> philip`: trust the media to make blanket statements that didn't say what the original article said. 8-}
  753. # [21:55] <Philip`> blooberry: I'm happy to trust them to do that :-)
  754. # [22:02] * Quits: aaronlev (n=chatzill@g226208009.adsl.alicedsl.de) (Read error: 104 (Connection reset by peer))
  755. # [22:03] <gsnedders> Didn't Hixie have a far lower percentage?
  756. # [22:13] <blooberry> gsnedders: For validation? He didn't run validation in his main study though right? (http://code.google.com/webstats/)
  757. # [22:14] <gsnedders> blooberry: I don't think it was in his main study, but it was if anything over a bigger number of docs, and it was only looking for basic syntax errors
  758. # [22:14] <gsnedders> blooberry: But I think it was < 1% without any
  759. # [22:15] <blooberry> so, basically a well-formedness check?
  760. # [22:15] <gsnedders> Well, well-formedness doesn't exist for HTML :P
  761. # [22:15] <gsnedders> But, yeah, basically
  762. # [22:15] <blooberry> he scanned deep URLs as well as surface and there are a loooot of deep URLs. MAMA's URL set for this report was primarily DMoz and it is heavily skewed to surface URLs.
  763. # [22:21] <blooberry> he told me once that the majority of his analysis set was deep URLs by a wide margin
  764. # [22:22] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  765. # [22:25] * Joins: roc (n=roc@202.0.36.64)
  766. # [22:27] <weinig> Hixie: ping
  767. # [22:27] <Hixie> yo
  768. # [22:29] * Quits: gsnedders (n=gsnedder@lal69-1-82-67-11-148.fbx.proxad.net) ("Killin' teh intarwebs")
  769. # [22:32] <weinig> Hixie: hey, I was wondering if you had decided what to do with multifile input type=file
  770. # [22:32] <weinig> Hixie: ie. use multiple attribute perhaps
  771. # [22:32] <weinig> Hixie: min/max as per WF2
  772. # [22:32] <Hixie> i'll probably use multiple=""
  773. # [22:33] <weinig> Hixie: cool
  774. # [22:33] <Hixie> if you want to implement something, go with that, and send feedback to the list reminding me
  775. # [22:33] <weinig> Hixie: will do
  776. # [22:33] <Hixie> thanks
  777. # [22:33] <weinig> Hixie: do think it is reasonable for the UA to change the look (probably the height being the big issue) of the input when you have multiple set for file?
  778. # [22:34] <Hixie> yes
  779. # [22:34] <weinig> Hixie: great to know
  780. # [22:34] <Hixie> we'll have to standardise on something though
  781. # [22:34] * weinig nods
  782. # [22:34] <Hixie> might help to see what opera does
  783. # [22:34] <Hixie> they might have implemented type=file min/max already
  784. # [22:34] <weinig> opera uses min/max
  785. # [22:34] <weinig> and it looks just like the old control for the most part
  786. # [22:35] <Hixie> k
  787. # [22:35] <Hixie> how do they show what's selected?
  788. # [22:36] <weinig> in a quoted list (I think comma separated) where the file name would go in the single file case
  789. # [22:36] <weinig> I don't think we would implement it like that
  790. # [22:36] <weinig> as it hides a lot of data
  791. # [22:37] <Hixie> k
  792. # [22:43] * Joins: nessy (n=nessy@124-171-22-123.dyn.iinet.net.au)
  793. # [22:43] <Lachy> Opera's UI for multiple file inputs isn't very usable at all
  794. # [22:44] * Quits: sbublava (n=stephan@77.117.139.188.wireless.dyn.drei.com)
  795. # [22:53] * Joins: sicking (n=chatzill@corp-241.mountainview.mozilla.com)
  796. # [23:04] * Quits: virtuelv (n=virtuelv@163.80-202-65.nextgentel.com) (Remote closed the connection)
  797. # [23:09] * Quits: Lachy (n=Lachlan@85.196.122.246) (Read error: 104 (Connection reset by peer))
  798. # [23:09] * Joins: Lachy (n=Lachlan@85.196.122.246)
  799. # [23:17] * Quits: mstange (n=markus@pD957A047.dip0.t-ipconnect.de) ("ChatZilla 0.9.83 [Firefox 3.1b2pre/20081016020319]")
  800. # [23:19] * Joins: eric_carlson_ (n=ericc@17.244.16.64)
  801. # [23:20] * Quits: eric_carlson_ (n=ericc@17.244.16.64) (Read error: 104 (Connection reset by peer))
  802. # [23:21] * Joins: eric_carlson_ (n=ericc@17.244.16.64)
  803. # [23:21] * Quits: csarven (n=csarven@80.76.201.52) ("http://www.csarven.ca")
  804. # [23:21] * Quits: nessy (n=nessy@124-171-22-123.dyn.iinet.net.au) (Read error: 54 (Connection reset by peer))
  805. # [23:21] * Joins: nessy (n=nessy@124-171-22-123.dyn.iinet.net.au)
  806. # [23:21] * Quits: Maurice` (n=copyman@cc90688-a.emmen1.dr.home.nl) ("Disconnected...")
  807. # [23:32] * Quits: eric_carlson (n=ericc@17.202.33.235) (Read error: 110 (Connection timed out))
  808. # [23:36] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  809. # [23:38] * om_sleep is now known as othermaciej
  810. # [23:38] * Quits: WulfTheSaxon (i=meh@cpe-76-178-210-214.maine.res.rr.com) ("ChatZilla 0.9.83-rdmsoft [XULRunner 1.9.0.3/2008092417]")
  811. # [23:39] * Quits: kangax (n=kangax@74.201.136.194)
  812. # [23:40] * Quits: nessy (n=nessy@124-171-22-123.dyn.iinet.net.au) (Read error: 110 (Connection timed out))
  813. # [23:44] * Joins: webben (n=benh@91.84.226.101)
  814. # [23:52] * Joins: franksalim (n=frank@adsl-76-202-78-147.dsl.pltn13.sbcglobal.net)
  815. # [23:52] <annevk3> all cool things belong to us: http://twitter.com/Thracks/statuses/962799479
  816. # [23:53] * annevk3 also sees "HTML5 geolocation" quite often
  817. # [23:54] <roc> erm, Safari 3.1 had @font-face support
  818. # [23:55] <roc> nice demo though
  819. # [23:57] <roc> oh, those are jresig's demos, heh
  820. # Session Close: Fri Oct 17 00:00:00 2008

The end :)