/irc-logs / freenode / #whatwg / 2012-09-25 / end

Options:

  1. # Session Start: Tue Sep 25 00:00:01 2012
  2. # Session Ident: #whatwg
  3. # [00:00] * Joins: jahman (~woops@129.175.204.73)
  4. # [00:00] * Joins: Raynos_ (u3611@gateway/web/irccloud.com/x-nvuhpkxhshqchwqf)
  5. # [00:00] * Quits: zewt (~foo@ec2-50-17-220-142.compute-1.amazonaws.com) (Ping timeout: 248 seconds)
  6. # [00:00] * Quits: cabanier (~cabanier@192.150.22.55) (Ping timeout: 248 seconds)
  7. # [00:00] * Quits: astearns (~astearns@192.150.22.5) (Ping timeout: 248 seconds)
  8. # [00:00] * Quits: jernoble (~jernoble@17.212.152.13) (Ping timeout: 248 seconds)
  9. # [00:00] * Joins: Velmont (~Velmont@193.157.115.211)
  10. # [00:01] * Joins: astearns (~astearns@192.150.22.5)
  11. # [00:02] * Joins: cabanier (~cabanier@192.150.22.55)
  12. # [00:02] * Joins: jernoble (~jernoble@17.212.152.13)
  13. # [00:03] * Joins: gsnedders (~gsnedders@mail.gsnedders.com)
  14. # [00:05] * Quits: Effilry (~firefly@firefly.xen.prgmr.com) (Changing host)
  15. # [00:05] * Joins: Effilry (~firefly@oftn/member/FireFly)
  16. # [00:05] * Effilry is now known as FireFly
  17. # [00:06] * Joins: jamesr (jamesr@nat/google/x-bxmfirhzezgzgimw)
  18. # [00:08] * Quits: othermaciej (~mjs@17.244.186.180) (Quit: othermaciej)
  19. # [00:09] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Remote host closed the connection)
  20. # [00:11] * Joins: isherman (isherman@nat/google/x-fruujoalfxmuuhdn)
  21. # [00:12] * Joins: othermaciej (~mjs@17.244.186.180)
  22. # [00:13] * Quits: teleject (~christoph@72-48-145-180.static.grandenetworks.net) (Remote host closed the connection)
  23. # [00:13] * Joins: teleject (~christoph@72-48-145-180.static.grandenetworks.net)
  24. # [00:14] * Quits: dgathright (~dgathrigh@nat/yahoo/x-hoasgajrlusrmuza) (Ping timeout: 245 seconds)
  25. # [00:14] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  26. # [00:14] * Joins: dgathright (~dgathrigh@nat/yahoo/x-zminxfckbvphgfsj)
  27. # [00:15] * Quits: isherman (isherman@nat/google/x-fruujoalfxmuuhdn) (Ping timeout: 250 seconds)
  28. # [00:15] * Joins: eric_carlson_ (~eric@17.212.152.104)
  29. # [00:15] * Joins: danzik17 (~danzik17@ool-435606a9.dyn.optonline.net)
  30. # [00:17] * Joins: jmb (~jmb@mail.parsifal.org.uk)
  31. # [00:17] * Joins: toddmparker__ (u3054@gateway/web/irccloud.com/x-pofeofoevakkezvn)
  32. # [00:18] * Joins: fkm (~fkm@unaffiliated/fkm)
  33. # [00:18] * Quits: jdaggett (~jdaggett@v023209.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
  34. # [00:18] * Joins: imrobert (~robert@139.62.84.187)
  35. # [00:19] * Joins: mpt_ (~mpt@faun.canonical.com)
  36. # [00:19] * Quits: linclark (~clark@c-67-186-35-246.hsd1.pa.comcast.net) (Ping timeout: 246 seconds)
  37. # [00:19] * Quits: eric_carlson (~eric@17.212.152.104) (Ping timeout: 246 seconds)
  38. # [00:19] * Quits: danielfi_ (~danielfil@201.52.236.78) (Ping timeout: 246 seconds)
  39. # [00:19] * Quits: paul_irish (~paul_iris@ve.hsh6wjwx.vesrv.com) (Ping timeout: 246 seconds)
  40. # [00:19] * Quits: imrobert_ (~robert@139.62.84.187) (Ping timeout: 246 seconds)
  41. # [00:19] * Quits: jmb^ (~jmb@mail.parsifal.org.uk) (Ping timeout: 246 seconds)
  42. # [00:19] * Quits: toddmparker_ (u3054@gateway/web/irccloud.com/x-qtaxtmwnwbscdrbs) (Ping timeout: 246 seconds)
  43. # [00:19] * Quits: mkf (~fkm@91.214.168.160) (Ping timeout: 246 seconds)
  44. # [00:19] * Quits: Jedi_ (~Jedi@jedi.org) (Ping timeout: 246 seconds)
  45. # [00:19] * Quits: jarib (~jarib@unaffiliated/jarib) (Ping timeout: 246 seconds)
  46. # [00:19] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 246 seconds)
  47. # [00:19] * toddmparker__ is now known as toddmparker_
  48. # [00:20] * Joins: paul_irish_ (~paul_iris@ve.hsh6wjwx.vesrv.com)
  49. # [00:21] * Quits: rwaldron (~rwaldron@pool-100-2-31-210.nycmny.fios.verizon.net) (Quit: Leaving...)
  50. # [00:21] * Quits: Benvie (~brandon@cpe-174-097-187-248.nc.res.rr.com) (Ping timeout: 240 seconds)
  51. # [00:22] * Joins: jarib (~jarib@109.74.192.179)
  52. # [00:22] * Joins: Benvie (~brandon@cpe-174-097-187-248.nc.res.rr.com)
  53. # [00:22] * Joins: Jedi (~Jedi@jedi.org)
  54. # [00:22] * Joins: danielfilho (~danielfil@201.52.236.78)
  55. # [00:22] * Quits: mpt_ (~mpt@faun.canonical.com) (Changing host)
  56. # [00:22] * Joins: mpt_ (~mpt@canonical/mpt)
  57. # [00:22] * eric_carlson_ is now known as eric_carlson
  58. # [00:22] * Quits: jarib (~jarib@109.74.192.179) (Changing host)
  59. # [00:22] * Joins: jarib (~jarib@unaffiliated/jarib)
  60. # [00:23] * Jedi is now known as Guest30994
  61. # [00:23] * Quits: odinho (~odinho@office.oslo.opera.com) (Ping timeout: 240 seconds)
  62. # Session Close: Tue Sep 25 00:27:52 2012
  63. #
  64. # Session Start: Tue Sep 25 00:27:52 2012
  65. # Session Ident: #whatwg
  66. # [00:27] * Disconnected
  67. # [00:29] * Attempting to rejoin channel #whatwg
  68. # [00:29] * Rejoined channel #whatwg
  69. # [00:29] * Topic is 'WHATWG: http://www.whatwg.org/ -- logs: http://krijnhoetmer.nl/irc-logs/ & http://logbot.glob.com.au/ -- stats: http://gavinsharp.com/irc/whatwg.html -- Please leave your sense of logic at the door, thanks!'
  70. # [00:29] * Set by smaug____!~chatzilla@GGZYYCCCXVIII.gprs.sl-laajakaista.fi on Wed Mar 21 17:14:24
  71. # [00:29] * Quits: foolip__ (~philip@node-7lfb9kgvc8zh2d4g8.a0.ipv6.opera.com) (Ping timeout: 245 seconds)
  72. # [00:29] <TabAtkins> Because the BinaryData proposal from tc39 was too slow, and WebGL just went with the simplest thing possible.
  73. # [00:29] * Joins: foolip__ (~philip@node-7lfb9kgvc8zh2d4g8.a0.ipv6.opera.com)
  74. # [00:30] * Joins: globbot (~logbot@lump.glob.com.au)
  75. # [00:30] * Joins: ciluu (~ciluu@2a01:270:201f::cafe)
  76. # [00:30] <SamB_MacG5> well, it is certainly simple
  77. # [00:34] <zewt_> it should have been a lot simpler, heh
  78. # [00:34] * Quits: NimeshNeema (u2689@gateway/web/irccloud.com/x-vmfzffsyegxrgxjr) (Max SendQ exceeded)
  79. # [00:34] * zewt_ is now known as zewt
  80. # [00:34] * Quits: ukai_ (ukai@nat/google/x-buqecrpjxzzwkbfi) (Ping timeout: 268 seconds)
  81. # [00:35] * Quits: jryans (~jryans@office.massrel.com) (Quit: Be back later)
  82. # [00:36] * Joins: NimeshNeema (u2689@gateway/web/irccloud.com/x-gfdlfcagpvryrvtw)
  83. # [00:36] * Quits: sicking (~chatzilla@nat/mozilla/x-qfdxauhyhwjupzce) (Ping timeout: 245 seconds)
  84. # [00:37] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  85. # [00:37] * SamB_MacG5 supposes Python doesn't have any such facility for arrays either, come to think of it ...
  86. # [00:38] * Joins: sicking (~chatzilla@nat/mozilla/x-tzktabtllnhypoco)
  87. # [00:38] * Quits: tndrH (~Rob@cpc4-seac20-2-0-cust858.7-2.cable.virginmedia.com) (Ping timeout: 256 seconds)
  88. # [00:41] * Quits: KevinMarks2 (~KevinMark@24-104-73-2-ip-static.hfc.comcastbusiness.net) (Quit: The computer fell asleep)
  89. # [00:41] * Joins: KevinMarks2 (~KevinMark@24-104-73-2-ip-static.hfc.comcastbusiness.net)
  90. # [00:45] * Quits: rniwa (rniwa@nat/google/x-fzxyaixubmgyzmgi) (Quit: rniwa)
  91. # [00:45] * Joins: rniwa (rniwa@nat/google/x-rabodkmwusrjkkwm)
  92. # [00:46] * Quits: tomasf (~tom@c-44dbe555.024-204-6c6b7012.cust.bredbandsbolaget.se) (Quit: tomasf)
  93. # [00:46] * Quits: KevinMarks2 (~KevinMark@24-104-73-2-ip-static.hfc.comcastbusiness.net) (Client Quit)
  94. # [00:46] * Joins: KevinMarks2 (~KevinMark@24-104-73-2-ip-static.hfc.comcastbusiness.net)
  95. # [00:49] * Joins: isherman (isherman@nat/google/x-flauxwszxivlwpqd)
  96. # [00:50] * Joins: Dashimon (Dashiva@84-72-44-85.dclient.hispeed.ch)
  97. # [00:50] * Quits: Dashimon (Dashiva@84-72-44-85.dclient.hispeed.ch) (Changing host)
  98. # [00:50] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  99. # [00:51] * Quits: KevinMarks2 (~KevinMark@24-104-73-2-ip-static.hfc.comcastbusiness.net) (Ping timeout: 252 seconds)
  100. # [00:53] * Joins: annevk_ (~annevk@a82-161-179-17.adsl.xs4all.nl)
  101. # [00:53] <annevk_> http://lists.w3.org/Archives/Public/uri/2012Sep/0002.html kind of an IETF-centric definition of obsolete there
  102. # [00:53] <annevk_> I was using it in the broad sense, in case anyone cares
  103. # [00:53] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 256 seconds)
  104. # [00:53] * Dashimon is now known as Dashiva
  105. # [00:53] <annevk_> And is someone still subscribed to www-tag?
  106. # [00:54] <annevk_> It appears they are confused about where the URL Standard is located...
  107. # [00:55] * Quits: sedovsek (~robert@89.142.241.54) (Quit: sedovsek)
  108. # [00:56] * Joins: eric_carlson_ (~eric@2620:149:4:1b01:395f:654c:542d:87c0)
  109. # [00:56] <SamB_MacG5> zewt: on the other hand, if it was more complicated that might mean less bikeshedding ;-P
  110. # [00:56] * Quits: annevk (~annevk@a82-161-179-17.adsl.xs4all.nl) (Ping timeout: 256 seconds)
  111. # [00:56] * Joins: danielfi_ (~danielfil@201.52.236.78)
  112. # [00:59] <zewt> don't know that there's much bikeshedding on that api (though i havn't been following webgl-dev for a couple months)
  113. # [01:00] * Joins: ukai_ (ukai@nat/google/x-iboyzvabqlstgnvv)
  114. # [01:01] * Quits: eric_carlson (~eric@17.212.152.104) (Ping timeout: 399 seconds)
  115. # [01:01] * Quits: Martijnc (~Martijn@nishino.lvp-media.com) (Ping timeout: 408 seconds)
  116. # [01:01] * eric_carlson_ is now known as eric_carlson
  117. # [01:01] * Joins: Martijnc (~Martijn@nishino.lvp-media.com)
  118. # [01:01] * Quits: dgathright (~dgathrigh@nat/yahoo/x-zminxfckbvphgfsj) (Ping timeout: 248 seconds)
  119. # [01:02] * Quits: danielfilho (~danielfil@201.52.236.78) (Ping timeout: 241 seconds)
  120. # [01:02] * Quits: othermaciej (~mjs@17.244.186.180) (Ping timeout: 241 seconds)
  121. # [01:03] * Quits: necolas (~necolas@8.25.194.28) (Remote host closed the connection)
  122. # [01:04] * Quits: fkm (~fkm@unaffiliated/fkm) (Quit: Bye)
  123. # [01:05] * Joins: fkm (~fkm@unaffiliated/fkm)
  124. # [01:08] * Joins: othermaciej (~mjs@17.245.111.37)
  125. # [01:09] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Remote host closed the connection)
  126. # [01:11] * Joins: jryans (~jryans@173-96-133-106.pools.spcsdns.net)
  127. # [01:12] * Joins: toddmparker__ (u3054@gateway/web/irccloud.com/x-sbfctzsrceomolsu)
  128. # [01:12] * Quits: toddmparker_ (u3054@gateway/web/irccloud.com/x-pofeofoevakkezvn) (Ping timeout: 252 seconds)
  129. # [01:12] * Quits: jmb (~jmb@mail.parsifal.org.uk) (Ping timeout: 252 seconds)
  130. # [01:12] * toddmparker__ is now known as toddmparker_
  131. # [01:12] * Joins: jmb^ (~jmb@mail.parsifal.org.uk)
  132. # [01:13] * Joins: dgathright (~dgathrigh@nat/yahoo/x-manvellrmbaxkxpk)
  133. # [01:14] * Quits: jryans (~jryans@173-96-133-106.pools.spcsdns.net) (Client Quit)
  134. # [01:15] * Quits: dgathright (~dgathrigh@nat/yahoo/x-manvellrmbaxkxpk) (Remote host closed the connection)
  135. # [01:16] * Joins: dgathright (~dgathrigh@nat/yahoo/x-exqmdczgfbanigog)
  136. # [01:20] * heycam|away is now known as heycam
  137. # [01:22] * Quits: Martijnc (~Martijn@nishino.lvp-media.com) (Ping timeout: 267 seconds)
  138. # [01:22] * Quits: [tm] (~MikeSmith@sideshowbarker.net) (Ping timeout: 267 seconds)
  139. # [01:22] * Joins: [tm] (~MikeSmith@sideshowbarker.net)
  140. # [01:22] * Joins: Martijnc (~Martijn@nishino.lvp-media.com)
  141. # [01:27] * Quits: ehsan (~ehsan@66.207.208.98) (Remote host closed the connection)
  142. # [01:27] * Quits: fkm (~fkm@unaffiliated/fkm) (Quit: Bye)
  143. # [01:28] * Joins: danielf__ (~danielfil@187.31.77.7)
  144. # [01:28] * Joins: fkm (~fkm@unaffiliated/fkm)
  145. # [01:29] * Joins: nessy (~silviapf@124-168-3-236.dyn.iinet.net.au)
  146. # [01:31] * Joins: nw_ (nw@kapsi.fi)
  147. # [01:31] * Joins: odinho_ (odinho@dalvik.ping.uio.no)
  148. # [01:31] * Joins: jmb (~jmb@mail.parsifal.org.uk)
  149. # [01:32] * Quits: ukai_ (ukai@nat/google/x-iboyzvabqlstgnvv) (Ping timeout: 248 seconds)
  150. # [01:32] * Quits: Velmont (~Velmont@193.157.115.211) (Ping timeout: 248 seconds)
  151. # [01:32] * Quits: danielfilho|w (~danielfil@187.31.77.7) (Ping timeout: 248 seconds)
  152. # [01:32] * Quits: jmb^ (~jmb@mail.parsifal.org.uk) (Ping timeout: 248 seconds)
  153. # [01:32] * Quits: odinho (~odinho@office.oslo.opera.com) (Ping timeout: 248 seconds)
  154. # [01:32] * Quits: nw (nw@kapsi.fi) (Ping timeout: 248 seconds)
  155. # [01:32] * Joins: odinho (~odinho@office.oslo.opera.com)
  156. # [01:38] * jernoble is now known as jernoble|afk
  157. # [01:38] * jernoble|afk is now known as jernoble
  158. # [01:38] * Quits: jernoble (~jernoble@17.212.152.13) (Remote host closed the connection)
  159. # [01:41] * Joins: krijn_ (u2319@gateway/web/irccloud.com/x-gkzyxtfmcobrscny)
  160. # [01:41] * Quits: stalled (~stalled@unaffiliated/stalled) (Ping timeout: 272 seconds)
  161. # [01:41] * Quits: krijn (u2319@gateway/web/irccloud.com/x-tafxbduxymbcegqv) (Ping timeout: 272 seconds)
  162. # [01:41] * krijn_ is now known as krijn
  163. # [01:44] * Joins: stalled (~stalled@unaffiliated/stalled)
  164. # [01:45] * Joins: lokling_ (~quassel@quassel.woboq.de)
  165. # [01:46] * Joins: jernoble (~jernoble@17.212.152.13)
  166. # [01:47] * Quits: lokling (~quassel@quassel.woboq.de) (Write error: Broken pipe)
  167. # [01:47] * Quits: tzik_ (~tzik@2401:fa00:4:1004:baac:6fff:fe99:85ab) (Remote host closed the connection)
  168. # [01:47] * Joins: tzik_ (~tzik@2401:fa00:4:1004:baac:6fff:fe99:85ab)
  169. # [01:48] * Quits: teleject (~christoph@72-48-145-180.static.grandenetworks.net) (Ping timeout: 264 seconds)
  170. # [01:50] * Joins: pablof (~pablof@144.189.150.130)
  171. # [01:55] * Joins: ukai_ (ukai@nat/google/x-fdrjtfkprelrczdc)
  172. # [01:58] * Joins: jondong (~jondong@123.126.22.58)
  173. # [01:59] * jondong is now known as Guest21870
  174. # [01:59] * Quits: drublic (~drublic@frbg-5f733b13.pool.mediaWays.net) (Remote host closed the connection)
  175. # [01:59] * Joins: tzik__ (~tzik@2401:fa00:4:1004:baac:6fff:fe99:85ab)
  176. # [02:00] * Quits: tzik_ (~tzik@2401:fa00:4:1004:baac:6fff:fe99:85ab) (Write error: Broken pipe)
  177. # [02:02] <jamesr_> Hixie_, so you've decided to let the UA pick a resolution however it likes for canvas 2d?
  178. # [02:02] <TabAtkins> That was the intent all along.
  179. # [02:03] <jamesr_> fwiw my thinking is that we'll always set this to 1 regardless of the display's properties. setting it to anything else is too problematic
  180. # [02:04] <zewt> jamesr: what problems are there that the addition of toDataURLHD and toBlobHD don't fix?
  181. # [02:04] <jamesr_> weird that it's tied to a task
  182. # [02:04] <jamesr_> and not the element (although all options here are weird)
  183. # [02:04] <Hixie_> jamesr_: webkit already picks higher res backing resolutions, at least for safari
  184. # [02:04] <Hixie_> jamesr_: are there any new problems that aren't handled?
  185. # [02:04] <jamesr_> safari on desktop does. chrome and mobilesafari don't
  186. # [02:05] * Quits: smaug____ (~chatzilla@cs181151161.pp.htv.fi) (Ping timeout: 264 seconds)
  187. # [02:06] * Joins: linclark (~clark@c-67-186-35-246.hsd1.pa.comcast.net)
  188. # [02:06] <Hixie_> jamesr_: well not ever using higher res backing stores is a non-starter.
  189. # [02:07] <Hixie_> jamesr_: but if there are problems not currently addressed, please do mention them on the list
  190. # [02:07] <jamesr_> how do you mean?
  191. # [02:07] <TabAtkins> Hixie_: I'll be separately encouraging our implementation to name the function ellipseTo when we implement it.
  192. # [02:07] <jamesr_> Hixie_, we currently set the backing store to whatever the width/height attributes are set to. seems to work out fine
  193. # [02:07] <Hixie_> jamesr_: i mean, retina macbook pros look ugly as hell on chrome
  194. # [02:08] <jamesr_> depends on the content
  195. # [02:08] <Hixie_> when they have canvases
  196. # [02:08] <Hixie_> TabAtkins: i'll be encouraging us not to implement the more complicated path syntax too :-P
  197. # [02:09] * Hixie_ really does think it's a terrible design choice to be doing this
  198. # [02:10] * Quits: rniwa (rniwa@nat/google/x-rabodkmwusrjkkwm) (Quit: rniwa)
  199. # [02:13] <TabAtkins> You don't seem to understand how much people hate A/a.
  200. # [02:13] <TabAtkins> They're *horrible* API for most use-cases.
  201. # [02:14] <TabAtkins> Anyway, your encouragement won't do much, since it's Dirk who'll be doing it for us. ^_^
  202. # [02:14] <Hixie_> i have no trouble understanding that A/a is bad
  203. # [02:14] <Hixie_> i have no trouble with the idea of adding new ways of doinh arcs
  204. # [02:15] * Quits: dgathright (~dgathrigh@nat/yahoo/x-exqmdczgfbanigog) (Quit: dgathright)
  205. # [02:15] <Hixie_> my problem is with this idea of adding new names for each command
  206. # [02:15] <Hixie_> or adding any names that aren't short one-letter names
  207. # [02:16] <TabAtkins> There are no reasonable letters left for new arc commands.
  208. # [02:17] * Quits: mattgifford (~mattgiffo@70.102.199.158) (Remote host closed the connection)
  209. # [02:17] <TabAtkins> I mean, the fact that a smooth quadratic uses T shows that we're out of reasonable letters already. ^_^
  210. # [02:17] <Hixie_> i don't understand the concern
  211. # [02:18] * Joins: mattgifford (~mattgiffo@70.102.199.158)
  212. # [02:18] <Hixie_> why does it matter what the letters are?
  213. # [02:18] <Hixie_> you just find a mnemonic and go with it
  214. # [02:18] <Hixie_> e.g. E for ellipse
  215. # [02:18] * Quits: mattgifford (~mattgiffo@70.102.199.158) (Read error: Connection reset by peer)
  216. # [02:18] <TabAtkins> ?_? You're asserting that we should continue with the practice of adding single-letter command names. I'm claiming that there are no reasonable single-letter names for those commands.
  217. # [02:18] <Hixie_> or R for rounded corner
  218. # [02:19] <Hixie_> or O for circle
  219. # [02:19] <Hixie_> or V for curVe
  220. # [02:19] <Hixie_> you don't double the size of a language because of lack of imagination
  221. # [02:19] <TabAtkins> Separately, I assert that the single-letter names are stupid. Syntax minimization at its worst.
  222. # [02:19] <Hixie_> that's fine, but that boat sailed years ago
  223. # [02:20] <TabAtkins> Yup, and it's returned, and we're changing the rigging on it now.
  224. # [02:20] <Hixie_> this is bad language design
  225. # [02:20] <Hixie_> if you're gonna start adding replacement features for everything SVG screwed up, you're gonna end up with the world's most confusing language
  226. # [02:20] <Hixie_> adding features doesn't simplify
  227. # [02:20] <TabAtkins> It's consistent with the names of the subpath *elements* we're adding.
  228. # [02:20] <Hixie_> it only makes things worse
  229. # [02:20] <Hixie_> oh god, you're adding elements too?
  230. # [02:20] <TabAtkins> I understand that you think that. I agree some of the time.
  231. # [02:21] * Quits: cabanier (~cabanier@192.150.22.55) (Quit: Leaving.)
  232. # [02:23] * Joins: teleject (~christoph@cpe-70-112-210-24.austin.res.rr.com)
  233. # [02:24] * Joins: rwaldron (~rwaldron@pool-100-2-31-210.nycmny.fios.verizon.net)
  234. # [02:27] * Quits: othermaciej (~mjs@17.245.111.37) (Quit: othermaciej)
  235. # [02:29] * Quits: danzik17 (~danzik17@ool-435606a9.dyn.optonline.net) (Ping timeout: 264 seconds)
  236. # [02:36] * Quits: sicking (~chatzilla@nat/mozilla/x-tzktabtllnhypoco) (Ping timeout: 265 seconds)
  237. # [02:37] <Hixie_> TabAtkins: why is it not true here?
  238. # [02:37] * Hixie_ is now known as Hixie
  239. # [02:39] * Quits: ap (~ap@2620:149:4:1b01:2505:2e8e:f435:d46) (Quit: ap)
  240. # [02:41] * Quits: jsbell (jsbell@nat/google/x-jnnqzlmjdexdgais) (Quit: There's no place like home...)
  241. # [02:42] * Joins: sicking (~chatzilla@nat/mozilla/x-cafgrgqxlahpxgsn)
  242. # [02:43] * Quits: sicking (~chatzilla@nat/mozilla/x-cafgrgqxlahpxgsn) (Client Quit)
  243. # [02:43] * Joins: sicking (~chatzilla@nat/mozilla/x-wkqqggcowheppynr)
  244. # [02:48] * Quits: jernoble (~jernoble@17.212.152.13) (Quit: Textual IRC Client: www.textualapp.com)
  245. # [02:49] <jamesr_> TabAtkins, y u n l c s?
  246. # [02:52] * Quits: jamesr_ (jamesr@nat/google/x-apwpjhxwwicyrzix) (Quit: Ex-Chat)
  247. # [02:57] * Quits: linclark (~clark@c-67-186-35-246.hsd1.pa.comcast.net) (Quit: linclark)
  248. # [02:59] * Quits: pablof (~pablof@144.189.150.130) (Quit: ^z)
  249. # [02:59] * Quits: typeclassy (~user@ool-ae2ceba4.dyn.optonline.net) (Remote host closed the connection)
  250. # [03:07] * abstractj|away is now known as abstractj
  251. # [03:14] * Joins: jacobolus (~jacobolus@ip-64-134-230-253.public.wayport.net)
  252. # [03:19] * Quits: teleject (~christoph@cpe-70-112-210-24.austin.res.rr.com) (Remote host closed the connection)
  253. # [03:19] * Joins: teleject (~christoph@cpe-70-112-210-24.austin.res.rr.com)
  254. # [03:27] * Joins: rniwa (rniwa@nat/google/x-ktegyicpijfkkbxv)
  255. # [03:35] * Joins: ehsan (~ehsan@24-212-206-174.cable.teksavvy.com)
  256. # [03:40] <TabAtkins> Hixie: Consistency is a virtue, but not an absolute one. One must balance it against the benefits of whatever is breaking consistency. Also, being consistent with the future and pushing the past to the side can mitigate a lot of the pain of inconsistency.
  257. # [03:40] <TabAtkins> Basically, it's just an error to reject something solely because it's inconsistent with the present.
  258. # [03:43] * SamB_MacG5 wonders why http://dev.w3.org/html5/spec/the-canvas-element.html#the-canvas-element suggests XBL as somehow being something you could use ...
  259. # [03:43] <TabAtkins> It was written a while ago.
  260. # [03:43] <Hixie> TabAtkins: i'm not talking about being consistent, though, i'm talking about adding redundant features
  261. # [03:44] <TabAtkins> Redundancy is fine! Redundancy can be author-friendly.
  262. # [03:45] <Hixie> if you're starting from that assumption, i think it's unlikely we'll agree :-)
  263. # [03:45] <TabAtkins> I think it is obviously untrue that redundancy is an absolute bad.
  264. # [03:46] <TabAtkins> And when there is a choice between redundancy and inconsistency, redundancy should probably win.
  265. # [03:47] <Hixie> i think following that line of reasoning would easily double the API surface of the web
  266. # [03:47] <Hixie> which imho is _clearly_ a negative
  267. # [03:48] <TabAtkins> It would only double if you're adding redundant version of everything.
  268. # [03:48] <TabAtkins> Increasing the surface area of the web by 20% or so, in return for making shitty legacy things more consistent with the more glorious future, is a cost I'm willing to pay.
  269. # [03:48] * Joins: danzik17 (~danzik17@ool-435606a9.dyn.optonline.net)
  270. # [03:49] <Hixie> but it doesn't make the old features more consistent with the future -- it makes a new feature consistent with the feature, while also keeping the old inconsistent features
  271. # [03:49] <Hixie> (and given how we don't know what the future is, it's unclear that one can be consistent with it)
  272. # [03:49] <TabAtkins> Yes? We can't get rid of the old features, and twisting the future to be consistent with them just produces something horrible.
  273. # [03:51] * Quits: jamesr (jamesr@nat/google/x-bxmfirhzezgzgimw) (Quit: jamesr)
  274. # [03:52] * abstractj is now known as abstractj|away
  275. # [03:52] * Quits: rniwa (rniwa@nat/google/x-ktegyicpijfkkbxv) (Quit: rniwa)
  276. # [03:52] <Hixie> having old+newold+new is worse than old+new (where newold = the new redundant feature)
  277. # [03:52] <Hixie> because basically the more you have, the more complicated it is, the harder it is to teach, to write tutorials, to test, to spec, to implement, to learn, etc
  278. # [03:53] <Hixie> it's arguable whether a new feature that isn't consistent with a bad old feature is better or worse than being consistent, given the cost of inconsistency, but that's a case-by-case thing
  279. # [03:59] * Quits: jwalden (~waldo@2620:101:8003:200:2c2e:54a2:9ec8:3bcb) (Quit: ChatZilla 0.9.87-5.1450hg.fc17 [XULRunner 15.0/20120827125645])
  280. # [04:00] * Quits: SamB_MacG5 (~samb_macg@207-172-123-137.c3-0.upd-ubr1.trpr-upd.pa.cable.rcn.com) (Remote host closed the connection)
  281. # [04:04] * Joins: cabanier (~cabanier@c-98-237-137-173.hsd1.wa.comcast.net)
  282. # [04:04] * Joins: SamB_MacG5 (~samb_macg@207-172-123-137.c3-0.upd-ubr1.trpr-upd.pa.cable.rcn.com)
  283. # [04:06] * Joins: yutak (~yutak@2401:fa00:4:1004:baac:6fff:fe99:adfb)
  284. # [04:08] * Quits: jacobolus (~jacobolus@ip-64-134-230-253.public.wayport.net) (Remote host closed the connection)
  285. # [04:09] * Quits: SamB_MacG5 (~samb_macg@207-172-123-137.c3-0.upd-ubr1.trpr-upd.pa.cable.rcn.com) (Remote host closed the connection)
  286. # [04:09] * Joins: SamB_MacG5 (~samb_macg@207-172-123-137.c3-0.upd-ubr1.trpr-upd.pa.cable.rcn.com)
  287. # [04:15] * Quits: nessy (~silviapf@124-168-3-236.dyn.iinet.net.au) (Quit: Leaving.)
  288. # [04:15] * Quits: sicking (~chatzilla@nat/mozilla/x-wkqqggcowheppynr) (Ping timeout: 252 seconds)
  289. # [04:16] * Joins: plutoniix (~plutoniix@node-84n.pool-101-108.dynamic.totbb.net)
  290. # [04:18] * Quits: BennyLava (~colin@pdpc/supporter/professional/riven) (Read error: Connection reset by peer)
  291. # [04:18] * Joins: BennyLava (~colin@53518387.cm-6-2c.dynamic.ziggo.nl)
  292. # [04:18] * Quits: BennyLava (~colin@53518387.cm-6-2c.dynamic.ziggo.nl) (Changing host)
  293. # [04:18] * Joins: BennyLava (~colin@pdpc/supporter/professional/riven)
  294. # [04:23] * Joins: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net)
  295. # [04:25] * Joins: Druide_ (~Druid@p5B1363B3.dip.t-dialin.net)
  296. # [04:26] * Joins: j_wright (~jwright@ip70-180-205-15.lv.lv.cox.net)
  297. # [04:38] * Quits: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net) (Quit: jamesr)
  298. # [04:55] * Joins: nessy (silviapf@nat/google/x-uiohdviotxvuubsh)
  299. # [04:59] * Joins: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net)
  300. # [05:08] * Joins: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net)
  301. # [05:08] * Quits: plutoniix (~plutoniix@node-84n.pool-101-108.dynamic.totbb.net) (Ping timeout: 265 seconds)
  302. # [05:10] * Joins: eric_carlson_ (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  303. # [05:14] * Quits: victrola` (~decadance@69.73.175.77) (Remote host closed the connection)
  304. # [05:19] * Quits: adlwalrus (~j@111.192.205.76) (Ping timeout: 256 seconds)
  305. # [05:29] * Joins: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net)
  306. # [05:36] <Hixie> othermaciej: htmlwg question -- if i notice an htmlwg bug that might be valid has been marked invalid without any comment (no boilerplate, rationale, etc), is this something anyone cares about that i should raise somewhere? i don't personally care but if i notice it and there's something trivial i can do to help, i'm happy to do so
  307. # [05:37] * Quits: eric_carlson_ (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Quit: eric_carlson_)
  308. # [05:39] * Quits: rwaldron (~rwaldron@pool-100-2-31-210.nycmny.fios.verizon.net) (Quit: Leaving...)
  309. # [05:40] * Quits: ImBcmDth_ (~Jon@pool-173-63-154-183.nwrknj.fios.verizon.net) (Ping timeout: 245 seconds)
  310. # [05:40] <othermaciej> Hixie: if you point such bugs out to an editor and/or a chair, it would be helpful
  311. # [05:41] <Hixie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18223 https://www.w3.org/Bugs/Public/show_bug.cgi?id=16512 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=16022
  312. # [05:41] <Hixie> (fyi, see also https://www.w3.org/Bugs/Public/show_bug.cgi?id=15042 )
  313. # [05:41] <Hixie> othermaciej: ^
  314. # [05:42] <othermaciej> I don't understand how to interpret "how do you set up the tracks in the html?" as spec feedback
  315. # [05:42] <othermaciej> if you understand what it means, I would appreciate if you could add a clarifying comment
  316. # [05:42] <Hixie> i presume it's asking for examples of <track>
  317. # [05:42] <othermaciej> likewise "I first saw this code suggested by Jeremy Keith in his excellent book ‘HTML5
  318. # [05:42] <othermaciej> For Web Designers’ ("
  319. # [05:43] <othermaciej> is it? it might be asking for an example, or the person might be confused, or they might think there is a bug with <track>
  320. # [05:43] <Hixie> well like i said, "might be"
  321. # [05:43] <Hixie> not saying they are :-)
  322. # [05:43] <othermaciej> what about the one citing Jeremy Keith?
  323. # [05:43] <Hixie> yeah that one is less clear
  324. # [05:43] <othermaciej> what does that mean?
  325. # [05:44] <Hixie> dunno. probably cut off. seemed likely to be an intentional question, though, not just invalid
  326. # [05:44] <othermaciej> seems invalid to me, or needs info at best
  327. # [05:44] <Hixie> oh definitely isn't directly actionable
  328. # [05:44] <othermaciej> I personally feel that one is of the same status as "asdfgh asdfgh"
  329. # [05:45] <Hixie> k
  330. # [05:45] <othermaciej> in that it does not even suggest either a problem with the spec or a proposed change
  331. # [05:45] <othermaciej> for 16022, I also am not really sure what it means
  332. # [05:45] <othermaciej> do you understand what it is saying?
  333. # [05:45] <Hixie> haven't studied it closely enough
  334. # [05:46] <Hixie> but if someone filed it and is watching the bug, it seems polite to ask for more info rather than just closing it without following the process :-)
  335. # [05:46] <othermaciej> I find myself unable to parse it
  336. # [05:46] <Hixie> given that the bug system is the w3c's main feedback mechanism
  337. # [05:46] <Hixie> it's like with the whatwg list, i promise replies to all feedback on the spec, even nonsensical feedback
  338. # [05:47] <othermaciej> the HTML WG policy is that INVALID may be applied if "Bug is obvious junk or spam. Or, originator decides upon reconsideration that the comment is wrong. Does not require a full Editor's response."
  339. # [05:47] <othermaciej> NEEDSINFO is "Additional information is required to accept or reject this comment. Editor's response required. Editor should be clear on what additional info is required. It is strongly recommended that bug reporters should provide the requested additional information, if the request is reasonable, before they consider escalating."
  340. # [05:47] <othermaciej> I would consider either acceptable for those three bugs
  341. # [05:48] <Hixie> i guess my definition of "junk" is less wide than yours :-)
  342. # [05:48] <othermaciej> as the required info would be "please clearly state a problem with the spec or identify a suggested change"
  343. # [05:48] <Hixie> (as editor i basically didn't mark any invalid, iirc)
  344. # [05:48] <Hixie> (so i was a bit surprised to see it being used)
  345. # [05:50] <othermaciej> I don't think your recollection is correct
  346. # [05:50] <othermaciej> I found 183 bugs in the "HTML5 spec" component that were marked INVALID while you were editor
  347. # [05:50] <Hixie> any of them marked that way by me?
  348. # [05:50] <Hixie> without boilerplate?
  349. # [05:51] <othermaciej> that's harder to do a quick query for
  350. # [05:52] <othermaciej> I see many marked as such by the editorial assistants or by Msg2er
  351. # [05:52] <othermaciej> in random sampling
  352. # [05:52] <Hixie> (search within that set for bugs closed by me, then search again for bugs closed by me with the boilerplate, and subtract the counts, that should do it. not that you need to bother :-) )
  353. # [05:53] <othermaciej> I can't readily search for bugs closed without the boilerplate
  354. # [05:53] <Hixie> right, search for them all, then with it
  355. # [05:53] <Hixie> the difference is those without
  356. # [05:54] <Hixie> (if you wanted the actual bugs, you could grab the IDs from the second set and list them as IDs to exclude in the first search, or something)
  357. # [05:54] <Hixie> (but that's getting messy)
  358. # [05:54] <othermaciej> point being, it has been accepted process that bugs which do not appear to state an issue and instead appear to be a copy/paste error, random typing, a non-bug question, or the like can be resolved w/o boilerplate
  359. # [05:54] <Hixie> anyway, it's no big deal
  360. # [05:54] <Hixie> k
  361. # [05:54] <othermaciej> I'm willing to believe you never personally used INVALID since I can't find any counter-examples
  362. # [05:55] <Hixie> the fourth one was a separate thing, just fyi. https://www.w3.org/Bugs/Public/show_bug.cgi?id=15042
  363. # [05:55] <Hixie> hopefully it'll solve itself.
  364. # [05:55] <othermaciej> it does seem to me the test suite bug you cited was probably wrongly closed, but the spec bug rules don't apply there and I have not followed test suite development, so I am not in a good position to comment further
  365. # [05:55] <Hixie> yeah i wasn't saying that one was part of the same issue.
  366. # [05:56] <Hixie> just making sure you had it on your radar.
  367. # [05:56] <Hixie> more in your role as webkit guy than htmlwg guy.
  368. # [05:56] <othermaciej> ok
  369. # [05:57] <othermaciej> it does seem necessary to figure out the answer to what toDataURL does for hi-res backing stores
  370. # [05:57] <Hixie> the whatwg spec is clear on that topic
  371. # [05:57] <othermaciej> perhaps it needs the "HD" treatment like getImageData and putImageData
  372. # [05:57] <Hixie> it has had that treatment in the whatwg spec.
  373. # [05:57] <othermaciej> ah, ok
  374. # [05:57] <Hixie> this is one of the areas where tho two specs have forked.
  375. # [05:57] <othermaciej> I believe our canvas implementors are tracking the whatwg spec more than the htmlwg spec on this
  376. # [05:58] <Hixie> yeah, i expect everyone but microsoft is in that boat.
  377. # [05:58] <othermaciej> it would be nice if the w3c version was at least not contrary to the high-res-compatible edition
  378. # [05:58] <Hixie> (sadly it was microsoft people who wontfixed the bug)
  379. # [05:58] <Hixie> agreed
  380. # [05:59] <othermaciej> is the canvas toBlob method a fork point?
  381. # [05:59] <Hixie> dunno
  382. # [05:59] <othermaciej> (wondering if toBlobHD or toBlob is the fork, to determine if this same issue applies)
  383. # [05:59] <Hixie> i'm guessing it's all the HD stuff
  384. # [05:59] <Hixie> i think we had toBlob long ago
  385. # [05:59] <Hixie> i definitely didn't add toBlob at the same time as the HD stuff
  386. # [06:00] <Hixie> the HD stuff is relatively new
  387. # [06:00] <Hixie> (in response to safari feedback, mainly)
  388. # [06:00] <othermaciej> yes, I'm aware, and I'm glad it was added
  389. # [06:00] <othermaciej> as you can see, all of Apple's product line is moving to 2x displays
  390. # [06:00] <othermaciej> so we got to be the first ones to test how the old spec worked in the face of 1x-only-tested content
  391. # [06:00] <Hixie> yeah
  392. # [06:01] <Hixie> (love the retina macbook btw)
  393. # [06:01] <othermaciej> I wish I had one, trying to order them for my engineers first though
  394. # [06:03] <Hixie> yeah, i don't have one personally, but i got one for my partner
  395. # [06:05] * Joins: jacobolus (~jacobolus@76.91.212.21)
  396. # [06:07] * Quits: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net) (Quit: jamesr)
  397. # [06:07] * heycam is now known as heycam|away
  398. # [06:12] <Hixie> in other news, man, w3c bugzilla is being slow today
  399. # [06:12] <Hixie> keep getting 502s
  400. # [06:13] <othermaciej> me too :-(
  401. # [06:18] * Joins: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net)
  402. # [06:29] * Joins: kennyluck (~kennyluck@119.161.158.96)
  403. # [06:36] * Guest30994 is now known as Jedi_
  404. # [06:37] * Joins: auchenberg (~auchenber@176.222.239.226)
  405. # [06:39] * Joins: eric_carlson_ (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  406. # [06:41] * Quits: auchenberg (~auchenber@176.222.239.226) (Ping timeout: 256 seconds)
  407. # [06:52] * SamB_MacG5 is surprised to discover that he is in the XSL or XQuery working group
  408. # [06:52] <SamB_MacG5> (well, that's what bugzilla thinks, anyway!)
  409. # [07:02] <othermaciej> Hixie: why did you move this bug to the whatwg product? https://www.w3.org/Bugs/Public/show_bug.cgi?id=10912
  410. # [07:02] <othermaciej> Hixie: are you going to back-clone it?
  411. # [07:03] <othermaciej> (HTML WG needs copies of resolved bugs in our product to be able to provide a record of responses to comments)
  412. # [07:08] * Joins: snowfox_ben (~benschaaf@c-98-243-88-119.hsd1.mi.comcast.net)
  413. # [07:08] * Joins: ImBcmDth (~Jon@pool-71-127-243-30.nwrknj.fios.verizon.net)
  414. # [07:13] <nessy> it's happening to many bugs - looks like all of the ones that were resolved later...
  415. # [07:15] * Joins: adlwalrus (~j@111.192.205.76)
  416. # [07:16] <kennyluck> Can we have a QA contact (a mailing list) for all bugs in the WHATWG component? I'd like to subscribe to that list.
  417. # [07:19] * Quits: danzik17 (~danzik17@ool-435606a9.dyn.optonline.net) (Ping timeout: 246 seconds)
  418. # [07:23] * Quits: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net) (Quit: jamesr)
  419. # [07:30] * Parts: adlwalrus (~j@111.192.205.76)
  420. # [07:36] * Joins: niloy (~niloy@61.12.96.242)
  421. # [07:42] * Quits: eric_carlson_ (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Quit: eric_carlson_)
  422. # [07:50] * Joins: maikmerten (~merten@ls5dhcp200.cs.uni-dortmund.de)
  423. # [07:50] * Joins: Martin_L (~Martin_L@194.18.12.26)
  424. # [07:51] * heycam|away is now known as heycam
  425. # [07:57] <Hixie> othermaciej: oh, didn't realise you wanted the closed ones also. i moved all the bugs assigned to me that were marked LATER to the WHATWG component.
  426. # [07:57] <Hixie> othermaciej: so i wouln't lose them.
  427. # [07:59] * Joins: silverroots (~silverroo@144.187.148.25)
  428. # [08:00] <Hixie> othermaciej: there have been many bugs that get reassigned to other components, e.g. HTML.next, rather than get resolved, fwiw. so i don't know that it's possible to make such a list currently.
  429. # [08:00] <Hixie> kennyluck: contributor@whatwg.org should be that, iirc
  430. # [08:00] <Hixie> kennyluck: just follow that
  431. # [08:00] <othermaciej> Hixie: can you clone them in one direction or another please?
  432. # [08:01] <Hixie> othermaciej: yeah, send me a mail to remind me
  433. # [08:01] <kennyluck> Hixie, how to? Is that a mailing list?
  434. # [08:01] <Hixie> should be easy enough to set up my script to do that
  435. # [08:01] <Hixie> kennyluck: in bugzilla, you should be able to set your account to follow that one
  436. # [08:01] <kennyluck> oh, you mean Bugzilla following?
  437. # [08:01] <Hixie> https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
  438. # [08:01] <Hixie> yeah
  439. # [08:02] <Hixie> gotta go, bbl
  440. # [08:08] * Joins: zcorpan (~zcorpan@81-231-170-159-no135.tbcn.telia.com)
  441. # [08:35] * Quits: malcolmva (~malcolmva@c-67-180-203-233.hsd1.ca.comcast.net) (Ping timeout: 246 seconds)
  442. # [08:42] * Joins: PalleZingmark (~Adium@217.13.228.226)
  443. # [08:48] * Joins: SimonSapin (~simon@ip-222.net-80-236-80.issy.rev.numericable.fr)
  444. # [08:52] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  445. # [09:01] * Joins: drublic (~drublic@frbg-4d028f07.pool.mediaWays.net)
  446. # [09:09] * heycam is now known as heycam|away
  447. # [09:12] * Quits: tzik__ (~tzik@2401:fa00:4:1004:baac:6fff:fe99:85ab) (Read error: Connection reset by peer)
  448. # [09:14] * Joins: richt (~richt@c-7b67e555.155-2-64736c16.cust.bredbandsbolaget.se)
  449. # [09:15] * Quits: JohnAlbin_zzzzzz (~JohnAlbin@114-36-33-26.dynamic.hinet.net) (Quit: HTTP/1.1 404 JohnAlbin Not Found)
  450. # [09:23] * Quits: shepazu (~shepazu@108-70-132-46.lightspeed.rlghnc.sbcglobal.net) (Read error: Connection reset by peer)
  451. # [09:27] * Joins: auchenberg (~auchenber@176.222.239.226)
  452. # [09:28] <jgraham> othermaciej: BTW your more minimal filesystem API looks nicer than the Google one, but it does seem like one would quickly end up with a "pyramid of doom" if every single file operation needs to be in its own callback
  453. # [09:29] * Joins: tndrH (~Rob@cpc4-seac20-2-0-cust858.7-2.cable.virginmedia.com)
  454. # [09:34] * Joins: darobin (~darobin@spintank2-160-134.cnt.nerim.net)
  455. # [09:37] * Joins: Ms2ger (~Ms2ger@91.181.95.180)
  456. # [09:40] * Joins: victor2 (~Adium@did75-14-82-236-18-74.fbx.proxad.net)
  457. # [09:40] * Parts: victor2 (~Adium@did75-14-82-236-18-74.fbx.proxad.net)
  458. # [09:43] * Quits: drublic (~drublic@frbg-4d028f07.pool.mediaWays.net) (Remote host closed the connection)
  459. # [09:43] * Joins: drublic (~drublic@frbg-4d028f07.pool.mediaWays.net)
  460. # [09:46] * Joins: tzik__ (~tzik@2401:fa00:4:1004:baac:6fff:fe99:85ab)
  461. # [09:48] * Quits: drublic (~drublic@frbg-4d028f07.pool.mediaWays.net) (Ping timeout: 276 seconds)
  462. # [09:54] * Joins: henrikkok (~henrikkok@81.27.221.193)
  463. # [09:54] * Joins: sedovsek (~robert@89.143.12.238)
  464. # [09:58] * Quits: PalleZingmark (~Adium@217.13.228.226) (Quit: Leaving.)
  465. # [10:00] * Quits: espadrine (~thaddee_t@85-218-9-34.dclient.lsne.ch) (Ping timeout: 272 seconds)
  466. # [10:00] * Joins: drublic (~drublic@p5098a42b.dip0.t-ipconnect.de)
  467. # [10:01] <jgraham> othermaciej: In addition I am worried that we have added, or attempted to add, 3 local storage mechanisms in the last 5 years, and our record of doing it well isn't that great
  468. # [10:02] <jgraham> (localStorage, WebSQL, IndexedDB)
  469. # [10:02] * Joins: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net)
  470. # [10:04] <jgraham> (so the platform total, including WebSQL, is 4 of which 3 are already known to be various degrees of broken)
  471. # [10:05] <SimonSapin> jgraham: which is the not-known-broken one?
  472. # [10:08] <jgraham> IndexedDB
  473. # [10:08] <Ms2ger> That one's just hated, right?
  474. # [10:08] <jgraham> By no one uses that yet
  475. # [10:09] <jgraham> So we probably haven't worked out why it is broken yet
  476. # [10:09] <jgraham> Hence I am worried about adding a new storage API before we even work out what the problems that need to be fixed with the previous one are
  477. # [10:10] <jgraham> (I suspect "callback hell" is one of the problems, and I don't think the filesystem API proposals address that)
  478. # [10:10] * Quits: silverroots (~silverroo@144.187.148.25) (Read error: Connection reset by peer)
  479. # [10:11] * Joins: silverroots (~silverroo@144.187.180.13)
  480. # [10:12] * Joins: Druide__ (~Druid@p5B135C26.dip.t-dialin.net)
  481. # [10:13] * Quits: Druide_ (~Druid@p5B1363B3.dip.t-dialin.net) (Ping timeout: 265 seconds)
  482. # [10:19] * Joins: smaug____ (~chatzilla@cs181151161.pp.htv.fi)
  483. # [10:19] * Quits: nessy (silviapf@nat/google/x-uiohdviotxvuubsh) (Quit: Leaving.)
  484. # [10:23] * Quits: SimonSapin (~simon@ip-222.net-80-236-80.issy.rev.numericable.fr) (Read error: Connection reset by peer)
  485. # [10:25] * Joins: charlvn (~charlvn@charlvn.nl)
  486. # [10:25] * Joins: PalleZingmark (~Adium@217.13.228.226)
  487. # [10:26] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Remote host closed the connection)
  488. # [10:37] * Quits: j_wright (~jwright@ip70-180-205-15.lv.lv.cox.net) (Ping timeout: 256 seconds)
  489. # [10:39] * Joins: Smylers (~smylers@62.249.246.74)
  490. # [10:44] * Zauberfisch_ is now known as Zauberfisch
  491. # [10:50] * Joins: nonge_ (~nonge@p5082A372.dip.t-dialin.net)
  492. # [10:52] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  493. # [10:54] * Quits: nonge (~nonge@p5082AA22.dip.t-dialin.net) (Ping timeout: 268 seconds)
  494. # [11:01] * Quits: Ms2ger (~Ms2ger@91.181.95.180) (Quit: bbl)
  495. # [11:02] * Joins: SimonSapin (~simon@2a01:e35:2e8d:b5f0:24ef:db19:73df:6e01)
  496. # [11:03] * Quits: jacobolus (~jacobolus@76.91.212.21) (Remote host closed the connection)
  497. # [11:03] * Joins: jacobolus (~jacobolus@76.91.212.21)
  498. # [11:06] <eighty4> Any ideas on http://www.netmagazine.com/features/truth-about-structuring-html5-page ?
  499. # [11:11] <zcorpan> TabAtkins: maybe you should ask what the svg wg think about multiple-letter commands before discussing it in whatwg :-)
  500. # [11:11] * Quits: Benvie (~brandon@cpe-174-097-187-248.nc.res.rr.com) (*.net *.split)
  501. # [11:12] * Quits: ajpiano (~ajpiano@li98-57.members.linode.com) (*.net *.split)
  502. # [11:12] * Quits: dsheets (~Adium@c-67-180-11-170.hsd1.ca.comcast.net) (*.net *.split)
  503. # [11:12] * Quits: vidu (u5404@gateway/web/irccloud.com/x-fmtfpbutvqckhmqu) (*.net *.split)
  504. # [11:12] * Joins: ajpiano (~ajpiano@li98-57.members.linode.com)
  505. # [11:12] * Joins: Benvie (~brandon@cpe-174-097-187-248.nc.res.rr.com)
  506. # [11:12] * Joins: dsheets (~Adium@c-67-180-11-170.hsd1.ca.comcast.net)
  507. # [11:16] * Quits: dsheets (~Adium@c-67-180-11-170.hsd1.ca.comcast.net) (Ping timeout: 250 seconds)
  508. # [11:17] * Quits: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net) (Quit: rniwa)
  509. # [11:26] <annevk_> eighty4: hard to argue with the truth
  510. # [11:26] <eighty4> annevk_: i.e. we shouldn't use the new html5 elements?
  511. # [11:27] * Joins: vidu (u5404@gateway/web/irccloud.com/session)
  512. # [11:27] * annevk_ was mocking the title
  513. # [11:27] <hsivonen> the outline algorithm is ill-clothed as long as there’s no selector for selecting by outline depth
  514. # [11:27] <eighty4> ...
  515. # [11:27] * annevk_ is now known as annevk
  516. # [11:27] * eighty4 is to stupid to get jokes just before lunch
  517. # [11:28] <annevk> eighty4: I stopped caring about semantics a while ago, so these days whenever people ask me I just tell them to use what works best for them
  518. # [11:28] <annevk> eighty4: I personally use <nav> and such as it's nicer than <div id=nav>, if some people prefer the latter, that's cool too
  519. # [11:29] * Joins: isherman-book (~Adium@173-167-102-230-sfba.hfc.comcastbusiness.net)
  520. # [11:29] <eighty4> annevk: I've been finding <header> and such in the same way
  521. # [11:29] <eighty4> makes my html cleaner and easier to maintain imo
  522. # [11:29] <hsivonen> Re: semantics: https://twitter.com/glazou/status/250516174473920512
  523. # [11:31] <annevk> eighty4: exactly, and in a decade from now or so someone will do a new study towards what people are doing and how markup is practiced and the definitions in the specification will be adjusted accordingly
  524. # [11:32] <eighty4> ah well. Back to figuring out how to move things around in this comment form I guess. Seems more important.
  525. # [11:32] <annevk> eighty4: just like the HTML4 element definitions have been adjusted (e.g. for <dl>)
  526. # [11:32] <jgraham> eighty4: I read a little bit of that article and found it was wrong on matters of fact, so I gave up and stopped reading
  527. # [11:33] <jgraham> If the facts taht you are using to support your opinion are fabrications, there's probably very little value in your opinions
  528. # [11:33] <annevk> hsivonen: that's "asshole" per pilgrim classification, no?
  529. # [11:33] <eighty4> jgraham: if anything you should point that out. Seems a shame if people read it and believe it :)
  530. # [11:33] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
  531. # [11:34] <annevk> if people believe stuff they read online they might be in for some surprises down the road :)
  532. # [11:34] <jgraham> eighty4: If I pointed it out every time some clueless or malicious web developer used incorrect assertions to write controversial articles in the name of publicity I wouldn't have any time to do anything else
  533. # [11:34] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  534. # [11:34] <eighty4> annevk: lol
  535. # [11:35] <hsivonen> but see http://epubsecrets.com/ibooks-the-latest-epub-3-0-reader.php
  536. # [11:35] <eighty4> jgraham: meh!
  537. # [11:35] <annevk> eighty4: also, it's important to conserve one's energy http://xkcd.com/386/
  538. # [11:35] <eighty4> jgraham: (swedish for me not having a response but thinking you should do it anyways)
  539. # [11:36] * Joins: jarib (~jarib@unaffiliated/jarib)
  540. # [11:36] <eighty4> annevk: I love that one. I live by it :)
  541. # [11:36] <annevk> I like to think I learned from it :p
  542. # [11:36] <eighty4> I never learn
  543. # [11:38] <eighty4> ah well, when I have the time I'll read som of the responses to the post. Should be fun
  544. # [11:41] <annevk> eighty4: you'll learn, might take a long time, mind you; I think I've done it for over half a decade at least with regards to standards discussions
  545. # [11:42] <annevk> and actually, I still do: http://krijnhoetmer.nl/irc-logs/whatwg/20120925#l-101 I just no longer bother sending email :)
  546. # [11:42] * Quits: smaug____ (~chatzilla@cs181151161.pp.htv.fi) (Ping timeout: 252 seconds)
  547. # [11:43] <eighty4> annevk: In truth I do get better. I've stopped arguing with trolls :)
  548. # [11:44] <eighty4> annevk: that log is from a couple of hours back :D
  549. # [11:45] * Quits: teleject (~christoph@cpe-70-112-210-24.austin.res.rr.com) (Read error: Connection reset by peer)
  550. # [11:46] * Joins: teleject (~christoph@cpe-70-112-210-24.austin.res.rr.com)
  551. # [11:53] * Quits: jacobolus (~jacobolus@76.91.212.21) (Remote host closed the connection)
  552. # [12:00] * abstractj|away is now known as abstractj
  553. # [12:07] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Connection reset by peer)
  554. # [12:08] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  555. # [12:18] * Quits: isherman-book (~Adium@173-167-102-230-sfba.hfc.comcastbusiness.net) (Quit: Leaving.)
  556. # [12:19] * Quits: Martin_L (~Martin_L@194.18.12.26) (Ping timeout: 248 seconds)
  557. # [12:21] * Joins: plutoniix (~plutoniix@node-19v3.pool-125-24.dynamic.totbb.net)
  558. # [12:23] * Quits: vidu (u5404@gateway/web/irccloud.com/session) (Changing host)
  559. # [12:23] * Joins: vidu (u5404@gateway/web/irccloud.com/x-khxsffaqgcyduaab)
  560. # [12:24] * Quits: plutoniix (~plutoniix@node-19v3.pool-125-24.dynamic.totbb.net) (Read error: Connection reset by peer)
  561. # [12:26] * Joins: jacobolus (~jacobolus@76.91.212.21)
  562. # [12:26] * Joins: plutoniix (~plutoniix@node-19v3.pool-125-24.dynamic.totbb.net)
  563. # [12:29] * abstractj is now known as abstractj|coffee
  564. # [12:34] * Quits: Guest21870 (~jondong@123.126.22.58) (Remote host closed the connection)
  565. # [12:34] * abstractj|coffee is now known as abstractj
  566. # [12:42] * Joins: isherman-book (~Adium@173-167-102-230-sfba.hfc.comcastbusiness.net)
  567. # [12:42] * Quits: isherman-book (~Adium@173-167-102-230-sfba.hfc.comcastbusiness.net) (Client Quit)
  568. # [12:46] <jgraham> hsivonen: Do you really want to encourage the W3C to have big monolithic releases where all known issues have to be fixed?
  569. # [12:49] * Joins: j_wright (~jwright@ip70-180-205-15.lv.lv.cox.net)
  570. # [12:49] * Joins: shwetank (~shwetank@pat-tazdevil.opera.com)
  571. # [12:51] <hsivonen> jgraham: no. they can drop stuff from snapshots instead of fixing: http://w3cmemes.tumblr.com/post/31865121758/the-joker-shares-his-approach-on-css2-1-issues
  572. # [12:51] * Quits: jacobolus (~jacobolus@76.91.212.21) (Quit: Leaving...)
  573. # [12:52] <hsivonen> jgraham: I don't want Microsoft to create a new doc mode that implements stuff that others won't be able to implement across modes
  574. # [12:52] * Quits: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com) (Read error: Connection reset by peer)
  575. # [12:52] <hsivonen> jgraham: and I don't want to deflect n00b requests to implement the bogus REC in Gecko
  576. # [12:53] <jgraham> I don't want the navigation algorithm to be replaced by "now do magic stuff" just for fear that Microsoft might otherwise add in a mode that implements it
  577. # [12:54] <jgraham> In fact I don't think that's practically possible
  578. # [12:55] <hsivonen> jgraham: the W3C REC could say “do magic” and WHATWG and W3C ED’s could try to say something more precise
  579. # [12:55] <eighty4> annevk: ok, I know I shouldn't care but the authors html is kind of horrible :)
  580. # [12:55] <jgraham> In this specific case I don't see how that would work without undefining a bunch of stuff
  581. # [12:55] <eighty4> www.truthabouthtml5.com really isn't nice html
  582. # [12:55] <annevk> noobs caring about the navigation algorithm? not sure that would ever happen
  583. # [12:56] <jgraham> I mean, navigation spreads its tentacles all over the spec
  584. # [12:57] <hsivonen> eighty4: oh was the article trolling for attention in order to sell a book? ok.
  585. # [12:57] <eighty4> hsivonen: I would imagine so, given that the article seems taken from the book.
  586. # [12:58] <jgraham> hsivonen: I would much prefer that the W3C moved to a model where we got releases say every 6 months, and there was an understanding that the spec might not be bug-free
  587. # [12:58] <jgraham> Seems like the closest thing to a living standard that could be fig-leafed as process
  588. # [13:02] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  589. # [13:03] * Quits: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com) (Read error: Connection reset by peer)
  590. # [13:03] * Joins: adactio_ (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  591. # [13:06] * Quits: sedovsek (~robert@89.143.12.238) (Quit: sedovsek)
  592. # [13:08] * Joins: nessy (~silviapf@124-168-3-236.dyn.iinet.net.au)
  593. # [13:13] * Joins: [[zzz]] (~q@node-rrx.pool-180-180.dynamic.totbb.net)
  594. # [13:15] * Quits: imrobert (~robert@139.62.84.187) (Ping timeout: 240 seconds)
  595. # [13:17] * Quits: [[zz]] (~q@node-z9c.pool-180-180.dynamic.totbb.net) (Ping timeout: 264 seconds)
  596. # [13:34] * Quits: kennyluck (~kennyluck@119.161.158.96) (Quit: kennyluck)
  597. # [13:38] * Joins: sedovsek (~robert@89.143.12.238)
  598. # [13:39] * Quits: shwetank (~shwetank@pat-tazdevil.opera.com) (Quit: Leaving...)
  599. # [13:41] * abstractj is now known as abstractj|away
  600. # [13:42] * Joins: eric_carlson_ (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  601. # [13:45] * Joins: shwetank (~shwetank@pat-tazdevil.opera.com)
  602. # [13:46] * Joins: linclark (~clark@c-67-186-35-246.hsd1.pa.comcast.net)
  603. # [13:51] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Remote host closed the connection)
  604. # [13:51] * Quits: adactio_ (~adactio@host213-123-197-180.in-addr.btopenworld.com) (Quit: adactio_)
  605. # [13:56] * Joins: teleject_ (~christoph@cpe-70-112-210-24.austin.res.rr.com)
  606. # [13:57] * Quits: sedovsek (~robert@89.143.12.238) (Quit: sedovsek)
  607. # [13:57] * Joins: sedovsek (~robert@89.143.12.238)
  608. # [14:00] * Quits: teleject (~christoph@cpe-70-112-210-24.austin.res.rr.com) (Ping timeout: 246 seconds)
  609. # [14:01] * Quits: teleject_ (~christoph@cpe-70-112-210-24.austin.res.rr.com) (Ping timeout: 252 seconds)
  610. # [14:05] * Quits: shwetank (~shwetank@pat-tazdevil.opera.com) (Quit: Leaving...)
  611. # [14:07] * Joins: shwetank (~shwetank@pat-tazdevil.opera.com)
  612. # [14:09] * Quits: eric_carlson_ (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Quit: eric_carlson_)
  613. # [14:22] * Quits: Zauberfisch (~Zauberfis@2a01:4f8:100:73c3::3) (Read error: Connection reset by peer)
  614. # [14:23] * Joins: Zauberfisch (~Zauberfis@2a01:4f8:100:73c3::3)
  615. # [14:31] <zcorpan> i've moved this to a separate file so other specs can use it: http://dvcs.w3.org/hg/quirks-mode/raw-file/tip/status-warning.js
  616. # [14:32] * Quits: snowfox_ben (~benschaaf@c-98-243-88-119.hsd1.mi.comcast.net) (Quit: snowfox_ben)
  617. # [14:32] <zcorpan> (see http://dvcs.w3.org/hg/quirks-mode/raw-file/tip/Overview.src.html for how it looks)
  618. # [14:35] * [[zzz]] is now known as [[zz]]
  619. # [14:44] * abstractj|away is now known as abstractj
  620. # [14:46] * Joins: teleject (~christoph@72-48-145-180.static.grandenetworks.net)
  621. # [14:47] * Quits: teleject (~christoph@72-48-145-180.static.grandenetworks.net) (Remote host closed the connection)
  622. # [14:48] * Joins: teleject (~christoph@72-48-145-180.static.grandenetworks.net)
  623. # [14:48] * Quits: teleject (~christoph@72-48-145-180.static.grandenetworks.net) (Remote host closed the connection)
  624. # [14:53] * Quits: nessy (~silviapf@124-168-3-236.dyn.iinet.net.au) (Quit: Leaving.)
  625. # [15:01] * Joins: krawchyk (~krawchyk@65.220.49.251)
  626. # [15:01] * Joins: izhak (~izhak@188.244.176.232)
  627. # [15:03] * Joins: JohnAlbin (~JohnAlbin@111-250-144-93.dynamic.hinet.net)
  628. # [15:10] * Joins: thisgeek (~chris@ool-45757782.dyn.optonline.net)
  629. # [15:15] * Quits: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net) (Quit: tomasf)
  630. # [15:17] * Quits: shwetank (~shwetank@pat-tazdevil.opera.com) (Quit: Leaving...)
  631. # [15:18] * Quits: plutoniix (~plutoniix@node-19v3.pool-125-24.dynamic.totbb.net) (Quit: จรลี จรลา)
  632. # [15:18] * Joins: shwetank (~shwetank@pat-tazdevil.opera.com)
  633. # [15:25] * Joins: snowfox_ben (~benschaaf@50-77-199-197-static.hfc.comcastbusiness.net)
  634. # [15:30] * Joins: MacTed (~Thud@63.119.36.36)
  635. # [15:32] * Joins: smaug____ (~chatzilla@cs181151161.pp.htv.fi)
  636. # [15:36] * lokling_ is now known as lokling
  637. # [15:47] * Joins: danzik17 (~danzik17@164.55.254.106)
  638. # [15:49] * Quits: ehsan (~ehsan@24-212-206-174.cable.teksavvy.com) (Remote host closed the connection)
  639. # [15:50] * Joins: tomasf (~tomasf@static-88.131.62.36.addr.tdcsong.se)
  640. # [15:50] * Quits: tomasf (~tomasf@static-88.131.62.36.addr.tdcsong.se) (Client Quit)
  641. # [15:50] * Joins: tomasf (~tomasf@static-88.131.62.36.addr.tdcsong.se)
  642. # [15:51] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  643. # [15:51] * Joins: ehsan (~ehsan@24-212-206-174.cable.teksavvy.com)
  644. # [15:55] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Read error: Operation timed out)
  645. # [15:57] * Quits: danielfi_ (~danielfil@201.52.236.78) (Remote host closed the connection)
  646. # [15:57] * Joins: scor (~scor@132.183.243.214)
  647. # [15:57] * Quits: scor (~scor@132.183.243.214) (Changing host)
  648. # [15:57] * Joins: scor (~scor@drupal.org/user/52142/view)
  649. # [15:59] * Joins: erichynds (~ehynds@64.206.121.41)
  650. # [16:00] * Joins: rwaldron (~rwaldron@pool-100-2-31-210.nycmny.fios.verizon.net)
  651. # [16:01] * Quits: PalleZingmark (~Adium@217.13.228.226) (Quit: Leaving.)
  652. # [16:02] * Joins: garciawebdev (~garciaweb@190.244.76.14)
  653. # [16:02] * mpt_ is now known as mpt
  654. # [16:09] * Quits: ehsan (~ehsan@24-212-206-174.cable.teksavvy.com) (Remote host closed the connection)
  655. # [16:14] * Quits: silverroots (~silverroo@144.187.180.13) (Ping timeout: 265 seconds)
  656. # [16:14] <annevk> who the fuck cares about .mobi anyway?
  657. # [16:15] <darobin> .mobi is still around?
  658. # [16:16] <annevk> it was awkward when I ran into some people from Vodaphone couple of years after I published http://annevankesteren.nl/2004/12/mobi-stld and they recalled what I wrote
  659. # [16:17] <darobin> I reckon they're used to that :)
  660. # [16:18] * Joins: imrobert (~robert@139.62.84.187)
  661. # [16:22] <hsivonen> what’s the spec for window.screen?
  662. # [16:22] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  663. # [16:24] <smaug____> paul_irish: looks like robohornet does something odd with testharness, which causes tests to test something else than what is actually expected. https://github.com/robohornet/robohornet/issues/66
  664. # [16:25] <hsivonen> I miss zcorpan’s .mobi site that served a single-pixel GIF
  665. # [16:25] * Joins: rworth (~rworth@209-255-211-4.ip.mcleodusa.net)
  666. # [16:25] <zcorpan> hsivonen: i let the domain expire
  667. # [16:25] * Joins: miketaylr (~miketaylr@cpe-70-112-101-224.austin.res.rr.com)
  668. # [16:26] * Joins: Ms2ger (~Ms2ger@kotnet-146.kulnet.kuleuven.be)
  669. # [16:28] * Joins: mattgifford (~mattgiffo@108.161.20.199)
  670. # [16:29] <annevk> Ms2ger: was just looking into merging that fix from hasather
  671. # [16:29] <Ms2ger> Too late ;)
  672. # [16:29] <annevk> guess we can now declare hosting specs on github a "great success"
  673. # [16:29] <odinho> and everyone had cake and was happy :-)
  674. # [16:29] <Ms2ger> Did someone change the case of whatwg again?
  675. # [16:31] * Ms2ger mumbles about unnecessary merges
  676. # [16:31] <annevk> Ms2ger: my bad
  677. # [16:31] <Ms2ger> Hmm? No, github's bad :)
  678. # [16:31] <annevk> Ms2ger: well I renamed back to /whatwg
  679. # [16:31] <Ms2ger> Oh
  680. # [16:32] * Joins: yodasw16 (~yodasw16@ql1fwhide.rockfin.com)
  681. # [16:32] <Ms2ger> Keep it that way now? :)
  682. # [16:32] <annevk> but quite a while ago
  683. # [16:32] <annevk> yes
  684. # [16:33] <zewt> heh i read .mobi as the kindle ebook format
  685. # [16:33] * Quits: smaug____ (~chatzilla@cs181151161.pp.htv.fi) (Read error: Connection reset by peer)
  686. # [16:33] * Joins: WolfieZero (~WolfieZer@87.124.34.32)
  687. # [16:33] * Quits: WolfieZero (~WolfieZer@87.124.34.32) (Client Quit)
  688. # [16:33] * Joins: smaug____ (~chatzilla@cs181151161.pp.htv.fi)
  689. # [16:34] <annevk> hsivonen: window.screen is in CSSOM View (at least when I worked on that)
  690. # [16:40] * Quits: zcorpan (~zcorpan@81-231-170-159-no135.tbcn.telia.com) (Remote host closed the connection)
  691. # [16:40] <zewt> google's search result stats must get pretty nastily broken for ED/TR results
  692. # [16:40] * Joins: zcorpan (~zcorpan@81-231-170-159-no135.tbcn.telia.com)
  693. # [16:40] <zewt> -ED
  694. # [16:42] <zewt> since invariably the TR gets returned and i can't quickly find the ED in the results, so i click the TR result then click through to the ED--presumably making google thing the TR is what I wanted, making it even more likely to be at the top
  695. # [16:42] * Quits: zcorpan (~zcorpan@81-231-170-159-no135.tbcn.telia.com) (Remote host closed the connection)
  696. # [16:44] * Joins: ehsan (~ehsan@66.207.208.98)
  697. # [16:46] * Quits: izhak (~izhak@188.244.176.232) (Remote host closed the connection)
  698. # [16:49] * Joins: izhak (~izhak@188.244.176.232)
  699. # [16:51] * JohnAlbin is now known as JohnAlbin_food
  700. # [16:52] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  701. # [16:52] * danielf__ is now known as danielfilho|w
  702. # [16:53] * Quits: miketaylr (~miketaylr@cpe-70-112-101-224.austin.res.rr.com) (Quit: dflk;adfslkj;alsiekfj;laiskdf)
  703. # [16:58] <annevk> whoa, Opera and Chrome accept http://017700000001/
  704. # [16:59] <annevk> http://www.amazon.com/The-Tangled-Web-Securing-Applications/dp/1593273886 is pretty interesting
  705. # [16:59] <zewt> octal, one of those things which are utterly useless yet somehow refuse to die
  706. # [17:00] <zewt> heh https://twitter.com/ID_AA_Carmack/status/243125862403297281
  707. # [17:02] <othermaciej> jgraham: doesn't the Google one also require a callback for each operation?
  708. # [17:02] <othermaciej> jgraham: (other than when using the sync API in a Worker)
  709. # [17:03] * Quits: vincent_ (~woops@87-231-117-240.rev.numericable.fr) (Read error: Connection reset by peer)
  710. # [17:08] * Quits: smaug____ (~chatzilla@cs181151161.pp.htv.fi) (Quit: ChatZilla 0.9.89 [Firefox 18.0a1/20120923200442])
  711. # [17:09] * Joins: smaug____ (~chatzilla@cs181151161.pp.htv.fi)
  712. # [17:09] * Quits: maikmerten (~merten@ls5dhcp200.cs.uni-dortmund.de) (Remote host closed the connection)
  713. # [17:19] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
  714. # [17:21] <annevk> zewt: the problem is more that IPv4 is only allowed to be written as DEC.DEC.DEC.DEC
  715. # [17:24] * Quits: richt (~richt@c-7b67e555.155-2-64736c16.cust.bredbandsbolaget.se) (Remote host closed the connection)
  716. # [17:25] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
  717. # [17:26] * Joins: jarib (~jarib@unaffiliated/jarib)
  718. # [17:32] * jtcranme1 is now known as jtcranmer
  719. # [17:33] * Quits: cabanier (~cabanier@c-98-237-137-173.hsd1.wa.comcast.net) (Quit: Leaving.)
  720. # [17:37] * Quits: tomasf (~tomasf@static-88.131.62.36.addr.tdcsong.se) (Quit: tomasf)
  721. # [17:43] <zewt> annevk: when parsing a URL whose base URL is null, what does eg. "set scheme to base's scheme" mean? SIGSEGV? (i might be missing a default-base-url rule somewhere)
  722. # [17:43] <annevk> zewt: how did you get there?
  723. # [17:44] <zewt> new URL("http://foo.com");
  724. # [17:44] <annevk> you would not get there
  725. # [17:45] <annevk> you can never get in the "hierarchical" state if base URL is null
  726. # [17:45] * Joins: jsbell (jsbell@nat/google/x-aliuxhwhwbcrlhxh)
  727. # [17:47] <annevk> maybe I'll rename "hierarchical" to "relative"
  728. # [17:47] <zewt> new URL("?a=1"): 1: scheme start, step 1 does nothing, step 2 goes to no scheme; 2: no scheme goes to hierarchical
  729. # [17:47] <zewt> (the case I was actually tracing)
  730. # [17:48] <annevk> ah
  731. # [17:48] <annevk> small bug, thanks
  732. # [17:49] <zewt> (i guessed doing that would actually want to end up invalidated, but was trying to see if that's what actually happens)
  733. # [17:52] <annevk> fixed
  734. # [17:53] * JohnAlbin_food is now known as JohnAlbin
  735. # [17:53] <dglazkov> good morning, Whatwg!
  736. # [17:54] <zewt> should the URL ctor throw on invalid URLs, since it does that for base anyway? seems confusing that eg. changing .path and querying .href silently gives the original URL if it was invalid
  737. # [17:55] * Joins: smaug (~chatzilla@cs181151161.pp.htv.fi)
  738. # [17:55] <annevk> zewt: maybe, but a) that does not happen for <a> and such and b) it might make introducing new schemes that need parser integration trickier
  739. # [17:55] <annevk> zewt: you can check the new isInvalid flag
  740. # [17:56] <annevk> maybe that should be named isValid
  741. # [17:56] * Quits: smaug____ (~chatzilla@cs181151161.pp.htv.fi) (Ping timeout: 248 seconds)
  742. # [17:56] * smaug is now known as smaug____
  743. # [17:56] * Quits: shwetank (~shwetank@pat-tazdevil.opera.com) (Quit: Leaving...)
  744. # [17:57] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Quit: http://mhausenblas.info/#i says TTYL)
  745. # [17:57] <zewt> seems confusing that changes are silently discarded in that state, though
  746. # [17:57] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
  747. # [17:57] * Quits: auchenberg (~auchenber@176.222.239.226) (Remote host closed the connection)
  748. # [18:00] <annevk> you can still set .href
  749. # [18:00] <zewt> but nothing else
  750. # [18:00] * Joins: dragon__ (~dragon@182-166-107-150f1.hyg2.eonet.ne.jp)
  751. # [18:00] <annevk> well doh, if the input is invalid it would be kinda hard to change anything
  752. # [18:00] * Quits: dragon__ (~dragon@182-166-107-150f1.hyg2.eonet.ne.jp) (Client Quit)
  753. # [18:01] <annevk> and it's largely an edge case anyway and it that case better extensibility wins
  754. # [18:01] <annevk> in*
  755. # [18:03] <jgraham> othermaciej: Yes, but their proposal sucks even more, so that's not a great argument
  756. # [18:04] <othermaciej> jgraham: I don't know of a reasonable way to avoid callback-per-operation while still avoiding synchronous I/O on the main thread
  757. # [18:04] <zewt> it just seems like a confusingly silent error condition, where the interface is still there, no errors are raised, but it doesn't do anything useful and the reason for why it's no-opping isn't necessarily obvious
  758. # [18:04] <othermaciej> jgraham: that being said, I am not really sure why any local sandboxed storage use cases would need this but couldn't use indexeddb
  759. # [18:04] <jgraham> othermaciej: I think we should perhaps spend some time trying to work out a pattern for that
  760. # [18:04] <othermaciej> jgraham: so I think maybe the right next step is to get very clear about the use cases
  761. # [18:05] <jgraham> Before adding yet more APIs that die under callback hell
  762. # [18:05] <jgraham> But yeah, I agree about IndexedDB and use cases
  763. # [18:05] * Quits: Ms2ger (~Ms2ger@kotnet-146.kulnet.kuleuven.be) (Quit: Leaving)
  764. # [18:05] <annevk> zewt: not too worried with error consoles and whatnot
  765. # [18:05] * Joins: Ms2ger (~Ms2ger@kotnet-146.kulnet.kuleuven.be)
  766. # [18:05] <rwaldron> annevk was just looking at the mutation methods—great stuff. One question though: Can these be specified to return the node they operate on?
  767. # [18:05] <rwaldron> http://dom.spec.whatwg.org/#mutation-methods
  768. # [18:06] <zewt> othermaciej: fwiw, i expect a portion of it is that everyone implicitly understands and "trusts" filesystem access as a basic storage mechanism for file-like data, where indexeddb is less known and proven in people's minds
  769. # [18:06] <annevk> rwaldron: I haven't done that because that would be inconsistent with every other platform API there is
  770. # [18:06] <rwaldron> I see
  771. # [18:06] <rwaldron> well, that's unfortunate.
  772. # [18:07] <Ms2ger> This ain't jquery
  773. # [18:07] <othermaciej> zewt: yeah, but - Chrome's sandboxed filesystem store is (I believe) in reality backed by a database
  774. # [18:07] <othermaciej> zewt: so the trust level is completely illusory
  775. # [18:08] <zewt> othermaciej: yeah that's pretty bad, defeats the benefits entirely
  776. # [18:08] <annevk> rwaldron: so yes, we can do whatever we want, but taking the rest of the platform into consideration is important
  777. # [18:08] <annevk> rwaldron: it's already inconsequential enough imo
  778. # [18:09] <rwaldron> Ms2ger what do you gain from saying that? Or better, what does the future of the platform gain?
  779. # [18:09] <zewt> (databases don't tend to be terribly good at file-like stuff, eg. storing a 500 MB file and then modifying a few bytes in the middle, appending data without compounding fragmentation, etc)
  780. # [18:09] * Joins: eric_carlson_ (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  781. # [18:09] <Ms2ger> rwaldron, the ability to have functions return something more useful than the this value
  782. # [18:10] <rwaldron> annevk I understand, but since these effectively supplant the previous API, it doesn't seem unreasonable.
  783. # [18:10] <rwaldron> Ms2ger such as?
  784. # [18:10] <annevk> rwaldron: by the platform I mean more than just DOM manipulation :)
  785. # [18:10] <annevk> I mean every API in every standard
  786. # [18:11] <rwaldron> annevk yes, the same ones that are abstracted over, because they are mostly miserable.
  787. # [18:11] * Ms2ger yawns
  788. # [18:11] <rwaldron> Ok, well I can see that arguing this is pointless, so thanks for your time everyone.
  789. # [18:12] * Ms2ger implements remove() instead
  790. # [18:13] <Ms2ger> I guess I get to write tests now
  791. # [18:13] * Quits: Smylers (~smylers@62.249.246.74) (Ping timeout: 246 seconds)
  792. # [18:13] <annevk> rwaldron: I'd prefer a more complete plan than just changing some APIs here and there into chaining APIs
  793. # [18:13] <annevk> rwaldron: it feels a bit irresponsible to just do it here and there
  794. # [18:14] <annevk> rwaldron: I'm not opposed to the idea though
  795. # [18:14] * Joins: tantek (~tantek@70-36-139-86.dsl.dynamic.sonic.net)
  796. # [18:14] <rwaldron> Ms2ger seriously? I'm reaching out to spec authors, as a member of TC39 (representing jQuery), to coordinate efforts that will improve the use of APIs that will be used to create the future
  797. # [18:14] <rwaldron> I don't appreciate your dismissive comments
  798. # [18:14] <rwaldron> Considering I said nothing to you to deserve them
  799. # [18:15] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  800. # [18:15] <Ms2ger> This is an issue that would be better solved in JS proper
  801. # [18:15] <Ms2ger> If you're in tc39, you're better placed than me to do that
  802. # [18:15] <rwaldron> Ms2ger and what issue is that?
  803. # [18:16] <Ms2ger> You mean there is no issue?
  804. # [18:16] <Ms2ger> Then why do you want to change a few methods in DOM?
  805. # [18:16] <rwaldron> I'm asking you to clarify what issue you're referring to
  806. # [18:16] <rwaldron> "This is an issue that would be better solved in JS proper"
  807. # [18:16] <Ms2ger> Clearly you believe there is an issue with the mutation methods
  808. # [18:17] <rwaldron> I believe there is an issue with the way much of the DOM has been specified
  809. # [18:17] <Ms2ger> I never really understood which issue it is that returning the this value is supposed to solve
  810. # [18:17] <rwaldron> It's not a problem with the language, it's a problem with the authors of the specifications.
  811. # [18:17] <Ms2ger> But it is pointless to try to fix it by changing a few methods here and there
  812. # [18:18] * Quits: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net) (Quit: othermaciej)
  813. # [18:18] * Joins: ls_n (~ls_n@c-98-246-32-40.hsd1.or.comcast.net)
  814. # [18:19] <paul_irish> as pointless as adding a duplicate remove() method purely for improved usability?
  815. # [18:19] <rwaldron> If these methods represent a newly created API, why not specify them in a way that will match the expectations of web developers that are currently using libraries to abstract over the existing APIs
  816. # [18:19] <rwaldron> let me rephrase that...
  817. # [18:19] <rwaldron> "Give them what they want"
  818. # [18:19] * Joins: jacobolus (~jacobolus@76.91.212.21)
  819. # [18:19] * Quits: jtcranmer (~jcranmer@ltsp2.csl.tjhsst.edu) (Ping timeout: 264 seconds)
  820. # [18:20] <Ms2ger> paul_irish, I'm not sure what parallel you're trying to draw?
  821. # [18:20] <zewt> because adding a return value that has minor benefit just because you're not currently using the return value means you can never, ever in the future use the return value to represent something very useful
  822. # [18:20] <rwaldron> You're implementing methods that "almost" match the API of several DOM libraries
  823. # [18:20] <rwaldron> except that you've left out a significant part and that will just cause more confusion.
  824. # [18:21] <Ms2ger> "Do what jquery does" is not an argument
  825. # [18:21] <ls_n> not just jQuery
  826. # [18:21] <danheberden> Wow, that was a quick mis-characterization of what rwaldron said
  827. # [18:21] <annevk> rwaldron: can't blame Ms2ger and I for the DOM... that was done way back; we just fixed a bunch of holes
  828. # [18:22] <annevk> anyway, gotta go
  829. # [18:22] <rwaldron> Ms2ger that's amusing.
  830. # [18:22] <paul_irish> i'm saying these new methods are introduced for the purpose of improving the usability of the DOM. I can guarantee you that developers would find a useful return value more intuitive
  831. # [18:22] <Ms2ger> You're clearly just trolling
  832. # [18:22] <rwaldron> paul_irish +1
  833. # [18:23] <zewt> (rwaldron: being rude is not going to convince anyone of much of anything)
  834. # [18:23] <rwaldron> Ms2ger I am absolutely not trolling
  835. # [18:23] <rwaldron> And I don't appreciate the name "name-calling"
  836. # [18:23] <danheberden> zewt, as someone mostly reading this conversation and not participating, I would hardly call rwaldron the rude one here
  837. # [18:24] <rwaldron> so far you've resorted to being unfairly dismissive and now to name calling.
  838. # [18:24] <rwaldron> I spoke up because I want a better DOM API
  839. # [18:24] <rwaldron> That's not trolling.
  840. # [18:24] <ls_n> From my review of the spec, I found it odd that the method names and intent seemed to be following popular library implementations, but without including a return value.
  841. # [18:24] <zewt> the addBefore/addAfter tend not to actually need chaining, since their pattern is e.addAfter(a, b, c); you don't need to say e.addAfter(a).addAfter(b).addAfter(c)
  842. # [18:24] * Joins: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net)
  843. # [18:25] <rwaldron> ls_n agreed, which is why I came to discuss
  844. # [18:25] * Joins: shwetank (~shwetank@cm-84.215.28.236.getinternet.no)
  845. # [18:25] <ls_n> If the spec had included a return value other than the calling node, I would have called that into question because there is precedence, but I could have been convinced.
  846. # [18:26] * Joins: jwalden (~waldo@2620:101:8003:200:f562:597b:7d05:ecf8)
  847. # [18:26] * SamB_MacG5 thinks it would be handy if the multi-page specs had auto-redirect pages, like epydoc makes: http://epydoc.sourceforge.net/faq.html#redirect
  848. # [18:26] <rwaldron> and all I've gotten in response is "yawn", some snide comments about jQuery and some misguided argument about fixing the issue in JS (ie. the language).
  849. # [18:26] <ls_n> Without a return value, it seems very confusing. Almost purposeful. Why not preserve least surprise, and follow precedence?
  850. # [18:27] <Ms2ger> Is there any reason it is "confusing" except for "it doesn't match jquery"?
  851. # [18:27] <rwaldron> ls_n before annevk left, he told me that having a return value doesn't match the rest of the platform
  852. # [18:27] * Quits: smaug____ (~chatzilla@cs181151161.pp.htv.fi) (Remote host closed the connection)
  853. # [18:28] <ls_n> Ms2ger: fwiw, YUI also includes these methods, and also returns the calling node.
  854. # [18:28] * Joins: smaug____ (~chatzilla@cs181151161.pp.htv.fi)
  855. # [18:28] * Joins: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  856. # [18:28] <Ms2ger> Let's take "jquery" as a shorthand for "jquery and other frameworks that look the same"
  857. # [18:28] <Ms2ger> if that makes you happy
  858. # [18:28] <SamB_MacG5> Ms2ger: if you take the name, well ...
  859. # [18:28] <ls_n> rwaldron: interesting. I wonder what the definition of "platform" is in that context. I'm thinking appendChild() has a return value.
  860. # [18:29] <Ms2ger> ls_n, appendChild() returns the argument, not the this value
  861. # [18:29] <ls_n> Ms2ger: I'm aware :) My point is that it returns something.
  862. # [18:30] <Ms2ger> Hah
  863. # [18:30] <SamB_MacG5> that doesn't sound like much of an argument
  864. # [18:30] <Ms2ger> Nobody claimed that returning something useful didn't match the rest of the patform
  865. # [18:30] <zewt> annevk obviously didn't say that DOM functions should never return anything at all, heh
  866. # [18:30] <Ms2ger> platform*
  867. # [18:30] <danheberden> Ms2ger: from a completely "read the statement" - you start with something, you do something to it, why did the thing go away?
  868. # [18:30] <danheberden> sorry, completely "read the statement" argument
  869. # [18:30] <zewt> (parse error, redo from start)
  870. # [18:30] <Ms2ger> So
  871. # [18:31] <danheberden> like - i think that while jQuery executed successfully, there is a natural tendency to expect that
  872. # [18:31] <rwaldron> Ms2ger as does Prototype (however, its use has significanlty diminished) and Dojo (which is widely used in the enterprise)
  873. # [18:31] <Ms2ger> Does anybody want to reply to my actual point instead of complaining about my use of "jquery"?
  874. # [18:32] <danheberden> Ms2ger: but youre combatting points with "because jQuery does it means nothing"
  875. # [18:32] * jwalden suspects this scrollback would be marginally interesting to read, fires up logs
  876. # [18:32] <SamB_MacG5> Ms2ger: isn't "gratuitous mismatch with libraries" enough?
  877. # [18:32] * Joins: say2joe (~say2joe@204.56.108.2)
  878. # [18:33] <ls_n> appendChild() would be less useful if it didn't return something. If it returned the calling node, it would still be useful. Whether more or less useful than returning the argument is debatable, but not the point. There is utility there. There is less utility without a return value.
  879. # [18:33] <Ms2ger> SamB_MacG5, I was asking for a point besides that
  880. # [18:33] <zewt> SamB_MacG5: no, "we should do it because libraries do it" is not an argument at all
  881. # [18:33] <rwaldron> Ms2ger my response is this: devs use libraries because the DOM APIs are awful. Regardless of the libary, they all share common behaviours and returning the this value is one of them.
  882. # [18:34] <SamB_MacG5> zewt: not a strong argument, I'll grant
  883. # [18:34] <Ms2ger> That's not an answer to my question
  884. # [18:34] <danheberden> And how _else_ would you characterizing people's wants besides their use of these libraries?
  885. # [18:34] <Ms2ger> Let me try again
  886. # [18:34] <rwaldron> These new mutation methods will not ease any DOM API pain points
  887. # [18:34] <zewt> ls_n: as I already said, functions should *not* be given a return value soley for the sake of having a return value; it needs to have enough value to *commit* that return value to that purpose for all time
  888. # [18:34] <SamB_MacG5> but if you haven't got anything *better* to do ...
  889. # [18:34] <danheberden> there is no big online survey of "how do you want the dom to work"
  890. # [18:34] <danheberden> you look at library useage
  891. # [18:34] <zewt> using the return value for something of value 0.1 means you can never use it to support a use case that appears a year from now with value 5.0
  892. # [18:34] <Ms2ger> Is there any reason that not returning the this value is "confusing" except for "it doesn't match a number of JS libraries"?
  893. # [18:34] <zewt> you're stuck with the 0.1 forever
  894. # [18:35] <SamB_MacG5> zewt: okay, that's an argument
  895. # [18:35] <ls_n> zewt: A fair point, but fear of the future in the face of current usage with developers expectating a return value seems silly.
  896. # [18:35] * Quits: eric_carlson_ (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Quit: eric_carlson_)
  897. # [18:35] <rwaldron> zewt but... the current API is the problem
  898. # [18:36] <rwaldron> library adoption over DOM API seems to indicate displeasure with the way it was originally done, in favor of what we are explaining
  899. # [18:36] <danheberden> My addition, Ms2ger, was that JS devs get the idea that "i have something, then i call something on it" and naturally expect that 'something' to be there again
  900. # [18:36] <danheberden> that there is a natural inclination, in addition to library buy-in
  901. # [18:36] <zewt> ls_n: can't say I agree with the premise; I expect functions to do what they're documented as doing
  902. # [18:37] * Joins: hasather_ (~hasather_@cm-84.208.71.130.getinternet.no)
  903. # [18:37] <SamB_MacG5> zewt: probably best not to steal the names the libraries have been using, then ?
  904. # [18:37] <danheberden> and that "it doesn't match a number of JS libraries" might indeed be the only big reason, albeit a very big reason/indicator
  905. # [18:37] <SamB_MacG5> otherwise, the users are liable to read the wrong documentation
  906. # [18:38] * jwalden never understood returning-this behavior, versus just naming the same variable a second time, which is inarguably clearer as it requires no knowledge of the return type of the method that's being called
  907. # [18:38] <zewt> rwaldron: that's merely saying "we should arbitrarily mimic jquery because people use jquery" and could be applied to any aspect of the library
  908. # [18:38] <SamB_MacG5> jwalden: well, the one problem with that is that you have to actually name a variable in the first place
  909. # [18:39] <zewt> SamB_MacG5: as long as it doesn't result in weird, contrived or hard to type function names, i don't mind trying to use different names, no
  910. # [18:39] <rwaldron> Ms2ger if the method is "setting" (which includes mutation of subtrees, etc) the this value should be returned. If the method is "getting" (eg. an attribute value by name) then return the value of thing we're requesting. I don't understand what is so hard about this. cc zewt
  911. # [18:39] <jwalden> SamB_MacG5: I don't believe that's a problem, only if you buy into the jquery mindset of chaining method-call upon method-call in the first place
  912. # [18:39] <jwalden> SamB_MacG5: it kind of begs the question
  913. # [18:39] <danheberden> rwaldron: you could also add 'creating' to that list
  914. # [18:39] <SamB_MacG5> jwalden: well, I didn't say it was a *big* problem
  915. # [18:40] <Ms2ger> rwaldron, nothing hard about "how it works", only about "why it's useless"
  916. # [18:40] <rwaldron> danheberden +1
  917. # [18:40] <Ms2ger> Sorry, useful*
  918. # [18:40] <zewt> (rwaldron: you're repeating yourself and ignoring the responses, so unless you have something new to say I'm not going to repeat responses :)
  919. # [18:40] <SamB_MacG5> but I must admit sometimes I have trouble naming my variables :-)
  920. # [18:40] <danheberden> zewt, i'll bite - there are known problems with how jQuery's API is - rather, some outstanding bugs of people saying they'd like certain api methods to work
  921. # [18:41] <danheberden> and we're backed into a corner because it's existing stuff or we want to match the dom
  922. # [18:41] * jwalden sees naming variables as a quite-useful form of documentation, all the more for being an actual part of the code, so less apt to bitrotting
  923. # [18:41] <ls_n> So this argument boils down to a disagreement in the value of returning this?
  924. # [18:41] <danheberden> however, this concept - of return values - people like
  925. # [18:41] <danheberden> people comment on how helpful it is
  926. # [18:41] <danheberden> or how unhelpful it is that the DOM doesn't do that
  927. # [18:41] <zewt> SamB_MacG5: again the chaining pattern tends to be built around eg. "add this one element", but when you're able to pass a list of items to add, a lot of that goes away
  928. # [18:41] <danheberden> so taking a huge number of developers that _choose_ to use jQ's API in to consideration seems worth something, ya?
  929. # [18:42] * Joins: cabanier (~cabanier@192.150.22.55)
  930. # [18:43] <zewt> (danheberden: <zewt> rwaldron: that's merely saying "we should arbitrarily mimic jquery because people use jquery" and could be applied to any aspect of the library)
  931. # [18:43] <Ms2ger> danheberden, jquery has its advantages
  932. # [18:43] <danheberden> but no one is saying we should arbitrarily mimic jquery
  933. # [18:43] <danheberden> except you two
  934. # [18:43] <Ms2ger> Papering over browser differences, say
  935. # [18:43] <danheberden> instead of replying to points, you mis-characterize the argument
  936. # [18:43] <zewt> that's exactly what you just said--"lots of people choose to use jquery, and that's an argument for doing this one particular thing in jquery's way"
  937. # [18:43] <Ms2ger> I think that's a bigger reason that people would use it than just the chaining
  938. # [18:44] <danheberden> zewt - THAT PARTICULAR feature
  939. # [18:44] <jwalden> this late in the game, fighting against long-standing DOM precedent, consistency with the rest of the DOM seems the right thing, and let libraries do their thing however they want it as they always do
  940. # [18:44] <rwaldron> In addition to danheberden's argument about taking developer preference into consideration, I'd also like to share some third party statistics: http://trends.builtwith.com/javascript
  941. # [18:44] <danheberden> i'm talking about the return value
  942. # [18:44] <zewt> no, we've replied to many points; i suspect you're not paying attention
  943. # [18:44] <danheberden> zewt - i've agreed with some, i think, so perhaps i should add a +1 in reply if i don't have an argument
  944. # [18:45] <rwaldron> zewt sure, I'll bite... ready? Here goes...
  945. # [18:45] <ls_n> zewt: There are many differences between DOM libraries. If they all, or even mostly, agree on a set of methods to improve the experience of working with the DOM, that's not mimicking jQuery, that's codifying accepted convention.
  946. # [18:46] <zewt> anyway, HTML API design is based around technical arguments, not statistics and +1s and "look how many people use jquery"; i can recall no technical arguments being given for this at all, so i'm going to go and do my day job unless one turns up
  947. # [18:46] <rwaldron> Developers that build real things on the real web prefer library APIs, such as jQuery, YUI, Dojo, etc. as such, the API decisions of those libraries should be taken into consideration when new DOM APIs are created.
  948. # [18:46] <danheberden> zewt, you're aware that these "people" are the ones using these APIs, ya?
  949. # [18:46] <zewt> i use these APIs every day
  950. # [18:46] <danheberden> and the technical arguments don't have to use the APIs daily?
  951. # [18:47] <danheberden> and you wouldn't like them at all easier to use?
  952. # [18:47] <zewt> returning "this" doesn't make them easier to use
  953. # [18:47] <Ms2ger> danheberden, sure, I want them to be easier to use
  954. # [18:47] <danheberden> or because YOU'VE used them and like them means the other thousand people should too
  955. # [18:47] <zewt> not significantly enough to commit the return value to it forever
  956. # [18:47] * Joins: jtcranmer (~jcranmer@ltsp2.csl.tjhsst.edu)
  957. # [18:47] <danheberden> cuz zewt, personally, i agree with you
  958. # [18:47] <Ms2ger> I've been trying to get people to explain why returning "this" would make them easier to use
  959. # [18:47] <Ms2ger> I haven't heard anything
  960. # [18:47] <danheberden> i am so used to how it works it doesn't bother me
  961. # [18:48] <danheberden> but i see the need for many others
  962. # [18:48] <danheberden> mainly because i work support a lot
  963. # [18:48] <danheberden> so i get a sense of that
  964. # [18:48] <danheberden> i do trainings and deal with a lot of typical developers
  965. # [18:49] <danheberden> Ms2ger: what kind of metrics _would_ be helpful?
  966. # [18:49] <danheberden> like - what way could we get an idea of buy-in from people that would satisfy you?
  967. # [18:49] <Ms2ger> I don't care much about "buy-in"
  968. # [18:49] * Parts: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  969. # [18:49] <danheberden> perhaps i'm not using the right word
  970. # [18:50] <danheberden> i'm meaning if people would find it useful
  971. # [18:50] <danheberden> how to track/measure that
  972. # [18:50] <zewt> it seems clear to me that having a few functions return this, and most (eg. the legacy ones) return nothing or (in the case of appendChild) its argument, both makes the chaining pattern much less useful and very brittle and confusing
  973. # [18:50] <Ms2ger> I'm looking for someone to explain why people would find it useful
  974. # [18:50] <danheberden> like if i asked all of my students in a training, and had my coworkers do the same
  975. # [18:50] <rwaldron> zewt... technical argument: ES1, 3, 5, 5.1 and 6 (draft) have set a precendent for objects whose prototype methods return either a specific value that is relevant to or the result of an operation on the calling object, or a newly created copy of the calling object itself, which allows further calls to be "chained"
  976. # [18:51] * Quits: niloy (~niloy@61.12.96.242) (Ping timeout: 246 seconds)
  977. # [18:51] * Joins: sicking (~chatzilla@nat/mozilla/x-evxlcsxlgfbxskft)
  978. # [18:51] <Ms2ger> rwaldron, want to give a few examples?
  979. # [18:52] <rwaldron> the DOM has deviated for a long time and users of DOM APIs have been "fixing" it for a decade.
  980. # [18:52] <jwalden> rwaldron: what precedents can you name for chaining in ECMAScript? I can think of exactly one
  981. # [18:52] <jwalden> rwaldron: (in the language, I mean)
  982. # [18:52] <zewt> the argument i'm looking for is "here's a thing which is made so much easier or less error-prone that it justifies committing the return value to this--and nothing else--even if it's inconsistent with lots of other functions that do related things"
  983. # [18:52] <danheberden> Ms2ger: as for the personal why, i've had people express their displeasure at it NOT returning `this`; i can try to gain more insight as to the motivation behind that
  984. # [18:53] * Quits: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net) (Quit: jamesr)
  985. # [18:53] <rwaldron> Ms2ger yes. Array.prototype.push returns a relevant value: the new length. Array.prototype.map returns a newly created array object with the values of the map operation
  986. # [18:53] <Ms2ger> danheberden, I would appreciate that
  987. # [18:53] <rwaldron> need more?
  988. # [18:53] * Quits: darobin (~darobin@spintank2-160-134.cnt.nerim.net) (Ping timeout: 264 seconds)
  989. # [18:53] <rwaldron> There is a whole spec full of examples.
  990. # [18:53] <Ms2ger> rwaldron, I think you misunderstood my question
  991. # [18:53] <zewt> rwaldron: what? the new length isn't "this", it's the new length
  992. # [18:54] <Ms2ger> rwaldron, I'm looking for cases where ES returns the this value
  993. # [18:54] <zewt> (and precedent isn't an argument that something should be done, it just means it has been)
  994. # [18:54] <jwalden> rwaldron: [].map is not an example of chaining, it's an example of a function with a return value, no?
  995. # [18:54] <rwaldron> zewt read my previous message before trying to argue something that I _just_ said
  996. # [18:54] <jwalden> rwaldron: the only example I can come up with is [].sort, for a method that chains but doesn't return a new value/object
  997. # [18:54] <Ms2ger> rwaldron, sorry, I misunderstood you
  998. # [18:55] <rwaldron> [12:40 PM] <rwaldron> zewt... technical argument: ES1, 3, 5, 5.1 and 6 (draft) have set a precendent for objects whose prototype methods return either a specific value that is relevant to or the result of an operation on the calling object, or a newly created copy of the calling object itself, which allows further calls to be "chained"
  999. # [18:55] <Ms2ger> rwaldron, I'm just not sure how that is relevant, then
  1000. # [18:55] <rwaldron> jwalden push?
  1001. # [18:55] <rwaldron> sorry, no
  1002. # [18:55] <rwaldron> strike that
  1003. # [18:55] <Ms2ger> rwaldron, I think we're all in violent agreement that there is a point to returning a useful value
  1004. # [18:55] <rwaldron> (I missed the part where you said "chains but doesn't"
  1005. # [18:56] <rwaldron> Ms2ger agreed.
  1006. # [18:56] <rwaldron> But I argue that returning void 0/undefined is not doing anyone any favors
  1007. # [18:56] <Ms2ger> Phew, we agreed on something ;)
  1008. # [18:56] <rwaldron> +1
  1009. # [18:56] <danheberden> Ms2ger: lol
  1010. # [18:57] * Joins: pablof (~pablof@144.189.150.130)
  1011. # [18:57] <danheberden> Ms2ger: what dangers do you think are present in returning `this` instead of undefined?
  1012. # [18:57] <Ms2ger> I guess I don't really see the value of returning 'this' in a few cases where we would otherwise return undefined
  1013. # [18:57] <danheberden> what bad issues or problems would arrise from that?
  1014. # [18:57] <zewt> danheberden: i've already explained that repeatedly :)
  1015. # [18:57] <Ms2ger> One is that you can't return anything else
  1016. # [18:58] <zewt> <zewt> using the return value for something of value 0.1 means you can never use it to support a use case that appears a year from now with value 5.0
  1017. # [18:58] <Ms2ger> Another is that you still need to remember which methods return something useful, and which return this
  1018. # [18:58] <danheberden> zewt, so if addEventListener, after all these years, was going to support a different return value
  1019. # [18:58] <Ms2ger> I think what would be more useful is a JS feature to call multiple functions on one object
  1020. # [18:59] <zewt> if the value of returning "this" is 5.0--if it's a significant, measurable win--then sure; but "we should return *something*, so it may as well be this" is a bad idea
  1021. # [18:59] <danheberden> zewt - it's more, like, "this function has no useful return value except for the original element"
  1022. # [18:59] <zewt> danheberden: you're confusing foresight with hindsight: when addEventListener was first implemented, there was no way of knowing whether some other return value would have turned up
  1023. # [19:00] <danheberden> zewt, i'm saying take advantage of that hindsight
  1024. # [19:00] <ls_n> zewt: So the number of years that libraries have been using these methods, returning 'this', and not running into any major use case that would have been so much better than returning 'this' is not evidence? What would a reasonable wait time be?
  1025. # [19:00] * abstractj is now known as abstractj|lunch
  1026. # [19:01] <Ms2ger> ls_n, who says they haven't found (even not particularly big) such use cases?
  1027. # [19:01] <danheberden> zewt, i *do* understand your point
  1028. # [19:01] <danheberden> and it's a good one
  1029. # [19:01] <zewt> ls_n: it's not about "wait time", it's about adding a feature when there's a clear, measurable win, and that's exactly what nobody is giving--examples of things which are made measurably easier or less error-prone by doing this
  1030. # [19:01] <Ms2ger> It's not like they could have implemented those
  1031. # [19:01] <danheberden> i don't think this shoudl all be tackled super lightly
  1032. # [19:02] <rwaldron> zewt Ms2ger I'm worried that the "avoid future hostility" argument is actually going to end up turning this into a lost opportunity (purely opinion)
  1033. # [19:02] <danheberden> but i think there are some cases where one could ascertain whether or not returning this would be a safe future proof change
  1034. # [19:02] <rwaldron> :|
  1035. # [19:02] <Ms2ger> rwaldron, possibly
  1036. # [19:02] <danheberden> and honestly, with this argument, you would NEVER change the return value from undefinded to something
  1037. # [19:02] <danheberden> because of the fear you'd need that return value in the future
  1038. # [19:02] <Ms2ger> danheberden, why not? Because something *even better* could come along?
  1039. # [19:03] <danheberden> i do that too - i buy a really tasty snack and wait for the best time to eat it.. but in the end, it just goes bad
  1040. # [19:03] <danheberden> because i waited and waited
  1041. # [19:03] <zewt> danheberden: of course you would--when you have a clear benefit for doing so, just like adding any feature. that benefit isn't clear (at least to us) in this case
  1042. # [19:03] <danheberden> zewt - so perhaps the question isn't as much of 'should we' or 'shouldn't we'
  1043. # [19:03] <danheberden> but how can we gather the information necessary to make this decision
  1044. # [19:04] * jwalden doesn't think the "we might want to return something in the future" argument has much value here -- either there's an obvious return value, or there's nothing, and thinking something might turn up in the distant future seems unrealistic
  1045. # [19:04] <ls_n> Ms2ger: what inconveniences people have come across have been inconveniences. At least, speaking from the YUI side of things. At the end of the day, if these methods are implemented without return value, then the libraries will call them, then return 'this' manually. It will still just be an inconvenience.
  1046. # [19:04] <danheberden> jwalden i think it has some merit, for a period of time at least
  1047. # [19:04] <SamB_MacG5> I think the "we might want to return something" argument should be judged based on what you could reasonably return
  1048. # [19:04] <jwalden> danheberden: plausible, depending on the API I guess
  1049. # [19:04] <danheberden> i think libraries like jQuery give an oppurtunity to see if stuff is garbage or not
  1050. # [19:04] * Joins: ralphholzmann (~ralphholz@li533-65.members.linode.com)
  1051. # [19:05] <jwalden> for most APIs it's kind of a stretch
  1052. # [19:05] <danheberden> i mean, look at jQ - `.click and .mouseover` - seriously?
  1053. # [19:05] <danheberden> we learned that kind of stuff is awful
  1054. # [19:05] * Joins: jernoble (~jernoble@17.212.152.13)
  1055. # [19:06] <zewt> and again, inconsistently returning "this" is confusing--for example, e.addBefore(e2).appendChild(e3).addBefore(e4) is very confusing, since appendChild returns e3, not e
  1056. # [19:06] <SamB_MacG5> I'm guessing most methods have a three or less reasonable, non-vacuous return values
  1057. # [19:06] <SamB_MacG5> s/a /
  1058. # [19:07] <SamB_MacG5> zewt: yes, agreed
  1059. # [19:07] <ls_n> zewt: yes is it
  1060. # [19:07] <danheberden> (i have a call to take, my non-response isn't grumpy silence :)
  1061. # [19:08] <jwalden> danheberden: fine, then, be that way
  1062. # [19:08] <jwalden> ;-)
  1063. # [19:08] <ls_n> would e.appendChild(e2).append(e3).boom() be less confusing?
  1064. # [19:08] <zewt> anyhow i'm out of time for now--day job and all--so afk
  1065. # [19:08] <jgraham> It would be nicer if js made it easier to write a function like chain(elem, appendChild(e1), appendChild(e2), appendChild(e3)) and so on
  1066. # [19:08] * Quits: mattgifford (~mattgiffo@108.161.20.199) (Remote host closed the connection)
  1067. # [19:09] * Joins: mattgifford (~mattgiffo@108.161.20.199)
  1068. # [19:09] <jgraham> Rather than forcing each function to return this or not work with chaining
  1069. # [19:09] <Ms2ger> ^ that
  1070. # [19:09] * Joins: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net)
  1071. # [19:10] <Hixie> annevk: extending the legal url syntax lgtm
  1072. # [19:10] <Hixie> annevk: do you have a plan for how to specify the authoring conformance criteria?
  1073. # [19:12] <annevk> Hixie: not really, wanted to figure out browser stuff first
  1074. # [19:12] <Hixie> k
  1075. # [19:12] <annevk> Hixie: but I guess in the end I'll just take inspiration from one of your specs
  1076. # [19:13] * Quits: mattgifford (~mattgiffo@108.161.20.199) (Read error: Connection reset by peer)
  1077. # [19:13] <Hixie> heh
  1078. # [19:13] * Joins: mattgiff_ (~mattgiffo@108.161.20.199)
  1079. # [19:13] <annevk> Hixie: that's what I usually do anyway, look for some existing pattern
  1080. # [19:14] <Hixie> well there's several options on this front even just amongst stuff i've done :-)
  1081. # [19:14] <Hixie> in particular, BNF variants and straight prose
  1082. # [19:17] <annevk> rwaldron: """and all I've gotten in response is "yawn", some snide comments about jQuery and some misguided argument about fixing the issue in JS (ie. the language). """ dude, I tried to explain where I came from
  1083. # [19:17] * Quits: drublic (~drublic@p5098a42b.dip0.t-ipconnect.de) (Remote host closed the connection)
  1084. # [19:17] * Quits: jacobolus (~jacobolus@76.91.212.21) (Remote host closed the connection)
  1085. # [19:17] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Quit: http://mhausenblas.info/#i says TTYL)
  1086. # [19:17] <annevk> rwaldron: up to and including that I'm fine with changing it, if we have some kind of plan
  1087. # [19:17] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
  1088. # [19:17] * Quits: mattgiff_ (~mattgiffo@108.161.20.199) (Remote host closed the connection)
  1089. # [19:18] * Joins: mattgifford (~mattgiffo@108.161.20.199)
  1090. # [19:19] * Quits: Ms2ger (~Ms2ger@kotnet-146.kulnet.kuleuven.be) (Ping timeout: 265 seconds)
  1091. # [19:19] <annevk> rwaldron: thus far it's like "can we do x?" "well, most of y doesn't do x at the moment and although we could try it, it seems kind of irresponsible without a plan for y" "..."
  1092. # [19:19] <rwaldron> annevk I wasn't referring my discussion with you
  1093. # [19:20] <rwaldron> annevk while you were away I provided several arguments beyond simply "can we do x?"
  1094. # [19:20] <annevk> I think Ms2ger is arguing the same point, but not as constructive and friendly unfortunately
  1095. # [19:21] <rwaldron> Ms2ger and I actually both agree that returning something is better then nothing
  1096. # [19:22] * Quits: sedovsek (~robert@89.143.12.238) (Quit: sedovsek)
  1097. # [19:22] * Quits: mattgifford (~mattgiffo@108.161.20.199) (Ping timeout: 256 seconds)
  1098. # [19:23] <rwaldron> I'm stepping out for a few
  1099. # [19:23] <annevk> that's not what he agreed to
  1100. # [19:23] <annevk> see e.g. "I guess I don't really see the value of returning 'this' in a few cases where we would otherwise return undefined "
  1101. # [19:23] <annevk> but yeah, my point was in particular that the platform does not return "this"
  1102. # [19:24] <annevk> I don't know such APIs anyway
  1103. # [19:24] <rwaldron> annevk [12:45 PM] <Ms2ger> rwaldron, I think we're all in violent agreement that there is a point to returning a useful value
  1104. # [19:24] <annevk> right
  1105. # [19:24] <annevk> but he's not convinced (like me) "this" is useful
  1106. # [19:24] <annevk> furthermore, nowhere in the platform is this returned
  1107. # [19:25] <rwaldron> This is really frustrating
  1108. # [19:25] <annevk> and fwiw, platform is http://platform.html5.org/ of course
  1109. # [19:25] * Joins: BennyLava` (~colin@53518387.cm-6-2c.dynamic.ziggo.nl)
  1110. # [19:25] * Quits: BennyLava` (~colin@53518387.cm-6-2c.dynamic.ziggo.nl) (Changing host)
  1111. # [19:25] * Joins: BennyLava` (~colin@pdpc/supporter/professional/riven)
  1112. # [19:25] * Joins: othermaciej (~mjs@17.245.111.37)
  1113. # [19:25] <rwaldron> at no point did i say that ms2ger had agreed to returning this
  1114. # [19:25] <rwaldron> I'm not even sure how you came to that based on what I jsut said
  1115. # [19:26] <annevk> because you said he thought something is better than nothing
  1116. # [19:26] <annevk> which is not what he said
  1117. # [19:26] <rwaldron> dude
  1118. # [19:26] <rwaldron> wtf
  1119. # [19:26] <rwaldron> [12:45 PM] <Ms2ger> rwaldron, I think we're all in violent agreement that there is a point to returning a useful value
  1120. # [19:26] <rwaldron> [12:45 PM] <rwaldron> (I missed the part where you said "chains but doesn't"
  1121. # [19:26] <rwaldron> [12:45 PM] <rwaldron> Ms2ger agreed.
  1122. # [19:26] <rwaldron> [12:46 PM] <rwaldron> But I argue that returning void 0/undefined is not doing anyone any favors
  1123. # [19:26] <rwaldron> [12:46 PM] <Ms2ger> Phew, we agreed on something ;)
  1124. # [19:26] <rwaldron> [12:46 PM] <rwaldron> +1
  1125. # [19:27] <rwaldron> I hate to leave while we're having so much, but I actually have to step out for an appointment
  1126. # [19:27] <annevk> returning a useful value does not mean that returning something is better than nothing
  1127. # [19:27] <zewt> ... he was agreeing with the first line (returning something useful is useful), not that returning undefined is bad
  1128. # [19:28] <annevk> right
  1129. # [19:28] * Quits: BennyLava (~colin@pdpc/supporter/professional/riven) (Ping timeout: 256 seconds)
  1130. # [19:28] <rwaldron> Cool, well don't sweat it.
  1131. # [19:28] <annevk> rwaldron: ttyl then
  1132. # [19:29] <rwaldron> I'm actually not interested in participating in this discussion anymore
  1133. # [19:29] <rwaldron> Good luck with further development, I wish you nothing but success.
  1134. # [19:30] <annevk> rwaldron: that's unfortunate; I hope you'll still contribute to other discussions
  1135. # [19:30] * Joins: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  1136. # [19:31] * Quits: pablof (~pablof@144.189.150.130) (Ping timeout: 250 seconds)
  1137. # [19:31] * Joins: Ms2ger (~Ms2ger@kotnet-146.kulnet.kuleuven.be)
  1138. # [19:31] * Joins: danbri__ (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  1139. # [19:32] * Quits: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Ping timeout: 252 seconds)
  1140. # [19:33] * Joins: dgathright (~dgathrigh@nat/yahoo/x-ewbneagxvemxltwe)
  1141. # [19:34] * Joins: pablof (~pablof@144.189.150.130)
  1142. # [19:35] * Quits: danbri_ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Ping timeout: 256 seconds)
  1143. # [19:37] <annevk> I had not expected people would actually call Array.prototype.push "chaining" as well
  1144. # [19:37] <annevk> I thought "chaining" was reserved for methods that return "this"
  1145. # [19:38] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Quit: http://mhausenblas.info/#i says TTYL)
  1146. # [19:38] * Quits: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net) (Quit: jamesr)
  1147. # [19:38] <Hixie> annevk: ho does Array push() chain?
  1148. # [19:38] * Joins: karlcow (~karl@nerval.la-grange.net)
  1149. # [19:39] <Hixie> heycam|away: you following this Location thread on whatwg?
  1150. # [19:39] <annevk> Hixie: because it returns something on which you can do an operation reportedly
  1151. # [19:39] <ls_n> it's not chaining
  1152. # [19:39] <Hixie> every function that returns anything is chaining then?
  1153. # [19:39] <Hixie> o_O
  1154. # [19:40] <zewt> that was just one of many confusions in that discussion, heh
  1155. # [19:40] <ls_n> well, maybe this is semantics...
  1156. # [19:40] <annevk> or maybe I parsed http://krijnhoetmer.nl/irc-logs/whatwg/20120925#l-975 and subsequent lines incorrectly
  1157. # [19:41] <ls_n> "chaining" == `return this` vs "returns object" vs ?
  1158. # [19:41] <Ms2ger> ls_n, I understood it to mean `return this`
  1159. # [19:41] <annevk> ls_n: dunno man, I thought it was about returning the object you invoked the method on
  1160. # [19:42] <Hixie> yeah, me too
  1161. # [19:42] * Quits: SimonSapin (~simon@2a01:e35:2e8d:b5f0:24ef:db19:73df:6e01) (Ping timeout: 246 seconds)
  1162. # [19:42] <Hixie> imho chaining is a layering violation, taking what should be a syntactic issue and dragging it into the api layer
  1163. # [19:42] <ls_n> Yeah, I can see it either way, because you're chaining operations through the return value, regardless of whether it's 'this'
  1164. # [19:43] * Joins: ap (~ap@2620:149:4:1b01:808c:e015:ab04:503d)
  1165. # [19:43] <Ms2ger> abarth, so the html test suite currently splits submitted tests by person/organization that submitted them, any preference where those location tests should go?
  1166. # [19:43] <zewt> annevk: ms2 asked for "examples" (implied: of things in ES that return the calling object), but was taken literally and received examples of random-not-chaining-at-all return values
  1167. # [19:44] <Hixie> bbiab
  1168. # [19:44] <annevk> zewt: so are there examples for "this"?
  1169. # [19:44] <zewt> annevk: (also, though the ES quote thing wasn't relevant, it also says "a newly created copy of the calling object itself"--which isn't chaining at all when applied to something like a DOM node)
  1170. # [19:45] <zewt> annevk: dunno; i don't think it matters (precedent isn't an argument)
  1171. # [19:45] <zewt> (or I sure hope it isn't, we have mountains of really bad precedent in the older APIs :)
  1172. # [19:45] <Ms2ger> I think jwalden had one
  1173. # [19:46] <zewt> (in case the above wasn't clear--that ES line would mean returning this.cloneNode(), not this)
  1174. # [19:46] <jwalden> annevk: Array.prototype.sort returns this; that's the only example I can think of
  1175. # [19:47] * jwalden has no idea why it returns this
  1176. # [19:47] <annevk> jwalden: interesting
  1177. # [19:47] <Ms2ger> jwalden, arr.sort().sort() // Just making sure
  1178. # [19:47] <zewt> well, sorting multiple times is useful
  1179. # [19:47] * jwalden took advantage of that when constructing XSS exploits against the original Facebook platform, back five years ago, by applying sort to the global object :-)
  1180. # [19:47] <zewt> (with different orderings)
  1181. # [19:47] <annevk> zewt: I think precedents matter, because the lack of the platform doing it now is one of the arguments I use
  1182. # [19:48] <ls_n> jwalden: prior to forEach, I never found it practically useful.
  1183. # [19:48] <zewt> annevk: i think that's sort of halfway right
  1184. # [19:48] <Ms2ger> zewt, fair :)
  1185. # [19:48] * jwalden thinks lack-of-platform-doing-it-now is the strongest argument against suddenly doing it now for new methods
  1186. # [19:48] <zewt> annevk: it's not exactly precedent, so much as that the chaining paradigm only works well when it's supported consistently
  1187. # [19:49] <zewt> eg. we don't want two or three functions that do it (precedent), we'd want to be able to do it everywhere to satisfy that
  1188. # [19:49] <annevk> well yeah, my other argument is that I want to see some kind of plan rather than "lets do this here and see what happens" (sicking argues for that)
  1189. # [19:50] <zewt> personally i write lots of code without jQuery or any other monolithic library at all and have never gone "man, I wish I could chain these calls", which is my own basic rationale :)
  1190. # [19:50] <annevk> and Hixie's point about solving it elsewhere I like too, because then I don't have to worry
  1191. # [19:50] <jwalden> heh
  1192. # [19:50] * Joins: tomasf (~tom@c-44dbe555.024-204-6c6b7012.cust.bredbandsbolaget.se)
  1193. # [19:50] <ls_n> annevk: I think a great deal of the feedback is attached to the names. These same methods exist, and behave consistently in libs. If you'd chosen different names, there might have been less reaction.
  1194. # [19:51] <zewt> (i'm less enthusiastic about the language-level solution, since that's really hard to do in a sane way--adding new syntax to JS means you can't use it *at all* until it's widely supported, since the whole file will fail to parse)
  1195. # [19:51] <annevk> ls_n: nah, this kind of feedback is relatively common also for non-lib methods
  1196. # [19:51] <annevk> ls_n: e.g. the mutation observer stuff
  1197. # [19:52] <zewt> (unless someone gets creative enough to find a way to avoid that, like the "use strict"; hack, but I doubt that'll happen)
  1198. # [19:52] <jwalden> "use strict" was just a bad idea, given script concatenation
  1199. # [19:52] <jwalden> c'est la vie
  1200. # [19:53] <annevk> javascript folks should've learned from doctype switching, and didn't
  1201. # [19:53] <zewt> (i've found it useful, but mostly as a linting thing and to aid my unit tests--until every browser supports it I'm not turning it on in live code)
  1202. # [19:53] <annevk> but considering they were pretty far along with an out-of-band versioning strategy, maybe we're lucky :)
  1203. # [19:54] * Joins: dsheets (~Adium@c-67-180-11-170.hsd1.ca.comcast.net)
  1204. # [19:55] <annevk> brendan considers this different strategies for developing the platform a good thing, but I'm not sure I'm quite with him as the technologies do need to work together at the end of the day
  1205. # [19:55] <ls_n> There's attachment to the familiarity of appendChild() returning a node, and attachment to the existing behavior of append(str) in libs returning a node (though it is a different one).
  1206. # [19:56] <jwalden> well, at this point tc39 is in theory all gung-ho about "no more language modes/versions", so there shouldn't be any more "use strict" mistakes, or even |use strict;| pragmas, or whatever
  1207. # [19:56] <jwalden> new syntax will just break stuff, new editions will not break old code
  1208. # [19:56] <annevk> jwalden: littlecalculist (iirc) is a great man
  1209. # [19:57] <jwalden> :-)
  1210. # [19:58] <jwalden> a little too much of the PL-theory propellerhead for me on rare occasion, but yeah
  1211. # [19:58] <jwalden> and it takes all kinds anyway
  1212. # [19:58] * Joins: auchenberg (~auchenber@176.222.239.226)
  1213. # [19:58] * jwalden wouldn't want a committee of people like him :-)
  1214. # [19:58] <jwalden> at least, not a whole committee of them
  1215. # [19:58] <zewt> i don't really mind a bit of bumpiness for use strict, since some of the things it fixes are *really* annoying JS quirks (unintended globals being the most obvious; .freeze not causing exceptions is lame too, etc)
  1216. # [19:58] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
  1217. # [19:59] * Joins: eric_carlson_ (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  1218. # [19:59] <zewt> but i'd call that a one-time thing :)
  1219. # [19:59] <annevk> anyone from Google here? What are the best email addresses for Alex Russell and Erik Arvidsson? I have their @google.com addresses, but if there's something they actually read and reply to, might be nice
  1220. # [19:59] <jwalden> a better rollout strategy for use-strict probably would have helped some; jslint and json2.js picking it up prematurely was a large part of the problem
  1221. # [20:00] * Joins: jarib (~jarib@unaffiliated/jarib)
  1222. # [20:00] <jwalden> even still, "backwards compatible" but not is just the worst of both worlds
  1223. # [20:00] <annevk> in particular, I see arv is here, I'm looking for a reply to http://lists.w3.org/Archives/Public/www-dom/2012JulSep/0069.html
  1224. # [20:01] * Parts: ls_n (~ls_n@c-98-246-32-40.hsd1.or.comcast.net)
  1225. # [20:01] <zewt> jwalden: python 3's strategy is the worst of all worlds :) overlapping compatibility is much more copable
  1226. # [20:02] * abstractj|lunch is now known as abstractj
  1227. # [20:02] * jwalden is ambivalent about python 3's strategy
  1228. # [20:02] * zewt isn't
  1229. # [20:02] <jwalden> although I am perfectly happy to say it would not at all at all at all work for the web :-)
  1230. # [20:02] <jwalden> diff'rent strokes, perhaps
  1231. # [20:03] <zewt> python 3.0 released in dec 2008; it's 2012 and I'm still on 2.7. migration failed :)
  1232. # [20:03] * Quits: auchenberg (~auchenber@176.222.239.226) (Ping timeout: 264 seconds)
  1233. # [20:03] <jwalden> if they were aiming for a less-than-four-years transition
  1234. # [20:04] <jwalden> python's always been a with-all-deliberate-speed sort of group
  1235. # [20:04] * jgraham expects python 3 transition to work eventually
  1236. # [20:04] <jwalden> I think as long as they get there eventually, they're more or less happy
  1237. # [20:04] <jwalden> yeah
  1238. # [20:04] * Joins: jacobolus (~jacobolus@76.91.212.21)
  1239. # [20:04] <jwalden> expecting a turnaround by some particular time, or aiming for one, is setting oneself up for disappointment
  1240. # [20:05] <jwalden> and I've seen enough signs from people that they're slowly working on the transition that I don't think it can be said to have failed, right now
  1241. # [20:05] <zewt> much saner to make breaking changes slowly, and to keep reasonable compatibility overlap between adjacent versions, instead of making a ton of big breaking changes at once, which just seemed like they got impatient
  1242. # [20:05] <jwalden> signs from people, and from projects implemented in python, that is
  1243. # [20:08] * Joins: rgrove (~rgrove@c-76-105-195-76.hsd1.or.comcast.net)
  1244. # [20:10] <Ms2ger> I've seen work on py3 compat in Mozilla's new python code, fwiw
  1245. # [20:12] * Joins: a-ja (~chatzilla@70.230.163.14)
  1246. # [20:21] * Joins: danbri (~danbri@cable-146-255-148-108.dynamic.telemach.ba)
  1247. # [20:24] * Quits: danbri__ (~danbri@cable-146-255-148-108.dynamic.telemach.ba) (Ping timeout: 256 seconds)
  1248. # [20:26] * Quits: eric_carlson_ (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Quit: eric_carlson_)
  1249. # [20:27] * Joins: eric_carlson_ (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  1250. # [20:35] * Quits: shwetank (~shwetank@cm-84.215.28.236.getinternet.no) (Quit: Leaving...)
  1251. # [20:36] <zewt> annevk: should path step 2 also set fregment to "#", like hierarchical does?
  1252. # [20:39] * Quits: imrobert (~robert@139.62.84.187) (Read error: Operation timed out)
  1253. # [20:39] <zewt> (don't know which is correct, just seems odd that they differ)
  1254. # [20:39] * Parts: rgrove (~rgrove@c-76-105-195-76.hsd1.or.comcast.net)
  1255. # [20:39] * Joins: sedovsek (~robert@89.142.255.129)
  1256. # [20:47] <annevk> zewt: fixed
  1257. # [20:53] * Quits: eric_carlson_ (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Quit: eric_carlson_)
  1258. # [20:53] <Hixie> "Your task is nontrivial"
  1259. # [20:54] <Hixie> story of our lives
  1260. # [20:54] * Quits: izhak (~izhak@188.244.176.232) (Ping timeout: 264 seconds)
  1261. # [20:54] <zewt> "queue a nontrivial task"
  1262. # [20:55] <zewt> (a big queue)
  1263. # [20:57] <jgraham> It does sound like the end of the introduction to a badly translated text adventure, or something
  1264. # [20:57] * Joins: smus (smus@nat/google/x-ncgrzilydnwrstpe)
  1265. # [21:00] <Hixie> cabanier: is your work on adding blending etc to canvas covering things like adding blur effects?
  1266. # [21:03] <annevk> Hixie: not sure if trolling, or just misunderstanding what he's on about
  1267. # [21:04] <Hixie> pretty sure he's not trolling
  1268. # [21:04] <Hixie> he's right that defining the conformance criteria is non-trivial
  1269. # [21:04] <Hixie> but wrong if he thinks that's unusual :-)
  1270. # [21:04] <Hixie> i think it's just the regular culture clash -- ietf and w3c often tend to shy away from fixing hard problems
  1271. # [21:05] <Hixie> same with the shock that we might even consider doing something that we view as obsoleting an IETF STD
  1272. # [21:05] <Hixie> whereas from our point of view, we're like, "look, we said it was broken years ago, we gave you a chance to fix it, now we've timed out and are doing it ourselves"
  1273. # [21:06] <say2joe> hixie: Hooray to that.
  1274. # [21:07] <annevk> I guess indeed it's the regular culture clash, but using "finding URLs in text" as an example as to why we need to restrict the syntax...
  1275. # [21:08] <annevk> but I'm happy you took the time to explain that one
  1276. # [21:08] <Hixie> finding urls in text is indeed something that is impossible if we consider any random string valid
  1277. # [21:08] <Hixie> but (a) we don't, and (b) people don't want to find only valid URLs so that doesn't matter anyway
  1278. # [21:09] * Joins: rniwa (rniwa@nat/google/x-neszosacgypvrujj)
  1279. # [21:09] <Hixie> it's pretty common for people to will the use case to be different because the real use case is hard to fix :-P
  1280. # [21:09] <Hixie> (i do it all the time too :-P)
  1281. # [21:09] <dsheets> annevk: your assertion that the composition of parsing, resolving, and canonicalizing is trivial points to the problem. Your task is not trivial so why should your algorithm be?
  1282. # [21:10] <annevk> dsheets: hey!
  1283. # [21:10] <zewt> when I saw the "why don't you just patch RFC#whatever" post I just grimaced, pitied whoever had to reply to that noise, and moved on :)
  1284. # [21:10] <Hixie> we did patch the RFC
  1285. # [21:10] <Hixie> didn't work well enough. anne's now doing it properly. :-)
  1286. # [21:10] <zewt> exactly :)
  1287. # [21:11] <annevk> dsheets: well, 1) I said "quite trivial" and 2) I guess it is indeed non-trivial, but it is rather easy to follow
  1288. # [21:11] <Hixie> something can be non-trivial to design, yet be trivial in its result
  1289. # [21:12] <Hixie> in fact, the more trivial the solution, typically, the harder one had to work to develop it :-P
  1290. # [21:12] <Hixie> (all other things, e.g. how much the solution solves, being equal)
  1291. # [21:12] <dsheets> annevk: I find it very difficult to follow. What are the allowable alphabets of conforming productions? What normalization is done? It's all mixed together in a prose state machine.
  1292. # [21:12] <annevk> dsheets: and what I like about it in particular is that it is much closer to implementations, so if we want to extend it or implementations want to follow it to fix bugs, things will be a lot easier
  1293. # [21:13] <annevk> dsheets: "c" can be any code point basically, including surrogate code points
  1294. # [21:13] <annevk> dsheets: that's about it
  1295. # [21:13] <Hixie> there's a definition of conforming productions?
  1296. # [21:13] <annevk> nope
  1297. # [21:13] <zewt> dsheets: do you really find IETF-style specs easier to follow than HTML-style algorithmic specs? because you'd be the first I've heard of
  1298. # [21:13] <annevk> need to add that under "Writing" at some point
  1299. # [21:13] * attiks|away is now known as attiks
  1300. # [21:13] <Hixie> dsheets: he hasn't defined what's valid yet.
  1301. # [21:14] <Hixie> zewt: lots of people think declarative is easier than imperative. They're right, when you don't care about defining timing and error handling.
  1302. # [21:14] <Ms2ger> zewt, for authoring, sure
  1303. # [21:14] <Hixie> zewt: see e.g. the websocket protocol hybi mailing list
  1304. # [21:14] <Hixie> zewt: it's really hard to read complex algorithms and work out their implications.
  1305. # [21:15] <zewt> Hixie: personally I find imperative easier even as a user--anne's DOM Events work made the event system infinitely clearer to me, for example
  1306. # [21:15] <dsheets> zewt: for testing, yes
  1307. # [21:15] <zewt> there's a breaking point, of course, depending on the complexity of the algorithm
  1308. # [21:15] <Hixie> zewt: fair enough
  1309. # [21:16] <annevk> dsheets: fwiw, I'm not opposed to including some ABNF somewhere
  1310. # [21:16] * Joins: vikash (~vikash@1.186.9.182)
  1311. # [21:16] * Quits: vikash (~vikash@1.186.9.182) (Changing host)
  1312. # [21:16] * Joins: vikash (~vikash@unaffiliated/vikash)
  1313. # [21:16] <annevk> dsheets: at the moment I'm focused on figuring out parsing (mostly what code browsers/curl/search engines/etc. need to run)
  1314. # [21:17] * Joins: danzik171 (~danzik17@164.55.254.106)
  1315. # [21:18] <dsheets> annevk: mixing parsing and normalization obscures the meaning of a given identifier. Separating the spec into phases and specifying exactly what will pass through unmangled would be very helpful.
  1316. # [21:18] <Hixie> what is "normalisation" here?
  1317. # [21:20] <dsheets> Hixie: producing identifiers over which serialize compose parse is identity
  1318. # [21:20] <dsheets> Hixie: that is, nonconforming -> conforming
  1319. # [21:20] * Joins: mkanat (mkanat@nat/google/x-iolyhqislniykzrq)
  1320. # [21:21] * Quits: danzik17 (~danzik17@164.55.254.106) (Ping timeout: 264 seconds)
  1321. # [21:21] <dsheets> Hixie: canonicalization is related, i believe, but concerns things like hexadecimal case changes where both input and output are conforming but one representation is 'canonical'
  1322. # [21:21] <Hixie> dsheets: i have no idea what what you just said means
  1323. # [21:22] <Hixie> dsheets: how does this differ from "parse"?
  1324. # [21:22] <dsheets> Hixie: which bit? if you parse a conforming URI and then serialize it, the result should be the original URI
  1325. # [21:23] <annevk> hmm; http://example.org is conforming yet gives http://example.org/; or http://example.org:/ gives http://example.org/
  1326. # [21:24] <dsheets> Hixie: perhaps you say that there are conforming URIs that are not canonical and so the result is the canonicalization of the input… feeding this result back through should result in the same string
  1327. # [21:24] <Hixie> dsheets: sounds like what you're saying is "normalisation" is the act of parsing then serialising.
  1328. # [21:24] <Hixie> dsheets: so how could you separate it from parsing?
  1329. # [21:24] <zewt> yeah. conforming and normalized are different things
  1330. # [21:25] <dsheets> Hixie: normalization is whatever you do to produce a valid identifier from an arbitrary input
  1331. # [21:25] <Hixie> dsheets: ok, so, parse then serialise.
  1332. # [21:25] <dsheets> that is how you can test it, yes, but that is not the normalization algorithm
  1333. # [21:25] <Hixie> dsheets: i guess i don't understand what you are asking for.
  1334. # [21:26] <annevk> dsheets: it is in the new spec
  1335. # [21:26] <Hixie> dsheets: the normalisation algorithm is "parse the string. serialise the bits into a url."
  1336. # [21:26] <annevk> dsheets: and for sure parser/serialize is how a typical URL library works
  1337. # [21:26] <Hixie> i don't see how else you could do it
  1338. # [21:26] <dsheets> I am asking for the explicit separation of nonconforming -> conforming as well as conforming -> canonical
  1339. # [21:27] <dsheets> http://www.example.com is conforming but noncanonical. http://www.example.com/ is canonical
  1340. # [21:27] <zewt> to back up a little: what's the purpose of this?
  1341. # [21:27] <annevk> sure, the former is input, the latter is output
  1342. # [21:28] <annevk> that the former is conforming is yet to be written down
  1343. # [21:28] <Hixie> dsheets: i don't think it makes sense to define two different parsers.
  1344. # [21:28] <dsheets> If there are invalid inputs that produce valid outputs, those invalid inputs must undergo some sort of normalization to put them in the space of valid inputs
  1345. # [21:28] <Hixie> dsheets: that would just be asking for them to end up out of sync.
  1346. # [21:29] * Quits: henrikkok (~henrikkok@81.27.221.193) (Quit: Leaving.)
  1347. # [21:29] <Hixie> dsheets: it's better not to think of inputs as valid or invalid
  1348. # [21:29] <Hixie> dsheets: whether a URL is valid or not is really just a minor detail for authoring conformance/lint tools
  1349. # [21:29] <dsheets> Hixie: how can they be out of sync? they compose
  1350. # [21:29] <Hixie> dsheets: to help authors avoid likely mistakes
  1351. # [21:30] * Quits: MacTed (~Thud@63.119.36.36) (Ping timeout: 245 seconds)
  1352. # [21:30] <Hixie> dsheets: i don't see how you could describe a parser that only parses invalid urls and that then passes the result of that to a parser that only accepts valid urls, that would be insane
  1353. # [21:30] <Hixie> dsheets: you'd actually need three parsers then, one for invalid urls, one for valid urls, and one for unknown urls to determine if they were valid or not!
  1354. # [21:30] <annevk> it would be twice the work and nobody would ever implement it that way
  1355. # [21:30] <Hixie> dsheets: just have one parser, it's cleaner
  1356. # [21:31] <annevk> this argument is interesting though
  1357. # [21:31] <annevk> because it's the exact same argument we got from the W3C TAG about the HTML parser
  1358. # [21:31] <Hixie> dsheets: can you imagine what a mess HTML parsing would be if we used that kind of strategy?
  1359. # [21:31] <annevk> nobody else ever cared
  1360. # [21:31] <Hixie> annevk: really? i guess i blissfully missed that
  1361. # [21:31] <Hixie> annevk: or i've blocked it out of my memory :-P
  1362. # [21:32] * Quits: vikash (~vikash@unaffiliated/vikash) (Quit: Leaving)
  1363. # [21:32] <dsheets> Hixie: not parsers, functions. You can compose all these functions in your parser and most implementations will.
  1364. # [21:32] * Joins: MacTed (~Thud@63.119.36.36)
  1365. # [21:32] <Hixie> dsheets: function, parser, same thing
  1366. # [21:32] <annevk> Hixie: I quite clearly remember DanC and such wanting a parser just for valid stuff
  1367. # [21:32] <Hixie> annevk: weird
  1368. # [21:32] <Hixie> dsheets: s/parser/algorithm/ in my argument above, it still holds.
  1369. # [21:33] <dsheets> Hixie: no. Every parser is a function but not every function is a parser. Parsers operate on strings.
  1370. # [21:33] <Hixie> dsheets: that doesn't affect my argument
  1371. # [21:33] <annevk> hsivonen: sad news: "Unicode 6.2 will include the accelerated publication of the character U+20BA TURKISH LIRA SIGN"
  1372. # [21:34] * Quits: hasather_ (~hasather_@cm-84.208.71.130.getinternet.no) (Remote host closed the connection)
  1373. # [21:35] <Hixie> imho, the right way to do this is to have one function that turns a string into components (parser), one that turns components into strings (serialiser), one that turns an incomplete set of components and a complete set of components into one complete set of components (resolution), and one that takes a string and returns a boolean (conformance definition)
  1374. # [21:35] <dsheets> Hixie: Does it? Specifying the composition of these functions for different inputs makes the meaning of the spec much clearer. It is then obvious what inputs are 'safe', what inputs will be mangled, and what inputs will never be mangled.
  1375. # [21:35] <Hixie> dsheets: defining what inputs are safe is done by defining "valid URL", which is an entirely separate problem.
  1376. # [21:36] * Joins: zcorpan (~zcorpan@81-231-170-159-no135.tbcn.telia.com)
  1377. # [21:36] <Hixie> dsheets: in the HTML spec, this is http://whatwg.org/html#writing vs http://whatwg.org/html#parsing
  1378. # [21:36] * Joins: mattgifford (~mattgiffo@108.161.20.199)
  1379. # [21:37] <dsheets> Hixie: it would appear that inside of the parser, you generate a valid URL. Why is this obscured?
  1380. # [21:37] <annevk> Hixie: parser and resolution are merged in the current spec
  1381. # [21:37] * Joins: jamesr (jamesr@nat/google/x-tdmswwgynocjaurq)
  1382. # [21:37] <annevk> Hixie: I haven't written a serializer yet; though the API has various members that serialize URLs in various ways
  1383. # [21:38] <annevk> Hixie: so I might not bother writing an explicit serializer
  1384. # [21:38] <annevk> (never mind, I guess I should for HTTP and such)
  1385. # [21:38] <Hixie> dsheets: i don't understand the question.
  1386. # [21:39] <Hixie> annevk: i need a "parse" algorithm that returns components, and a "resolve" algorithm that returns an absolute url
  1387. # [21:39] <annevk> Hixie: parse always returns an absolute URL
  1388. # [21:39] <Hixie> annevk: how do i get the components?
  1389. # [21:39] <dsheets> Hixie: Why specify only the composition instead of the factors?
  1390. # [21:39] <annevk> Hixie: it returns a URL object that has components
  1391. # [21:39] <Hixie> dsheets: i don't understand what that means
  1392. # [21:40] <annevk> Hixie: but it's always a complete URL (or invalid)
  1393. # [21:40] <Hixie> annevk: if it returns both an absolute URL and components, that's fine by me
  1394. # [21:40] * jernoble is now known as jernoble|afk
  1395. # [21:40] * jernoble|afk is now known as jernoble
  1396. # [21:40] <annevk> Hixie: http://url.spec.whatwg.org/#concept-url is what you get back
  1397. # [21:41] <annevk> Hixie: you parse an "input" into a concept-url, which has concept-url-scheme etc.
  1398. # [21:41] <Hixie> annevk: k
  1399. # [21:41] <Hixie> annevk: lgtm
  1400. # [21:41] <dsheets> annevk: the base may be unknown or ambiguous. Can I defer relative resolution?
  1401. # [21:42] <Hixie> just don't parse it until you need to resovle it
  1402. # [21:43] <annevk> dsheets: hold the "input" until you have the base
  1403. # [21:44] <TabAtkins> zcorpan: I sent email to WHATWG on *behalf* of the SVGWG, *because* we're adopting multi-letter commands. ^_^
  1404. # [21:44] * Quits: zcorpan (~zcorpan@81-231-170-159-no135.tbcn.telia.com) (Remote host closed the connection)
  1405. # [21:45] <dsheets> Hixie: so no means will be provided to manipulate relative references? Relative references can never be serialized?
  1406. # [21:45] * Joins: zcorpan (~zcorpan@81-231-170-159-no135.tbcn.telia.com)
  1407. # [21:45] <Hixie> dsheets: you shouldn't ask me, anne is the editor of this url spec
  1408. # [21:45] <Hixie> dsheets: but i'm sure if you give anne use cases, he will be more than happy to address them
  1409. # [21:46] <Hixie> dsheets: does anything on the web serialise relative urls?
  1410. # [21:46] <dsheets> Hixie: anything that manipulates data structures which use relative references and outputs said data structures...
  1411. # [21:46] <Hixie> dsheets: such as?
  1412. # [21:47] <dsheets> Hixie: DOM transformers
  1413. # [21:47] * Joins: jamesr_ (jamesr@nat/google/x-lqhzzbtlegckpsvl)
  1414. # [21:47] <zewt> (how is it 2012 and gmail doesn't let you add filters to mark as spam?)
  1415. # [21:47] <annevk> dsheets: and they manipulate URLs?
  1416. # [21:48] <dsheets> annevk: sure, partial resolution of URLs is common
  1417. # [21:48] <Hixie> dsheets: do you have an example i can look at?
  1418. # [21:48] <Hixie> zewt: it does
  1419. # [21:48] * Quits: tantek (~tantek@70-36-139-86.dsl.dynamic.sonic.net) (Quit: tantek)
  1420. # [21:49] <smaug____> paul_irish: ping
  1421. # [21:49] <zewt> Hixie: lets you delete, and "never spam", but not "always spam"
  1422. # [21:49] <annevk> dsheets: in any event, if we decide that we do want parsing and resolution separate, that's not really a big deal
  1423. # [21:49] <zewt> i guess since the difference between deleted and spam is so opaque with gmail (if it affects filtering, I can't measure it), i may as well not care
  1424. # [21:49] <Hixie> zewt: huh
  1425. # [21:49] * Quits: zcorpan (~zcorpan@81-231-170-159-no135.tbcn.telia.com) (Ping timeout: 264 seconds)
  1426. # [21:50] <TabAtkins> zewt: I think the intent is that you just mark it as spam normally, and let your filters catch up.
  1427. # [21:50] <Hixie> zewt: i stand corrected.
  1428. # [21:50] <paul_irish> smaug____: yessir
  1429. # [21:50] <zewt> anyway, sorry for the distraction, didn't notice that you were still talking with ds :)
  1430. # [21:50] <Hixie> zewt: i am capable of having multiple conversations at once :-P
  1431. # [21:50] <TabAtkins> s/filters/normal spam filter/
  1432. # [21:50] <Hixie> zewt: (whenever i'm chatting here i'm also editing the spec :-P)
  1433. # [21:50] <dsheets> Hixie: not off-hand, no. You can't conceive of converting a relative path into an absolute path or a schemed URI into a scheme relative URI?
  1434. # [21:51] <zewt> well, i try to limit random irrelevant drop-ins to when there isn't an on-topic discussion going on :)
  1435. # [21:51] <Hixie> dsheets: if you have no concrete examples, i have no trouble saying we don't need to address it.
  1436. # [21:51] <Hixie> dsheets: i have never found a need to do so, personally
  1437. # [21:51] <smaug____> paul_irish: just curious, based on what is some test added to robohornet
  1438. # [21:52] <dsheets> Hixie: really? I have done this numerous times in numerous languages. Absolutizing URI references is useful.
  1439. # [21:52] <Hixie> dsheets: i'd be happy to look at concrete examples
  1440. # [21:52] <Hixie> dsheets: resolving urls is certainly useful, and the algorithm anne is defining does so
  1441. # [21:53] <smaug____> (the range API for example looks very odd, since it ends up adding element with same id 50 times to document)
  1442. # [21:53] <Hixie> smaug____: sounds realistic :-P
  1443. # [21:53] <dsheets> Hixie: you are stonewalling. Please address the technical consideration.
  1444. # [21:54] <dsheets> Hixie: resolution and partial resolution are different
  1445. # [21:54] <zewt> he's asking for use cases--what you actually want to do (or would want to do) that the proposed API and spec doesn't handle
  1446. # [21:54] <smaug____> paul_irish: you probably also saw https://github.com/robohornet/robohornet/issues/66 . It means that some tests are actually testing something else than what they are supposed to test
  1447. # [21:54] <smaug____> Hixie: sure :)
  1448. # [21:54] <Hixie> dsheets: i'm not the editor, anne is the one who will address issues on this spec. I'm just trying to explain to you how we work.
  1449. # [21:54] <paul_irish> smaug____: based on isolated performance issues that have been identified in a few notable js applications and libraries. they've been reduced down to a useful quantity of code
  1450. # [21:54] <zewt> that isn't stonewalling, it's the standard approach here
  1451. # [21:54] <Hixie> dsheets: and the way we work is we don't address hypotheticals
  1452. # [21:54] <paul_irish> smaug____: yeah 66 looks legit.
  1453. # [21:54] <Hixie> dsheets: if you have done it as many times as you say, then you need but document them for us
  1454. # [21:55] <Hixie> dsheets: e.g. a pointer to a page that does it
  1455. # [21:55] <dsheets> Hixie: resolving foo/bar against /baz/ into /baz/foo/bar
  1456. # [21:55] <Hixie> dsheets: do you have an example of something that does that?
  1457. # [21:55] <paul_irish> smaug____: benchmark.js seems to be the strongest harness for benchmarking, but yeah produces some problems with this test in partic
  1458. # [21:56] <dsheets> Hixie: resolving #frag against path into path#frag
  1459. # [21:56] <smaug____> paul_irish: I was looking at DOM Range test, because I know that code is probably the least optimized code in Gecko... but then the test is actually spending time everywhere else but in Range code
  1460. # [21:56] <smaug____> paul_irish: "some" problems
  1461. # [21:56] <Hixie> dsheets: do you have an example of something that does that?
  1462. # [21:56] <smaug____> paul_irish: if you run the innerHTML testfile itself, it ends up testing innerHTML
  1463. # [21:56] <paul_irish> yeah
  1464. # [21:56] <Hixie> dsheets: it's easy to come up with arbitrary needs, but those aren't use cases
  1465. # [21:56] <smaug____> if you use the testharness, it tests something else too
  1466. # [21:57] <zewt> dsheets: the question isn't what it is (we get that--modifying relative paths as-is without resolving them), it's why you want to do it
  1467. # [21:57] <Hixie> dsheets: use cases are concrete examples of actual problems met by real users
  1468. # [21:57] <paul_irish> smaug____: really appreciate you, boris, kyle, others looking at these btw
  1469. # [21:57] <paul_irish> yes
  1470. # [21:57] <smaug____> paul_irish: anyhow, sounds like the usual problems with tests. Testing something else than one is supposed to test :)
  1471. # [21:57] <annevk> dsheets: I have looked into this, and as far as http://platform.html5.org is concerned, only parsing input (maybe combined with a base URL) into a URL is what is visibly exposed
  1472. # [21:58] <annevk> dsheets: and actually used
  1473. # [21:58] <dsheets> Hixie: I am a real user and I have personally constructed systems to do this for real world use cases. It is useful in conjunction with pushState.
  1474. # [21:58] <annevk> dsheets: and although I have found some libraries that do the kind of thing you mentioned just now, I have never seen a request for such functionality before
  1475. # [21:58] * Quits: danielfilho|w (~danielfil@187.31.77.7) (Remote host closed the connection)
  1476. # [21:58] <zewt> how, concretely, is it useful with pushState?
  1477. # [21:59] <paul_irish> smaug____: is the range issue that the gEBId soaking up the time?
  1478. # [21:59] <zewt> (i've used pushState extensively; I give it relative URLs, and it pushes a resolved absolute URL)
  1479. # [21:59] <zewt> not doubting you, just trying to get closer to what you want to do
  1480. # [22:00] <Hixie> dsheets: can you provide me with a URL to such a page?
  1481. # [22:00] <smaug____> paul_irish: the range test is actually testing parsing time ( r.createContextualFragment(REPLACEMENT_HTML) ) and inserting something to DOM ( r.insertNode )
  1482. # [22:00] <smaug____> very little about range specific stuff
  1483. # [22:01] <dsheets> Hixie: http://ashimagroup.net/~sheets/demo/pano/mars/#?az=1.020944687796126&el=-0.11416091059502942 The same app is served for http://ashimagroup.net/~sheets/demo/pano/mars/msl/nav1/ after partial relative resolution to root the common assets to the domain
  1484. # [22:02] <Hixie> can you elaborate on his this works? where do i see the partial resolution?
  1485. # [22:02] <annevk> Hixie: btw, on http://url.spec.whatwg.org/ and http://xhr.spec.whatwg.org/ dfn.js does not work
  1486. # [22:02] * Joins: bentruyman (~bentruyma@li159-104.members.linode.com)
  1487. # [22:03] <paul_irish> smaug____: got it. making a ticket.
  1488. # [22:03] <Hixie> annevk: any idea why not?
  1489. # [22:03] <annevk> actually on xhr it just complaints about some cookie function
  1490. # [22:03] <annevk> but on url it fails
  1491. # [22:03] <Hixie> annevk: probably missing some other script it relies on
  1492. # [22:03] <smaug____> paul_irish: Add rows to ticket seems to test reflow, so looks like the issue 66
  1493. # [22:03] * Joins: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
  1494. # [22:03] <annevk> Hixie: for url it says "Uncaught TypeError: Object function Object() { [native code] } has no method 'push' "
  1495. # [22:04] <dsheets> Hixie: currently it is done at build time
  1496. # [22:04] <Hixie> annevk: no idea
  1497. # [22:04] <zewt> in other news, onerror in ios 6 safari finally gives useful info, huzzah
  1498. # [22:04] <annevk> Hixie: Opera says
  1499. # [22:04] <zewt> also usable remote debugging, huzzah^2
  1500. # [22:04] <annevk> Error thrown at line 26, column 10 in <anonymous function>() in http://www.whatwg.org/specs/web-apps/current-work/dfn.js:
  1501. # [22:04] <annevk> dfnMap[s].push(links[k]);
  1502. # [22:04] <Hixie> dsheets: can you elaborate? (this is exactly the kind of thing that is useful here)
  1503. # [22:04] * Quits: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Max SendQ exceeded)
  1504. # [22:04] <smaug____> paul_irish: oh, AddRows explicitly wants to flush layout. Then it is testing the thing it tries to test :)
  1505. # [22:05] <paul_irish> smaug____: whats your github username
  1506. # [22:05] <smaug____> hmm, I did have one...
  1507. # [22:05] <smaug____> can't recall
  1508. # [22:06] <smaug____> I'll follow robohornet issues
  1509. # [22:06] <dsheets> Hixie: elaborate on what? The absolute path is unknown in development. The host is unknown at deploy time. The scheme is unknown at run time.
  1510. # [22:06] <Hixie> cabanier: your input on the most recent mail to whatwg would be most helpful (re your blending spec)
  1511. # [22:07] <Hixie> dsheets: i'm trying to understand what happens in the build process.
  1512. # [22:07] <annevk> Hixie: so if I want that fixed I will have to debug?
  1513. # [22:07] <Hixie> annevk: yup :-)
  1514. # [22:07] <paul_irish> smaug____: https://github.com/robohornet/robohornet/issues/69
  1515. # [22:07] <Hixie> annevk: or send me mail
  1516. # [22:07] <Hixie> annevk: no eta
  1517. # [22:08] <Hixie> dsheets: e.g. why can't you just use relative URLs? Why do you have something to partially resolve?
  1518. # [22:08] <annevk> yeah okay, I'll look into it some day, might learn a thing or two
  1519. # [22:08] <Hixie> dsheets: how do you do it today?
  1520. # [22:08] <smaug____> paul_irish: thanks
  1521. # [22:09] <dsheets> Hixie: the relative path "panos/MER.jpg" is resolved to "/~sheets/demo/pano/mars/panos/MER.jpg"
  1522. # [22:09] <Hixie> dsheets: but why? why not just leave it as panos/MER.jpg ?
  1523. # [22:10] <dsheets> Hixie: the same source is served for all subpaths and the display is switched in JS to accomodate pushState
  1524. # [22:11] <Hixie> why are there multiple subpaths
  1525. # [22:11] <Hixie> sorry if it sounds like i'm being stupid here but this really feels like trying to get blood from a stone
  1526. # [22:12] <dsheets> Hixie: I'm sorry you are having a hard time understanding. I will try to explain more clearly.
  1527. # [22:14] <dsheets> Hixie: your question is "why are there multiple subpaths in your single-page pushState-using web app?"? Is that accurate? Why not?
  1528. # [22:14] * Joins: nessy (~silviapf@124-168-3-236.dyn.iinet.net.au)
  1529. # [22:14] * Quits: sicking (~chatzilla@nat/mozilla/x-evxlcsxlgfbxskft) (Ping timeout: 248 seconds)
  1530. # [22:14] <Hixie> dsheets: well specifically, why would your one-page app be exposed using multiple URLs when its resources are only exposed at one URL each
  1531. # [22:15] <Hixie> dsheets: what user-problem does this solve?
  1532. # [22:15] <Hixie> dsheets: seems like a much simpler solution would be to just have one URL, and then you wouldn't have to resolve any resource URLs
  1533. # [22:15] <Hixie> dsheets: in terms of spec problems, we don't solve hypotheticals, but we also don't solve unnecessary problems, hence i'm trying to work out why this is a necessary problem rather than just make-work
  1534. # [22:15] * Quits: Ms2ger (~Ms2ger@kotnet-146.kulnet.kuleuven.be) (Quit: nn)
  1535. # [22:16] * Quits: erichynds (~ehynds@64.206.121.41)
  1536. # [22:16] <dsheets> Hixie: How do I have one URL for multiple resources? Doesn't pushState allow me to design my URI scheme in a way that keeps distinct resources distinct?
  1537. # [22:17] <dsheets> Hixie: your dismissive attitude is unnecessary.
  1538. # [22:18] <Hixie> dsheets: ok i'm going for lunch, i'll be back in a few. I recommend writing an e-mail the describes your use case, and why it is important, and sending it to the WHATWG list. I recommend doing so in a manner that actually describes the entirety of the problem and doesn't feel as reluctant to share as this conversation has.
  1539. # [22:18] <Hixie> bbiab.
  1540. # [22:20] <annevk> dsheets: so is your concern that the specification no longer addresses ../foo resolved against /bar/?
  1541. # [22:20] * BennyLava` is now known as BennyLava
  1542. # [22:20] <annevk> dsheets: or do you want an API that resolves ../foo against /bar/?
  1543. # [22:20] <annevk> dsheets: there's certainly no such API now, so you must use a workaround of some kind
  1544. # [22:21] <annevk> dsheets: in any event, concrete examples would go a long way (unfortunately does require some work)
  1545. # [22:22] * Quits: nessy (~silviapf@124-168-3-236.dyn.iinet.net.au) (Quit: Leaving.)
  1546. # [22:24] <dsheets> annevk: I want to be able to parse a URI reference in a JSON object, use the browser API to normalize/canonicalize/whatever it, and re-emit a relative URI reference in a JSON object. If parsing entails resolution into an absolute URI, I have to know which bits of the input URI are present, resolve it against a dummy base and then throw away the bits that come from the dummy base.
  1547. # [22:24] * Quits: krawchyk (~krawchyk@65.220.49.251) (Remote host closed the connection)
  1548. # [22:25] <annevk> yeah, you can hack around it like that
  1549. # [22:26] <dsheets> annevk: yeah, so that's not so cool because now I can't simply use the API, I have to inspect the string itself and bring my own code to understand which components are present.
  1550. # [22:26] <annevk> but that wouldn't give you things like input: http://example.org/test/bar/ and /test/foo -> "../foo"
  1551. # [22:27] <annevk> I mean there's all kinds of stuff you could write, but it's kinda nice to know the use cases
  1552. # [22:27] <dsheets> annevk: which sort of makes the API (which is already doing this internally) unusable
  1553. # [22:27] * Joins: drublic_ (~drublic@frbg-4d028f07.pool.mediaWays.net)
  1554. # [22:28] <dsheets> annevk: that is not he algorithm I am talking about. relativization is significantly more complicated and I do not expect it in the API.
  1555. # [22:29] <annevk> okay, so this complaint is about the API, not the way the spec is written?
  1556. # [22:30] <annevk> because that wasn't really clear to me
  1557. # [22:30] <dsheets> annevk: I want the browser to supply a function that takes "/%65/" and outputs "/e/" or "#%65" and outputs "#e", for example
  1558. # [22:31] * Joins: espadrine (~thaddee_t@85-218-9-34.dclient.lsne.ch)
  1559. # [22:31] <annevk> the browser does no such thing now...
  1560. # [22:31] <annevk> but you can use encodeURI and decodeURI for that
  1561. # [22:31] <annevk> (it does no such thing if you put those in places that take actual URLs)
  1562. # [22:32] <annevk> anyway, I need to get some sleep
  1563. # [22:33] <dsheets> annevk: doesn't the spec specify the API? If the spec says parsing and relative resolution are always composed and parsing can only occur relative to a base URI, then I can't use its normalization.
  1564. # [22:33] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
  1565. # [22:33] <annevk> there's no normalization like %65 -> e
  1566. # [22:34] <annevk> %65 stays the same
  1567. # [22:34] <annevk> ™ will turn into %E2%84%A2
  1568. # [22:35] <annevk> but %E2%84%A2 will never upon parsing turn into ™
  1569. # [22:35] <annevk> but using JavaScript's encodeURI and decodeURI you can go both ways
  1570. # [22:38] <dsheets> annevk: you are correct. Take relative path components, then. Or your trademark example… I have the string "#™" and want to encode/decode this… the "#" is not handled how I would expect by encode/decode.
  1571. # [22:40] <dsheets> a = document.createElement("a"); a.href = "../foo"; a.href now stringifies to the absolute URI with relative path components resolved
  1572. # [22:41] <annevk> yeah
  1573. # [22:41] <annevk> you can get a.pathname if you just want the path
  1574. # [22:42] <annevk> there's actually only very little code points affected in the fragment part
  1575. # [22:42] <annevk> only some whitespace code points are ignored, that's it
  1576. # [22:42] <dsheets> annevk: I want the same components that I passed in, but now normalized.
  1577. # [22:43] <dsheets> annevk: ">" in fragment? "]" in fragment?
  1578. # [22:43] <annevk> dsheets: stays the same
  1579. # [22:44] <annevk> dsheets: even U+0000 although maybe we should drop that just like U+000A
  1580. # [22:44] <annevk> dunno
  1581. # [22:45] <dsheets> annevk: why aren't they percent encoded in the normal form? NUL seems dangerous.
  1582. # [22:45] <annevk> because browsers don't do that
  1583. # [22:45] * Joins: craig_lock (~craig_loc@static-173-50-48-6.syrcny.fios.verizon.net)
  1584. # [22:45] <annevk> and it's not really needed anyway, it doesn't go over the wire
  1585. # [22:45] * Quits: craig_lock (~craig_loc@static-173-50-48-6.syrcny.fios.verizon.net) (Client Quit)
  1586. # [22:45] * Joins: nessy (~silviapf@1.125.222.133)
  1587. # [22:46] <annevk> (even over the wire it's not strictly needed and IE is known for sending raw utf-8 octets in some cases)
  1588. # [22:46] <dsheets> annevk: uhh? how do you mean? are the percent-encoded forms equivalent to the literal forms?
  1589. # [22:47] * Joins: tantek (~tantek@nat/mozilla/x-gzgomwlzidwrmnpc)
  1590. # [22:47] <annevk> well they're "considered" equivalent but they're not if you do e.g. string comparison
  1591. # [22:47] <annevk> as many people do
  1592. # [22:48] * Quits: rworth (~rworth@209-255-211-4.ip.mcleodusa.net) (Quit: Leaving...)
  1593. # [22:49] <dsheets> annevk: How do I access a comparison function that returns true for "]" and "%5d"?
  1594. # [22:49] <annevk> there's no such thing
  1595. # [22:50] <dsheets> why not? aren't they equivalent in URI space?
  1596. # [22:51] <dsheets> a.href === b.href returns false
  1597. # [22:51] <annevk> there's no URI in user agents
  1598. # [22:51] <dsheets> "URLUtils"
  1599. # [22:52] <annevk> yeah they'd not be equivalent and you'd get different requests to the server
  1600. # [22:52] <annevk> one containing ] and one containing %5d
  1601. # [22:52] <annevk> even %5d and %5D result in different requests
  1602. # [22:52] <annevk> STD 66 allows for all that btw
  1603. # [22:52] <annevk> they don't really place any requirements
  1604. # [22:52] <annevk> which is why it's quite useless
  1605. # [22:54] <dsheets> yes… so you will not perform any canonicalization or normalization? just parse+resolve and that's it?
  1606. # [22:54] * Quits: a-ja (~chatzilla@70.230.163.14) (Ping timeout: 264 seconds)
  1607. # [22:55] <annevk> well there's some
  1608. # [22:55] <annevk> see e.g. the bits about percent encoded
  1609. # [22:55] <annevk> how \ turns into / most of the time, etc.
  1610. # [22:55] <annevk> how http://example.org: turns into http://example.org/ etc.
  1611. # [22:55] <annevk> or http://example.org:80 becomes http://example.org/
  1612. # [22:56] <annevk> at some point it will define how http://EXAMPLE/ becomes http://example/ (host names and IP addresses need some more research)
  1613. # [22:56] <annevk> schemes are lowercased
  1614. # [22:56] <annevk> there's a bunch of stuff
  1615. # [22:56] <annevk> (when I think about it)
  1616. # [22:56] <annevk> anyway, bedtime
  1617. # [22:57] * tantek compares http://url.spec.whatwg.org/ to the table in http://tantek.com/2011/238/b1/many-ways-slice-url-name-pieces and wonders if he will need to add another row.
  1618. # [22:58] * Joins: sicking (~chatzilla@nat/mozilla/x-jdxfwtvdphrvvgzz)
  1619. # [22:58] <annevk> ah damn it, hey tantek!
  1620. # [22:58] <annevk> tantek: I saw that table and it's pretty awesome
  1621. # [22:59] * Quits: mpt (~mpt@canonical/mpt) (Read error: Connection reset by peer)
  1622. # [22:59] <annevk> tantek: if you have any particular opinion on terms to use it's much appreciated
  1623. # [22:59] <annevk> tantek: I'm pretty flexible on that front
  1624. # [22:59] <annevk> nn
  1625. # [23:01] * Quits: nessy (~silviapf@1.125.222.133) (Quit: Leaving.)
  1626. # [23:01] * Quits: dgathright (~dgathrigh@nat/yahoo/x-ewbneagxvemxltwe) (Ping timeout: 240 seconds)
  1627. # [23:02] * Joins: a-ja (~chatzilla@70.230.163.14)
  1628. # [23:03] * Quits: drublic_ (~drublic@frbg-4d028f07.pool.mediaWays.net) (Remote host closed the connection)
  1629. # [23:03] * Joins: drublic (~drublic@frbg-4d028f07.pool.mediaWays.net)
  1630. # [23:04] * Joins: mpt (~mpt@faun.canonical.com)
  1631. # [23:04] * Quits: mpt (~mpt@faun.canonical.com) (Changing host)
  1632. # [23:04] * Joins: mpt (~mpt@canonical/mpt)
  1633. # [23:05] <tantek> annevk nn - I have no / little particular preference on terms - was more just dismayed at how much a supposedly "simple" thing was reinvented/renamed. We can discuss when you get back online tomorrow morning.
  1634. # [23:08] * Joins: PalleZingmark (~Adium@90-229-139-33-no195.tbcn.telia.com)
  1635. # [23:08] * Quits: ap (~ap@2620:149:4:1b01:808c:e015:ab04:503d) (Quit: ap)
  1636. # [23:10] * Joins: isherman-book (Adium@nat/google/x-wigsnwqkhovtyswf)
  1637. # [23:14] * Quits: MacTed (~Thud@63.119.36.36)
  1638. # [23:15] * jernoble is now known as jernoble|afk
  1639. # [23:15] * jernoble|afk is now known as jernoble
  1640. # [23:20] * Joins: dgathright (~dgathrigh@c-67-169-92-165.hsd1.ca.comcast.net)
  1641. # [23:21] * Joins: nessy (silviapf@nat/google/x-dnzeyrxhknxebqvt)
  1642. # [23:21] * Quits: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  1643. # [23:25] * Quits: jarib (~jarib@unaffiliated/jarib) (Excess Flood)
  1644. # [23:26] * Joins: jarib (~jarib@unaffiliated/jarib)
  1645. # [23:26] * Quits: sicking (~chatzilla@nat/mozilla/x-jdxfwtvdphrvvgzz) (Remote host closed the connection)
  1646. # [23:29] * Joins: JonathanNeal (u5831@gateway/web/irccloud.com/x-nqkkefedvcivbhux)
  1647. # [23:31] * Joins: danielfilho (~danielfil@200-158-125-170.dsl.telesp.net.br)
  1648. # [23:31] <rniwa> annevk: yt?
  1649. # [23:33] <Hixie> tantek: man, if that's not a testament to the URL spec being deficient, i dunno what is :-) nice table
  1650. # [23:33] <tantek> Hixie, yeah, this is what happen when I try to re-use existing work and end up documenting a mess instead :(
  1651. # [23:34] * Joins: ojan_away (u5519@gateway/web/irccloud.com/x-lydnplsvwzdtujqe)
  1652. # [23:34] <rniwa> Who here knows WebIDL?
  1653. # [23:34] * ojan_away is now known as ojan
  1654. # [23:34] <zewt> death to "search"
  1655. # [23:34] <tantek> also, I have maybe 2 more frameworks/standards that use different terms for URL pieces that I have yet to add to the table
  1656. # [23:34] <TabAtkins> rniwa: Several of us, at least kinda?
  1657. # [23:34] <zewt> also to "fragment" :(
  1658. # [23:35] * Joins: ap (~ap@2620:149:4:1b01:29da:c3d0:b272:3806)
  1659. # [23:35] <rniwa> TabAtkins: so... how do I write a callback interface where callbacks are optional?
  1660. # [23:35] <rniwa> TabAtkins: for undo manager's DOMTransaction interface, all properties are optional.
  1661. # [23:35] <rniwa> TabAtkins: including callback methods
  1662. # [23:35] <tantek> zewt - which is your preferred set of terms for the pieces of a URL?
  1663. # [23:36] <TabAtkins> You can make any property optional, including ones that take a callback.
  1664. # [23:36] <rniwa> TabAtkins: what's the syntax for that?
  1665. # [23:37] * Quits: ap (~ap@2620:149:4:1b01:29da:c3d0:b272:3806) (Client Quit)
  1666. # [23:37] <zewt> intuitively, "query" and "hash" (those are the only really "contended" ones)
  1667. # [23:37] <tantek> btw - when I add the 2 pending splits, that will make 14 different ways people have come up with for expressing the parts of URLs. The URL spec will then be the 15th, thus fulfilling the prophecy foretold in XKCD 927.
  1668. # [23:37] <tantek> so are you a "scheme" guy or a "protocol" guy?
  1669. # [23:38] <TabAtkins> rniwa: I'm confused - it's the same as any other optional thing. When you define a callback, it just creates a new type that you can use elsewhere.
  1670. # [23:38] <TabAtkins> tantek: I'm more of a "boobs" guy.
  1671. # [23:38] <zewt> ("host" vs. "hostname", "path" vs "pathname" are trivial differences; i'd have preferred protocol to scheme, but that one's long gone)
  1672. # [23:38] <zewt> TabAtkins: try dieting and exercise
  1673. # [23:39] <zewt> *crickets*
  1674. # [23:42] <zewt> the "1996 HTTP RFC" row makes me :|
  1675. # [23:42] <TabAtkins> Why?
  1676. # [23:42] <zewt> because it's five rows, heh
  1677. # [23:42] <TabAtkins> jQuery 2011 is 6. ^_^
  1678. # [23:43] <Hixie> "scheme" is the http: part of a URL, "protocol" is what set of rules the scheme maps to (HTTP)
  1679. # [23:43] <zewt> interesting that (if I'm reading this table correctly) in every case, the "search" name includes the ? and the "query" name does not
  1680. # [23:43] <zewt> a pattern I hadn't noticed
  1681. # [23:43] * Joins: ap (~ap@2620:149:4:1b01:545a:c718:739d:b4ca)
  1682. # [23:43] * tantek sends TabAtkins to the inclusivity dungeon.
  1683. # [23:43] <TabAtkins> tantek: Yeah, I know, bad on me. It was too obvious for me to pass up. :(
  1684. # [23:43] <tantek> zewt - that is correct.
  1685. # [23:44] <zewt> almost the same pattern for hash/fragment, with a couple misses
  1686. # [23:45] <tantek> I built the table for exactly that reason, to see what patterns (if any) would be revealed.
  1687. # [23:45] <zewt> (wouldn't necessarily say it's a *useful* distinction, but it's an interesting one)
  1688. # [23:45] <tantek> yeah
  1689. # [23:45] <zewt> (that is, the pattern--whether you include it or don't include it is certainly important from an API standpoint)
  1690. # [23:46] * Quits: danzik171 (~danzik17@164.55.254.106) (Ping timeout: 265 seconds)
  1691. # [23:47] * Joins: abarth_ (~abarth@50-76-44-122-ip-static.hfc.comcastbusiness.net)
  1692. # [23:48] <zewt> Hixie: sure, I just don't think the distinction is necessary in this context (but as far as naming goes this one's been decided--scheme it is!)
  1693. # [23:48] <Hixie> othermaciej: yt?
  1694. # [23:48] <Hixie> zewt: yeah i dunno if the distinction makes sense either.
  1695. # [23:48] <Hixie> zewt: people often refer to the thing, and the identifier for the thing, by the same name
  1696. # [23:48] <othermaciej> Hixie: yeah, but I have weinig here in my office so not totally paying attention to IRC
  1697. # [23:49] * Quits: abarth_ (~abarth@50-76-44-122-ip-static.hfc.comcastbusiness.net) (Client Quit)
  1698. # [23:49] <Hixie> othermaciej: k, just had a quick q RE: the bugs you want cloned back; do you want them reresolved also? Most of them are things I never actually resolved, just punted for a few months, and was planning on reopening (i'll be doing that in january for the whatwg ones)
  1699. # [23:50] <othermaciej> Hixie: my preference would be to leave them with their prior resolution, even if it was LATER or REMIND
  1700. # [23:50] <Hixie> othermaciej: roger
  1701. # [23:51] * Joins: sicking (~chatzilla@nat/mozilla/x-qgwlfmvmtivkwzqg)
  1702. # [23:52] * Joins: danzik17 (~danzik17@ool-435606a9.dyn.optonline.net)
  1703. # [23:53] <tantek> Hixie, zewt, re: scheme vs. protocol, the real question is, does "protocol" include the trailing ":" or not? For a good time, see this github thread discussion that very issue in Node.js: https://github.com/joyent/node/pull/1580
  1704. # [23:54] <tantek> *discussing
  1705. # [23:54] <Hixie> i'll let anne worry about that :-)
  1706. # [23:57] * Joins: Smylers (~smylers@host86-167-76-92.range86-167.btcentralplus.com)
  1707. # Session Close: Wed Sep 26 00:00:00 2012

The end :)