/irc-logs / freenode / #whatwg / 2009-09-17 / end

Options:

  1. # Session Start: Thu Sep 17 00:00:00 2009
  2. # Session Ident: #whatwg
  3. # [00:03] * Quits: ap (n=ap@nat/apple/x-wppeexrsxuehrwsz)
  4. # [00:03] * Quits: ericc|away (n=ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net)
  5. # [00:04] * Joins: ap (n=ap@17.246.19.174)
  6. # [00:07] * Joins: jamesr_ (n=jamesr@nat/google/x-ndvrfejkvcwrgxmk)
  7. # [00:07] <TabAtkins> http://www.xanthir.com/:v3z <-- basic reimplementation of Kemp's slides using the above hack
  8. # [00:07] * aroben is now known as aroben|meeting
  9. # [00:08] <TabAtkins> The slides are id'ed as #s1, #s2, etc.
  10. # [00:09] * Quits: jamesr_ (n=jamesr@nat/google/x-ndvrfejkvcwrgxmk) (Client Quit)
  11. # [00:10] * Quits: hobertoAtWork (n=hobertoa@198.45.18.20) ("Nettalk6 - www.ntalk.de")
  12. # [00:12] * Quits: taf2 (n=taf2@38.99.201.242)
  13. # [00:12] * Joins: jamesr_ (n=jamesr@nat/google/x-fugwrtjazpofjngh)
  14. # [00:12] * Quits: jamesr_ (n=jamesr@nat/google/x-fugwrtjazpofjngh) (Client Quit)
  15. # [00:16] * Quits: jamesr (n=jamesr@nat/google/x-zvpgmtnlmxziuhfb) (Read error: 110 (Connection timed out))
  16. # [00:17] * Quits: paul_irish (n=paul_iri@12.33.239.250)
  17. # [00:19] * Joins: GarethAdams_ (n=GarethAd@pdpc/supporter/active/GarethAdams)
  18. # [00:20] * Quits: virtuelv (n=virtuelv@125.175.251.212.customer.cdi.no) (Read error: 60 (Operation timed out))
  19. # [00:23] * Joins: jamesr (n=jamesr@nat/google/x-aqadnuokaaauwmnz)
  20. # [00:24] * Joins: cying_ (n=cying@70.90.171.153)
  21. # [00:26] * Quits: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com) (Read error: 113 (No route to host))
  22. # [00:27] * Quits: jamesr (n=jamesr@nat/google/x-aqadnuokaaauwmnz) (Client Quit)
  23. # [00:28] <annevk42> Hixie, shouldn't http://html5.org/tools/web-apps-tracker?from=3877&to=3878 be INVALID_STATE_ERR?
  24. # [00:30] * Quits: heycam (n=cam@210-84-56-211.dyn.iinet.net.au) ("bye")
  25. # [00:30] * Quits: cying_ (n=cying@70.90.171.153) (Remote closed the connection)
  26. # [00:30] * Quits: cying (n=cying@70.90.171.153) (Read error: 104 (Connection reset by peer))
  27. # [00:30] * Joins: cying (n=cying@70.90.171.153)
  28. # [00:36] * Joins: Binarytales (n=Binaryta@host81-157-255-224.range81-157.btcentralplus.com)
  29. # [00:36] * Joins: jamesr (n=jamesr@nat/google/x-ogxmwqieeocmhuqi)
  30. # [00:37] * Quits: jamesr (n=jamesr@nat/google/x-ogxmwqieeocmhuqi) (Client Quit)
  31. # [00:37] * Joins: othermaciej (n=mjs@17.246.17.210)
  32. # [00:37] * Quits: Binarytales (n=Binaryta@host81-157-255-224.range81-157.btcentralplus.com) (Client Quit)
  33. # [00:41] * Quits: dglazkov (n=dglazkov@nat/google/x-kfbgeyjofkvxdyfv)
  34. # [00:41] * Quits: franksalim (n=frank@adsl-75-61-85-210.dsl.pltn13.sbcglobal.net) ("Leaving")
  35. # [00:42] * Joins: doublec (n=doublec@203-97-204-82.dsl.clear.net.nz)
  36. # [00:49] * Quits: takoratta (n=takoratt@p1173-ipbf2410marunouchi.tokyo.ocn.ne.jp) (Read error: 110 (Connection timed out))
  37. # [00:50] * Quits: ifette (n=ifette@nat/google/x-xklpbnaichwyeqqs) (Read error: 110 (Connection timed out))
  38. # [00:52] * Quits: othermaciej (n=mjs@17.246.17.210)
  39. # [00:54] * Joins: jamesr (n=jamesr@nat/google/x-gjomugkjhscvcqzh)
  40. # [00:55] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) (Remote closed the connection)
  41. # [00:59] * Quits: jamesr (n=jamesr@nat/google/x-gjomugkjhscvcqzh) (Client Quit)
  42. # [01:00] * Joins: othermaciej (n=mjs@17.244.10.163)
  43. # [01:02] * Quits: othermaciej (n=mjs@17.244.10.163) (Client Quit)
  44. # [01:03] * Joins: othermaciej (n=mjs@17.244.10.163)
  45. # [01:05] * Joins: Super-Dot (n=Super-Do@66-240-27-3.isp.comcastbusiness.net)
  46. # [01:08] * Joins: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  47. # [01:10] * Quits: annevk42 (n=annevk@5355732C.cable.casema.nl)
  48. # [01:12] * Joins: ifette (n=ifette@nat/google/x-vbxezqfsoeemmjwz)
  49. # [01:12] * Joins: boblet (n=boblet@p1254-ipbf304osakakita.osaka.ocn.ne.jp)
  50. # [01:18] * Joins: webben (n=benh@91.85.72.193)
  51. # [01:18] * Quits: dbaron (n=dbaron@nat/mozilla/x-fcdysxhvhebtfblu) ("8403864 bytes have been tenured, next gc will be global.")
  52. # [01:19] * Quits: aroben|meeting (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  53. # [01:21] <Hixie> microdata in the wild: http://dragnetslegacy.blogspot.com/
  54. # [01:22] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  55. # [01:24] * Quits: Super-Dot (n=Super-Do@66-240-27-3.isp.comcastbusiness.net)
  56. # [01:25] * Joins: Super-Dot (n=Super-Do@66-240-27-3.isp.comcastbusiness.net)
  57. # [01:40] * Quits: TabAtkins (n=chatzill@adsl-69-151-221-188.dsl.hstntx.swbell.net) (Read error: 110 (Connection timed out))
  58. # [01:40] <roc> why does the structured clone algorithm force leaf objects to be cloned?
  59. # [01:40] <roc> when they could be shared?
  60. # [01:43] <roc> for example if you have an array of N references to the same ImageData object, structured clone gives you back an array with N different ImageData objects
  61. # [01:47] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  62. # [01:53] * Quits: othermaciej (n=mjs@17.244.10.163)
  63. # [01:54] * Joins: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu)
  64. # [02:02] * Joins: takoratta (n=takoratt@220.109.219.244)
  65. # [02:04] * Quits: arun___ (n=arun@nat/mozilla/x-pdfekexgsmkjkoyz)
  66. # [02:07] * Joins: MikeSmith (n=MikeSmit@EM114-48-246-111.pool.e-mobile.ne.jp)
  67. # [02:10] <Philip`> c14n is far too much fun
  68. # [02:11] * Quits: ttepass- (n=ttepas--@p5B016A3B.dip.t-dialin.net) ("?Q")
  69. # [02:12] * Joins: _crow (n=miketayl@user-0cdf5gs.cable.mindspring.com)
  70. # [02:12] * Joins: ifette_GOOG (n=ifette@216.239.45.4)
  71. # [02:13] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) (Remote closed the connection)
  72. # [02:13] * _crow is now known as miketaylr_
  73. # [02:16] * Quits: weinig (n=weinig@17.246.16.129)
  74. # [02:17] * Quits: cying (n=cying@70.90.171.153)
  75. # [02:17] * Joins: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu)
  76. # [02:20] * Quits: lazni (n=lazni@118.71.115.2) ("Leaving.")
  77. # [02:27] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) (Remote closed the connection)
  78. # [02:29] * Quits: ifette (n=ifette@nat/google/x-vbxezqfsoeemmjwz) (Read error: 110 (Connection timed out))
  79. # [02:29] * Joins: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu)
  80. # [02:31] * Joins: wakaba_ (n=wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  81. # [02:37] * Joins: takoratt_ (n=takoratt@220.109.219.244)
  82. # [02:47] * Quits: ap (n=ap@17.246.19.174)
  83. # [02:52] * Quits: sicking (n=chatzill@nat/mozilla/x-zmzlfpenjamwatpf) (Read error: 110 (Connection timed out))
  84. # [02:53] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) (Remote closed the connection)
  85. # [02:54] * Quits: takoratta (n=takoratt@220.109.219.244) (Read error: 110 (Connection timed out))
  86. # [03:02] * Quits: ojan (n=ojan@72.14.229.81)
  87. # [03:04] * Quits: fishd (n=darin@nat/google/x-osuvjnqeqbqoenkq) (Read error: 110 (Connection timed out))
  88. # [03:24] * Joins: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  89. # [03:24] * Quits: SamerZ (n=SamerZ@CPE00222d5410b8-CM00222d5410b5.cpe.net.cable.rogers.com)
  90. # [03:25] * Joins: fishd (n=darin@67.180.164.209)
  91. # [03:27] * Joins: fishd_ (n=darin@72.14.224.1)
  92. # [03:34] * Quits: fishd (n=darin@67.180.164.209) (Read error: 145 (Connection timed out))
  93. # [03:37] * Joins: annodomini (n=lambda@wikipedia/lambda)
  94. # [03:38] * Joins: othermaciej (n=mjs@17.244.10.163)
  95. # [03:39] * Quits: othermaciej (n=mjs@17.244.10.163) (Client Quit)
  96. # [03:46] * Joins: takoratta (n=takoratt@220.109.219.244)
  97. # [03:47] * Joins: tantek (n=tantek@76-191-207-53.dsl.dynamic.sonic.net)
  98. # [03:47] * Joins: lazni (n=lazni@123.24.188.206)
  99. # [04:02] * Quits: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  100. # [04:03] * Quits: takoratt_ (n=takoratt@220.109.219.244) (Read error: 110 (Connection timed out))
  101. # [04:04] * Quits: fishd_ (n=darin@72.14.224.1) (Read error: 110 (Connection timed out))
  102. # [04:06] * Quits: drunknbass_work (n=aaron@pool-71-107-253-243.lsanca.dsl-w.verizon.net) ("Bye!")
  103. # [04:10] * Quits: Super-Dot (n=Super-Do@66-240-27-3.isp.comcastbusiness.net)
  104. # [04:15] * Quits: benward (n=benward@nat/yahoo/x-whbvajfwtqpsbvkq) (Read error: 104 (Connection reset by peer))
  105. # [04:16] * Joins: takoratt_ (n=takoratt@220.109.219.244)
  106. # [04:18] * Quits: ifette_GOOG (n=ifette@216.239.45.4)
  107. # [04:34] * Quits: takoratta (n=takoratt@220.109.219.244) (Read error: 110 (Connection timed out))
  108. # [04:39] * Joins: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  109. # [04:41] * Joins: takoratta (n=takoratt@220.109.219.244)
  110. # [04:46] * Quits: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  111. # [04:47] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  112. # [04:55] * Quits: takoratt_ (n=takoratt@220.109.219.244) (Read error: 110 (Connection timed out))
  113. # [05:08] * Quits: MikeSmith (n=MikeSmit@EM114-48-246-111.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
  114. # [05:18] * Joins: jacobolus (n=jacobolu@140.247.154.198)
  115. # [05:20] * Joins: arun__ (n=arun@adsl-75-36-189-9.dsl.pltn13.sbcglobal.net)
  116. # [05:21] * Quits: jwalden (n=waldo@nat/mozilla/x-otuwmvlxjthikznb) (Remote closed the connection)
  117. # [05:27] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  118. # [05:31] * Joins: takoratt_ (n=takoratt@220.109.219.244)
  119. # [05:35] * Quits: dpranke (n=Adium@nat/google/x-mqsiizcdljfizyqv) ("Leaving.")
  120. # [05:39] * Quits: takoratta (n=takoratt@220.109.219.244) (Read error: 110 (Connection timed out))
  121. # [05:39] * Quits: tantek (n=tantek@76-191-207-53.dsl.dynamic.sonic.net)
  122. # [05:43] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  123. # [05:53] * Joins: MikeSmith (n=MikeSmit@EM114-49-176-214.pool.e-mobile.ne.jp)
  124. # [05:55] * Joins: cying (n=cying@adsl-75-18-225-53.dsl.pltn13.sbcglobal.net)
  125. # [05:59] * Joins: benward (n=benward@98.210.154.133)
  126. # [06:11] * Joins: tantek (n=tantek@12.140.254.34)
  127. # [06:18] * Quits: tantek (n=tantek@12.140.254.34)
  128. # [06:26] * Quits: doublec (n=doublec@203-97-204-82.dsl.clear.net.nz) ("Leaving")
  129. # [06:26] * Quits: miketaylr_ (n=miketayl@user-0cdf5gs.cable.mindspring.com)
  130. # [06:37] * Joins: lazni1 (n=lazni@123.24.188.206)
  131. # [06:37] * Joins: takoratta (n=takoratt@220.109.219.244)
  132. # [06:39] * Joins: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  133. # [06:54] * Quits: GarethAdams_ (n=GarethAd@pdpc/supporter/active/GarethAdams)
  134. # [06:55] * Quits: takoratt_ (n=takoratt@220.109.219.244) (Read error: 110 (Connection timed out))
  135. # [06:56] * Quits: lazni (n=lazni@123.24.188.206) (Read error: 110 (Connection timed out))
  136. # [06:56] * Quits: takoratta (n=takoratt@220.109.219.244) (Read error: 110 (Connection timed out))
  137. # [07:03] * Joins: viana (n=viana@222.168.56.194)
  138. # [07:04] * Joins: zdobersek (n=zan@cpe-92-37-76-154.dynamic.amis.net)
  139. # [07:14] <hsivonen> looks like the SVG WG is pondering extending DOM Core: http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API
  140. # [07:15] <heycam> hsivonen, ideally, such generic extensions would go in dom core
  141. # [07:15] * Quits: lazni1 (n=lazni@123.24.188.206) ("Leaving.")
  142. # [07:18] * Quits: gavin (n=gavin@firefox/developer/gavin) (Remote closed the connection)
  143. # [07:18] * Joins: gavin (n=gavin@people.mozilla.com)
  144. # [07:19] * Joins: zalan (n=zalan@catv-89-135-144-193.catv.broadband.hu)
  145. # [07:19] * Quits: zdobersek (n=zan@cpe-92-37-76-154.dynamic.amis.net) ("Leaving.")
  146. # [07:19] * Joins: fishd_ (n=darin@c-67-180-164-209.hsd1.ca.comcast.net)
  147. # [07:25] <othermaciej> my kingdom for someone to edit Web DOM Core
  148. # [07:25] * Joins: fishd__ (n=darin@72.14.224.1)
  149. # [07:25] <heycam> apple's a big company, surely you have people
  150. # [07:29] * Quits: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  151. # [07:31] * Joins: fishd (n=darin@c-67-180-164-209.hsd1.ca.comcast.net)
  152. # [07:39] <hsivonen> the concept of having on-default graphs seems like an upcoming interop disaster: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0144.html
  153. # [07:39] * Joins: gavin__ (n=gavin@CPE001346f5db49-CM0018c0db9a8a.cpe.net.cable.rogers.com)
  154. # [07:39] <hsivonen> s/on-default/non-default/
  155. # [07:39] * Quits: gavin_ (n=gavin@firefox/developer/gavin) (Nick collision from services.)
  156. # [07:40] * gavin__ is now known as gavin_
  157. # [07:43] <othermaciej> heycam: the number of people who are capable of doing such a thing, willing to do so, and can be spared from other tasks, is pretty small
  158. # [07:44] * Quits: fishd_ (n=darin@c-67-180-164-209.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  159. # [07:44] * Quits: annodomini (n=lambda@wikipedia/lambda)
  160. # [07:44] <othermaciej> hsivonen: whoah
  161. # [07:46] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  162. # [07:48] * Joins: |zalan| (n=zalan@catv-89-135-144-193.catv.broadband.hu)
  163. # [07:49] <othermaciej> hsivonen: if they make xmlns declarations for prefixes optional and define a hardcoded or registry-based list of predefined prefixes, I won't complain
  164. # [07:49] * Quits: fishd__ (n=darin@72.14.224.1) (Read error: 110 (Connection timed out))
  165. # [07:51] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Remote closed the connection)
  166. # [07:52] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  167. # [07:56] * Joins: fishd_ (n=darin@72.14.224.1)
  168. # [08:07] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) ("This computer has gone to sleep")
  169. # [08:07] * Quits: zalan (n=zalan@catv-89-135-144-193.catv.broadband.hu) (Read error: 110 (Connection timed out))
  170. # [08:11] * Quits: kristallpirat (n=kristall@c-base/crew/kristall) ("Wünsche weiterhin guten Flug")
  171. # [08:14] * Quits: fishd (n=darin@c-67-180-164-209.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  172. # [08:18] * Quits: dave_levin (n=dave_lev@74.125.59.65)
  173. # [08:26] * Quits: viana (n=viana@222.168.56.194) (Remote closed the connection)
  174. # [08:34] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) ("bye")
  175. # [08:37] * weinig is now known as weinig|zzz
  176. # [08:42] * Joins: takoratta (n=takoratt@114.49.11.104)
  177. # [08:44] * Joins: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl)
  178. # [08:50] * Quits: jacobolus (n=jacobolu@140.247.154.198) (Remote closed the connection)
  179. # [08:50] * Joins: fishd (n=darin@c-67-180-164-209.hsd1.ca.comcast.net)
  180. # [08:50] * Quits: arun__ (n=arun@adsl-75-36-189-9.dsl.pltn13.sbcglobal.net)
  181. # [08:51] * Joins: fishd__ (n=darin@72.14.224.1)
  182. # [08:54] * Joins: cpharmston (n=cpharmst@pool-173-73-172-177.washdc.fios.verizon.net)
  183. # [08:59] * Quits: fishd_ (n=darin@72.14.224.1) (Read error: 110 (Connection timed out))
  184. # [09:03] * Joins: zcorpan (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  185. # [09:05] * Joins: pesla (n=retep@procurios.xs4all.nl)
  186. # [09:09] * Quits: fishd (n=darin@c-67-180-164-209.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  187. # [09:09] * Quits: takoratta (n=takoratt@114.49.11.104) (Read error: 145 (Connection timed out))
  188. # [09:15] * Joins: jacobolus (n=jacobolu@dhcp-0020078915-89-25.client.student.harvard.edu)
  189. # [09:21] * Quits: zcorpan (n=zcorpan@c83-252-193-59.bredband.comhem.se) (Read error: 110 (Connection timed out))
  190. # [09:23] * Joins: heycam (n=cam@210-84-56-211.dyn.iinet.net.au)
  191. # [09:25] * Joins: erlehmann (n=erlehman@80.187.101.17)
  192. # [09:31] * Quits: |zalan| (n=zalan@catv-89-135-144-193.catv.broadband.hu) (Read error: 110 (Connection timed out))
  193. # [09:33] * Joins: lazni (n=lazni@123.24.188.206)
  194. # [09:42] * fishd__ is now known as fishd
  195. # [09:46] * Joins: GarethAdams_ (n=GarethAd@pdpc/supporter/active/GarethAdams)
  196. # [09:50] * Joins: arun__ (n=arun@adsl-75-36-189-9.dsl.pltn13.sbcglobal.net)
  197. # [09:50] * Joins: cpharmston1 (n=cpharmst@pool-173-73-172-177.washdc.fios.verizon.net)
  198. # [09:50] * Quits: cpharmston (n=cpharmst@pool-173-73-172-177.washdc.fios.verizon.net)
  199. # [09:50] * Quits: cpharmston1 (n=cpharmst@pool-173-73-172-177.washdc.fios.verizon.net) (Remote closed the connection)
  200. # [09:50] * Quits: GarethAdams_ (n=GarethAd@pdpc/supporter/active/GarethAdams) (Client Quit)
  201. # [09:50] * Joins: cpharmston (n=cpharmst@pool-173-73-172-177.washdc.fios.verizon.net)
  202. # [10:12] * Joins: zcorpan (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  203. # [10:15] * Quits: drry (n=drry@ct91.opt2.point.ne.jp) ("Tiarra 0.1+svn-34672M: SIGTERM received; exit")
  204. # [10:16] <zcorpan> http://forums.whatwg.org/viewtopic.php?t=4063
  205. # [10:16] * zcorpan is now known as zcorpan_
  206. # [10:16] * zcorpan_ is now known as zcorpan__
  207. # [10:16] <zcorpan__> http://forums.whatwg.org/viewtopic.php?t=4063
  208. # [10:16] * Parts: zcorpan__ (n=zcorpan@c83-252-193-59.bredband.comhem.se)
  209. # [10:19] * Joins: drunknbass (n=drunknba@cpe-76-173-187-247.socal.res.rr.com)
  210. # [10:19] <drunknbass> heh, my little game engine is coming together nice
  211. # [10:19] <drunknbass> and renders good
  212. # [10:21] * Joins: drry (n=drry@211.9.170.91)
  213. # [10:21] <Philip`> Is it fast enough now? :-)
  214. # [10:22] <drunknbass> haha yea
  215. # [10:23] <drunknbass> http://dl.getdropbox.com/u/890870/multitouchpipes.mp4
  216. # [10:23] <drunknbass> it runs really fast on device too
  217. # [10:23] <MikeSmith> drunknbass: but can it beat box? A lot of MCs have some decent mike skills but beatboxing is what really separates the men from the boys.
  218. # [10:23] <drunknbass> thats just me getting the multi touch manager working with my game objects
  219. # [10:27] <annevk2> http://www.w3.org/mid/17E341CD-E790-422C-9F9A-69347EE01CEB@iki.fi is both funny and true
  220. # [10:27] <annevk2> especially the feed autodiscovery example is very nice
  221. # [10:29] <hsivonen> annevk2: what's the funny part?
  222. # [10:30] <annevk2> the contrast I think
  223. # [10:31] * Quits: webben (n=benh@91.85.72.193) (Read error: 110 (Connection timed out))
  224. # [10:32] <MikeSmith> what I conclude for this is to get real work done, we clearly need more Joes in basements.
  225. # [10:32] <hsivonen> annevk2: did my other email to www-tag this morning make sense?
  226. # [10:33] <MikeSmith> following the Field of Dreams approach, maybe if we build more basements we will get more Joes and thus more good specs.
  227. # [10:34] <drunknbass> anyone know anything about the pre?
  228. # [10:37] * Joins: mat_t (n=mattomas@91.189.88.12)
  229. # [10:37] <Philip`> MikeSmith: How many more basements do you think the world can accommodate?
  230. # [10:38] <MikeSmith> drunknbass: I don't know much but would be interested in hearing what your question is.
  231. # [10:38] <MikeSmith> drunknbass: one thing I've been told is that the UI seems to be noticeably more responsive than UI on the iPhone. so my question is, I would like to know how they did that.
  232. # [10:38] <drunknbass> just curious if canvas is supported
  233. # [10:38] <MikeSmith> drunknbass: I mean in terms of scrolling speed and such
  234. # [10:38] <drunknbass> no the ui is nowhere close
  235. # [10:38] <Philip`> What browser engine does it use?
  236. # [10:38] <MikeSmith> ah, OK
  237. # [10:38] <drunknbass> the whole ui experience is horrible
  238. # [10:38] <MikeSmith> Philip`: webkit
  239. # [10:39] <drunknbass> the browser itself doesnt seem to support canvas
  240. # [10:39] <drunknbass> but i thought native apps did
  241. # [10:39] <drunknbass> i just havent gotten around to witing any code for it yet
  242. # [10:39] <MikeSmith> drunknbass: well, that's disappointing.. from what I was told, I had been hoping they had figured out some magic
  243. # [10:39] <drunknbass> nope, ive been devving for iphone almost 2 years
  244. # [10:39] <drunknbass> the pre is nowhere close
  245. # [10:39] <MikeSmith> drunknbass: have you installed the SDK and tried it out at all
  246. # [10:40] <MikeSmith> (the Pre SDK I mean)
  247. # [10:40] <drunknbass> i have the palm sdk but havent written any palm specific code yet, was getting a basic canvas based engine going and testing in iphone safari
  248. # [10:40] <annevk2> hsivonen, haven't read that one yet
  249. # [10:40] <drunknbass> and my stuff works well in iphone so far
  250. # [10:40] <MikeSmith> Philip`: the world also needs more basements, with wood paneling, and beanbag chairs
  251. # [10:41] <hsivonen> when did Pre branch from WebKit trunk?
  252. # [10:41] <MikeSmith> drunknbass: have you tried out and Android development?
  253. # [10:41] <drunknbass> nope, ive been waiting till android actually was looking brighter
  254. # [10:41] <drunknbass> which seems to be now
  255. # [10:43] <drunknbass> so im waiting on the moto cliq to buy a device, then ill get a sholes when thats out since its gonna be a beast
  256. # [10:43] <MikeSmith> drunknbass: I live in Japan and 3rd-party Android development seems to be picking up here -- Android devices for Docomo now available
  257. # [10:43] <drunknbass> oh cool.. yea i put it off cause i hate java
  258. # [10:43] <annevk2> hsivonen, yes
  259. # [10:44] <drunknbass> but it seems they have a ndk now so that looks interesting
  260. # [10:45] <MikeSmith> drunknbass: I thought the NDK only let you build components -- libraries or whatever -- but that the actual apps still need to be produced using the Java SDK
  261. # [10:45] <hsivonen> annevk2: ok. thanks
  262. # [10:46] <MikeSmith> drunknbass: the writeups I've seen about the Cliq make it sound pretty disappointing
  263. # [10:47] <drunknbass> well. the cli will be better than the g1
  264. # [10:47] <drunknbass> but its still not iphone quality
  265. # [10:47] <MikeSmith> drunknbass: have you ever done any BREW development?
  266. # [10:47] <drunknbass> but there are no android devices that are on that level till sholes is out so its not a big deal
  267. # [10:47] <drunknbass> nope. but i did buy a book to learn it lol
  268. # [10:48] <drunknbass> i started writing java for dangerOS and hated it
  269. # [10:48] <annevk2> how ugly is the image for menu type=toolbar?
  270. # [10:48] <drunknbass> and that was the last java i touched
  271. # [10:48] <annevk2> is that really how we envision it?
  272. # [10:48] <MikeSmith> drunknbass: was dangerOS J2ME?
  273. # [10:48] <drunknbass> i think so
  274. # [10:49] * Joins: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
  275. # [10:49] <annevk2> Hixie, is type=toolbar for system menus or something else?
  276. # [10:49] <Hixie> it's for toolbars
  277. # [10:49] <annevk2> and would it be drawn on the page's canvas or the browser UI?
  278. # [10:49] <annevk2> the spec is really vague
  279. # [10:50] <Hixie> how is the spec vague
  280. # [10:50] <MikeSmith> maybe you'd like Java development for mobile in a real Java SDK better (which Android has) better than J2ME
  281. # [10:50] <Hixie> there's whole sections on this
  282. # [10:50] <drunknbass> im sure once i get the hang of it ill be ok
  283. # [10:50] <Hixie> annevk2: http://www.whatwg.org/specs/web-apps/current-work/#tool-bars-0
  284. # [10:50] <drunknbass> i just hate the initial hump to get over
  285. # [10:50] <drunknbass> esp when i feel so good writing code for mac or iphone
  286. # [10:51] <drunknbass> like learning js enough to write a game ive been in a pretty shitty mood the last week or so lol
  287. # [10:51] <MikeSmith> drunknbass: just tell yourself, It could be worse. I could be having to program in BREW.
  288. # [10:51] <annevk2> Hixie, ok, so it appears inline
  289. # [10:51] <annevk2> Hixie, I was looking for menu element in the rendering section
  290. # [10:51] <Hixie> ah
  291. # [10:52] * Joins: ROBOd (n=robod@89.122.216.38)
  292. # [10:52] <annevk2> Hixie, but image in the menu element section does not represent the Mac OS platform for toolbars afaict
  293. # [10:52] <Hixie> (sorry, kinda grumpy right now, lacking in sleep)
  294. # [10:52] <Hixie> annevk2: yeah the image is a disaster
  295. # [10:52] <Hixie> annevk2: wasn't sure how to make a better one to represent that markup
  296. # [10:53] * Joins: workmad3 (n=davidwor@ashleys2.mimas.ac.uk)
  297. # [10:53] <Hixie> annevk2: i tried playing around in interface builder with little success
  298. # [10:53] <annevk2> and shouldn't we be addressing the typical dropdown menus you find on pages first?
  299. # [10:53] <Hixie> i thought this _was_ addressing that
  300. # [10:54] <annevk2> i guess maybe they can if we provide a ton of styling hooks
  301. # [10:54] <hsivonen> is Opera Mini available for Brew these days? is it an manual implementation or a Java compilation targeted at non-Java byte code and libs?
  302. # [10:54] <drunknbass> yea i swore js was the worst
  303. # [10:54] <drunknbass> but its not THAT bad
  304. # [10:55] <drunknbass> but only because i can see what im doing actually performing fairly well
  305. # [10:56] <annevk2> hsivonen, http://www.opera.com/press/releases/2007/12/06/
  306. # [10:56] <MikeSmith> hsivonen: yeah, I think they did a BREW port of Mini, but I have not idea of how it was built
  307. # [10:56] <MikeSmith> hsivonen: takkaria might now
  308. # [10:56] <annevk2> hsivonen, no idea how much I can share about implementation details, so I'm not gonna
  309. # [10:56] <MikeSmith> *know
  310. # [10:57] <hsivonen> annevk2: OK. The press release is silent on implementation strategy
  311. # [10:57] * MikeSmith notices that annevk2 was actually answering hsivonen questions while I was speculating, and will shut up now
  312. # [10:57] * hsivonen recalls reading that Opera had an API wrapper for Android and not an independent port
  313. # [10:58] <MikeSmith> hsivonen: that API wrapper was a thing that translates J2ME calls to real Java SE calls
  314. # [10:59] * Quits: erlehmann (n=erlehman@80.187.101.17) (Remote closed the connection)
  315. # [10:59] * Hixie works on ws: and wss: registrations and grumbles at the inane design of the uri/iri specs
  316. # [10:59] * Joins: zalan (n=zalan@catv-89-135-144-193.catv.broadband.hu)
  317. # [10:59] <annevk2> Hixie, maybe you should say in a reply to Larry that the registration process should be simplified
  318. # [11:00] <Hixie> still waiting for larry to respond to me
  319. # [11:00] <Hixie> for the last e-mail i sent
  320. # [11:00] <annevk2> review comments?
  321. # [11:00] * annevk2 got replies from Martin
  322. # [11:01] <Hixie> something about how the error handling algorithms aren't quite what we need
  323. # [11:01] <annevk2> I wonder if it was because of my email to the public-html list suggesting we should include URL stuff again or some other reason...
  324. # [11:04] * Joins: erlehmann (n=erlehman@tmo-101-17.customers.d1-online.com)
  325. # [11:05] * Joins: webben (n=benh@nat/yahoo/x-tkvekykbitdqnudp)
  326. # [11:07] <Hixie> wooo, we crossed the 100 e-mail barrier
  327. # [11:07] * Joins: SamerZ (n=SamerZ@CPE00222d5410b8-CM00222d5410b5.cpe.net.cable.rogers.com)
  328. # [11:09] <Lachy_> Hixie, how far below it are you?
  329. # [11:09] <Philip`> Quick, send more email so we can cross it again
  330. # [11:10] <Hixie> right at this minute i'm at 85
  331. # [11:10] <Lachy_> Philip`, that's why I was asking how many :-)
  332. # [11:10] <Hixie> 85 e-mails remaining; 137 issues remaining; 165 bugs remaining
  333. # [11:10] <jgraham_> Now we get to see if you are cheating
  334. # [11:11] <jgraham_> Because we must reach equlibrium at some point where issues come in as fast as you can respond to them
  335. # [11:11] <hsivonen> Hixie: issues as in issues markers in the spec?
  336. # [11:11] <krijnh> Will there be a party when we/you reach 0? :)
  337. # [11:11] <Hixie> yes
  338. # [11:11] <jgraham_> (unless, I guess, you deal with issues faster than several hyundred people report them)
  339. # [11:11] <krijnh> Great!
  340. # [11:11] <jgraham_> (which is possible, so ignore me)
  341. # [11:11] <Hixie> the yes was to hsivonen :-P
  342. # [11:12] <krijnh> No, no, that's not how I read the logs! :)
  343. # [11:12] <Hixie> jgraham_: i've been responding to requests faster than they've been coming in on average for several years now
  344. # [11:12] <Lachy_> krijnh, Hixie said yes before you asked the question
  345. # [11:12] * krijnh changes the logs a bit
  346. # [11:12] <Hixie> we can have a party also, if you like
  347. # [11:12] <Philip`> No, Hixie said yes after krijnh's question
  348. # [11:12] <krijnh> There :)
  349. # [11:13] <Hixie> personally i was thinking of announcing last call and going on vacation
  350. # [11:13] <Philip`> from my frame of reference
  351. # [11:13] <krijnh> Hixie: aren't you gonna wait for you Christmas bonus?
  352. # [11:13] <Hixie> christmas bonus?
  353. # [11:14] <jgraham_> Hixie: But that doesn't necessarily work once you get to a small number of outstanding items because your abilility to respond faster than stuff comes in is predictaed on there being a large volume of communication per issue
  354. # [11:14] <Hixie> i'll be back before christmas
  355. # [11:14] <krijnh> For reaching LC before Christmas!
  356. # [11:14] <hsivonen> LC in October, CR by Christmas :-)
  357. # [11:14] <Hixie> jgraham_: i just have to wait til you're all in bed, do the last few issues, announce LC, and then go to bed
  358. # [11:14] <Hixie> christmas 2012, maybe
  359. # [11:15] <krijnh> You can redefine Christmas using a willful violation!
  360. # [11:15] <krijnh> No idea what problem that solves, but heck
  361. # [11:15] <Philip`> Someone needs to set up a script that we can submit feedback to, and then it will forward one message to the mailing list every ten minutes
  362. # [11:15] <hsivonen> krijnh: it would be backwards-incompatible
  363. # [11:16] * Quits: benward (n=benward@98.210.154.133) ("Sleep")
  364. # [11:16] <krijnh> hsivonen: I need data for that
  365. # [11:16] <Philip`> hsivonen: It wouldn't be if you only redefine the meaning of Christmas for years >= 2009
  366. # [11:16] * Quits: erlehmann (n=erlehman@tmo-101-17.customers.d1-online.com) (Read error: 54 (Connection reset by peer))
  367. # [11:16] <Philip`> I suppose it would still be incompatible with backwards people who haven't adopted our new system, though
  368. # [11:17] <krijnh> So anyway, annevk2: let's organize a party with Fronteers when HTML5 reaches LC :)
  369. # [11:17] * Joins: erlehmann (n=erlehman@tmo-101-17.customers.d1-online.com)
  370. # [11:17] <Lachy_> where should we hold this party?
  371. # [11:17] <krijnh> In NL, of course
  372. # [11:18] <Lachy_> ok. I do need to visit NL one day soon
  373. # [11:18] <Lachy_> before going to the US
  374. # [11:18] <krijnh> Before the TPAC you mean?
  375. # [11:19] <annevk2> krijnh, I should be in NL between oct25 and nov2 or so
  376. # [11:19] <Lachy_> it might have to be after TPAC, since I intend to crash at Anne's place and finding a time when he's at home between now and TPAC isn't going to be easy
  377. # [11:19] <Lachy_> unless I go then
  378. # [11:20] * Lachy_ is now known as Lachy
  379. # [11:20] <MikeSmith> hsivonen: I'm writing a message to the jena-dev list about AryehGregor's http://bugzilla.validator.nu/show_bug.cgi?id=641 bug report
  380. # [11:20] <MikeSmith> hsivonen: and I wanted to ask something
  381. # [11:20] * Joins: takoratta (n=takoratt@natsv1.u-aizu.ac.jp)
  382. # [11:21] <MikeSmith> hsivonen: which is, does v.nu do any pre-processing of any kind on IRIs before passing them to the Jena IRI library for checking?
  383. # [11:21] * Joins: takoratt_ (n=takoratt@natsv1.u-aizu.ac.jp)
  384. # [11:21] <hsivonen> IIRC, not for http
  385. # [11:21] <MikeSmith> OK
  386. # [11:21] <hsivonen> I can't recall what I did with javascript:
  387. # [11:22] <MikeSmith> do you have any insight at all on that error? it seems like a bug in the Jena library, right?
  388. # [11:22] <hsivonen> is the character classified as a compatibility character in Unicode?
  389. # [11:23] <hsivonen> grr. someone is shaking the house
  390. # [11:23] <MikeSmith> hsivonen: err, I'm not sure. I guess I should check that first
  391. # [11:23] <hsivonen> hrm. so hard to keeps hard disks safe from vibrations
  392. # [11:23] * MikeSmith googles to figure out how to check if something is a compatibility character or not
  393. # [11:23] <hsivonen> someone is digging a hole in the ground right outside my window
  394. # [11:24] * Quits: fishd (n=darin@72.14.224.1) (Read error: 110 (Connection timed out))
  395. # [11:24] <hsivonen> MikeSmith: I'd expect there to be an RFC somewhere that has a SHOULD NOT for compatibility chars
  396. # [11:24] <hsivonen> MikeSmith: maybe it's silly, but I'd expect the Jena check to come from someone
  397. # [11:24] <MikeSmith> OK
  398. # [11:24] <MikeSmith> r12a told me that there is some normalized equivalent for that character
  399. # [11:24] <hsivonen> so far I've always been able to trace Jena IRI lib behavior to an RFC
  400. # [11:25] <MikeSmith> hmm, OK
  401. # [11:26] <hsivonen> 5.3.2.2. Character Normalization
  402. # [11:26] <hsivonen> in RFC 3987 looks interesting
  403. # [11:26] <boblet> Hixie: re: using <dl> to mark up conversations a la HTML4, what was the reason that was bad?
  404. # [11:27] <Hixie> same reason that using <em> for citations is bad
  405. # [11:27] <boblet> Hixie: I remember it as abuse of <dl>, rather than use of <dt>/<dd>…?
  406. # [11:27] <Hixie> right
  407. # [11:27] <boblet> so overloading one element with two semantic meanings is the bad thing, is that correct?
  408. # [11:28] <hsivonen> I'm not seeing anything about compatibility characters under security considerations
  409. # [11:28] <Hixie> boblet: no
  410. # [11:28] <hsivonen> but the spec mentions NFKC which doesn't preserve compatibility characters...
  411. # [11:28] <Hixie> boblet: not necessarily
  412. # [11:28] * Quits: takoratta (n=takoratt@natsv1.u-aizu.ac.jp) (Read error: 60 (Operation timed out))
  413. # [11:28] <Hixie> boblet: overloading one element for two meanings in an indistinguishable way can be a problem, though
  414. # [11:29] <hsivonen> MikeSmith: found a SHOULD!
  415. # [11:29] <Hixie> boblet: especially when the ways are somewhat contradictory (e.g. "name-value pairs" vs "dialogue")
  416. # [11:29] <boblet> Hixie: I’m wondering if given <dt>/<dd>’s recent expansion into <figure> etc, would <ol><dt><dd></ol> be feasible?
  417. # [11:29] <MikeSmith> hsivonen: http://www.eki.ee/letter/chardata.cgi?ucode=edc
  418. # [11:29] <hsivonen> section 7.5. third paragraph
  419. # [11:29] <Hixie> boblet: to mean what?
  420. # [11:30] <MikeSmith> hsivonen: .me reads RFC 3987
  421. # [11:30] <boblet> Hixie: as a substitute for <dialog><dt><dd></dialog>
  422. # [11:30] <hsivonen> MikeSmith: I take "<compat>" to mean it's a compatibility character
  423. # [11:30] <boblet> admittedly a stretch…
  424. # [11:30] <Hixie> boblet: what's wrong with <p></p> as a substitute
  425. # [11:30] <boblet> a conversation seems to call for a list ordered by time
  426. # [11:31] <Hixie> o_O
  427. # [11:31] <hsivonen> MikeSmith: I'm not taking a stance on whether the SHOULD makes sense, but it's not a Jena bug
  428. # [11:31] * boblet wonders if that’s the falling off the chair emoticon
  429. # [11:32] <hsivonen> MikeSmith: one option would be disabling the treatment of SHOULD violations as errors
  430. # [11:32] <MikeSmith> hsivonen: yeah
  431. # [11:32] <hsivonen> in the datatype lib where the Jena lib is configured
  432. # [11:33] <MikeSmith> hsivonen: but it gets back to, we'd still want to warn about those at least
  433. # [11:33] <MikeSmith> so we need that warn mechanism...
  434. # [11:33] <MikeSmith> in the HTML5 datatype lib
  435. # [11:33] <hsivonen> yes...
  436. # [11:34] <MikeSmith> hsivonen: I will try to work on it next week
  437. # [11:34] <hsivonen> Hixie: did you mean to import IRI SHOULD violations into HTML5 conformance criteria?
  438. # [11:34] <hsivonen> MikeSmith: cool
  439. # [11:34] <Hixie> hsivonen: no idea
  440. # [11:34] <Hixie> hsivonen: which ones
  441. # [11:34] <Philip`> hsivonen: You should use cloud storage, so your disks are isolated from any vibrations down on the ground
  442. # [11:34] <hsivonen> Hixie: any
  443. # [11:35] * MikeSmith seems to remember promising last week to work on it this week..
  444. # [11:35] <hsivonen> Hixie: any that apply to authors that is
  445. # [11:35] <boblet> Hixie: I’m guessing that meant I’m talking crazy then, huh :)
  446. # [11:35] <Hixie> boblet: :-)
  447. # [11:35] <Hixie> boblet: i just don't understand the problem it would solve
  448. # [11:35] <Hixie> hsivonen: as a general rule i want to violate other specs as little as possible
  449. # [11:36] <Hixie> hsivonen: however, as a general rule, i'll violate them where it's necessary for compatibility or sanity
  450. # [11:36] <Philip`> boblet: http://en.wikipedia.org/wiki/o_O :-p
  451. # [11:36] <Hixie> hsivonen: dunno what else to say unless you have a more specific question
  452. # [11:36] <Philip`> (Hmm, actually that page doesn't quite describe that symbol)
  453. # [11:37] <boblet> a sanctioned way to mark up dialogs that is more semantic than <p><i class="speaker">speaker</i> statement</p>
  454. # [11:37] <Hixie> boblet: "Semantic" is not a goal
  455. # [11:37] * boblet is rescued from ignorance by Philip`
  456. # [11:37] <hsivonen> Hixie: is it dumb to emit an error when Wikipedia uses ໜ in href?
  457. # [11:37] <boblet> I gotta go,
  458. # [11:38] <boblet> might email it to the list so I can be shot down in a more public forum ;-)
  459. # [11:38] <Hixie> (that is, "semantic" is a means, not an end)
  460. # [11:38] <Hixie> hsivonen: dunno
  461. # [11:38] <Hixie> hsivonen: why would it be an error?
  462. # [11:38] * Joins: davidhund (n=davidhun@a82-95-120-160.adsl.xs4all.nl)
  463. # [11:38] <boblet> Hixie: I’ll ask you about that next time I’m on… til then
  464. # [11:38] <hsivonen> Hixie: it's a compatibility character
  465. # [11:38] <annevk2> hsivonen, since you validate href= you should arguably validate CSS too :)
  466. # [11:38] * boblet is now known as boblet_
  467. # [11:39] <Hixie> hsivonen: those are bad right?
  468. # [11:39] <Hixie> hsivonen: i guess it should be an error then
  469. # [11:39] * Joins: adactio (n=adactio@host86-138-101-27.range86-138.btcentralplus.com)
  470. # [11:39] <Hixie> hsivonen: dunno, ask martin d or r12a
  471. # [11:39] <hsivonen> Hixie: well, the IRI spec says they are bad on the SHOULD level
  472. # [11:39] <hsivonen> Hixie: I'm not sure what the exact badness is
  473. # [11:39] <hsivonen> Hixie: except if you print the IRI and type it back in, it's ambiguous what IRI you meant
  474. # [11:40] <Hixie> hsivonen: sounds bad
  475. # [11:40] <hsivonen> actually, that's the badness
  476. # [11:41] <hsivonen> AryehGregor: would MediaWiki be helped or hindered if it used NFKC for article IRIs?
  477. # [11:42] <hsivonen> AryehGregor: maybe it could use NFKC for canonical IRIs and redirect non-NFKC IRIs to the NFKC-normalized IRIs
  478. # [11:42] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  479. # [11:42] <annevk2> hsivonen, IRIs should be NFC
  480. # [11:42] <hsivonen> AryehGregor: does referring to Lao Wikipedia articles in print work in practice now
  481. # [11:42] <annevk2> hsivonen, when you type in an IRI, it ought to be normalized to NFC
  482. # [11:42] <hsivonen> annevk2: the RFC encourages NFKC but allows NFC
  483. # [11:43] <annevk2> that's weird
  484. # [11:43] <hsivonen> when one types the said Lao character, does one get NFKC on the usual operating systems?
  485. # [11:44] <hsivonen> annevk2: Although there may be exceptions, newly created resource names should generally be in NFKC [UTR15] (which means that they are also in NFC).
  486. # [11:44] <annevk2> http://tools.ietf.org/html/rfc3987#section-3.1 see step 1, substep a
  487. # [11:44] <hsivonen> says RFC 3987
  488. # [11:44] <annevk2> ah ok
  489. # [11:45] <hsivonen> Unicode ❤
  490. # [11:45] <MikeSmith> hsivonen: fwiw, dependencies/iri-0.5/src/com/hp/hpl/jena/iri/impl/AbsLexer.java has this comment:
  491. # [11:45] <MikeSmith> 170 // compatibility char
  492. # [11:45] <MikeSmith> 171 // defn is NFD != NFKD, ... hmmm
  493. # [11:45] <MikeSmith> what does that mean?
  494. # [11:45] <MikeSmith> is it relevant?
  495. # [11:45] <annevk2> hsivonen, actually
  496. # [11:46] <hsivonen> MikeSmith: I *think* it means that character c is a compatibility character if NFD(c) != NFKD(c)
  497. # [11:46] <annevk2> "IRIs SHOULD be created by using NFC. Using NFKC may avoid even more problems; for example, by choosing half-width Latin letters instead of full-width ones, and full-width instead of half-width Katakana."
  498. # [11:47] <hsivonen> annevk2: why is that SHOULD in all caps but the one I quoted isn't?
  499. # [11:47] <hsivonen> significant or bad editing?
  500. # [11:48] <hsivonen> oh. chapter 7 is informative
  501. # [11:48] <hsivonen> way to go IETF! using "should" in informative text
  502. # [11:48] * Parts: davidhund (n=davidhun@a82-95-120-160.adsl.xs4all.nl)
  503. # [11:49] <annevk2> IETF is teh awesome
  504. # [11:49] <jgraham_> Does no one read these specs for basic things like that?
  505. # [11:49] * hsivonen leaves for lunch
  506. # [11:50] <MikeSmith> http://www.eki.ee/letter/chardata.cgi?ucode=3f0 has <compat> in its Decomposition field also
  507. # [11:50] <MikeSmith> ϰ GREEK KAPPA SYMBOL
  508. # [11:51] * Quits: takoratt_ (n=takoratt@natsv1.u-aizu.ac.jp) (Read error: 110 (Connection timed out))
  509. # [11:51] * MikeSmith wonders does that mean using a GREEK KAPPA SYMBOL in an IRI is also going to make the IRI library emit that error
  510. # [11:51] <hsivonen> MikeSmith: ANSTROM SIGN also decomposes to plain Å
  511. # [11:51] <Philip`> Seems like it's not a problem if they consistently use SHOULD in normative text, and should in informative text
  512. # [11:52] <Philip`> because then it's clear what each word means, and clear they didn't just make a simple capitalisation mistake
  513. # [11:52] <hsivonen> *ANGSTROM
  514. # [11:53] <jgraham_> Philip`: It seems like poor form to ever use RFC2119 keywords in a way that is not supposed to convey the keyword meaning
  515. # [11:53] * Joins: MikeSmithX (n=MikeSmit@EM114-48-135-31.pool.e-mobile.ne.jp)
  516. # [11:54] * Quits: MikeSmith (n=MikeSmit@EM114-49-176-214.pool.e-mobile.ne.jp) (Nick collision from services.)
  517. # [11:55] * MikeSmithX is now known as MikeSmith
  518. # [11:55] * Parts: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
  519. # [11:57] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  520. # [12:00] * Quits: lazni (n=lazni@123.24.188.206) ("Leaving.")
  521. # [12:01] <Philip`> jgraham_: I don't see why it's a problem if it's unambiguous, and if there's a clear consistent convention about always spelling keywords in uppercase then it seems unambiguous
  522. # [12:02] * Quits: SamerZ (n=SamerZ@CPE00222d5410b8-CM00222d5410b5.cpe.net.cable.rogers.com)
  523. # [12:11] * Quits: nessy (n=nessy@124-170-13-58.dyn.iinet.net.au) ("This computer has gone to sleep")
  524. # [12:25] <hsivonen> hmm. it turns out that the people digging the hole outside my window are fixing my ADSL
  525. # [12:30] <Hixie> heh
  526. # [12:31] <hsivonen> it's a bit unusual that an ADSL problem is actually diagnosed to be a problem with the cable coming into the building
  527. # [12:43] <erlehmann> hsivonen, did the support at least ask you to use the original provider-crapware before doing anything ?
  528. # [12:44] <hsivonen> erlehmann: actually, the offered to reboot their end and send me a new ADSL model
  529. # [12:44] <hsivonen> s/model/modem/
  530. # [12:45] <erlehmann> oh wow
  531. # [12:45] <hsivonen> erlehmann: but when their rebooted their end, they found something worse
  532. # [12:45] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  533. # [12:45] <zcorpan> the resource selection algorithm is non-trivial to understand
  534. # [12:45] <hsivonen> the guys digging the cables said they suspected water damage in the cables
  535. # [12:47] <zcorpan> although i guess it's just Hixie, the implementors, and the test case writers who need to understand it
  536. # [12:48] * hsivonen has no idea what kind of diagnostics telcos have for deciding where they need to dig if a DSL line doesn't come back up normally after rebooting the provider end
  537. # [12:48] <hsivonen> also, I'm positively surprised by the effectiveness of the subcontracting chain
  538. # [12:48] <hsivonen> there are at least 4 companies acting on less than 24 hour notice to fix stuff
  539. # [12:50] <jgraham_> zcorpan: So that's like 9 people in the world?
  540. # [12:50] <zcorpan> jgraham_: yes
  541. # [12:51] <jgraham_> Oh well. I guess they can just suffer ;)
  542. # [12:51] <zcorpan> it seems i have caused a new acronym to be minted: PIPA (processing instruction with pseudo-attributes)
  543. # [12:51] <zcorpan> but one of them is me! :(
  544. # [12:51] <jgraham_> I know!
  545. # [12:51] <zcorpan> you're evil
  546. # [12:51] <erlehmann> hsivonen, i would suspect this http://en.wikipedia.org/wiki/Time-domain_reflectometer
  547. # [12:52] <zcorpan> although i guess you know what it's like, with ecmascript
  548. # [12:53] <hsivonen> erlehmann: ok. I didn't know about those
  549. # [12:54] <erlehmann> hsivonen, magic^H^H^H physics is awesome :>
  550. # [12:56] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Ex-Chat")
  551. # [12:59] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  552. # [13:00] * Quits: webben (n=benh@nat/yahoo/x-tkvekykbitdqnudp) (Client Quit)
  553. # [13:07] * Quits: arun__ (n=arun@adsl-75-36-189-9.dsl.pltn13.sbcglobal.net)
  554. # [13:09] * Joins: arun__ (n=arun@adsl-75-36-189-9.dsl.pltn13.sbcglobal.net)
  555. # [13:09] * Philip` is reminded of http://jwz.livejournal.com/94645.html about debugging cables
  556. # [13:11] * Quits: arun__ (n=arun@adsl-75-36-189-9.dsl.pltn13.sbcglobal.net) (Client Quit)
  557. # [13:15] * Joins: yutak_home (n=kee@M006079.ppp.dion.ne.jp)
  558. # [13:26] * Quits: cying (n=cying@adsl-75-18-225-53.dsl.pltn13.sbcglobal.net)
  559. # [13:33] * Quits: erlehmann (n=erlehman@tmo-101-17.customers.d1-online.com) (Read error: 113 (No route to host))
  560. # [13:34] * Joins: erlehmann (n=erlehman@tmo-101-17.customers.d1-online.com)
  561. # [13:35] * Joins: nessy (n=nessy@124-170-13-58.dyn.iinet.net.au)
  562. # [13:41] <jgraham_> hsivonen: I used <details> yesterday
  563. # [13:41] <hsivonen> jgraham_: how?
  564. # [13:42] <jgraham_> With javascript to do the open/close thing wrapped in an if (details.open === undefined){}
  565. # [13:42] <hsivonen> jgraham_: living dangerously
  566. # [13:42] <jgraham_> I guess
  567. # [13:43] <jgraham_> I jsut do markup for the andrenaline rush
  568. # [13:43] <zcorpan> that's when you know you're alive
  569. # [13:45] * zcorpan misspells </titel>
  570. # [13:51] <Lachy> I wonder how many authors attempting to do a check like that, would fail by using == instead of ===?
  571. # [13:51] <hsivonen> http://twitter.com/ppk/status/4051901363
  572. # [13:51] <hsivonen> it's now in three browsers isn't it?
  573. # [13:52] <Lachy> the drag and drop stuff was based on IE's implementation, wasn't it? So it's not really our fault if it sucks
  574. # [13:52] <hsivonen> Lachy: right
  575. # [13:53] <Lachy> although, I've never had a need to use it, so I don't really know whether it's good or bad.
  576. # [13:53] <Lachy> maybe I should try experimenting with it one day
  577. # [13:57] * Joins: SamerZ (n=SamerZ@204.225.63.69)
  578. # [14:03] * Quits: MikeSmith (n=MikeSmit@EM114-48-135-31.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
  579. # [14:13] <jgraham_> Lachy: re: == vs ===; if you are using == you've already lost
  580. # [14:14] <jgraham_> s/using/ever using/
  581. # [14:15] <Lachy> jgraham_, why?
  582. # [14:15] * Joins: pmuellr (n=pmuellr@nat/ibm/x-ivjitzygpofeodor)
  583. # [14:15] <krijnh> hsivonen: when are you going to integrate the new dt/dd stuff into validator.nu?
  584. # [14:15] <krijnh> (If ever)
  585. # [14:16] <hsivonen> krijnh: in Q4 unless Mike does it first
  586. # [14:16] <jgraham_> Lachy: Because it does implicit type conversion. Eventually you will get bugs
  587. # [14:17] * Joins: wes88 (n=chatzill@77.61.253.97)
  588. # [14:18] <Lachy> yeah, you have to be careful with it, but sometimes, it's the right thing to use
  589. # [14:19] * jgraham_ doubts it ;)
  590. # [14:22] <Lachy> jgraham_, as a simple example, consider a form validation script that is checking whether or not a user entered an acceptable number into a text field.
  591. # [14:22] <Lachy> It's easier to say: if (input.value >=1) than to have to explicitly convert the value to a number first
  592. # [14:24] <Lachy> oops, I meant to use ==, not >=
  593. # [14:26] <jgraham_> if (input.value === "1") is also fine
  594. # [14:27] <Lachy> not if the 1 is replaced with a variable, which is known to be calculated as a number
  595. # [14:28] <Philip`> if ((double ? input.value*2 : input.value) == 1) ...
  596. # [14:28] <Lachy> so either way, you would need to either do an explicit type conversion, or just accept the automatic conversion
  597. # [14:28] <Philip`> (Uh, is double a reserved word? Use some other variable name if so)
  598. # [14:28] <Philip`> You might not know or care what the type is
  599. # [14:29] <jgraham_> Philip`: double is a FutureReservedWord. WHich in practice means that it's probably not
  600. # [14:31] * jgraham_ doesn't really understand what Philip` is trying to show. Are you expecting 2*input.value to be 2 or "11" given input.value == 1
  601. # [14:31] <Lachy> yeah, the attempts to introduce new reserved words into a widely used language, when such reserved words have no other way to be distinguished from variables is a bit silly
  602. # [14:31] <Lachy> jgraham_, in JS, it would be 2
  603. # [14:32] <Lachy> I don't see why anyone would expect a multiplaction of "1" to end up as "11"
  604. # [14:32] <jgraham_> Oh, I've been looking at addition too much (that prefers implicit string conversion)
  605. # [14:32] <Lachy> *multiplication
  606. # [14:32] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  607. # [14:33] <jgraham_> Lachy: python has 2*"1" == "11"
  608. # [14:33] <jgraham_> But it also doesn't have silly implicit type conversions for equality or addition
  609. # [14:33] <Lachy> jgraham_, that doesn't answer the question, of who on earth would *expect* such insane behaviour?
  610. # [14:34] <jgraham_> Lachy: Me, obviously
  611. # [14:34] <Philip`> jgraham_: The point is the result might be a number (due to *'s automatic conversion) or a string, so you don't know its type, and you don't really care what its type is, since you can just use == to compare and it will do what you want
  612. # [14:34] <Lachy> you're obviously not on earth then, where multiplication is a numeric operation, not string concatenation
  613. # [14:34] <jgraham_> Lachy: Seriously, if I need a string with 500 a's in it, what syntax would you suggest?
  614. # [14:34] <jgraham_> s/a/"a"/
  615. # [14:35] <Lachy> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
  616. # [14:35] <jgraham_> Lachy: haha
  617. # [14:35] <jgraham_> Assume 500 is a variable that I don't know in advance
  618. # [14:35] <Lachy> what's the use case?
  619. # [14:36] <cpharmston> "a"*500
  620. # [14:36] <jgraham_> Well I use it pretty often in python so it obviously has a use case
  621. # [14:36] <jgraham_> Nothing so thrilling that I recall it off the top of my head
  622. # [14:36] <workmad3> "a" * no_of_a
  623. # [14:36] <workmad3> (in this case, no_of_a would have the value '500')
  624. # [14:37] <Lachy> workmad3, that doesn't work in JS
  625. # [14:37] <Philip`> jgraham_: "a" x 500
  626. # [14:37] <workmad3> not in js, no
  627. # [14:37] <workmad3> that's python
  628. # [14:37] <Lachy> I know, as jgraham_ already pointed out
  629. # [14:37] <Philip`> jgraham_: That's what Perl does, and it avoids weird overloading of '*'
  630. # [14:37] <workmad3> ah right
  631. # [14:37] <workmad3> sorry
  632. # [14:38] <jgraham_> Philip`: I still think you are better off doing an explicit type conversion for equality
  633. # [14:38] <Philip`> jgraham_: (It also uses . for concatenation to avoid weird overloading of '+', which avoids the JS bugs you get with input.value+1 etc)
  634. # [14:39] <workmad3> var lots_of_a = ""; for( var i = 0; i < no_of_a; i++) {lots_of_a += "a";}
  635. # [14:39] <workmad3> that's the best I can think of for JS
  636. # [14:39] <jgraham_> Philip`: I don't see a problem with using + to concatanate when both operands are strings
  637. # [14:40] <jgraham_> workmad3: (new Array(500)).join("a") would work
  638. # [14:40] <workmad3> ... good point
  639. # [14:40] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  640. # [14:40] <workmad3> but yeah, I'm with you in that I don't have a problem with + for concatenation of strings
  641. # [14:41] * Parts: adactio (n=adactio@host86-138-101-27.range86-138.btcentralplus.com)
  642. # [14:42] <workmad3> and using a . instead would mean the parser would need to be worked on as you could have some_string.some_other_string and that could be either a method call or string concatenation
  643. # [14:42] <Philip`> jgraham_: It seems reasonable in statically typed languages, where you know it's obviously concatenation, but it's confusing and error-prone in dynamically typed languages where you can't tell from the code what the '+' is doing
  644. # [14:43] <jgraham_> Philip`: What do you mean "you can't tell from the code...". Obviously you can tell if you know the types of the operands
  645. # [14:44] <Lachy> jgraham_, yeah, but you have to know the types, which doesn't work in this case:...
  646. # [14:44] <Lachy> function foo(a, b) { return a + b; }
  647. # [14:44] <Philip`> jgraham_: You don't know the types of the operands, because it's dynamic and you have to trace back the execution until some point where you can know what the type is
  648. # [14:44] <jgraham_> Right that will do different things depoending on what types a and b have
  649. # [14:45] <Lachy> yep
  650. # [14:45] <jgraham_> But it would even if each thing had a unique operator
  651. # [14:45] <Philip`> and you'll probably have to look up some API documentation to work out what type is, if it comes from a DOM API or something
  652. # [14:45] <jgraham_> because e.g. foo(3, "3") would throw
  653. # [14:45] <jgraham_> but foo(3,3) would return 6
  654. # [14:46] <Philip`> jgraham_: The operators can do automatic type conversion, e.g. '+' converts its operands to numbers (then adds), and '.' converts its operands to strings (then concatenates)
  655. # [14:46] <Lachy> foo(3, "3") in JS would return "33"
  656. # [14:46] <Philip`> and so you never have to care whether your values are strings-of-digits or numbers, because they're treated equivalently
  657. # [14:47] <jgraham_> Lachy: I know. I was assuming a strongly, dynamically typed language
  658. # [14:47] <jgraham_> which is what I thought we were talking about
  659. # [14:47] <Lachy> using . as an operand for string concatenation, like in PHP, is a silly convention
  660. # [14:47] <Lachy> . should be used for methods, like it is in sensible languages
  661. # [14:48] <Philip`> Choose some other symbol then, as long as it's not '+'
  662. # [14:48] <Lachy> jgraham_, oh, sorry, didn't realise
  663. # [14:48] <Lachy> IIRC, VisualBasic used &
  664. # [14:48] <Philip`> Perl 6 agrees . should be used for method calls, so it's changed to ~ for string concatenation
  665. # [14:48] * Quits: wakaba_ (n=wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) ("Leaving...")
  666. # [14:49] <workmad3> but then you're using a logic operator and the same issues apply
  667. # [14:49] <Lachy> workmad3, I know
  668. # [14:49] <jgraham_> Philip`: Sure you never have to care if you only care about not throwing at operators rather than getting the right result
  669. # [14:49] <workmad3> I can't think of a standard symbol that isn't already used
  670. # [14:50] <jgraham_> Weak typing typically just increases the distance between the bug and the error being thrown
  671. # [14:50] <jgraham_> (or prevents an error but gives an incorrect result)
  672. # [14:50] <Lachy> jgraham_, yes, but it makes things easier in the process
  673. # [14:51] * Parts: zcorpan (n=zcorpan@pat.se.opera.com)
  674. # [14:51] <Philip`> jgraham_: If I write '1' into an input box, and my code does input.value+1, I think 2 is the right result
  675. # [14:51] <Philip`> and I'm happy for it to do automatic type conversion from strings to numbers for addition
  676. # [14:51] <Philip`> and there's no bug
  677. # [14:51] <jgraham_> Philip`: Javascript would give you '11' though
  678. # [14:51] <jgraham_> so you would be surprised
  679. # [14:52] <Philip`> jgraham_: Sure, which is why JS is silly, but Perl is sensible because it will always give 2
  680. # [14:53] * jgraham_ notes that Perl code is not typically held up as being easy to understand
  681. # [14:53] <Philip`> and I don't have to care whether the inputs are strings-of-digits or numbers
  682. # [14:53] <jgraham_> Philip`: In this micro example you don't. In almost any real world example you would
  683. # [14:53] <Lachy> I like CSS's approach to string concatentation in the content property: content: "a" "b";
  684. # [14:53] <Lachy> no need for an extra symbol
  685. # [14:53] <Philip`> jgraham_: There's no implication between "some Perl code is hard to understand" and "if X is a feature that exists in Perl, then X makes programs hard to understand"
  686. # [14:55] <jgraham_> Philip`: Not using deductive logic no. But it does suggest you should think about whether X is in fact a feature that makes programs hard to understand
  687. # [14:55] <Philip`> jgraham_: Sure, and I've thought about it, and it doesn't :-p
  688. # [14:55] <jgraham_> Philip`: Yes it does :p
  689. # [14:56] <Philip`> I've written real bugs because of JS's + doing concatenation when I expected addition
  690. # [14:56] <jgraham_> Right. So if it did neither you would be fine and your error console would tell you exactly where the bug was
  691. # [14:56] <Philip`> and Perl prevents those bugs, because it doesn't surprisingly switch from addition to concatenation depending on the run-time state of its variables
  692. # [14:56] * Joins: myakura (n=myakura@p2046-ipbf4007marunouchi.tokyo.ocn.ne.jp)
  693. # [14:57] <Philip`> I'm not sure if you're disagreeing that Perl is better than JS, or if you're just saying that throwing exceptions instead of automatically converting type would be even better
  694. # [14:57] <jgraham_> (assuming you had different types of variables)
  695. # [14:57] <Philip`> s/type/types/
  696. # [14:57] <jgraham_> I'm saying that throwing exceptions when the variables are different types is probably the best approach
  697. # [14:58] <jgraham_> At least for addition and equality
  698. # [14:58] <jgraham_> (and subtraction and division, obviously)
  699. # [14:58] <Lachy> Philip`, how do you feel about operator overloading in C++, which allows + (and other operators) to be overridden to do basically anything with a given object?
  700. # [14:58] <Philip`> That seems contrary to design of all dynamically typed languages I'm aware of, which all treat strings-of-digits as equivalent to numbers in almost all cases
  701. # [14:59] <jgraham_> Er, sorry, I don't mean "throw for equality", I mean "return False for equality"
  702. # [14:59] <jgraham_> Philip`: Python doesn't
  703. # [15:00] <Philip`> jgraham_: Oh, I forgot Python :-(
  704. # [15:00] <takkaria> Lachy: that is evil, it really screws up the ability to understand what's going on
  705. # [15:01] <Philip`> Lachy: I think it's useful when it's used carefully, e.g. it's useful that std::string overloads + for concatenation instead of requiring a method call or special parser magic (like in Java)
  706. # [15:02] <Philip`> and if you have e.g. a 3D vector or a fixed point number or something, then it's useful to overload + for addition because it lets you write much more understandable code than with explicit method calls
  707. # [15:03] <Lachy> takkaria, at least in C++, you don't have dynamically typed variables, so you know what + is going to be just by looking at the code
  708. # [15:03] <takkaria> Lachy: well, you don't, because as you note, it can do anything
  709. # [15:03] <takkaria> you have to then go look up the class in question
  710. # [15:03] <Philip`> (and then it's useful for generic programming, e.g. you can write a templated 'sum' function which works for 3D vectors just as well as it works for ints)
  711. # [15:03] <takkaria> and then possibly its superclass(es)
  712. # [15:04] <Lachy> takkaria, as long as you know the varible type and what that type does with it.
  713. # [15:04] * Joins: virtuelv (n=virtuelv@125.175.251.212.customer.cdi.no)
  714. # [15:04] <Philip`> takkaria: How is that any different to an explicit method call, which can do anything?
  715. # [15:04] <takkaria> Philip`: because '+' and '-' have pretty deeply embedded meanings, and some people do horrific things with operator overloading
  716. # [15:05] <takkaria> for stuff like vectors and strings, admittedly, it works OK
  717. # [15:05] <takkaria> but they should be language features anyway :)
  718. # [15:05] <Philip`> If people do horrific things, the problem is that people are doing horrific things, the problem isn't simply operator overloading
  719. # [15:05] <Philip`> and so the solution is to tell people not to do horrific things, and hit them with sharp sticks when they do
  720. # [15:05] <takkaria> yeah, but if you give people a feature which is easily misused, then you're partially to blame and you should have designed things better
  721. # [15:05] <Philip`> What if you don't like the standard string class and want to create your own that uses UTF-8 internally or something?
  722. # [15:06] * Joins: annodomini (n=lambda@c-75-69-96-104.hsd1.nh.comcast.net)
  723. # [15:06] <Philip`> Would it have to be a second-class citizen with string1.concat(string2) while only officially blessed standard strings can use +?
  724. # [15:07] <takkaria> I don't have all the answers, I just know that it's really easy for people to misuse operator overloading and I'd rather it were avoided
  725. # [15:08] <takkaria> especially when you have to search up chains of inheritance in a large codebase
  726. # [15:11] <Philip`> The replacement for operator overloading is explicit method calls, and then you have to identically search up chains of inheritance, so why is that any different?
  727. # [15:11] <Philip`> (You're just searching up the chains for 'add' rather than for 'operator+')
  728. # [15:11] * Joins: zdobersek (n=zan@cpe-92-37-79-46.dynamic.amis.net)
  729. # [15:12] * Joins: taf2 (n=taf2@38.99.201.242)
  730. # [15:12] <takkaria> you may have backed me into a corner here
  731. # [15:13] <Philip`> Because you're wrong? ;-)
  732. # [15:13] <takkaria> I think I just don't have particularly good reasons for disliking them
  733. # [15:13] <takkaria> except that I've been exposed to some bad overloading
  734. # [15:13] <Philip`> So it's an irrational aesthetic dislike? :-)
  735. # [15:14] <takkaria> apparently so
  736. # [15:15] * Quits: cpharmston (n=cpharmst@pool-173-73-172-177.washdc.fios.verizon.net) ("Leaving.")
  737. # [15:15] <workmad3> the problem with overloading isn't really in the operator overloading part, more in the fact that people think they have to use it
  738. # [15:15] <Philip`> Aesthetics seems to be a pretty low priority in the design of C++
  739. # [15:16] <workmad3> people are able to overload all the operators, so they go looking for things to jam into each and every one in order to 'use them up' as it were
  740. # [15:17] <Lachy> workmad3, really? Why?
  741. # [15:17] * Joins: hobertoAtWork (n=hobertoa@gw1.mcgraw-hill.com)
  742. # [15:17] <Philip`> http://spirit.sourceforge.net/distrib/spirit_1_8_5/libs/spirit/doc/quick_start.html
  743. # [15:17] <workmad3> and that leads to programmers with that mentality to write bad overloads
  744. # [15:17] <Philip`> r = real_p >> *(ch_p(',') >> real_p);
  745. # [15:17] <Lachy> do they think it makes their code more robust to be able to handle all operators or something?
  746. # [15:17] <Philip`> (A parser for a comma-separated list of reals)
  747. # [15:17] <workmad3> Lachy, if I knew why people abused operator overloading, I probably wouldn't be sat here :P
  748. # [15:18] <Philip`> (It's kind of clever, but also insane and stupid)
  749. # [15:18] <workmad3> Lachy, that, or they are looking for ways to reduce their typing, or they want it to be a 'cool' class that lets them do all of these things
  750. # [15:18] <takkaria> actually, the C++y 'cout << "text here"' thing really annoys me
  751. # [15:18] <takkaria> like, those operators are for bitshifting, not for printing text, don't screw with the semantics like that
  752. # [15:19] <takkaria> I'm pretty sure they only did it that way to say "look, we have operator overloading!"
  753. # [15:19] <workmad3> I dislike them for a different reason... it's almost impossible to do decent localisation with C++ streams
  754. # [15:20] <Lachy> next time I write a program in C++, I'm going to overload some random operators just for the fun of it
  755. # [15:20] <workmad3> heh :)
  756. # [15:21] <erlehmann> Lachy, or use the preprocessor to make TRUE to FALSE and vice versa -- maintainer fun :D
  757. # [15:21] <workmad3> that said, my point on that front isn't that operator overloads are bad, it's that there are a lot of bad programmers out there that will misuse them... but the same is true of any feature
  758. # [15:21] <Philip`> (std::cout << "text" is particularly confusing when you learn that the operator<< function is in the std namespace, and the only way the compiler can find the function is through argument-dependent lookup, i.e. it searches in the std namespace because the first argument is in std)
  759. # [15:24] <workmad3> there is one nice thing about input and output streams using overloaded operators in C++ though (and this is more due to their operator overloading mechanics)... you can easily extend the input and output streams to use your custom classes and it'll fit in seamlessly with the existing syntax
  760. # [15:24] <takkaria> I think the other reason the use of << for printing irks me is that a barrel shift operator is normally stateless, e.g. (a << b) is just an expression and doesn't modify a in the process
  761. # [15:25] <Philip`> C++ using bit-shift operators from stream IO isn't much weirder than Python using the modulo operator from string interpolation
  762. # [15:25] <Philip`> s/from/for/
  763. # [15:25] <Philip`> (twice)
  764. # [15:25] * Joins: wes88_ (n=chatzill@77.61.253.97)
  765. # [15:25] <workmad3> ruby uses << for appending to arrays :)
  766. # [15:25] <takkaria> yeah, that's weird too
  767. # [15:25] <workmad3> that took me a few times to parse correctly
  768. # [15:27] <workmad3> still, hating a language feature because some people have misused it is irrational
  769. # [15:27] <workmad3> equivalent to hating hammers because they have been used to hurt people
  770. # [15:28] <takkaria> I have seen many hammers and I have never seen someone hurting someone else
  771. # [15:28] <takkaria> I have seen not that much C++ and I have seen overloading misused
  772. # [15:28] <workmad3> I've seen a fair chunk of C++ and not seen too much overloading misuse
  773. # [15:29] * Joins: cfq (n=cfq@client-82-3-44-202.sqy-bng-011.adsl.virginmedia.net)
  774. # [15:29] * Quits: annodomini (n=lambda@wikipedia/lambda)
  775. # [15:29] <workmad3> and I've hurt myself with a hammer before, and heard of people hurting others with them
  776. # [15:31] <workmad3> I've not heard anyone suggesting that because they can be used to hurt people though, that instead we should get rid of hammers and replace them with soft foam mallets instead
  777. # [15:31] <workmad3> (and no, I don't have a match in programming terms for 'soft foam mallets' in this now stretched metaphor)
  778. # [15:31] * Joins: zcorpan (n=zcorpan@pat.se.opera.com)
  779. # [15:32] <zcorpan> hmm, removing <source> elements is interesting
  780. # [15:32] <Philip`> Knives can be used to hurt people, so somebody designed a knife that can't stab people and is suggesting that people use it
  781. # [15:32] <workmad3> ah yeah, I saw that
  782. # [15:33] <workmad3> and also saw straight away that it could still probably stab people, and definitely be used to cut (otherwise it wouldn't be any good as a knife after all :))
  783. # [15:33] <Philip`> but in that case the knife is still useful for its intended purpose (food production)
  784. # [15:33] <workmad3> it may need a bit more forcing for the stabbing though
  785. # [15:33] <Philip`> If there was something equivalent to operator overloading that avoided the bad uses without impacting on the good uses, that would be good, but I haven't seen any suggestions
  786. # [15:35] * Joins: TabAtkins (n=chatzill@adsl-76-195-204-109.dsl.hstntx.sbcglobal.net)
  787. # [15:35] <Philip`> (Well, I suppose operator overloading plus code review by a sane person would be a solution)
  788. # [15:35] <TabAtkins> Mornin'.
  789. # [15:36] <workmad3> sane people program now? when did that happen? :)
  790. # [15:36] <Philip`> workmad3: They could have retired from programming and regained their sanity, to a sufficient extent that they can review other people's code
  791. # [15:37] * Joins: tantek (n=tantek@70.36.139.108)
  792. # [15:39] * Quits: wes88 (n=chatzill@77.61.253.97) (Read error: 110 (Connection timed out))
  793. # [15:40] * Quits: zdobersek (n=zan@cpe-92-37-79-46.dynamic.amis.net) (Read error: 110 (Connection timed out))
  794. # [15:41] * Joins: BlurstOfTimes (n=blurstof@168.203.117.59)
  795. # [15:52] * Quits: erlehmann (n=erlehman@tmo-101-17.customers.d1-online.com) ("Ex-Chat")
  796. # [15:52] * Joins: erlehmann (n=erlehman@tmo-101-17.customers.d1-online.com)
  797. # [15:53] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 145 (Connection timed out))
  798. # [15:57] * Joins: erlehmann_ (n=erlehman@tmo-104-210.customers.d1-online.com)
  799. # [16:00] * Quits: mat_t (n=mattomas@91.189.88.12) (Remote closed the connection)
  800. # [16:03] * Quits: nessy (n=nessy@124-170-13-58.dyn.iinet.net.au) ("This computer has gone to sleep")
  801. # [16:04] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  802. # [16:05] * Quits: jacobolus (n=jacobolu@dhcp-0020078915-89-25.client.student.harvard.edu) (Remote closed the connection)
  803. # [16:17] * Joins: paul_irish (n=paul_iri@12.33.239.250)
  804. # [16:21] * Quits: erlehmann (n=erlehman@tmo-101-17.customers.d1-online.com) (Read error: 110 (Connection timed out))
  805. # [16:21] * Joins: cpharmston (n=cpharmst@pool-173-73-172-177.washdc.fios.verizon.net)
  806. # [16:24] * Quits: Rik|work (n=Rik|work@fw01d.skyrock.net)
  807. # [16:24] * Quits: cpharmston (n=cpharmst@pool-173-73-172-177.washdc.fios.verizon.net) (Client Quit)
  808. # [16:24] * Joins: aroben (n=aroben@unaffiliated/aroben)
  809. # [16:24] * Joins: Rik|work (n=Rik|work@fw01d.skyrock.net)
  810. # [16:29] * Joins: ttepasse (n=ttepas--@p5B015531.dip.t-dialin.net)
  811. # [16:31] * Joins: eric_carlson (n=ericc@nat/apple/x-ypttdyewpuluaxiq)
  812. # [16:33] * Joins: fishd (n=darin@67.180.164.209)
  813. # [16:42] * Joins: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
  814. # [16:43] * erlehmann_ is now known as erlehmann
  815. # [16:46] * Joins: fishd_ (n=darin@72.14.224.1)
  816. # [16:46] * Quits: cardona507 (n=cardona5@c-67-180-160-250.hsd1.ca.comcast.net)
  817. # [16:47] * Joins: mat_t (n=mattomas@91.189.88.12)
  818. # [16:52] * Joins: cying (n=cying@adsl-75-18-225-53.dsl.pltn13.sbcglobal.net)
  819. # [16:52] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  820. # [16:53] <TabAtkins> Is it defined anywhere what happens to content in <details> that isn't contained in a <dt> or <dd>?
  821. # [16:54] * Quits: fishd (n=darin@67.180.164.209) (Read error: 145 (Connection timed out))
  822. # [16:55] <jgraham_> TabAtkins: Define "happens"
  823. # [16:55] <jgraham_> It ends up in the DOM. The rendering section defines how it is rendered
  824. # [16:56] <jgraham_> (the rendering section might have a suboptimal definition of course, I don't know what it says)
  825. # [16:56] * Quits: cfq (n=cfq@client-82-3-44-202.sqy-bng-011.adsl.virginmedia.net)
  826. # [16:58] * Quits: yutak_home (n=kee@M006079.ppp.dion.ne.jp) ("Ex-Chat")
  827. # [17:00] <TabAtkins> Ah, got it. For some reason I never go from "how is something parsed/rendered" to "I should look in the 'HTML Syntax' section".
  828. # [17:00] <TabAtkins> Everything but the first <dt> is considered to be the details.
  829. # [17:06] * Quits: fishd_ (n=darin@72.14.224.1) (Read error: 110 (Connection timed out))
  830. # [17:11] * zcorpan notes that there are unresolved spec bugs regarding the rendering of details
  831. # [17:14] * Joins: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley)
  832. # [17:14] * Joins: sbublava (n=stephan@77.119.62.19.wireless.dyn.drei.com)
  833. # [17:16] <jgraham_> I really dislike the idea of using h1 for <details> or <figure>. In particular I would expect it to interact poorly with legacy AT
  834. # [17:17] * aroben is now known as aroben|phone
  835. # [17:19] <krijnh> In <figure> it wouldn't make much sense either: <figure><img><h1>Foo</h1></figure>
  836. # [17:21] * Joins: Lachy (n=Lachlan@85.196.122.246)
  837. # [17:21] <jgraham_> Actually the biggest problem I forsee with <dt> and <dd> is that it is way to easy to get them confused
  838. # [17:22] <jgraham_> They should have been called <name> and <value> or something
  839. # [17:22] <Lachy> too late for that, unfortunately
  840. # [17:22] <jgraham_> The confusion is especially bad for <figure> because it is pretty hard to spot
  841. # [17:22] * aroben|phone is now known as aroben
  842. # [17:22] <jgraham_> Lachy: I know :(
  843. # [17:23] <erlehmann> when no access control header is sent for videos, is thet akin to access for "*" ?
  844. # [17:23] <erlehmann> jgraham_, who uses that? is <legend> unexpectedly dead?
  845. # [17:23] <Lachy> I'm not a huge fan of reusing dt and dd for figure
  846. # [17:23] <Lachy> though it works well for details
  847. # [17:23] <jgraham_> erlehmann: <legend> is just for fieldsets again
  848. # [17:23] <erlehmann> OH NOEZ
  849. # [17:25] <jgraham_> TabAtkins: Reusing <h1> would also be bad in cases where the user fell back to the UA stylesheet in an existing browser
  850. # [17:26] <TabAtkins> jgraham_ No worse than what happens if you use <h1> for all headings, though.
  851. # [17:26] <erlehmann> i hate it when they change the spec.
  852. # [17:26] <erlehmann> coding to moving targets ;_;
  853. # [17:26] <erlehmann> jgraham_, using <h1> wouldn't that confuse older UAs particularly concerning accessability ?
  854. # [17:26] <erlehmann> everything would be HUGE
  855. # [17:26] <jgraham_> TabAtkins: Much worse. A figure caption could be several paragraphs of text
  856. # [17:26] <erlehmann> why was legend not good enough ? i had no major parsing or styling problems with it in webkit, presto, gecko …
  857. # [17:26] <Lachy> erlehmann, that is the inevitably fate of early adopters
  858. # [17:26] <jgraham_> In fact aren't there parsing issues with <h1>
  859. # [17:26] <Lachy> *inevitable
  860. # [17:26] <TabAtkins> Are there?
  861. # [17:27] <erlehmann> Lachy, my code ist frozen till 2022, then.
  862. # [17:27] <Lachy> :-)
  863. # [17:27] <erlehmann> now can anyone tell me whats so bad about legend ?
  864. # [17:27] <erlehmann> was it on the list?
  865. # [17:28] <Lachy> on an unrelated issue, I was thinking about the styling of headings today and the idea that's been floating around of introducing a :heading() pseudo class
  866. # [17:28] <erlehmann> so :heading(2) would be for 2-level headings?
  867. # [17:29] <Lachy> it seems that hgroup and the issue of subheadings make the issue a little more complicated
  868. # [17:29] <Lachy> erlehmann, in principle, yes
  869. # [17:29] <erlehmann> either its too late for that or CSSWG has something like this already, let me check.
  870. # [17:30] <TabAtkins> I know that :heading() (and :section()?) has been discussed before, quite some time ago.
  871. # [17:30] <Lachy> e.g. should :heading(2) match the h2 in <hgroup><h1>Top Level Heading</h1><h2>Subheading</h2></hgroup>?
  872. # [17:30] <TabAtkins> I think it's pretty necessary.
  873. # [17:30] <TabAtkins> Lachy: No, it should match the <hgroup> itself, if it represents a second-level heading.
  874. # [17:31] <jgraham_> TabAtkins: In practice no one uses <h1> in blockquote (I expect)
  875. # [17:31] <Lachy> TabAtkins, assume there's a <body> immediately before that example of mine, so it's the page's top level heading
  876. # [17:31] <jgraham_> That bit of the spec is basically theoretical purity
  877. # [17:32] <TabAtkins> Lachy: Then I dont' think it should match. The <hgroup> would match :heading(1), but its child headings won't match *any* :heading(n).
  878. # [17:32] <Lachy> TabAtkins, also, I would have intuitively expected the :heading() pseudo to only match the h1 (if it were a 2nd level heading)
  879. # [17:33] <erlehmann> put it on the list, already \o/
  880. # [17:33] <TabAtkins> That's possibly, too, I guess - just having it match the identifying heading of the hgroup.
  881. # [17:33] <Lachy> as in <body>...<section><h1>2nd Level Heading</h1>...</section> OR this <body>...<section><hgroup><h1>2nd Level Heading</h1><h2>...</h2></hgroup>...</section>
  882. # [17:33] <TabAtkins> jgraham_, I agree that it's probably not common.
  883. # [17:33] <krijnh> Did the list receive mail today?
  884. # [17:33] <jgraham_> krijnh: Yes
  885. # [17:33] <krijnh> Then my mail is broken :(
  886. # [17:33] <TabAtkins> krijnh - yes?
  887. # [17:34] <hsivonen> Lachy: shouldn't the pseudo match other elements based on their level in the outline, too
  888. # [17:34] <jgraham_> krijnh: Then you have a whole run of thrilling and not-at-all-inflammatory messages to look forward to!
  889. # [17:34] <TabAtkins> Lachy: That seems probably useful. I'm not certain, but I wouldn't disagree with it.
  890. # [17:34] <krijnh> jgraham_: I think they didn't arrive
  891. # [17:34] <Lachy> also i checked jQuery's docs earlier, and that uses a custom :header for matching h1 - h6, so there shouldn't be any issue with calling it :heading() as I once suspected
  892. # [17:34] <krijnh> What should I do with all this extra time I have now!
  893. # [17:35] <Lachy> hsivonen, yes, it should match any of the h1 to h6 elements, based on what heading level they represent
  894. # [17:35] <Lachy> I'm just figuring out how hgroup and subheadings would be affected
  895. # [17:35] <hsivonen> Lachy: I meant matching p:outline-level(3)
  896. # [17:35] <Lachy> what's the use case for that?
  897. # [17:36] <hsivonen> Lachy: setting the font size or bg color depending on outline depth
  898. # [17:36] * Joins: dglazkov (n=dglazkov@nat/google/x-ufgzxstpiarfxobn)
  899. # [17:36] <jgraham_> (or indent)
  900. # [17:36] <Lachy> the use case for headings is replacing what was formerly possible in HTML4 simply by using the numbered heading elements.
  901. # [17:36] <hsivonen> jgraham_: that, too
  902. # [17:36] <TabAtkins> I sorta prefer ::section(n). It's a new pseudoelement, but it doesn't cross element boundaries and has an intuitiviely obvious wrapping level.
  903. # [17:37] * Joins: fishd_ (n=darin@c-67-180-164-209.hsd1.ca.comcast.net)
  904. # [17:37] <TabAtkins> That way you can do borders, margins, etc. even if using implicit sectioning.
  905. # [17:37] <Lachy> TabAtkins, interesting idea
  906. # [17:37] <hsivonen> we should have <figure><bikeshed></figure>
  907. # [17:38] <takkaria> <figure><span role="semantic-meaning"></span></figure>
  908. # [17:38] <TabAtkins> hsivonen: Put it to a vote. I'm for it. But I require <bikeshed color="#f00">
  909. # [17:38] <hsivonen> TabAtkins: I want color=papayawhip
  910. # [17:38] <erlehmann> I WANT MAH LEGEND BACK
  911. # [17:38] <erlehmann> <div class="figure presentation"><span role="semantic-meaning"></span></div>
  912. # [17:38] <erlehmann> i want a pony !
  913. # [17:39] <erlehmann> color=ponypink !
  914. # [17:39] * Quits: erlehmann (n=erlehman@tmo-104-210.customers.d1-online.com) ("Ex-Chat")
  915. # [17:40] <Lachy> TabAtkins, with the ::section() pseudo-element, that makes styling section elements by their nesting level a little confusing, since if you do section::section(n), you end up styling the pseudo instead of the section element itself
  916. # [17:40] <TabAtkins> Lachy: Heh, I was just in the middle of typing exactly that.
  917. # [17:41] <Lachy> and that's a little problematic if you want to set default styles for section, and then override them based on the level
  918. # [17:41] <Lachy> and I'd rather not have :section() pseudo-class and a ::section pseudo-element to cover both cases
  919. # [17:41] <TabAtkins> Lachy: One possibility is making ::section(all) work, or similar. That way if you were using ::section at all, you'd *always* use it.
  920. # [17:42] <TabAtkins> And you wouldn't have to distinguish between explicit <article>/<section>/etc
  921. # [17:42] <TabAtkins> Of course, this would absolutely require the relaxation of the "only one pseudoelement, and only at the end" requirement.
  922. # [17:43] <Lachy> why would it?
  923. # [17:43] <TabAtkins> Because it seems silly that you can do section::before but not ::section(1)::before.
  924. # [17:43] <TabAtkins> Or ::section > p
  925. # [17:44] <krijnh> Silly putty?
  926. # [17:44] <Lachy> also, that won't work cause you want to style elements within that pseudo element, you'd have weird stuff like this: ::section(3) p { color: blue; }
  927. # [17:44] <TabAtkins> ::silly > putty
  928. # [17:44] <TabAtkins> Is that weird? I don't think so.
  929. # [17:44] <Lachy> I don't think pseudo elements normally have descendants
  930. # [17:45] <TabAtkins> Not normally.
  931. # [17:45] <TabAtkins> But why should that stop us?
  932. # [17:45] <Lachy> how does it work with the ::outside pseudo?
  933. # [17:45] <TabAtkins> (Also, I think that's mostly an accident of history.)
  934. # [17:45] <TabAtkins> Are you asking what ::section(3)::outside would do?
  935. # [17:46] * Joins: cpharmston (n=cpharmst@pool-173-73-172-177.washdc.fios.verizon.net)
  936. # [17:46] <Lachy> no, what does this do: ::outside p { ... }
  937. # [17:46] * Parts: cpharmston (n=cpharmst@pool-173-73-172-177.washdc.fios.verizon.net)
  938. # [17:46] <TabAtkins> Oh, I see. It would work exactly as you'd think. ::outside is a wrapper element, and it has the same descendants as its superior parent.
  939. # [17:46] <Lachy> I forget with CSS draft outside is defined in
  940. # [17:46] <TabAtkins> Generated Content.
  941. # [17:47] <Lachy> makes sense
  942. # [17:47] <TabAtkins> Hixie's the editor. >_<
  943. # [17:47] <Lachy> he was. Not any more. It's just that no-one has touched it since
  944. # [17:47] <takkaria> I wonder if CSS3 will ever be Turing-complete
  945. # [17:47] <takkaria> or rather, just CSS
  946. # [17:48] <Lachy> takkaria, then what happens with div::outside div
  947. # [17:48] <Lachy> I mean, div::outside>div
  948. # [17:48] <TabAtkins> That's a very good question, and I think both immediate answers are reasonable.
  949. # [17:48] <Lachy> s/takkaria/TabAtkins/
  950. # [17:49] <TabAtkins> That is, it would be reasonable for ::outside to have its superior parent as a child, but it would also be reasonable to just say that it doesn't, and that its descendants are identical to those of its superior parent.
  951. # [17:49] <Lachy> TabAtkins, takkaria, one of you has to change your name. You're messing with my autocomplete! :-)
  952. # [17:49] <TabAtkins> Just type three letters!
  953. # [17:49] <TabAtkins> And I could go back to Xanthir, but then nobody knows who I am.
  954. # [17:50] <Lachy> no, it's fine. I'll deal with it
  955. # [17:50] <TabAtkins> Using the latter would probably work better in conjuction with a theoretical ::inside as well - all three (base element, ::outside, and ::inside) would have the same set of descendants.
  956. # [17:51] <takkaria> public-html was getting reasonably technical before this dt thread came along
  957. # [17:52] <TabAtkins> It's too easy to blame Shelley, so I'm going to blame Lief for it, takkaria.
  958. # [17:52] <hsivonen> who is behind this: http://www.o3mobi.com/ ?
  959. # [17:52] <Lachy> takkaria, then it's good the dt thread started then. We can't mess with the status quo, and have public-html become productive all of a sudden. That would create all sorts of confusion.
  960. # [17:53] <takkaria> "oh no, a sudden outbreak of productivity! quick, build a bikeshed over it!"
  961. # [17:53] <Lachy> what colour?!
  962. # [17:55] * Quits: pesla (n=retep@procurios.xs4all.nl) ("( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )")
  963. # [17:55] <takkaria> "we can't reuse an old colour, we need a new colour, one which no-one has ever even imagined before"
  964. # [17:56] <TabAtkins> breenwhip
  965. # [17:57] <TabAtkins> So hey, let's talk about <h1> some more. There was something about figure>h1 containing paragraphs of content, and this being a problem?
  966. # [17:57] <TabAtkins> Presumably a styling problem, having paragraphs of 2em-tall text.
  967. # [17:57] <TabAtkins> Also maybe a parsing issue?
  968. # [17:58] <takkaria> don't think there are parsing isues with <h1>
  969. # [17:58] <Lachy> takkaria, we should pick a colour outside of the visible light spectrum so that we can be sure it hasn't been used before
  970. # [17:58] * Quits: workmad3 (n=davidwor@ashleys2.mimas.ac.uk) (Read error: 110 (Connection timed out))
  971. # [17:59] <TabAtkins> jgraham_ mentioned a possible parsing issue, but didn't go into details.
  972. # [18:01] * Quits: hobertoAtWork (n=hobertoa@gw1.mcgraw-hill.com) ("Nettalk6 - www.ntalk.de")
  973. # [18:02] <Lachy> I'm not sure what parsing issue he was referring to either. I don't know of any that would have any relevance within figure
  974. # [18:03] <TabAtkins> All right, I will assume drugs were involved until further notice.
  975. # [18:03] <da3d> Lachy: Octarine :)
  976. # [18:04] * Joins: erlehmann (n=erlehman@tmo-104-210.customers.d1-online.com)
  977. # [18:07] <TabAtkins> So, is the only issue with <h1> in <figure> a display issue? (One that can be trivially fixed in an author's CSS.)
  978. # [18:07] <hsivonen> http://whois.net/whois/o3mobi.com
  979. # [18:07] <hsivonen> looks like someone wants to publish interesting software but stay secret about who they are
  980. # [18:08] * Joins: MikeSmith (n=MikeSmit@EM114-48-135-155.pool.e-mobile.ne.jp)
  981. # [18:09] * Quits: drunknbass (n=drunknba@cpe-76-173-187-247.socal.res.rr.com) (Read error: 104 (Connection reset by peer))
  982. # [18:12] * Joins: sicking (n=chatzill@32.155.145.179)
  983. # [18:17] * Joins: annevk42 (n=annevk@5355732C.cable.casema.nl)
  984. # [18:21] * Joins: ap (n=ap@17.246.19.174)
  985. # [18:22] * Quits: erlehmann (n=erlehman@tmo-104-210.customers.d1-online.com) ("Ex-Chat")
  986. # [18:22] * Joins: erlehmann_ (n=erlehman@tmo-104-210.customers.d1-online.com)
  987. # [18:28] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) ("This computer has gone to sleep")
  988. # [18:28] * Quits: erlehmann_ (n=erlehman@tmo-104-210.customers.d1-online.com) (Read error: 54 (Connection reset by peer))
  989. # [18:28] * Joins: erlehmann__ (n=erlehman@tmo-104-210.customers.d1-online.com)
  990. # [18:29] <boblet_> TabAtkins: was the parsing issue from jgraham_ you were referring to the concern about <figure><h1> in legacy AT?
  991. # [18:29] <TabAtkins> I dunno. He didn't give details, so maybe?
  992. # [18:30] <boblet_> “jgraham_: I really dislike the idea of using h1 for <details> or <figure>. In particular I would expect it to interact poorly with legacy AT”
  993. # [18:30] <boblet_> just in case that’s more info than you already had
  994. # [18:30] <boblet_> (a couple of hours ago)
  995. # [18:31] * Quits: fishd_ (n=darin@c-67-180-164-209.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  996. # [18:31] * Joins: dave_levin (n=dave_lev@74.125.59.73)
  997. # [18:31] <zcorpan> TabAtkins: what if you want <h1> to be the figure content?
  998. # [18:32] <zcorpan> <dt> and <legend> cannot be the figure content because they are only allowed in some special places
  999. # [18:32] <boblet_> (ah, you were in that conversation I see—ignore)
  1000. # [18:33] <TabAtkins> zcorpan: Either make the <h1> that's supposed to label the figure come first, or put the <h1> that's supposed to be in the figure content in a wrapper of some sort - only the first h1 *child* of figure would be considered.
  1001. # [18:35] <MikeSmith> boblet_: thanks for the Google ウェーブ pointer
  1002. # [18:36] <boblet_> MikeSmith: np—one of my Twitter friends mentioned she’d be going to a Wave talk at Kyoto GUG so it was easy to ask
  1003. # [18:36] <boblet_> looks like the Tokyo one was earlier
  1004. # [18:37] * Quits: zcorpan (n=zcorpan@pat.se.opera.com)
  1005. # [18:37] * Joins: fishd_ (n=darin@nat/google/x-igxwatemunjkwfno)
  1006. # [18:40] <gsnedders> Anyone who speaks French around?
  1007. # [18:40] <Philip`> I can paste text into Google Translate
  1008. # [18:40] <Philip`> Does that count?
  1009. # [18:40] <boblet_> Philip` is armed and dangerous
  1010. # [18:40] <gsnedders> Philip`: no
  1011. # [18:42] <krijnh> gsnedders: pourquoi?
  1012. # [18:42] <gsnedders> krijnh: "les photos du bal de moi" is wrong, is it not? How would I phrase that?
  1013. # [18:42] <MikeSmith> gsnedders: plh speaks French, plus speaks English with a French accent
  1014. # [18:43] <MikeSmith> I think Hixie speaks French too
  1015. # [18:43] <gsnedders> Yeah, Hixie speaks the (Swiss) French of a 10 year old kid.
  1016. # [18:43] <hober> Hixie: I guess you were right re: s/en-US-x-Hixie/en-US/ in that blog post; an excerpt from it on ajaxian.com includes the full, joke lang="" value
  1017. # [18:43] <MikeSmith> and karlcow does too a little
  1018. # [18:43] <gsnedders> But he's asleep right now, so he isn't very useful.
  1019. # [18:43] <Rik|work> gsnedders: I'm French
  1020. # [18:43] * gavin speaks french
  1021. # [18:43] <gsnedders> Rik|work: See above
  1022. # [18:44] <gavin> "Des photos de moi au bal"?
  1023. # [18:44] <gavin> "Des photos de mon bal"?
  1024. # [18:44] <Rik|work> gsnedders: do you speak about pictures of you at a bal or pictures of your bal
  1025. # [18:44] <gsnedders> Rik|work: Of me at a ball
  1026. # [18:44] <gavin> my 1st option then
  1027. # [18:44] <gavin> s/Des/Les/ if desired
  1028. # [18:45] <Rik|work> gsnedders: "Des photos de moi au bal", as gavin said
  1029. # [18:45] * Quits: ttepasse (n=ttepas--@p5B015531.dip.t-dialin.net) ("?Q")
  1030. # [18:45] <gsnedders> Ah, so you'd use à, etc. for what a photo is of?
  1031. # [18:45] <Philip`> Hint for writing specs: Put the most controversial stuff at the end, so anyone reviewing the document is too tired by that point to comment on it
  1032. # [18:45] <gsnedders> (Or where it comes from, rather)
  1033. # [18:46] <gavin> equivalent to "Photos of me _at a_ ball"
  1034. # [18:46] <gsnedders> Yeah, right
  1035. # [18:46] <gsnedders> You wouldn't say photos of me of the ball in English either…
  1036. # [18:47] * Quits: erlehmann__ (n=erlehman@tmo-104-210.customers.d1-online.com) (Read error: 110 (Connection timed out))
  1037. # [18:47] <gsnedders> Pah. I just need to think more :)
  1038. # [18:47] <TabAtkins> Though it would be appropriate to say "photos of me from the ball", which would also be "a" in Spanish at least.
  1039. # [18:47] <TabAtkins> Gah, I mean "de".
  1040. # [18:48] <gavin> "Mes photos du bal" is "My photos from|of the bal"
  1041. # [18:48] <boblet_> hober: nice article btw :)
  1042. # [18:48] <gsnedders> gavin: Yeah, right, I know fine
  1043. # [18:48] <gsnedders> gavin: I just always fail to think of how to say stuff in French, though I'm fine when given French to read.
  1044. # [18:49] <gavin> yeah I have that problem too actually... despite having done K-12 entirely in french, I hardly ever get to speak/read it in day-to-day life nowadays
  1045. # [18:50] <gavin> so its easy to lose familiarity with phrasing/expressions/etc.
  1046. # [18:51] <gsnedders> All of the French relatives I speak to semi-regularly are bilingual, and as my French has fallen out of practice I've stopped speaking French to them so much (as doing so is harder), hence making my French ever more out of practice
  1047. # [18:52] * Quits: taf2 (n=taf2@38.99.201.242)
  1048. # [18:56] * Joins: cpharmston (n=cpharmst@office.threespot.com)
  1049. # [19:01] * Joins: annodomini (n=lambda@130.189.179.215)
  1050. # [19:02] <tantek> gsnedders - if you want practice French, especially in speaking about the web, check out #openweb
  1051. # [19:02] * Quits: sicking (n=chatzill@32.155.145.179) (Read error: 110 (Connection timed out))
  1052. # [19:02] <Rik|work> don't go there, it's full of strange people
  1053. # [19:03] * Parts: boblet_ (n=boblet@p1254-ipbf304osakakita.osaka.ocn.ne.jp)
  1054. # [19:03] * Joins: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com)
  1055. # [19:03] <Rik|work> gsnedders: if you wanna practice french, come to http://www.paris-web.fr/2009/
  1056. # [19:04] * Joins: cohitre (n=cohitre@64-40-56-45-dsl.itltd.net)
  1057. # [19:06] * Parts: annevk42 (n=annevk@5355732C.cable.casema.nl)
  1058. # [19:08] <MikeSmith> .me sees bruce lawson tweet about object and tries to remember why @classid on object is not defined as a conformant attribute in the spec
  1059. # [19:09] * Joins: annevk42 (n=annevk@5355732C.cable.casema.nl)
  1060. # [19:09] <hsivonen> MikeSmith: it's product-specific
  1061. # [19:10] <hsivonen> (to IE)
  1062. # [19:10] <MikeSmith> ah
  1063. # [19:10] <hsivonen> MikeSmith: it's also redundant with the mime type-based dispatch
  1064. # [19:10] * MikeSmith remembers some list discussions now
  1065. # [19:11] <MikeSmith> hsivonen: thanks
  1066. # [19:11] <MikeSmith> bruce should just get on IRC
  1067. # [19:11] * Joins: erlehmann (n=erlehman@tmo-104-210.customers.d1-online.com)
  1068. # [19:12] * MikeSmith will be glad when this whole microblogging fad is over and people rediscover irc
  1069. # [19:12] * Joins: benward (n=benward@nat/yahoo/x-ajftldheqpawllff)
  1070. # [19:12] <MikeSmith> Google Wave is basically just IRC, but with images and what-not
  1071. # [19:13] <Philip`> Google Wave is to IRC as HTML email is to plain text email
  1072. # [19:13] <MikeSmith> heh
  1073. # [19:13] <MikeSmith> IRC is just like CB radio, except with text instead of actual talking
  1074. # [19:14] <erlehmann> Google Wave is to IRC what Battlestar Galactica is to Voyager
  1075. # [19:14] <othermaciej> IRC is such a crufty and half-assed protocol
  1076. # [19:14] <Rik|work> MikeSmith: there's a backlog with IRC, not with CB
  1077. # [19:14] <Philip`> I remember the PowWow chat program (long long ago, before ICQ) where you could see the characters people were typing in real time, and you could change your font and background colour
  1078. # [19:14] <TabAtkins> The nice thing about tweets is that they are relatively permanent and searchable, unlike your average IRC room.
  1079. # [19:14] <othermaciej> it's a wonder that it hasn't been either replaced or properly specified by RFC
  1080. # [19:14] <Philip`> so naturally I had 24pt magenta Comic Sans on a yellow background
  1081. # [19:14] <erlehmann> Rik|work, there is a backlog on entry with Jabber MUC
  1082. # [19:14] <Philip`> It was horrid
  1083. # [19:15] <MikeSmith> LL Cool J once said that IRC rocks the bells
  1084. # [19:15] <erlehmann> Philip`, iNtErEsTiNg :D
  1085. # [19:15] <MikeSmith> I think the Too Live Crew said it too
  1086. # [19:15] * Joins: cying_ (n=cying@70.90.171.153)
  1087. # [19:16] <Philip`> erlehmann: Watch out, I think you may have a small animal jumping up and down on your shift key
  1088. # [19:16] <erlehmann> yurr
  1089. # [19:16] <TabAtkins> I think we need a text-transform:alternating-caps value.
  1090. # [19:17] * Joins: taf2 (n=taf2@216-15-54-105.c3-0.grg-ubr3.lnh-grg.md.cable.rcn.com)
  1091. # [19:17] <erlehmann> it will be integrated in CSS3 text modes, together with text-transform:rot13 and text-transform:leet
  1092. # [19:17] <TabAtkins> I am satisfied with this progress.
  1093. # [19:17] * Quits: cpharmston (n=cpharmst@office.threespot.com) ("Leaving.")
  1094. # [19:17] <erlehmann> CSSquirrel comic about that proposal in three, two, one …
  1095. # [19:17] <Rik|work> we need text-transform: banner; and text-transform: figlet too
  1096. # [19:18] <Philip`> othermaciej: You mean like http://tools.ietf.org/html/rfc2810 (plus the subsequent three)?
  1097. # [19:18] <Philip`> or are those just not "proper"?
  1098. # [19:18] <othermaciej> Philip`: my understanding is that clients and servers all deviate from those RFCs in various ways (but I could be misinformed)
  1099. # [19:19] <Philip`> othermaciej: That's true of all specifications, so IRC doesn't seem particularly special in that way
  1100. # [19:19] <Philip`> Maybe IRC has many more deviations than most protocols, though
  1101. # [19:20] <takkaria> the IRC RFCs are good enough to write a client with, generally
  1102. # [19:21] <othermaciej> Philip`: fair enough
  1103. # [19:21] * Joins: zdobersek (n=zan@cpe-92-37-67-47.dynamic.amis.net)
  1104. # [19:21] * Philip` wrote a text-based FPS game which provided an IRC server interface, and it probably totally violated all the RFCs but it actually worked quite nicely with mIRC
  1105. # [19:21] * Quits: myakura (n=myakura@p2046-ipbf4007marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  1106. # [19:26] * Quits: weinig|zzz (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  1107. # [19:28] <tantek> TabAtkins, erlehmann, you should propose those additional text-transform features for CSS4.1, as I did with "text-transform:continental" here: http://lists.w3.org/Archives/Public/www-style/2003Apr/0012.html
  1108. # [19:32] <TabAtkins> tantek: I see that text-transform:l33t was already suggested in that thread.
  1109. # [19:33] <tantek> TabAtkins, indeed, although I would suggest text-transform:1337 instead
  1110. # [19:34] * Joins: mlpug (n=mlpug@a88-115-164-40.elisa-laajakaista.fi)
  1111. # [19:36] * Joins: jacobolus (n=jacobolu@dhcp-0059640045-80-3c.client.student.harvard.edu)
  1112. # [19:36] * Quits: jacobolus (n=jacobolu@dhcp-0059640045-80-3c.client.student.harvard.edu) (Remote closed the connection)
  1113. # [19:36] * Joins: jacobolus (n=jacobolu@dhcp-0059640045-80-3c.client.student.harvard.edu)
  1114. # [19:38] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
  1115. # [19:39] * Quits: erlehmann (n=erlehman@tmo-104-210.customers.d1-online.com) (Read error: 104 (Connection reset by peer))
  1116. # [19:39] * Joins: erlehmann_ (n=erlehman@tmo-104-210.customers.d1-online.com)
  1117. # [19:50] * Quits: erlehmann_ (n=erlehman@tmo-104-210.customers.d1-online.com) ("Ex-Chat")
  1118. # [19:53] * Quits: jacobolus (n=jacobolu@dhcp-0059640045-80-3c.client.student.harvard.edu) (Read error: 110 (Connection timed out))
  1119. # [19:54] * Quits: taf2 (n=taf2@216-15-54-105.c3-0.grg-ubr3.lnh-grg.md.cable.rcn.com)
  1120. # [19:55] * Joins: jwalden (n=waldo@nat/mozilla/x-wlbihhrswerczshi)
  1121. # [19:55] * Joins: weinig (n=weinig@17.246.16.129)
  1122. # [19:57] * Quits: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com) (Read error: 113 (No route to host))
  1123. # [19:58] * Joins: erlehmann (n=erlehman@tmo-104-210.customers.d1-online.com)
  1124. # [19:58] * Quits: erlehmann (n=erlehman@tmo-104-210.customers.d1-online.com) (Client Quit)
  1125. # [19:59] * ap is now known as ap|away
  1126. # [19:59] * Joins: franksalim (n=frank@adsl-75-61-85-210.dsl.pltn13.sbcglobal.net)
  1127. # [20:04] * Joins: mpilgrim (n=mark@64.241.37.140)
  1128. # [20:05] <TabAtkins> tantek, you planning on writing up that <pre separator> proposal anytime soon?
  1129. # [20:08] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  1130. # [20:08] * Joins: cying__ (n=cying@70.90.171.153)
  1131. # [20:09] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Read error: 104 (Connection reset by peer))
  1132. # [20:10] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  1133. # [20:14] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  1134. # [20:14] * Quits: zdobersek (n=zan@cpe-92-37-67-47.dynamic.amis.net) ("Leaving.")
  1135. # [20:15] * Joins: sicking (n=chatzill@nat/mozilla/x-nszrtczdyvlugjtq)
  1136. # [20:15] * Joins: dbaron (n=dbaron@nat/mozilla/x-hwihhpqdbzpugwht)
  1137. # [20:15] * Joins: [1]mpilgrim (n=mark@64.241.37.140)
  1138. # [20:17] <Lachy> TabAtkins, what's the <pre separator> proposal?
  1139. # [20:17] <tantek> TabAtkins - yes I have a .txt file on it
  1140. # [20:18] <TabAtkins> Lachy: A proposal to make allow csv data to be treated like a table. Put it in <pre>, specify what the separator is (tab, comma, etc), and bam.
  1141. # [20:18] <Lachy> interesting
  1142. # [20:18] <TabAtkins> I've got a js parser built for it that just swaps the <pre> out for an equivalent <table>.
  1143. # [20:19] <TabAtkins> tantek mentioned it offhand one day, I thought it was interesting and threw together a parser in about 20 minutes. Then I spent some time to make a *good* parser that will actually work on real content.
  1144. # [20:19] <TabAtkins> http://www.xanthir.com/etc/csv.htmlhttp://www.xanthir.com/etc/csv.html
  1145. # [20:19] <TabAtkins> http://www.xanthir.com/etc/csv.html rather
  1146. # [20:20] * Quits: weinig (n=weinig@17.246.16.129) (Remote closed the connection)
  1147. # [20:20] * Joins: weinig (n=weinig@nat/apple/x-xkmxodikivozcqdz)
  1148. # [20:21] <Lachy> how would that work with styling though? Presumably, a browser implementation would leave the <pre> in the DOM, rather than replacing it, but render it as a table
  1149. # [20:21] * Quits: cohitre (n=cohitre@64-40-56-45-dsl.itltd.net)
  1150. # [20:21] <Lachy> seems like something that could, in theory, be done with an XBL binding
  1151. # [20:21] <tantek> Lachy - you could use the table pseudo-elements from CSS
  1152. # [20:21] <tantek> even easier than XBL
  1153. # [20:21] <Lachy> does CSS have table pseudo-elements now?
  1154. # [20:21] <annevk2> there are no table psuedo-elements
  1155. # [20:22] <TabAtkins> Lachy: Dunno, unfortunately. You'd probably have to go with something like XBL somehow.
  1156. # [20:22] <Lachy> I suspect annevk2 is right. I've not seen them before
  1157. # [20:22] <annevk2> and implementing them for this seems a little excessive for something that can be done through scripting
  1158. # [20:23] * Quits: cying__ (n=cying@70.90.171.153)
  1159. # [20:23] <Lachy> I've heard proposals for table related pseudo-classes though, but they wouldn't work here
  1160. # [20:23] * Joins: drunknbass_work (n=aaron@pool-71-107-253-243.lsanca.dsl-w.verizon.net)
  1161. # [20:23] <TabAtkins> Yeah, those discussion were just for :col() and :nth-col()
  1162. # [20:24] <TabAtkins> You really would need either pseudoelements, or a CSS shadow tree.
  1163. # [20:24] <annevk2> your feature proposal is not going to make it then :)
  1164. # [20:24] * Quits: cying_ (n=cying@70.90.171.153) (Connection timed out)
  1165. # [20:25] <TabAtkins> Noes!
  1166. # [20:25] * TabAtkins cries.
  1167. # [20:25] <dbaron> I wanted :col() and :nth-col() to be pseudo-classes, not pseudo-elements.
  1168. # [20:25] <TabAtkins> dbaron: Yeah, we're not trying to abuse those into working here. ^_^
  1169. # [20:25] <gsnedders> tantek: I have almost no technical French, so that would be hard.
  1170. # [20:26] <gsnedders> Rik|work: If you can get my employer to pay for me to go :P
  1171. # [20:26] * Quits: fearphage (n=fearphag@xbmc/user/fearphage) (farmer.freenode.net irc.freenode.net)
  1172. # [20:26] <Rik`> gsnedders: which is ?
  1173. # [20:26] <gsnedders> Rik`: Opera
  1174. # [20:26] * Joins: fearphage (n=fearphag@xbmc/user/fearphage)
  1175. # [20:26] <Rik`> oh, Molly and Chaals are already coming
  1176. # [20:27] <TabAtkins> The big problem, I think, even bigger than styling, is just how it's supposed to be exposed in the dom. Part of the point of <pre separator> is that it is supposed to magically *act* like a <table>.
  1177. # [20:27] <gsnedders> Rik`: Don't you know half this channel works for Opera? :P
  1178. # [20:27] <TabAtkins> I suggest we just swap the <pre> out in the dom for a <table>. That solves everything. ^_^
  1179. # [20:27] * Joins: cohitre (n=cohitre@c-24-18-158-106.hsd1.wa.comcast.net)
  1180. # [20:28] <annevk2> you seriously think all this complexity is worth it over a simple online cvs to HTML <table> converter?
  1181. # [20:28] <annevk2> because if you do you'd be wrong
  1182. # [20:28] * Joins: taf2 (n=taf2@216-15-54-105.c3-0.grg-ubr3.lnh-grg.md.cable.rcn.com)
  1183. # [20:28] <TabAtkins> I think it was a fun project to work on. Tantek's the one with the vision.
  1184. # [20:28] <annevk2> s/cvs/csv/
  1185. # [20:28] <tantek> annevk2 - what complexity?
  1186. # [20:28] <Rik`> gsnedders: you should talk with Chaals, he's really speaking a good French
  1187. # [20:29] <tantek> and if an online cvs to HTML <table> converter is so simple, where are they? show some URLs - or else it's not simple.
  1188. # [20:29] <gsnedders> Rik`: I scarcely have the opportunity to speak to him.
  1189. # [20:30] <Rik`> so do I, lots of unanswered mails :(
  1190. # [20:30] <gsnedders> Rik`: I could far more easily just talk to one of my French relatives :)
  1191. # [20:31] <tantek> TabAtkins - the DOM problem is fairly straightforward, on <pre>s with separator, they get the <table> DOM interface as well
  1192. # [20:31] <TabAtkins> tantek: You mean other than my converter? ^_^
  1193. # [20:32] * Quits: fearphage (n=fearphag@xbmc/user/fearphage) (farmer.freenode.net irc.freenode.net)
  1194. # [20:32] * Joins: fearphage (n=fearphag@xbmc/user/fearphage)
  1195. # [20:33] <tantek> TabAtkins - right - your converter does it inline in a document, expressly to demonstrate the utility of <pre separator> - whereas annevk2 is implying a .cvs (like an entire file) to <table> converter
  1196. # [20:33] <TabAtkins> I found at least one of those, actually.
  1197. # [20:33] * Joins: zdobersek (n=zan@cpe-92-37-67-47.dynamic.amis.net)
  1198. # [20:34] <annevk42> tantek, styling, DOM, etc.
  1199. # [20:34] <tantek> annevk42, the DOM is a solved problem.
  1200. # [20:34] <annevk42> tantek, there's no need to have a separate syntax for something that's essentially a table
  1201. # [20:34] <tantek> give it a .table property that gives a <table> interface, done
  1202. # [20:35] <annevk42> euhm, no
  1203. # [20:35] * Quits: mpilgrim (n=mark@64.241.37.140) (Read error: 110 (Connection timed out))
  1204. # [20:35] <tantek> annevk42 - the utility is the rapid/easy re-use of all the opengov etc. data out there
  1205. # [20:35] <annevk42> but I'm not going to waste my time on this -- have fun :)
  1206. # [20:35] <tantek> your phrase "essentially a table" completely misses the point of the current difficulties that the open gov and science communities have today with datasets
  1207. # [20:36] <TabAtkins> http://plugins.jquery.com/project/csv2table
  1208. # [20:37] <annevk42> tantek, is the difficulty exporting it to HTML?
  1209. # [20:38] * Joins: murr4y (n=murray@85.84-49-67.nextgentel.com)
  1210. # [20:38] <tantek> annevk42 yes that's a big part of it, and then having libraries to interact with <table> as they do with csv today.
  1211. # [20:38] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  1212. # [20:38] <tantek> also, when you have huge datasets, the tagjunk from explicit <table> markup tends to bloat them (like double the size etc.)
  1213. # [20:39] <tantek> slows down processing efficiency etc.
  1214. # [20:39] <tantek> why would you convert your csv to explicit <table> markup if that meant processing your data would take 2 days instead of 1?
  1215. # [20:40] <tantek> etc.
  1216. # [20:40] <annevk42> why would you convert it before processing?
  1217. # [20:41] * Quits: cohitre (n=cohitre@c-24-18-158-106.hsd1.wa.comcast.net)
  1218. # [20:42] * aroben is now known as aroben|lunch
  1219. # [20:42] * Quits: [1]mpilgrim (n=mark@64.241.37.140) (Read error: 110 (Connection timed out))
  1220. # [20:42] * Joins: drunknbass_wor (n=aaron@pool-71-107-253-243.lsanca.dsl-w.verizon.net)
  1221. # [20:47] * Joins: cying_ (n=cying@70.90.171.153)
  1222. # [20:49] * Quits: murr4y` (n=murray@85.84-49-67.nextgentel.com) (Read error: 110 (Connection timed out))
  1223. # [20:50] * Guest31664 should probably ask here before he starts filling up Hixie's inbox with old tokenisation issues.
  1224. # [20:51] * Parts: Guest31664 (n=and@apo29.girton.cam.ac.uk)
  1225. # [20:51] * Joins: and (n=and@apo29.girton.cam.ac.uk)
  1226. # [20:52] <and> Sorry, wrong nickname.
  1227. # [20:53] <and> 1) At end of file, unclosed comments and DOCTYPEs are output, but not unclosed start and end tags. Is there a reason not to output whatever is unclosed at EOF?
  1228. # [20:54] * Quits: mat_t (n=mattomas@91.189.88.12) (Remote closed the connection)
  1229. # [20:54] <and> 2) Is it really necessary to handle slashes inside tags as whitespace now when it is handled specially at the end of void elements?
  1230. # [20:55] <and> 3) --!> and -- > (with a space) do not close short comments, i.e., those that contain only two or three hyphens.
  1231. # [20:56] <and> 4) Would it make sense to extend the concept of non-ambiguous ampersand? It is only truly ambiguous before A-Z, a-z and # anyway.
  1232. # [20:57] <annevk42> 2) pretty sure the answer is yes
  1233. # [20:57] <takkaria> 1) was changed for security reaosns from outputting those tags to not outputting them
  1234. # [20:58] <annevk42> 3) might be a bug, dunno
  1235. # [20:58] <and> In case the last part of the file is missing?
  1236. # [21:00] <takkaria> yeah, something like that
  1237. # [21:00] * Joins: webben (n=benh@nat/yahoo/x-vwhzsiyjneynilbd)
  1238. # [21:00] <jgraham_> and: In case an attacker manages to cause an EOF I think
  1239. # [21:02] <jgraham_> and: I think 3) is because Hixie didn't want those to close comments at all but it is needed for web-compat
  1240. # [21:02] <jgraham_> so he made it happen in as few places as possible
  1241. # [21:02] <jgraham_> (but it might be a bug)
  1242. # [21:03] <and> I do not quite see how the current behaviour helps, though. Presumably, it would be just as easy to insert EOF before the tag as in the middle?
  1243. # [21:06] <annevk42> prevents executing scripts
  1244. # [21:07] <and> If there is an onload on the element in question? (I am probably missing something obvious.)
  1245. # [21:08] <and> s/element/tag/
  1246. # [21:10] * Joins: dpranke (n=Adium@nat/google/x-yuzyjszytwtbckwx)
  1247. # [21:13] <annevk42> if it's a <script> tag
  1248. # [21:13] <annevk42> i forgot the exploit details to be honest
  1249. # [21:13] * Joins: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley)
  1250. # [21:14] * Joins: othermaciej (n=mjs@nat/apple/x-klttfmqvqjtzkndq)
  1251. # [21:15] <and> I guess a <script> tag with an unfinished src attribute might be problematic.
  1252. # [21:16] <and> Thanks everyone!
  1253. # [21:17] <and> (though it does not seem particularly easy to exploit)
  1254. # [21:22] * Joins: Super-Dot (n=Super-Do@66-240-27-50.isp.comcastbusiness.net)
  1255. # [21:24] <and> annevk2: I did finish testing encoding labels in IE last week, by the way. In summary: The "gb2312-80" label does not work. Almost all the (???) encodings seem problematic, most of them perhaps not supported. I have no idea what "x-europa" refers to. UTF-7 and four somewhat obscure Taiwanese encodings have not been tested at all.
  1256. # [21:25] * Joins: ojan (n=ojan@nat/google/x-iwdlhuxrhzguldzj)
  1257. # [21:26] <and> annevk2: The last sentence on the wiki seems wrong (... make such an effort probable).
  1258. # [21:28] * Quits: tantek (n=tantek@70.36.139.108)
  1259. # [21:31] * Philip` sees that and is in cam.ac.uk
  1260. # [21:31] <Philip`> It's a hotbed of tokeniser activity :-o
  1261. # [21:32] <TabAtkins> othermaciej: I was looking for synonyms of figure that started with a d, and settled on <diagram> as well. ^_^
  1262. # [21:34] * aroben|lunch is now known as aroben
  1263. # [21:38] <drunknbass_wor> i know you can use the img to draw to canvas but how does it know the image size?
  1264. # [21:38] <drunknbass_wor> do Image() have property w and h?
  1265. # [21:39] <Philip`> They have .width and .height
  1266. # [21:39] <drunknbass_wor> oh cool
  1267. # [21:41] * Quits: taf2 (n=taf2@216-15-54-105.c3-0.grg-ubr3.lnh-grg.md.cable.rcn.com)
  1268. # [21:52] * Joins: mpilgrim (n=mark@rrcs-96-10-240-189.midsouth.biz.rr.com)
  1269. # [21:53] * Joins: KevinMarks (n=KevinMar@157.22.22.46)
  1270. # [22:06] * Joins: cohitre (n=cohitre@dsl254-016-073.sea1.dsl.speakeasy.net)
  1271. # [22:14] * Joins: tantek (n=tantek@adsl-71-141-229-148.dsl.snfc21.pacbell.net)
  1272. # [22:16] * Quits: gsnedders (n=gsnedder@host217-44-35-222.range217-44.btcentralplus.com) (Remote closed the connection)
  1273. # [22:16] * Joins: gsnedders (n=gsnedder@host217-44-35-222.range217-44.btcentralplus.com)
  1274. # [22:17] <annevk42> and, changed
  1275. # [22:17] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) (Read error: 110 (Connection timed out))
  1276. # [22:18] <annevk42> and, IE testing sounds good
  1277. # [22:18] <annevk42> and, did you find missing things? e.g. most other UAs support "utf8" as alias
  1278. # [22:19] <and> annevk42: Looks fine now.
  1279. # [22:19] * Quits: mlpug (n=mlpug@a88-115-164-40.elisa-laajakaista.fi) (Remote closed the connection)
  1280. # [22:20] <and> annevk42: I did not look for missing labels. I did, however, try utf8 since you mentioned it earlier and found that it did *not* work in IE8.
  1281. # [22:20] <gsnedders> Anyone have any clue as to the status of html5lib Ruby?
  1282. # [22:21] <annevk42> and, k
  1283. # [22:22] * Joins: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley)
  1284. # [22:23] * Quits: cohitre (n=cohitre@dsl254-016-073.sea1.dsl.speakeasy.net)
  1285. # [22:23] <gsnedders> Also, and one know how to run the tests for Ruby?
  1286. # [22:25] * Joins: weinig_ (n=weinig@17.246.16.129)
  1287. # [22:25] * Quits: weinig_ (n=weinig@17.246.16.129) (Client Quit)
  1288. # [22:26] * Quits: tantek (n=tantek@adsl-71-141-229-148.dsl.snfc21.pacbell.net) (Read error: 104 (Connection reset by peer))
  1289. # [22:27] * Joins: tantekc (n=tantek@adsl-71-141-229-148.dsl.snfc21.pacbell.net)
  1290. # [22:28] <othermaciej> TabAtkins: I think <diagram> is less good as a name for what <figure> does, enough to make the benefit of d-alignment not worth it
  1291. # [22:28] <TabAtkins> othermaciej: I agree, unfortunately.
  1292. # [22:28] <TabAtkins> But I also think that <dt>/<dd> in <figure> just feels *retarded*.
  1293. # [22:28] <TabAtkins> We should just call it <digure> and be done with it.
  1294. # [22:29] <Lachy> haha
  1295. # [22:29] * Parts: zdobersek (n=zan@cpe-92-37-67-47.dynamic.amis.net)
  1296. # [22:30] <othermaciej> TabAtkins: my own feeling on it was "a little odd", but it's clear that it's created some highly negative reactions
  1297. # [22:30] * Quits: othermaciej (n=mjs@nat/apple/x-klttfmqvqjtzkndq) (Read error: 104 (Connection reset by peer))
  1298. # [22:31] * Joins: othermaciej (n=mjs@nat/apple/x-rnirwtkzdxrsnwin)
  1299. # [22:31] <TabAtkins> It doesn't bother me on the deep level that it seems to for others, but I can definitely understand why they feel that way.
  1300. # [22:31] * Joins: erlehmann (n=erlehman@echelon.ext.c-base.org)
  1301. # [22:31] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  1302. # [22:32] <TabAtkins> <dt>/<dd> are clearly associated with <d*> things. Classically it's <dl>, we had <dialog> for a long time, now <details> (where I think <dt>/<dd> work well), but <figure> is just an odd man out. It feels like a dirty hack where such a hack shouldn't be necessary.
  1303. # [22:32] * tantekc is glad <dialog> is out
  1304. # [22:32] <tantekc> <figure> is also quite a different use-case than <details>
  1305. # [22:33] <erlehmann> tantekc, what you say
  1306. # [22:33] <Lachy> I wonder if we could expand details to allow multiple dt/dd pairs, similar to dl, where each dt/dd can be opened or closed individually?
  1307. # [22:33] <othermaciej> I think a new element to use as a <figure> label is the only other alternative (except maybe <h1>, but <h1> doesn't seem any better than <dt> to me)
  1308. # [22:33] <Lachy> though, it would mess with the details.open API
  1309. # [22:33] <TabAtkins> I think <h1> doesn't make people angry.
  1310. # [22:33] <othermaciej> Lachy: the thought of implementing that makes me cry with sad
  1311. # [22:33] <erlehmann> othermaciej, i still dont get what problems occur with <legend>
  1312. # [22:33] <tantekc> has someone written up a whatwg wiki page on the options for "heading-like" elements to use as the caption on a figure?
  1313. # [22:33] <Lachy> fair enough
  1314. # [22:33] * tantekc is unable to follow all the email threads
  1315. # [22:33] * Joins: weinig_ (n=weinig@17.246.16.129)
  1316. # [22:34] * Quits: weinig_ (n=weinig@17.246.16.129) (Client Quit)
  1317. # [22:34] <othermaciej> erlehmann: all browsers currently in use parse <legend> in a way that doesn't give the desired DOM
  1318. # [22:34] <Lachy> TabAtkins, I'm not happy about using h1. It's not a heading, it's a caption
  1319. # [22:34] <erlehmann> othermaciej, oha.
  1320. # [22:34] <TabAtkins> tantekc: No, but I've sort of taken up the torch for writing up that stuff. I meant to start it last weekend, but my internet died on Friday night and still hasn't come back up.
  1321. # [22:35] <erlehmann> othermaciej, but WHYYY
  1322. # [22:35] <othermaciej> they either drop it entirely, wrap it in a <fieldset>, or insert empty elements named <legend> and </legend> instead of making a legend with content
  1323. # [22:35] <erlehmann> urgs
  1324. # [22:35] <erlehmann> baaaad
  1325. # [22:35] <TabAtkins> Lachy: Sure, but it's still sort of a heading for the included content.
  1326. # [22:35] <Lachy> tantekc, othermaciej wrote a nice summarising e-mail that listed most of the options considered
  1327. # [22:35] <tantekc> ideally we'd reuse <caption> because that's what people refer to when using figure as a term of speech
  1328. # [22:35] <Lachy> I think it was the dt/dd thread
  1329. # [22:35] <tantekc> Lachy - yeah, summary emails are also hard to find
  1330. # [22:35] <TabAtkins> Yeah, <caption> is really the absolute ideal name.
  1331. # [22:35] <Lachy> I will find it
  1332. # [22:35] <erlehmann> tantekc, why dont we ?
  1333. # [22:36] * Quits: webben (n=benh@nat/yahoo/x-vwhzsiyjneynilbd) (Read error: 110 (Connection timed out))
  1334. # [22:36] * Joins: weinig_ (n=weinig@17.246.16.129)
  1335. # [22:36] * Quits: GPHemsley (n=GPHemsle@pdpc/supporter/student/GPHemsley) ("Leaving")
  1336. # [22:36] * gsnedders hits issues again with html5lib tests not being JSON despite claiming to be
  1337. # [22:36] <TabAtkins> But I believe it dies when you try to use <figure><caption></figure> in a <table>?
  1338. # [22:36] <erlehmann> too much elements already?
  1339. # [22:36] <Lachy> tantekc, http://www.w3.org/mid/CF65ED73-5D08-4AAD-812B-4DB634E01566@apple.com
  1340. # [22:36] <tantekc> erlehmann, precisely the question I'm asking, but email sucks so it is difficult to answer
  1341. # [22:36] <othermaciej> anyone who wants to make a blog post out of that email should feel free to do so
  1342. # [22:36] <erlehmann> TabAtkins, would that fuck up the DOM as well ?
  1343. # [22:37] <tantekc> it should be a wiki page because the info evolves over time
  1344. # [22:37] <othermaciej> the specific problem with caption is that browsers drop it outside of tables (same issue as <legend>) and using it anywhere inside a table breaks out of the current cell to the table top level
  1345. # [22:37] * da3d proposes adding <faption> for figures...
  1346. # [22:37] <TabAtkins> <faption><faption><faption>
  1347. # [22:37] <othermaciej> I agree that it's the best word match for a figure's caption
  1348. # [22:37] * Quits: weinig (n=weinig@nat/apple/x-xkmxodikivozcqdz) (Read error: 110 (Connection timed out))
  1349. # [22:37] * weinig_ is now known as weinig
  1350. # [22:37] <Lachy> using <caption> is even more problematic than <legend> for backwards compatibility reasons.
  1351. # [22:37] <erlehmann> FapFapFap
  1352. # [22:37] <TabAtkins> I feel dirty typing that.
  1353. # [22:37] * Joins: ttepasse (n=ttepas--@dslb-084-060-012-022.pools.arcor-ip.net)
  1354. # [22:37] <tantekc> othermaciej, by "drop" do you mean "display:none" or not in the DOM tree?
  1355. # [22:38] <othermaciej> tantekc: not in the DOM
  1356. # [22:38] <erlehmann> urgs, not again
  1357. # [22:38] <othermaciej> but the table issue is the big one - it would make <figure> unusable in tables
  1358. # [22:38] <Lachy> but, I wonder if the parsing could be fixed so that <caption> within <figure> doesn't suffer from the insanity needed elsewhere.
  1359. # [22:38] <tantekc> indeed
  1360. # [22:39] <erlehmann> <figure><insanity/></figure>
  1361. # [22:39] <tantekc> othermaciej - I don't think that's that bad of a problem
  1362. # [22:39] <othermaciej> Lachy: it can't be fixed retroactively for legacy browsers
  1363. # [22:39] <tantekc> because such tables are likely due to layout anyway
  1364. # [22:39] <tantekc> which should be discouraged
  1365. # [22:39] * tantekc wonders if there is a table of figures use case.
  1366. # [22:39] <Lachy> othermaciej, yeah, I know, it sucks for legacy browsers. But as a long term plan for new browsers, I don't see why it couldn't work.
  1367. # [22:40] <erlehmann> Lachy, but HTML is legacy aware
  1368. # [22:40] <Lachy> though, that doesn't really solve the problem we were trying to avoid with legend
  1369. # [22:40] <othermaciej> exactly
  1370. # [22:40] <erlehmann> <figure> with <dd><dt> is already out ?
  1371. # [22:41] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Read error: 104 (Connection reset by peer))
  1372. # [22:41] <TabAtkins> Note: the "drops from the DOM" bit of <caption> is crazy! In FF at least it just drops the element, but still inserts the text content at the appropriate place in the DOM.
  1373. # [22:41] <othermaciej> the goal is to make figure usable this decade
  1374. # [22:41] <TabAtkins> erlehmann: figure>dt just feels horrible.
  1375. # [22:41] <othermaciej> TabAtkins: that's what it does in Safari too
  1376. # [22:41] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  1377. # [22:41] <othermaciej> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Ccaption%3Efoo%3C%2Fcaption%3E
  1378. # [22:42] <othermaciej> I think out of the existing elements with some technical difficulties, <label> has the least severe problems
  1379. # [22:42] <TabAtkins> I've never been quite sure - is there supposed to be a significant difference between <figure> and <aside>?
  1380. # [22:42] * drunknbass_wor is now known as drunknbass_work|
  1381. # [22:42] <Lachy> TabAtkins, yes
  1382. # [22:43] <TabAtkins> I see that <figure> is supposed to be main-flow content that isn't necessarily required to be presented in its given location.
  1383. # [22:43] <othermaciej> <figure> is supposed to be roughly for what you could call a figure in print - a picture, chart or table with a caption
  1384. # [22:43] * ap|away is now known as ap
  1385. # [22:43] <Lachy> a <figure> is for the type of thing that would, for instance, be listed in a Table of Figures commonly found in a book. Asides would never do that
  1386. # [22:43] <othermaciej> (though in HTML you could also make it a media item, such as a <video>)
  1387. # [22:44] <TabAtkins> I think I might want to do precisely that, though. It's tangentially-related content, right?
  1388. # [22:44] <othermaciej> <aside> is what you would use for a sidebar to a magazine article
  1389. # [22:44] <othermaciej> or a pull quote
  1390. # [22:45] <Lachy> yeah, <aside> is something that is out of the flow of the surrounding content
  1391. # [22:45] * Joins: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu)
  1392. # [22:45] <TabAtkins> Hmm. I get the distinction, but fear it may be cutting things pretty damn finely.
  1393. # [22:45] <Lachy> I really don't see how they are in any way similar
  1394. # [22:46] <TabAtkins> Both of them are content that is related to the document, but not in-flow.
  1395. # [22:46] <othermaciej> in the print realm you'd never confuse the two
  1396. # [22:46] <Lachy> figures are not necessarily out of the flow
  1397. # [22:49] <TabAtkins> Actually, I see that it's supposed to always be in-flow, but may be something that could be at least moved out of the text flow for visual reasons.
  1398. # [22:49] <erlehmann> like a table of figures at the end of the document
  1399. # [22:49] <TabAtkins> As opposed to <aside>, which isn't a part of the content at all, merely related to it in some way.
  1400. # [22:50] <TabAtkins> I suppose if I just keep thinking <aside>=<sidebar> I'll be okay.
  1401. # [22:50] <Lachy> I wish I could show you an example. But all the ones I'm thinking of are in my old text books from Uni, all of which are back home in Australia
  1402. # [22:51] * Quits: sbublava (n=stephan@77.119.62.19.wireless.dyn.drei.com)
  1403. # [22:51] <TabAtkins> Nah, I've got it in my head; I'm thinking of articles from SciAm which are usually chock full of graphs and figures illustrating things in the article.
  1404. # [22:51] <TabAtkins> I just dunno if I'll find the distinction useful in practice.
  1405. # [22:52] * TabAtkins used <dl> in crazy ways in his younger days.
  1406. # [22:52] <erlehmann> for styling reasons it sure is
  1407. # [22:52] <annodomini> Why can't we just use h1-h6 and/or hgroup for a figure caption?
  1408. # [22:52] <TabAtkins> annodomini: That's what I want to do.
  1409. # [22:53] <Lachy> because a heading is not a caption
  1410. # [22:53] <gsnedders> http://code.google.com/p/html5lib/issues/detail?id=117
  1411. # [22:53] <hober> re: aside v. figure, consider http://www.digital-web.com/articles/coding_for_content/
  1412. # [22:53] <TabAtkins> Lachy, it titles the figure.
  1413. # [22:53] <Lachy> and it has to be something that is easy to distinguish from the actual content of the figure, which could conceivably contain its own headings
  1414. # [22:54] <Lachy> (that's the reason <figure> is a section root, so that headings that are part of the figure don't affect the outline
  1415. # [22:54] <TabAtkins> Lachy: That's easy enough to do by saying that it's the figure>h1:first-of-type
  1416. # [22:55] <Lachy> that doesn't work when you want the caption to be at the end
  1417. # [22:55] <TabAtkins> So either put the caption before any other <h1>s, or wrap the figure content in something that will make its <h1>s not children of <figure>
  1418. # [22:55] <Lachy> that seems like a workaround for a problem that can be avoided
  1419. # [22:56] <erlehmann> dt dls !
  1420. # [22:56] <erlehmann> nah i'm drunk
  1421. # [22:56] <TabAtkins> Yeah, but other solutions either make people angry (<dt>/<dd>), don't work in legacy browsers (lots of stuff), or are just gratuitous (creating yet another heading element).
  1422. # [22:56] <Lachy> othermaciej, did you make any progress with implementing details, like you said you were going to do the other day? I'm curious to see what you came up with for it.
  1423. # [22:57] <othermaciej> Lachy: have not had time to work on it, but I intend to give it a crack this weekend
  1424. # [22:57] <Lachy> ok, cool.
  1425. # [22:57] <erlehmann> TabAtkins, I forsee styling issues with dt and dl too.
  1426. # [22:57] <Lachy> will it make it into a webkit nightly soon after?
  1427. # [22:57] <TabAtkins> erlehmann: I'm definitely going to have to revise some CSS before I can use <dt>/<dd> in <details> or <figure>.
  1428. # [22:58] <Lachy> I expect that will be a common problem for existing style sheets that style dt and dd in ways that won't be appropriate for details or figure
  1429. # [22:59] <erlehmann> TabAtkins, why the heck dont we add just another element? i mean, all existing solutions seem to feature insurmountabl obstacles :i
  1430. # [22:59] <TabAtkins> erlehmann: Because it's just so dumb to have a dozen different elements that all mean almost exactly the same thing. >_<
  1431. # [22:59] <Lachy> because Hixie is being stubbor about that
  1432. # [22:59] <erlehmann> TabAtkins, tell that to legacy browsers :P
  1433. # [22:59] <Lachy> *stubborn
  1434. # [23:00] <TabAtkins> erlehmann: Yeah, and do you want to be the legacy browser people curse in decades to come for implementing one or two *more*?
  1435. # [23:00] * Joins: itpastorn (n=gunther@139.57.227.87.static.th.siw.siwnet.net)
  1436. # [23:01] <erlehmann> TabAtkins, curse your sudden and inevitable long-term planning :D
  1437. # [23:01] * Quits: SamerZ (n=SamerZ@204.225.63.69)
  1438. # [23:01] <Lachy> TabAtkins, I don't get your argument
  1439. # [23:01] <TabAtkins> The nice thing about <h1> is that people are *already* going to have to adjust stylesheets if they want to use pure <h1>+<section> stuff. Making them have to handle <h1> in <figure> as well shouldn't be that hard.
  1440. # [23:01] <erlehmann> TabAtkins, BUT BROWSERS MADE TODAY ARE PURRFECT
  1441. # [23:02] <TabAtkins> erlehmann, OH GOD YOU ARE RIGHT HOW COULD I FORGET
  1442. # [23:02] <erlehmann> the bad thing about h1 is that legacy outliners will choke on them
  1443. # [23:02] <TabAtkins> That's gonna happen no matter what, though.
  1444. # [23:02] <erlehmann> and it will be there in BIG BOLD LETTERS
  1445. # [23:03] <TabAtkins> Nobody that relies on legacy outlining algorithms will correctly outline html5 documents.
  1446. # [23:03] <Lachy> legacy outliners are irrelevant
  1447. # [23:03] <erlehmann> cant we at least say that any heading in a figure is a caption ? then people could safely use <h3> and legacy styling will not be affected
  1448. # [23:03] <Lachy> well, almost
  1449. # [23:03] <erlehmann> but h1 is HUEG
  1450. # [23:03] <erlehmann> like xbox
  1451. # [23:04] <TabAtkins> erlehmann, your use of memes is getting ridiculous. ^_^
  1452. # [23:04] <Lachy> (I guess interpretation by screen readers will be the bigest problem since the heading levels will be reported wrongly)
  1453. # [23:04] <erlehmann> or put a hgroup in there
  1454. # [23:04] <erlehmann> then you have your title-subtitle thingy too for your figure
  1455. # [23:04] <erlehmann> also, way to much markup :p
  1456. # [23:04] <TabAtkins> Using <figure><h3><more stuff></figure> wont' display dumb, this is true.
  1457. # [23:04] * Joins: taf2 (n=taf2@216-15-54-105.c3-0.grg-ubr3.lnh-grg.md.cable.rcn.com)
  1458. # [23:04] <TabAtkins> Alternately: just do what someone else said and use <header>.
  1459. # [23:05] <TabAtkins> No outlining issues, no legacy styling issues, no parsing problems that people aren't already willing to deal with.
  1460. # [23:05] <erlehmann> TabAtkins, the <caption> is a lie! ;)
  1461. # [23:05] <da3d> <header> feels odd if you want to have the caption below the content
  1462. # [23:06] <erlehmann> TabAtkins, for consistency, footer too
  1463. # [23:06] * Quits: annodomini (n=lambda@wikipedia/lambda)
  1464. # [23:06] <Lachy> TabAtkins, using header would just be wrong
  1465. # [23:06] <TabAtkins> da3d: it also feels weird to put <footer> at the top of an article. But here we are.
  1466. # [23:06] <Lachy> because it would completely different from how its used within section
  1467. # [23:06] <da3d> TabAtkins: Does anyone do that?
  1468. # [23:06] <TabAtkins> erlehmann: The WHATWG would like to remind you that <caption> hell is real.
  1469. # [23:06] <TabAtkins> da3d: No one uses <footer> yet anyway (no one statistically significant), so meh.
  1470. # [23:07] <TabAtkins> Lachy: Hmm. You sure?
  1471. # [23:07] <TabAtkins> And by that I mean, can you quote me something that shows how I'm dumb?
  1472. # [23:08] <Lachy> yes
  1473. # [23:08] <TabAtkins> ...man, what *about* <footer>? That sort of not entirely inappropriate.
  1474. # [23:08] <TabAtkins> Lachy: Good, because I'm working and can't look up quotes to disprove myself right now. >_<
  1475. # [23:08] <Lachy> "The header element represents a group of introductory or navigational aids." - that is completely different from teh concept of a caption
  1476. # [23:08] <jgraham_> gsnedders: You planning to fix that bug or just complain?
  1477. # [23:08] * Quits: jacobolus (n=jacobolu@dhcp-0059871802-99-6d.client.student.harvard.edu) (Remote closed the connection)
  1478. # [23:08] <erlehmann> TabAtkins, different semantics are fail, Lachy is right with this.
  1479. # [23:09] <Lachy> I'm always right :-)
  1480. # [23:09] <jgraham_> <h1> is a totally different semantic and sucks much more in legacy browsers, especially AT
  1481. # [23:09] <Lachy> agreed
  1482. # [23:09] <TabAtkins> "A footer typically contains information about its section" <-- close enough for us to fiddle the text into working?
  1483. # [23:09] <jgraham_> You probably shouldn't use the all-<h1> headings thing in the near future for similar reasons
  1484. # [23:10] <da3d> Let's just add <stupidbrokencaptionparsers> and be done with it :p
  1485. # [23:10] <jgraham_> (You can always use <h1>-<h6> like normal in addition to <section>)
  1486. # [23:10] <erlehmann> TabAtkins, This figure problem is impossible. Make no attempt to solve it.
  1487. # [23:10] <jgraham_> TabAtkins: <footer> sounds wrong to any and all english speakers
  1488. # [23:11] <TabAtkins> Wronger than <dt>/<dd>?
  1489. # [23:11] <TabAtkins> I'd put even money on it.
  1490. # [23:11] <jgraham_> TabAtkins: The sensible options are <dt>,<dd>, <new>
  1491. # [23:11] <da3d> <figtion>
  1492. # [23:11] <erlehmann> <fiction>
  1493. # [23:12] <Lachy> dt/dd is also wrong and silly for figure. <figtion>, <figcaption>, etc. are terrible names
  1494. # [23:12] <erlehmann> jgraham_, is right. <dt> and <dl> are not entirely unreasonable (safe for styling issues)
  1495. # [23:12] <jgraham_> TabAtkins: <dt>,<dd> mean <name>,<value>. It's just some old version of HTML used over-short names
  1496. # [23:12] <Lachy> <c> and <description> are reasonable names for new elements
  1497. # [23:12] <TabAtkins> erlehmann: Remain resolute and resourceful in an atmosphere of extreme pessimism.
  1498. # [23:12] * Quits: zalan (n=zalan@catv-89-135-144-193.catv.broadband.hu) (Read error: 110 (Connection timed out))
  1499. # [23:12] <da3d> Lachy: <figtion> wasn't a serious suggestion :p
  1500. # [23:12] <TabAtkins> jgraham_, yeah, but that doesn't make them less stupid now.
  1501. # [23:13] <jgraham_> If we had <figure><value><img></value><name>My figure</name></figure> there wouldn't be this fuss
  1502. # [23:13] <Lachy> jgraham_, yes there would, because the extra wrapper around the value is unnecessary
  1503. # [23:13] <TabAtkins> jgraham_: Let's do it then. Throw out <dt><dd> entirely. <dl><name><value>...</dl> 4 life.
  1504. # [23:13] <jgraham_> TabAtkins: The reasons they are bad apply equally to <dl> and <details>
  1505. # [23:13] <erlehmann> Now you all are just getting silly for the sake of it.
  1506. # [23:14] * Joins: nessy (n=nessy@124-170-13-58.dyn.iinet.net.au)
  1507. # [23:14] <jgraham_> Lachy: It's odds on that authors will add an extra wrapper half the time anyway
  1508. # [23:14] <TabAtkins> jgraham_: No, <dl> and <details> at least have the benefit of mnemonics. The "t" and "d" stand for "title" and "data", obviously.
  1509. # [23:14] <jgraham_> Especially for non-<img> cases
  1510. # [23:14] <Lachy> if they want that for styling, let them. But don't force everyone to use it
  1511. # [23:14] <da3d> <c> works
  1512. # [23:15] <jgraham_> TabAtkins: I assumed they stood for "term" and "defenition"
  1513. # [23:15] <TabAtkins> Maybe back when dl stood for definition list, sure.
  1514. # [23:15] <erlehmann> what jgraham_said
  1515. # [23:15] <TabAtkins> also: "definition definition" is just silly.
  1516. # [23:15] <erlehmann> Maybe you should marry that <c> since you love it so much. i'd go for <description>
  1517. # [23:15] <Lachy> dd now effectively stands for description instead of definition.
  1518. # [23:15] <jgraham_> Lachy: I'm not arguing it's the best solution. But it is whole lot better than what we had before yet there is more fuss now
  1519. # [23:16] * Quits: dimich (n=dimich@74.125.59.73)
  1520. # [23:16] * jgraham_ would have minted a new element years ago
  1521. # [23:17] <TabAtkins> jgraham_ I think nobody really expected to *use* <figure> while it had <legend>. Now that it's suddenly possible to use, we're fussing about it not being good enough.
  1522. # [23:17] <erlehmann> I used it. Foolishly, i know.
  1523. # [23:17] <erlehmann> A simple regex over my blog will fix it as soon as a new element comes.
  1524. # [23:18] <TabAtkins> Shame on you, erlehmann.
  1525. # [23:19] <Lachy> another possible alternative, though I admit not well thought out, would be to use <p caption>...</p>. No parsing issues, and the caption attribute identifies it as being a caption.
  1526. # [23:19] <TabAtkins> I have a big list of sections in our software and bugs that have been fixed in each section. Appropriate to use <dl>? Or should I just stick with <h3> and <ul>?
  1527. # [23:19] <jgraham_> Yeah well that's just silly. People would have let the spec go to LC with <legend> which was broken-by-design but will go up in arms once there is an imperfect but not broken design in place
  1528. # [23:19] <TabAtkins> Lachy: Hmm. It has the nice parallel with <time pubdate> in being metadata about it's appropriate ancestor.
  1529. # [23:20] <TabAtkins> jgraham_, I'm not saying people aren't silly. I'm just saying that's what I think's going on.
  1530. # [23:20] <erlehmann> Lachy, dont new element semantics come to abolis attributes?
  1531. # [23:20] <TabAtkins> erlehmann: No, they abolish *classes*
  1532. # [23:20] <erlehmann> noticed.
  1533. # [23:20] <jgraham_> Lachy: pushing semantics to attributes is something that HTML traditionally avoids
  1534. # [23:20] * erlehmann scribbles furiously on his SPY NOTEPAD.
  1535. # [23:20] <Lachy> I didn't say it was a good idea. :-)
  1536. # [23:21] <TabAtkins> I sorta like it, shrug.
  1537. # [23:21] <TabAtkins> Better than <c>, at least.
  1538. # [23:21] * TabAtkins may just be channeling his love for binary attributes.
  1539. # [23:22] <erlehmann> a want a <description>
  1540. # [23:22] <jgraham_> Also, if one more person says "I looked in a thesaraus and we should call it <rubric>" I will go spare
  1541. # [23:22] * TabAtkins goes ahead and uses <dl> for his problem.
  1542. # [23:22] <TabAtkins> I don't even know what rubric means.
  1543. # [23:22] <jgraham_> hint: if you hd to look up the word it's not sufficiently obvious
  1544. # [23:23] <TabAtkins> And I've got a big vocabulary.
  1545. # [23:23] * Quits: pmuellr (n=pmuellr@nat/ibm/x-ivjitzygpofeodor)
  1546. # [23:23] <jgraham_> In fact a rubric isn't typically a figure caption. It's a set of instructions on an examination paper
  1547. # [23:23] <jgraham_> So it doesn't even mean the right thing
  1548. # [23:24] <jgraham_> (at least that is the only context in which I have actually heard it used)
  1549. # [23:24] <tantekc> erlehmann, the <meta> is a lie.
  1550. # [23:24] <TabAtkins> tantekc: That's because it's invisible metadata, and has drifted out of sync with the text.
  1551. # [23:24] <othermaciej> <rubric> is not particularly apposite
  1552. # [23:24] <othermaciej> but then again, neither was <legend>
  1553. # [23:24] <Lachy> rubric: "A part of a manuscript or book, such as a title, heading, or initial letter, that appears in decorative red lettering or is otherwise distinguished from the rest of the text."
  1554. # [23:25] <TabAtkins> ?_?
  1555. # [23:25] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  1556. # [23:25] <tantekc> perhaps a <longdesc> element to replace the longdesc attribute. ;)
  1557. # [23:25] <erlehmann> Lachy, sounds liek metadata.
  1558. # [23:25] <jgraham_> Lachy: Yeah I jut saw the same thing. It seems to be some histoical publishing convention
  1559. # [23:25] <jgraham_> *historical
  1560. # [23:26] <erlehmann> tantekc, stop suggesting things.
  1561. # [23:26] <tantekc> or I suppose it doesn't have to be long
  1562. # [23:26] <tantekc> so just <desc> then
  1563. # [23:26] <erlehmann> a <longdesc> element would look horrible urgs
  1564. # [23:26] <erlehmann> <desc> \o/
  1565. # [23:26] <tantekc> in the custom of oblique four letter abbrs for HTML tag names
  1566. # [23:27] <erlehmann> yeah, like <inpu> :D
  1567. # [23:27] <erlehmann> and <butt>
  1568. # [23:27] * tantekc wonders if there is a histogram of HTML element name lengths.
  1569. # [23:27] * TabAtkins giggles - he couldn't help himself.
  1570. # [23:27] * fishd_ is now known as fishd
  1571. # [23:28] <erlehmann> There is a special hell reserved for you web developers. Just so you know.
  1572. # [23:28] <TabAtkins> You're welcome.
  1573. # [23:29] <Lachy> we can't use <desc> because it clashes with SVG
  1574. # [23:29] <tantekc> erlehmann, I think the level for language developers is nested a bit deeper than that.
  1575. # [23:29] * Joins: murr4y` (n=murray@84.49.67.85)
  1576. # [23:29] <tantekc> Lachy, what does <desc> mean in SVG?
  1577. # [23:30] <virtuelv> oh, on the term "metadata", this is a worthwhile read: http://blogs.fluidinfo.com/fluidDB/2009/09/05/metadata-vs-data-a-wholly-artificial-distinction/
  1578. # [23:30] <Lachy> it's a description for something, but the issue is that the parsing algorithm needs to put the element into the right namespace
  1579. # [23:30] <virtuelv> (not all of it is directly relevant to a markup language)
  1580. # [23:30] <erlehmann> name-space. shhhh, ian better not hear this.
  1581. # [23:31] <tantekc> virtuelv - nice post
  1582. # [23:31] * Quits: eric_carlson (n=ericc@nat/apple/x-ypttdyewpuluaxiq)
  1583. # [23:31] <tantekc> Lachy, "right namespace" ? why?
  1584. # [23:31] <tantekc> so when the parser finds a <desc> inside a <figure> then it can treat it properly
  1585. # [23:32] <erlehmann> virtuelv, i prefer metacrap by doctorow, to end a debate like this: http://www.well.com/~doctorow/metacrap.htm
  1586. # [23:32] <erlehmann> tantekc, who says that you wont use figures to mark up SVG images, huh ?
  1587. # [23:32] <tantekc> and Lachy, if "right namespace" is an issue, how do you deal with svg:a vs html:a ??
  1588. # [23:32] <jgraham_> tantekc: Having element names that overlap is bad form. Where SVG has overlapped with HTML has caused us problems trying to integrate them
  1589. # [23:32] <annevk42> wow, journalists epically fail in sarcasm -- http://news.cnet.com/8301-30684_3-10355860-265.html
  1590. # [23:32] <jgraham_> e.g. <textArea>
  1591. # [23:33] <tantekc> jgraham - yeah, that was a tough lesson for SVG to learn wasn't it?
  1592. # [23:34] * tantekc would love to see the internal debate / process for who / however it was decided to create svg:a that's mostly like html:a but uses something more complex (XLink) to achieve the same functionality.
  1593. # [23:34] <erlehmann> tantekc, a special hell
  1594. # [23:34] <Hixie> tantekc: i imagine the debate was "ok we need a linking element." "we should use xlink!" "yeah!" "ok, done."
  1595. # [23:34] <tantekc> erlehmann, the <desc> would be inside the <figure> but not the nested <svg>
  1596. # [23:35] <tantekc> Hixie, I vaguely recall Chris Lilley saying something about not wanting to burden SVG authors with having to import the XHTML namespace just to be able to link to something.
  1597. # [23:35] <Hixie> ...
  1598. # [23:35] <tantekc> <cough>multi-namespace fail in practice</cough>
  1599. # [23:36] <Philip`> So instead they have to import the XLink namespace just to be able to link to something?
  1600. # [23:36] <Hixie> tantekc: btw i sent the payment to w3c for you, me, and the others google is paying for
  1601. # [23:36] * Joins: jwalden_ (n=waldo@nat/mozilla/x-cvyrlwqpxjvxltty)
  1602. # [23:36] <Hixie> tantekc: so we should be all set
  1603. # [23:36] <Hixie> tantekc: let me know if anyone suggests you haven't paid and i'll come wack them over the head
  1604. # [23:37] <tantekc> but Philip`, XLink is clean XML architecture! None of that messy hacky (X)HTML nonsense.
  1605. # [23:37] * tantekc is grateful for his corporate sponsor.
  1606. # [23:37] <erlehmann> i'm gone
  1607. # [23:37] * Quits: paul_irish (n=paul_iri@12.33.239.250)
  1608. # [23:37] <tantekc> /me is now looking for funding for the W3C CSS WG days...
  1609. # [23:37] <Lachy> my attendance at tpac is still undecided, though I will find out by some time next week I think
  1610. # [23:38] <Hixie> tantekc: fee goes up in like 4 days, fwiw
  1611. # [23:38] <Hixie> from $50/day to $75/day
  1612. # [23:38] * Quits: erlehmann (n=erlehman@echelon.ext.c-base.org) ("Ex-Chat")
  1613. # [23:38] * Quits: KevinMarks (n=KevinMar@157.22.22.46) ("The computer fell asleep")
  1614. # [23:38] <Hixie> (still can't believe we're being charged to attend, it's so ridiculous)
  1615. # [23:39] <Lachy> yeah, in that case, my attendance will be decided before the price goes up. If it's not, I doubt I will be going. But I hope I am
  1616. # [23:39] * tantekc thinks they should have named it Technical Update, Plenary, Advisory Committee meeting
  1617. # [23:39] <Lachy> haha
  1618. # [23:40] <TabAtkins> tantekc, hahaha
  1619. # [23:41] * Quits: murr4y (n=murray@85.84-49-67.nextgentel.com) (Read error: 110 (Connection timed out))
  1620. # [23:42] <Hixie> did maciej ever send his summary of the telecon from last week?
  1621. # [23:42] <Hixie> he told me he was planning on sending summaries, separate from minutes, but i don't recall seeing any
  1622. # [23:42] <Hixie> maybe the telecon didn't do anything to summarise...
  1623. # [23:42] * Quits: jwalden (n=waldo@nat/mozilla/x-wlbihhrswerczshi) (Read error: 110 (Connection timed out))
  1624. # [23:42] * jwalden_ is now known as jwalden
  1625. # [23:43] * Parts: ojan (n=ojan@nat/google/x-iwdlhuxrhzguldzj)
  1626. # [23:44] <tantekc> maybe it was in a <caption> element outside of a table and thus dropped...
  1627. # [23:47] * Joins: cohitre (n=cohitre@c-24-18-158-106.hsd1.wa.comcast.net)
  1628. # [23:47] * Joins: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  1629. # [23:51] <Hixie> you know for someone who's not a wg member shelley sure sends a lot of e-mail to the wg
  1630. # [23:52] <TabAtkins> Why isn't she a wg member? Does she have a reason?
  1631. # [23:52] <hober> TabAtkins: she periodically joins and leaves the WG, but that doesn't seem to affect her level of participation.
  1632. # [23:52] <Lachy> TabAtkins, because she can't stand working with the group
  1633. # [23:52] <TabAtkins> That's... odd.
  1634. # [23:53] <TabAtkins> For both of those.
  1635. # [23:53] <hober> it's sort of a moth/flame thing
  1636. # [23:56] * Joins: annodomini (n=lambda@64.30.3.122)
  1637. # [23:57] * Joins: starjive (i=beos@213-66-216-93-no30.tbcn.telia.com)
  1638. # Session Close: Fri Sep 18 00:00:00 2009

The end :)