/irc-logs / freenode / #whatwg / 2013-09-12 / end

Options:

  1. # Session Start: Thu Sep 12 00:00:00 2013
  2. # Session Ident: #whatwg
  3. # [00:00] * Quits: TheGallery (~TheGaller@athedsl-217130.home.otenet.gr) (Ping timeout: 264 seconds)
  4. # [00:00] * Quits: nimbu (~nimbu@192.150.10.206) (Read error: Connection reset by peer)
  5. # [00:00] * Joins: nimbu1 (~nimbu@192.150.10.206)
  6. # [00:02] * Quits: dbaron (~dbaron@202-160.80-90.static-ip.oleane.fr) (Ping timeout: 264 seconds)
  7. # [00:11] * Quits: nimbu1 (~nimbu@192.150.10.206) (Quit: Leaving.)
  8. # [00:14] * Joins: nimbu (~nimbu@192.150.10.206)
  9. # [00:14] * Quits: nimbu (~nimbu@192.150.10.206) (Client Quit)
  10. # [00:16] * Quits: tantek (~tantek@AMontsouris-554-1-115-143.w92-128.abo.wanadoo.fr) (Ping timeout: 276 seconds)
  11. # [00:16] * Quits: newtron (~newtron@199.71.174.103) (Ping timeout: 276 seconds)
  12. # [00:17] * Joins: KevinMarks (~KevinMark@host-78-147-142-228.as13285.net)
  13. # [00:19] * Quits: slartsa (~slartsa@46.19.36.11) (Ping timeout: 264 seconds)
  14. # [00:19] * Joins: slartsa (~slartsa@46.19.36.11)
  15. # [00:20] * Joins: tantek (~tantek@AMontsouris-554-1-115-143.w92-128.abo.wanadoo.fr)
  16. # [00:22] * Quits: felipeduardo (~felipedua@189.115.44.34) (Quit: Leaving)
  17. # [00:23] * Quits: encryptd_fractal (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Remote host closed the connection)
  18. # [00:35] * Quits: lmcliste_ (~lmclister@192.150.10.209)
  19. # [00:36] * Joins: lmcliste_ (~lmclister@192.150.10.209)
  20. # [00:38] * Joins: zkis (~zkis@188-67-161-229.bb.dnainternet.fi)
  21. # [00:41] * Quits: lmcliste_ (~lmclister@192.150.10.209)
  22. # [00:41] * heycam|away is now known as heycam
  23. # [00:43] * Joins: birtles (~chatzilla@61-121-216-2.bitcat.net)
  24. # [00:43] * Joins: nimbu (~nimbu@192.150.10.206)
  25. # [00:47] * Quits: eminor (~eminor@p548CE1B3.dip0.t-ipconnect.de) (Quit: eminor)
  26. # [00:48] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Ping timeout: 245 seconds)
  27. # [00:52] * Quits: sicking (~sicking@148.122.12.62) (Quit: sicking)
  28. # [00:57] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  29. # [00:57] * Joins: erichynds (~erichynds@146-115-145-170.c3-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com)
  30. # [00:57] * Quits: TheOtherGallery (~TheGaller@athedsl-218081.home.otenet.gr) (Quit: Leaving)
  31. # [01:05] * Quits: nimbu (~nimbu@192.150.10.206) (Quit: Leaving.)
  32. # [01:07] * Joins: tlr (~roessler@88.207.142.77)
  33. # [01:12] * Joins: nimbu (~nimbu@192.150.10.206)
  34. # [01:13] * Quits: zcorpan (~zcorpan@128.127.18.179) (Remote host closed the connection)
  35. # [01:14] * Joins: zcorpan (~zcorpan@128.127.18.179)
  36. # [01:16] * diffalot-away is now known as diffalot
  37. # [01:19] * Quits: zcorpan (~zcorpan@128.127.18.179) (Ping timeout: 256 seconds)
  38. # [01:19] * Quits: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp) (Remote host closed the connection)
  39. # [01:20] * Joins: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp)
  40. # [01:20] * Quits: zkis (~zkis@188-67-161-229.bb.dnainternet.fi) (Ping timeout: 256 seconds)
  41. # [01:20] * Quits: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp) (Read error: Connection reset by peer)
  42. # [01:20] * Joins: myakura_ (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp)
  43. # [01:22] * Joins: newtron (~newtron@75-119-230-53.dsl.teksavvy.com)
  44. # [01:27] * Quits: newtron (~newtron@75-119-230-53.dsl.teksavvy.com) (Ping timeout: 276 seconds)
  45. # [01:32] * Quits: annevk (~annevk@2.31.25.182) (Remote host closed the connection)
  46. # [01:33] * Quits: rego (~rego@231.193.27.77.dynamic.mundo-r.com) (Remote host closed the connection)
  47. # [01:33] * Joins: annevk (~annevk@2.31.25.182)
  48. # [01:33] * Quits: decotii (~decotii@hq.croscon.com) (Quit: Leaving)
  49. # [01:34] <Hixie_> annevk: i'm confused by "fetch" step 7, the one that queues tasks. what are the tasks? are these the same as the tasks to process the data as it is downloaded from HTML?
  50. # [01:34] <Hixie_> are they fired for incomplete headers? just data?
  51. # [01:36] * Joins: jdaggett (~jdaggett@61-121-216-2.bitcat.net)
  52. # [01:37] * Quits: annevk (~annevk@2.31.25.182) (Ping timeout: 245 seconds)
  53. # [01:44] * Quits: erichynds (~erichynds@146-115-145-170.c3-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com)
  54. # [01:48] * Quits: nimbu (~nimbu@192.150.10.206) (Quit: Leaving.)
  55. # [01:49] * Joins: seventh (seventh@69.80.108.163)
  56. # [01:56] * Joins: nimbu (~nimbu@192.150.10.206)
  57. # [01:59] * Quits: jernoble|laptop (~jernoble@17.212.155.75) (Quit: Computer has gone to sleep.)
  58. # [02:11] * Quits: cabanier (~cabanier@192.150.22.55) (Quit: Leaving.)
  59. # [02:12] * Joins: Spedax (~spedax@5.149.138.2)
  60. # [02:13] * Quits: ap (~ap@2620:149:4:304:3487:5b60:1100:108f) (Quit: ap)
  61. # [02:16] * Joins: Lachy (~textual@213.166.174.2)
  62. # [02:17] * Quits: Spedax (~spedax@5.149.138.2) (Ping timeout: 276 seconds)
  63. # [02:20] * Joins: cabanier (~cabanier@c-98-237-137-173.hsd1.wa.comcast.net)
  64. # [02:23] * Quits: jwalden (~waldo@c-71-202-165-226.hsd1.ca.comcast.net) (Quit: ChatZilla 0.9.87-7.1450hg.fc19 [XULRunner 23.0/20130805131520])
  65. # [02:24] * Joins: zcorpan (~zcorpan@128.127.18.179)
  66. # [02:25] * Quits: nimbu (~nimbu@192.150.10.206) (Quit: Leaving.)
  67. # [02:26] * Quits: jsbell (jsbell@nat/google/x-iyrfmrvbdentuccy) (Quit: There's no place like home...)
  68. # [02:27] * Joins: jarek (~jarek@unaffiliated/jarek)
  69. # [02:28] * Joins: newtron (~newtron@75-119-230-53.dsl.teksavvy.com)
  70. # [02:29] * Quits: zcorpan (~zcorpan@128.127.18.179) (Ping timeout: 245 seconds)
  71. # [02:36] * Quits: Lachy (~textual@213.166.174.2) (Quit: Textual IRC Client: www.textualapp.com)
  72. # [02:47] * Quits: smaug____ (~chatzilla@cs164155.pp.htv.fi) (Ping timeout: 256 seconds)
  73. # [02:48] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
  74. # [02:51] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  75. # [02:52] * Krinkle is now known as Krinkle|detached
  76. # [03:10] * Quits: bholley (~bholley@c-67-180-21-133.hsd1.ca.comcast.net) (Quit: bholley)
  77. # [03:20] * Quits: newtron (~newtron@75-119-230-53.dsl.teksavvy.com) (Remote host closed the connection)
  78. # [03:31] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
  79. # [03:42] * Quits: rniwa (~rniwa@17.212.154.114) (Quit: rniwa)
  80. # [03:51] * Quits: tantek (~tantek@AMontsouris-554-1-115-143.w92-128.abo.wanadoo.fr) (Quit: tantek)
  81. # [04:03] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: jarek)
  82. # [04:05] * Quits: myakura_ (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp) (Remote host closed the connection)
  83. # [04:06] * Joins: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp)
  84. # [04:07] * yutak_ is now known as yutak
  85. # [04:10] * Quits: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp) (Ping timeout: 264 seconds)
  86. # [04:17] * heycam is now known as heycam|away
  87. # [04:23] * Quits: seventh (seventh@69.80.108.163) (Ping timeout: 245 seconds)
  88. # [04:42] * Joins: Goplat (~goplat@reactos/developer/Goplat)
  89. # [04:47] * Joins: a-ja (~Instantbi@70.230.153.135)
  90. # [04:50] * Joins: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp)
  91. # [04:57] * Joins: milk (~milk@178.79.168.21)
  92. # [05:05] * Joins: lmcliste_ (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  93. # [05:05] * Joins: nonge (~nonge@p5082B67F.dip0.t-ipconnect.de)
  94. # [05:09] * Quits: nonge_ (~nonge@p5082B1EF.dip0.t-ipconnect.de) (Ping timeout: 264 seconds)
  95. # [05:09] * Joins: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net)
  96. # [05:14] * Quits: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net) (Ping timeout: 256 seconds)
  97. # [05:15] * Joins: encryptd_fractal (~encryptd_@71-89-74-12.dhcp.bycy.mi.charter.com)
  98. # Session Close: Thu Sep 12 05:32:17 2013
  99. #
  100. # Session Start: Thu Sep 12 05:32:17 2013
  101. # Session Ident: #whatwg
  102. # [05:32] * Disconnected
  103. # [05:37] * Attempting to rejoin channel #whatwg
  104. # [05:37] * Rejoined channel #whatwg
  105. # [05:37] * Topic is 'WHATWG: http://www.whatwg.org/ -- logs: http://krijnhoetmer.nl/irc-logs/ & http://logbot.glob.com.au/ -- stats: http://gavinsharp.com/irc/whatwg.html -- Please leave your sense of logic at the door, thanks!'
  106. # [05:37] * Set by smaug____!~chatzilla@GGZYYCCCXVIII.gprs.sl-laajakaista.fi on Wed Mar 21 17:14:24
  107. # [05:37] * Quits: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Ping timeout: 264 seconds)
  108. # [05:38] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
  109. # [05:39] * heycam|away is now known as heycam
  110. # [05:42] * Quits: jdaggett (~jdaggett@61-121-216-2.bitcat.net) (Quit: jdaggett)
  111. # [05:42] * Joins: jdaggett (~jdaggett@61-121-216-2.bitcat.net)
  112. # [05:42] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 264 seconds)
  113. # [05:45] * Quits: lmcliste_ (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  114. # [06:03] * Joins: nonge_ (~nonge@p508296A5.dip0.t-ipconnect.de)
  115. # [06:07] * Quits: nonge (~nonge@p5082B67F.dip0.t-ipconnect.de) (Ping timeout: 276 seconds)
  116. # [06:08] * Quits: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp) (Remote host closed the connection)
  117. # [06:09] * Joins: mven (~mven@ip68-224-15-53.lv.lv.cox.net)
  118. # [06:09] * Joins: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp)
  119. # [06:13] * Joins: Spedax (~spedax@5.149.138.2)
  120. # [06:13] * Quits: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp) (Ping timeout: 240 seconds)
  121. # [06:17] * Quits: Spedax (~spedax@5.149.138.2) (Ping timeout: 256 seconds)
  122. # [06:17] * Joins: rniwa (~rniwa@c-98-207-134-149.hsd1.ca.comcast.net)
  123. # [06:24] * Joins: lmcliste_ (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  124. # [06:28] * Quits: encryptd_fractal (~encryptd_@71-89-74-12.dhcp.bycy.mi.charter.com) (Remote host closed the connection)
  125. # [06:29] * Joins: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp)
  126. # [06:42] * Quits: lmcliste_ (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  127. # [06:58] * Joins: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net)
  128. # [07:03] * Quits: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net) (Ping timeout: 276 seconds)
  129. # [07:29] * Parts: a-ja (~Instantbi@70.230.153.135)
  130. # [07:38] * Quits: slartsa (~slartsa@46.19.36.11) (Read error: Connection reset by peer)
  131. # [07:45] * Quits: tndrH (~Rob@cpc4-seac20-2-0-cust858.7-2.cable.virginmedia.com) (Ping timeout: 260 seconds)
  132. # [07:55] * Joins: Smylers (~smylers@host86-152-155-75.range86-152.btcentralplus.com)
  133. # [08:04] * Quits: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp) (Remote host closed the connection)
  134. # [08:04] * Joins: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp)
  135. # [08:08] * Quits: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp) (Ping timeout: 248 seconds)
  136. # [08:18] * Quits: mven (~mven@ip68-224-15-53.lv.lv.cox.net) (Read error: Connection reset by peer)
  137. # [08:19] * Joins: mven (~mven@ip68-224-15-53.lv.lv.cox.net)
  138. # [08:26] * Quits: Smylers (~smylers@host86-152-155-75.range86-152.btcentralplus.com) (Quit: Leaving.)
  139. # [08:28] * Joins: dbaron (~dbaron@89.202.203.51)
  140. # [08:30] * Joins: rego (~rego@231.193.27.77.dynamic.mundo-r.com)
  141. # [08:32] * Quits: malcolmva (~malcolmva@c-67-180-203-233.hsd1.ca.comcast.net) (Ping timeout: 245 seconds)
  142. # [08:37] * Joins: malcolmva (~malcolmva@c-67-180-203-233.hsd1.ca.comcast.net)
  143. # [08:42] * Joins: zdobersek (~zdobersek@cpe-77.38.31.63.cable.t-1.si)
  144. # [08:45] * Joins: ehsan (~ehsan@148.122.12.62)
  145. # [08:47] * Joins: falken (falken@nat/google/x-jiqnhsuvbtahsjlk)
  146. # [08:55] * Joins: tantek (~tantek@226.249.65.86.rev.sfr.net)
  147. # [08:59] * Quits: tantek (~tantek@226.249.65.86.rev.sfr.net) (Client Quit)
  148. # [09:00] * Quits: ehsan (~ehsan@148.122.12.62) (Remote host closed the connection)
  149. # [09:01] * Joins: jdaggett_ (~jdaggett@61-121-216-2.bitcat.net)
  150. # [09:01] * Joins: ehsan (~ehsan@148.122.12.62)
  151. # [09:01] * Quits: jdaggett (~jdaggett@61-121-216-2.bitcat.net) (Ping timeout: 260 seconds)
  152. # [09:01] * jdaggett_ is now known as jdaggett
  153. # [09:03] * Quits: jdaggett (~jdaggett@61-121-216-2.bitcat.net) (Client Quit)
  154. # [09:04] * Joins: jdaggett (~jdaggett@61-121-216-2.bitcat.net)
  155. # [09:06] * Quits: ehsan (~ehsan@148.122.12.62) (Ping timeout: 264 seconds)
  156. # [09:07] * Quits: espadrine (~ttyl@AMontsouris-158-1-94-141.w90-2.abo.wanadoo.fr) (Ping timeout: 264 seconds)
  157. # [09:07] * Quits: KevinMarks (~KevinMark@host-78-147-142-228.as13285.net)
  158. # [09:07] * Joins: zcorpan (~zcorpan@89.202.203.52)
  159. # [09:10] * Joins: Kolombiken (~Adium@94.137.124.2)
  160. # [09:18] * Quits: rniwa (~rniwa@c-98-207-134-149.hsd1.ca.comcast.net) (Quit: rniwa)
  161. # [09:18] * Joins: zkis (~zkis@188-67-161-229.bb.dnainternet.fi)
  162. # [09:20] * Joins: tantek (~tantek@226.249.65.86.rev.sfr.net)
  163. # [09:21] * Quits: karlcow (~karl@nerval.la-grange.net) (Remote host closed the connection)
  164. # [09:22] * Joins: espadrine (~ttyl@AMontsouris-158-1-94-141.w90-2.abo.wanadoo.fr)
  165. # [09:24] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
  166. # [09:25] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  167. # [09:27] * Joins: baku (~baku@148.122.12.62)
  168. # [09:29] * Quits: lokling (~quassel@quassel.woboq.de) (Remote host closed the connection)
  169. # [09:30] * Joins: lokling (~quassel@quassel.woboq.com)
  170. # [09:30] * Joins: mitemitreski (~mitemitre@212.120.17.179)
  171. # [09:33] * Quits: zkis (~zkis@188-67-161-229.bb.dnainternet.fi) (Ping timeout: 248 seconds)
  172. # [09:34] * Joins: Spedax (~spedax@5.149.138.2)
  173. # [09:36] * Joins: darobin (~darobin@78.208.93.24)
  174. # [09:41] * Joins: sgalineau (~sylvaing@89.202.203.52)
  175. # [09:43] * Joins: ehsan (~ehsan@230.43.214.193.static.cust.telenor.com)
  176. # [09:43] * Quits: baku (~baku@148.122.12.62) (Ping timeout: 260 seconds)
  177. # [09:48] * Joins: marcosc (~marcosc@bl7-118-144.dsl.telepac.pt)
  178. # [09:53] * Joins: Smylers (~smylers@94.117.127.223)
  179. # [09:53] * Quits: tantek (~tantek@226.249.65.86.rev.sfr.net) (Quit: tantek)
  180. # [09:54] * Joins: cheron (~cheron@unaffiliated/cheron)
  181. # [09:55] * Quits: marcosc (~marcosc@bl7-118-144.dsl.telepac.pt) (Ping timeout: 245 seconds)
  182. # [10:10] * Quits: Smylers (~smylers@94.117.127.223) (Ping timeout: 264 seconds)
  183. # [10:10] * Joins: Lachy (~textual@213.166.174.2)
  184. # [10:15] * Joins: marcosc (~marcosc@bl7-118-144.dsl.telepac.pt)
  185. # [10:18] * Joins: Smylers (~smylers@81.143.60.194)
  186. # [10:20] * Quits: Smylers (~smylers@81.143.60.194) (Read error: Connection reset by peer)
  187. # [10:20] * Joins: Smylers (~smylers@81.143.60.194)
  188. # [10:30] * Quits: birtles (~chatzilla@61-121-216-2.bitcat.net) (Quit: ChatZilla 0.9.90-rdmsoft [XULRunner 1.9.0.17/2009122204])
  189. # [10:32] * Joins: sicking (~sicking@0.43.214.193.static.cust.telenor.com)
  190. # [10:33] * Quits: jdaggett (~jdaggett@61-121-216-2.bitcat.net) (Quit: jdaggett)
  191. # [10:34] * Joins: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net)
  192. # [10:39] * Quits: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net) (Ping timeout: 256 seconds)
  193. # [10:41] * Joins: temp01 (~temp01@unaffiliated/temp01)
  194. # [10:42] * Joins: baku (~baku@193.214.41.72)
  195. # [10:53] <Domenic_> what's the thing that's supposed to make reset stylesheets go away? `default`? it's not `initial`, is it?
  196. # [10:55] * Joins: tantek (~tantek@89.202.203.51)
  197. # [10:57] * Quits: sicking (~sicking@0.43.214.193.static.cust.telenor.com) (Quit: sicking)
  198. # [11:00] * Joins: sicking (~sicking@0.43.214.193.static.cust.telenor.com)
  199. # [11:01] <TabAtkins> It's called "unset" now.
  200. # [11:01] <TabAtkins> == initial or inherit, whichever is correct.
  201. # [11:04] <Domenic_> thanks. and is there a nesting spec still active?
  202. # [11:05] <Domenic_> hierarchies, got it
  203. # [11:06] * Quits: sicking (~sicking@0.43.214.193.static.cust.telenor.com) (Quit: sicking)
  204. # [11:08] * Joins: annevk (~annevk@207.218.72.65)
  205. # [11:11] * Joins: tomasf (~tomasf@77.72.97.10.c.fiberdirekt.net)
  206. # [11:13] * Joins: zkis (~zkis@2001:998:22:0:5800:f5f7:cf4f:7c5e)
  207. # [11:13] * Joins: SteveF (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginmedia.com)
  208. # [11:25] <TabAtkins> Domenic_: The syntax in Hierarchies isn't what we're going to use. It's too annoying, and prevents some stuff that SASS allows, like "foo { bar & {...} }".
  209. # [11:26] <TabAtkins> Domenic_: To do that, we need an explicit wrapper switching our context to selectors, and I think I'm just going to do {}.
  210. # [11:26] <TabAtkins> Like "foo { color: red; { bar { color: blue; } } }"
  211. # [11:27] <TabAtkins> That's really hard to read here in linear form, but it's fine when properly indented in a stylesheet. ^_^
  212. # [11:27] * Quits: SteveF (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginmedia.com) (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
  213. # [11:31] <annevk> Hixie_: the task queuing part of Fetch is broken
  214. # [11:33] * Joins: josemanuel (~josemanue@4.203.221.87.dynamic.jazztel.es)
  215. # [11:34] * Quits: josemanuel (~josemanue@4.203.221.87.dynamic.jazztel.es) (Client Quit)
  216. # [11:34] <annevk> Domenic_: yay for closing issues
  217. # [11:36] * heycam is now known as heycam|away
  218. # [11:37] <Domenic_> TabAtkins: fascinating. FWIW I've never been able to use SASS's ampersand-afterwards style very effectively, so something without it seems OK. But I'll trust you on this one.
  219. # [11:37] <Domenic_> annevk: ya, I thought it was time.
  220. # [11:38] <TabAtkins> Domenic_: The explicit context also lets you drop the ampersand from "& bar", like SASS does, which is nice.
  221. # [11:39] <Domenic_> TabAtkins: why doesn't SASS's exact syntax work? (Sorry I know these are nooby questions that could be answered by finding the right forum threads.)
  222. # [11:39] <TabAtkins> SASS is willing to do arbitrary lookahead to disambiguate selectors and properties. CSS isn't.
  223. # [11:40] <Domenic_> gotcha
  224. # [11:40] <TabAtkins> You can't tell whether "a:hover a a a a a a a..." is a selector or a property until you hit a "{" or a ";".
  225. # [11:43] * Quits: Yitro (~Yitro@101.164.245.158) (Ping timeout: 264 seconds)
  226. # [11:44] <annevk> foolip: yo, I told the i18n guys I wouldn't do Encoding standard updates for a couple of weeks, so I'll get back to that in October
  227. # [11:44] <annevk> foolip: wanted to let you know that and thank you for big5 research once more :)
  228. # [11:49] * Quits: ehsan (~ehsan@230.43.214.193.static.cust.telenor.com) (Remote host closed the connection)
  229. # [11:50] * Joins: ehsan (~ehsan@230.43.214.193.static.cust.telenor.com)
  230. # [11:55] * Quits: ehsan (~ehsan@230.43.214.193.static.cust.telenor.com) (Ping timeout: 264 seconds)
  231. # [11:55] * Joins: karlcow (~karl@nerval.la-grange.net)
  232. # [12:08] <zcorpan> anyone want to review https://critic.hoppipolla.co.uk/r/307 ?
  233. # [12:10] <annevk> Domenic_: so jQuery supports node.is("> test") // doesn't throw
  234. # [12:10] <annevk> Domenic_: how does that ever make sense?
  235. # [12:11] <annevk> whoa, but <body>.is("html > body") // true
  236. # [12:11] <annevk> that seems very weird
  237. # [12:14] <Domenic_> hmm
  238. # [12:14] <Domenic_> annevk: tbh mostly i use very simple selectors with .is, like tag names.
  239. # [12:15] <annevk> I think it should behave just like the selectors passed to querySelector
  240. # [12:15] <Domenic_> i agree .is("> test") doesn't make much sense, but then again, not throwing might be a useful property
  241. # [12:15] <annevk> The thing is, if you parse it as a relative selector, is .is("body") going to work?
  242. # [12:15] <Domenic_> <body>.is("html > body") seems good, I would use that
  243. # [12:16] <annevk> Then you cannot parse it as a relative selector
  244. # [12:16] * Joins: smaug____ (~chatzilla@cs164155.pp.htv.fi)
  245. # [12:16] <Domenic_> is there any reason it shouldn't just be an absolute selector? hmm
  246. # [12:16] <annevk> Or we'd have to redefine relative selector to be "sometimes relative selector" or some such and a different algorithm
  247. # [12:16] <annevk> Yeah, I don't know
  248. # [12:17] <annevk> Lachy: why did spec .matches() as taking a relative selector?
  249. # [12:17] <annevk> Domenic_: Elements.prototype.matches() should exist too right?
  250. # [12:17] <annevk> Hmm, maybe something like queryFilter() would be more useful
  251. # [12:17] <Domenic_> annevk: hmm probably, with for-all semantics i assume (not there-exists)?
  252. # [12:18] <annevk> Domenic_: yes
  253. # [12:18] <Domenic_> shall i add to gist?
  254. # [12:20] <annevk> Domenic_: dunno, I'm suggesting this because http://dev.w3.org/2006/webapi/selectors-api2/#the-apis has it
  255. # [12:21] <annevk> Domenic_: (matches() having a second argument for reference nodes)
  256. # [12:21] <annevk> Domenic_: btw, if I were to define Elements as a JavaScript thing, is there some ES6 precedent I can follow for that?
  257. # [12:22] <Domenic_> annevk: you mean, if you were to write a spec? hmm.
  258. # [12:22] <Domenic_> I think GeneratorFunction derives from Generator?
  259. # [12:22] <Domenic_> err, from Function
  260. # [12:24] * Quits: Spedax (~spedax@5.149.138.2) (Remote host closed the connection)
  261. # [12:25] <annevk> Domenic_: doesn't look like it
  262. # [12:26] * Joins: ehsan (~ehsan@230.43.214.193.static.cust.telenor.com)
  263. # [12:26] <Domenic_> annevk: no, it does. It's not very clear though. e.g. "The value of the [[Prototype]] internal data property of the GeneratorFunction constructor is the intrinsic object %Function%."
  264. # [12:27] <Domenic_> Plus "The value of the [[Prototype]] internal data property of the GeneratorFunction prototype object is the %FunctionPrototype% intrinsic object."
  265. # [12:27] <Domenic_> the first is constructor-side inheritance, the second prototype-side, together I think they do the trick.
  266. # [12:29] <annevk> "The GeneratorFunction prototype object is an ordinary object. It is not a function object and does not have a [[Code]] internal data property or any other of the internal data properties listed in Table 25 or Table 39."
  267. # [12:29] <Lachy> annevk, that's useful when there are reference nodes passed as well, so you can see if an element matches a selector relative to other specified elements.
  268. # [12:30] <annevk> Lachy: but it makes <body>.matches("html > body") fail, no?
  269. # [12:31] <Lachy> e.g. element.matches(">span", [el1, el2, el3]); matches if the element is a span that is a child of one of those elements.
  270. # [12:31] <Lachy> No.
  271. # [12:31] <Lachy> a relative selector doesn't always prepend :scope
  272. # [12:31] <annevk> Oh, it's always potentially relative?
  273. # [12:31] <Domenic_> annevk: yeah that's just the standard ES6 thing of making X.prototype not a useful instance of X.
  274. # [12:31] <Lachy> from memory, I think the algorithm for parsing relative selectors checks if there are any reference nodes first.
  275. # [12:32] <Lachy> if there aren't any, no :scope is prepended.
  276. # [12:32] * Quits: m4nu (~manu@216.252.204.51) (Ping timeout: 256 seconds)
  277. # [12:32] <Lachy> or something like that.
  278. # [12:32] * Joins: manu (~manu@216.252.204.51)
  279. # [12:32] * manu is now known as m4nu
  280. # [12:32] <Domenic_> (bbl, lunch)
  281. # [12:33] <annevk> Domenic_: okay, so why does a bunch of things need to be redefined?
  282. # [12:33] <Domenic_> annevk: which things?
  283. # [12:33] <annevk> Domenic_: e.g. the constructor
  284. # [12:33] <annevk> Domenic_: I guess it has a different constructor?
  285. # [12:33] <Domenic_> annevk: well probably yeah, generators are pretty different from functions
  286. # [12:34] <annevk> Domenic_: it seems to me for Elements we'd only have to define a minimal set of things, right?
  287. # [12:34] <Domenic_> annevk: agree, I am pretty sure.
  288. # [12:35] <Domenic_> Lachy: annevk: has anyone implemented "absolutize relative selector list" algorithm in JS? THat may be the easiest way to ensure it does what we want.
  289. # [12:36] <annevk> Domenic_: dunno, it'd require parsing selectors in JS... http://dev.w3.org/csswg/selectors/#absolutizing
  290. # [12:37] <foolip> annevk, sure, as long as it's on your radar. but why did the i18n people not want you to update the spec?
  291. # [12:38] <annevk> Lachy: http://dev.w3.org/csswg/selectors/#absolutizing seems to pretty much always prepend :scope? TabAtkins?
  292. # [12:39] <annevk> foolip: they want to publish a fork on TR/
  293. # [12:39] * Quits: ehsan (~ehsan@230.43.214.193.static.cust.telenor.com) (Remote host closed the connection)
  294. # [12:40] * Joins: ehsan (~ehsan@230.43.214.193.static.cust.telenor.com)
  295. # [12:40] <foolip> annevk, ew, but I take it you'll allow it?
  296. # [12:40] <annevk> foolip: I'd just have to notify them if I made a change so they could sync up again before publication, seemed easier to not update for a bit
  297. # [12:40] <annevk> foolip: I agreed to this before I decided it was a bad idea :/
  298. # [12:41] <annevk> foolip: also, CC0
  299. # [12:41] <foolip> I sure hope no one finds that TR/ spec and implements big5 with the wrong error handling
  300. # [12:41] <foolip> annevk, do you know if similar conditions might be needed for similar encodings?
  301. # [12:42] <annevk> foolip: yeah, if you follow the link at the top of the spec for open bugs, you'll find we're trying to figure out the right behavior for most multi-byte encodings :/
  302. # [12:42] <annevk> foolip: I need to study browsers some more basically
  303. # [12:43] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
  304. # [12:43] <foolip> annevk, no open bug for gb* encodings, which do decrease the byte pointer. is that an oversight or are you confident it's already correct?
  305. # [12:44] <annevk> foolip: I think gbk / gb18030 are correct, however, the mapping story needs work
  306. # [12:44] <foolip> annevk, btw, I tried to figure out what error handling chromium has, but it looks like maybe libicu is used and I couldn't grep my way to the source
  307. # [12:44] * Quits: ehsan (~ehsan@230.43.214.193.static.cust.telenor.com) (Ping timeout: 264 seconds)
  308. # [12:44] <annevk> foolip: they use ICU
  309. # [12:44] <annevk> foolip: but modified
  310. # [12:45] <foolip> yeah, I saw some patches there as well
  311. # [12:45] <foolip> but still nothing that looks like "decode big5 here" so I guess that it shares the algorithm with some other encodings or some such
  312. # [12:45] <annevk> foolip: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu51/
  313. # [12:47] <foolip> annevk, in any event, thanks for the feedback. I'm guessing that Mozilla is the most likely first implementor of the Big5 changes so I'm not worried that they/you'll look at the wrong spec :)
  314. # [12:47] <annevk> foolip: and maybe http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/icu46/ I suppose, looks like it has more patches, but maybe they've been upstreamed meanwhile
  315. # [12:47] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 245 seconds)
  316. # [12:47] <annevk> foolip: yeah, sure hope we fix that mess
  317. # [12:48] <foolip> chromium really should too, AFAIK it's still using PUA mappings :/
  318. # [12:48] <Lachy> annevk, check the algorithm I had in my fork of dom on github. That should have had the most recent version that I wrote.
  319. # [12:52] <annevk> Lachy: yours is different from the one that's in the Selectors specification
  320. # [12:52] <annevk> :/
  321. # [12:52] * Joins: gufdie (~gufdie@unaffiliated/gufdie)
  322. # [12:52] <mounir> Domenic_: ping
  323. # [12:52] * Quits: gufdie (~gufdie@unaffiliated/gufdie) (Read error: Connection reset by peer)
  324. # [12:52] <TabAtkins> annevk: It prepends :scope unless there's already a :scope somewhere in it.
  325. # [12:52] <annevk> TabAtkins: looking at https://github.com/lachlanhunt/dom/commit/453f2e2457202f49bd2743966a6f2f66f78a771a we don't want to prepend :scope if there's no reference elements
  326. # [12:52] <TabAtkins> There's a difference between "no reference elements" and "empty array of reference elements".
  327. # [12:52] <annevk> TabAtkins: ooh, and it looks like there was a way with a :scope flag
  328. # [12:53] <annevk> TabAtkins: no reference elements ends up at " Otherwise, this is a spec error. Please report it to the relevant standards body. "
  329. # [12:54] <TabAtkins> annevk: Yeah, we don't have a clause for explicitly "no reference elements", because there wasn't a way to do that in Selectors API 2, I thought.
  330. # [12:54] <TabAtkins> Really, if you have no reference elements at all, you shouldn't absolutize it - it's already an absolute selector.
  331. # [12:55] <annevk> TabAtkins: so what Selectors Level 2 had was a "scope flag"
  332. # [12:55] <TabAtkins> Btw, if there's context missing in the scrollback, let me know - I'm too busy with the meeting to read back right now.
  333. # [12:55] <annevk> TabAtkins: so for matches("html > body") it would not turn into ":scope html > body"
  334. # [12:56] <annevk> TabAtkins: but matches("> body") would turn into ":scope > body"
  335. # [12:56] <TabAtkins> Huh, so it wants to be stricter about relative-ness?
  336. # [12:56] * TabAtkins isn't sure how you can match :scope > body in the first place.
  337. # [12:56] <annevk> TabAtkins: it's more like "potentially relative"
  338. # [12:57] <annevk> TabAtkins: the latter would not match and would only work if you provide reference elements...
  339. # [12:57] <TabAtkins> ah, kk.
  340. # [12:57] <annevk> TabAtkins: it's not entirely clear to me whether we want the reference element feature if we're going to let things work on Elements, but jQuery parity would require not throwing for "> body" and making "html > body" work
  341. # [12:58] <TabAtkins> If you need it, I can provide an "absolutize a potentially relative selector" algo.
  342. # [12:58] <annevk> TabAtkins: it looks like jQuery always uses that
  343. # [12:59] <annevk> TabAtkins: e.g. w($("body").select("html > body")) returns the body element
  344. # [12:59] <TabAtkins> Depends on the function. jQuery's find() uses the currently specced algo.
  345. # [12:59] <TabAtkins> $("body").find("body") returns an empty set.
  346. # [12:59] <TabAtkins> iirc
  347. # [13:00] <annevk> TabAtkins: ah you're right
  348. # [13:00] * Joins: SteveF (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginmedia.com)
  349. # [13:00] <TabAtkins> Like I said, just let me know, and I can add the alternate algo.
  350. # [13:01] <annevk> TabAtkins: do I file bugs somewhere?
  351. # [13:01] <TabAtkins> send email, please.
  352. # [13:01] <TabAtkins> or just tell me right here, since I can do that immediately.
  353. # [13:01] <annevk> TabAtkins: alright, I'll send a single email once I know all the things I want
  354. # [13:01] <TabAtkins> kk
  355. # [13:03] * Joins: Spedax (~spedax@5.149.138.2)
  356. # [13:08] * Quits: tantek (~tantek@89.202.203.51) (Quit: tantek)
  357. # [13:10] <annevk> Domenic_: seems .is() has any semantics
  358. # [13:11] <annevk> Domenic_: e.g. [<script>, <div>].is("div") -> true
  359. # [13:11] * Quits: cheron (~cheron@unaffiliated/cheron) (Read error: Connection reset by peer)
  360. # [13:14] * Joins: cheron (~cheron@unaffiliated/cheron)
  361. # [13:18] <annevk> Also seems like is("> ..") has no useful semantics other than not throwing...
  362. # [13:20] * Quits: darobin (~darobin@78.208.93.24) (Remote host closed the connection)
  363. # [13:32] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  364. # [13:40] <Lachy> annevk, right. .is() in jquery is more limited than matches() was specced to be in that regard, because matches("> …", refNodes) made that syntax potentially more useful than simply not throwing.
  365. # [13:44] <Lachy> Adding support to refNodes and using a relative selector there was a way to address the syntax error issue, though the actual use case for using them with matches() is somewhat limited in practice. So, if you decide not to support refNodes in matches(), at least for now, and instead work around the syntax issue in some other way, then it wouldn't be a huge loss.
  366. # [13:46] * Joins: darobin (~darobin@78.109.80.74)
  367. # [13:54] * Joins: darobin_ (~darobin@78.109.80.74)
  368. # [13:54] * Quits: darobin (~darobin@78.109.80.74) (Read error: Connection reset by peer)
  369. # [13:56] * Joins: jdaggett (~jdaggett@y230006.dynamic.ppp.asahi-net.or.jp)
  370. # [13:57] * Joins: charl (~charl@2001:67c:2564:524:92b1:1cff:fe89:ae5)
  371. # [13:58] <Domenic_> mounir: pong
  372. # [13:59] <Domenic_> annevk: any semantics seem ok, dunno, seems like a rare case.
  373. # [14:00] <Domenic_> annevk: Lachy: seems like unlike find, for matches the reference nodes actually have a meaning, maybe. (although as Lachy says, not a terribly useful one.)
  374. # [14:01] * Quits: reyre (~reyre@CPE7cb21b1e2cf4-CM7cb21b1e2cf1.cpe.net.cable.rogers.com) (Remote host closed the connection)
  375. # [14:01] * Quits: SteveF (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginmedia.com) (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
  376. # [14:02] <Domenic_> in any case I think singleElement.matches(...) would be the 95% case.
  377. # [14:04] <Domenic_> does body.is("> body") work? feels like it should
  378. # [14:04] * Quits: lokling (~quassel@quassel.woboq.com) (Read error: Operation timed out)
  379. # [14:04] <Domenic_> nope, false
  380. # [14:04] <Lachy> Domenic_, no, it doesn't.
  381. # [14:04] <Domenic_> weird
  382. # [14:05] <Lachy> why would that be weird? You're basically asking is it a child of some undefined element
  383. # [14:05] <Domenic_> to me it feels like asking if it's the child of any element
  384. # [14:05] * Joins: lokling (~quassel@quassel.woboq.com)
  385. # [14:05] <Domenic_> but i guess i can't think of a real reason for that feeling so shrug
  386. # [14:06] <Lachy> if that's what you want, then use "*>body" or check if parentNode is null
  387. # [14:06] <Domenic_> right, "* > body" works, seems good.
  388. # [14:10] * Joins: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net)
  389. # [14:15] * Quits: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net) (Ping timeout: 264 seconds)
  390. # [14:22] <annevk> Lachy: the syntax being compatible was deemed important?
  391. # [14:23] <annevk> Lachy: my inclination would be to throw for .matches("> test")
  392. # [14:24] <annevk> Domenic_: I'd be inclined to not support Element.prototype.matches() until someone makes a compelling case
  393. # [14:25] <Lachy> You could do that too. Then when jquery uses matches, it can just catch the exception and ignore if it ever happens.
  394. # [14:25] <Domenic_> annevk: really? do you not think it'd be the 95% case?
  395. # [14:25] <annevk> Domenic_: sorry, Elements*
  396. # [14:25] <Domenic_> ah ok. yes in that case i agree.
  397. # [14:26] <annevk> Lachy: yeah
  398. # [14:26] <annevk> It seems kind of weird to start copying the quirks of libraries...
  399. # [14:27] <Domenic_> i think the question is, should asking whether something is a match ever throw
  400. # [14:27] <annevk> Although I guess we're doing that with promises...
  401. # [14:27] <Lachy> I liked it though, cause it basically gave refNodes support in matches for negligible implementation cost, once they're implemented for find()
  402. # [14:27] <mounir> Domenic_: I was wondering where the name Promise#race came from, I didn't see it in other libraries but I might as well have not searched enough
  403. # [14:27] <annevk> Domenic_: jQuery throws for e.g. is("::blah") which is a parse error in Selectors too
  404. # [14:28] <annevk> Lachy: we don't want them for find() anymore
  405. # [14:28] <Lachy> why not?
  406. # [14:28] <Domenic_> mounir: no libraries really have the operation, but MarkM's concurrency strawman does and Q added it recently based on that.
  407. # [14:28] <annevk> Lachy: see public-webapps
  408. # [14:28] <Lachy> at least for document.find(), there were some valuable use cases
  409. # [14:28] <Lachy> ok, will look
  410. # [14:28] <Domenic_> annevk: hmm ok, well if it does throw in some cases then throwing for "> body" seems totally fine.
  411. # [14:29] <mounir> Domenic_: why is that added in the first place? is this a commonly used feature?
  412. # [14:30] <Domenic_> mounir: not really sure, MarkM likes it I guess, and it was in the original DOM promises, so that is probably the impetus.
  413. # [14:33] <Lachy> annevk, is Elements.from() specced anywhere yet?
  414. # [14:33] * Joins: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net)
  415. # [14:33] <Lachy> I'm assuming that's the alternative solution to refNodes you're talking about
  416. # [14:34] <annevk> Lachy: that's like Array.from()
  417. # [14:34] <annevk> Lachy: Elements is just an array subclass that has query/queryAll as methods
  418. # [14:34] <annevk> Lachy: and is the return value for query/queryAll
  419. # [14:34] <Lachy> ah, ok. Is that Elements object specced somewhere then?
  420. # [14:35] <annevk> Lachy: it's https://gist.github.com/domenic/5864658
  421. # [14:35] <annevk> Lachy: I'm going to turn that into a spec at some point, once I figure out how
  422. # [14:35] <Lachy> ok
  423. # [14:36] <Lachy> That looks like a reasonable alternative to refNodes to me, in which case, I agee, just make matches a normal selector instead of relative.
  424. # [14:36] <Lachy> *agree
  425. # [14:40] <Domenic_> sounds like we're going with query instead of select, updating
  426. # [14:40] * Quits: Kolombiken (~Adium@94.137.124.2) (Ping timeout: 260 seconds)
  427. # [14:44] <annevk> Domenic_: yeah, seems safer
  428. # [14:44] <annevk> Domenic_: and hey, we just got everyone used to the name query...
  429. # [14:50] * Joins: Kolombiken (~Adium@gateway.creuna.se)
  430. # [14:51] <Lachy> what was wrong with the name "find"?
  431. # [14:51] <annevk> Lachy: Array.prototype.find is a thing
  432. # [14:52] * Joins: krawchyk (~krawchyk@65.220.49.251)
  433. # [14:52] <Lachy> oh, right.
  434. # [14:52] * Quits: Bass10 (~Bass10@c-76-113-194-7.hsd1.mn.comcast.net) (Quit: Leaving)
  435. # [14:55] * Joins: scor (~scor@drupal.org/user/52142/view)
  436. # [14:55] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
  437. # [14:56] * Joins: tantek (~tantek@pro75-2-82-224-126-163.fbx.proxad.net)
  438. # [15:00] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 256 seconds)
  439. # [15:08] * Quits: tantek (~tantek@pro75-2-82-224-126-163.fbx.proxad.net) (Ping timeout: 260 seconds)
  440. # [15:09] * Quits: annevk (~annevk@207.218.72.65) (Remote host closed the connection)
  441. # [15:09] * Joins: annevk (~annevk@207.218.72.65)
  442. # [15:10] * Quits: zkis (~zkis@2001:998:22:0:5800:f5f7:cf4f:7c5e) (Ping timeout: 245 seconds)
  443. # [15:12] * Joins: zkis (~zkis@2001:998:22:0:5800:f5f7:cf4f:7c5e)
  444. # [15:13] * Quits: Kolombiken (~Adium@gateway.creuna.se) (Quit: Leaving.)
  445. # [15:15] * Joins: rmichnik (~quassel@177.135.228.218)
  446. # [15:15] * Joins: Cromulent (~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com)
  447. # [15:21] * Joins: TheGallery (~TheGaller@athedsl-218081.home.otenet.gr)
  448. # [15:23] * Joins: Cromulent|2 (~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com)
  449. # [15:24] <annevk> I think I'll just use my own IDL syntax until heycam|away fixes bugs
  450. # [15:24] <annevk> Don't really want to go all ES6 on this as implementers are not going to use that anyway for the foreseeable future
  451. # [15:24] * Quits: Cromulent (~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com) (Ping timeout: 256 seconds)
  452. # [15:28] * Quits: Cromulent|2 (~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com) (Client Quit)
  453. # [15:29] * Joins: newtron (~newtron@199.71.174.103)
  454. # [15:30] * Joins: jreading (~Adium@ip98-169-193-48.dc.dc.cox.net)
  455. # [15:32] * Quits: Smylers (~smylers@81.143.60.194) (Remote host closed the connection)
  456. # [15:33] * Joins: Smylers (~smylers@81.143.60.194)
  457. # [15:35] * Joins: Kolombiken (~Adium@gateway.creuna.se)
  458. # [15:36] * Joins: TallTed (~Thud@31-34-45.wireless.csail.mit.edu)
  459. # [15:37] * Quits: zkis (~zkis@2001:998:22:0:5800:f5f7:cf4f:7c5e) (Ping timeout: 245 seconds)
  460. # [15:38] <Domenic_> mmm, yeah, lack of @@create is hurting.
  461. # [15:38] <Domenic_> i guess i should file those bugs
  462. # [15:39] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
  463. # [15:40] <annevk> engine bugs? cc me please
  464. # [15:41] <Domenic_> this one already exists it seems. https://bugzilla.mozilla.org/show_bug.cgi?id=838540
  465. # [15:41] <Domenic_> I'll add a comment
  466. # [15:41] <annevk> for all the benefits closer cooperation with ES brings, speeding things up is not one of them :/
  467. # [15:41] <Domenic_> ah
  468. # [15:41] <Domenic_> *hah
  469. # [15:44] <mounir> Domenic_: sorry to start again with Promise#race(), I was called for an urgent meeting
  470. # [15:44] * Joins: reyre (~reyre@142.204.133.18)
  471. # [15:44] <mounir> Domenic_: reading the issue, it seems like some people are not trilled with the name and the behaviour
  472. # [15:44] <mounir> Domenic_: why not simply not add it to the standardise subset?
  473. # [15:47] <Domenic_> mounir: it's more of a question of "why not simply remove it from the standard," which is quite a different question. Under a different name, it's in DOM promises.
  474. # [15:50] * Quits: kinetik (~kinetik@121.99.58.238) (Ping timeout: 256 seconds)
  475. # [15:51] <mounir> Domenic_: I know it was in DOM promises
  476. # [15:51] <mounir> but why was it there?
  477. # [15:51] <mounir> Domenic_: DOM promises wasn't stable enough to be an authoritative document ;)
  478. # [15:51] * Joins: zkis (~zkis@2001:998:22:0:5800:f5f7:cf4f:7c5e)
  479. # [15:52] * Joins: encryptd_fractal (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  480. # [15:52] * Joins: kinetik (~kinetik@121.99.144.210)
  481. # [15:54] <mounir> Domenic_: I mean, I don't see the pros in adding this to the spec and there seem to be cons, if it was a Web API, I would say that the simplest solution would be to simply not add it and figure out later how things evolve
  482. # [15:54] <Domenic_> mounir: I won't shed a tear if it dies, but nobody gave any real arguments against it that were more than "I don't like the bikeshed color" (and nobody even proposed a better color).
  483. # [15:55] <Domenic_> mounir: if you really want to campaign to kill someone's pet feature, be ready for having a fight on your hands, and start opening issues/gathering consensus from parties involved.
  484. # [15:57] * Joins: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net)
  485. # [15:59] <mounir> Domenic_: I will not campaign against it but I just don't understand the reasons behind this feature
  486. # [16:00] <Domenic_> mounir: basically it is an easy-to-spec combinator that some people, in particular MarkM, have found useful in their work.
  487. # [16:00] * Quits: tomasf (~tomasf@77.72.97.10.c.fiberdirekt.net) (Ping timeout: 240 seconds)
  488. # [16:02] <mounir> Domenic_: will file an issue and see how it goes
  489. # [16:02] <mounir> I will not die on that hill and no need to discuss it in a not-so-public way
  490. # [16:02] * Quits: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net) (Ping timeout: 276 seconds)
  491. # [16:02] * Joins: ehsan (~ehsan@230.43.214.193.static.cust.telenor.com)
  492. # [16:03] <Domenic_> seems like a plan
  493. # [16:05] <annevk> Domenic_: not sure Mark felt that strongly about it
  494. # [16:05] <Domenic_> annevk: agree, he probably wouldn't mind that much, but just mentioning that he is the one who has actually used it.
  495. # [16:08] * Quits: reyre (~reyre@142.204.133.18) (Read error: Connection reset by peer)
  496. # [16:08] * Joins: reyre_ (~reyre@142.204.133.18)
  497. # [16:08] * Quits: reyre_ (~reyre@142.204.133.18) (Read error: Connection reset by peer)
  498. # [16:09] * Joins: reyre (~reyre@142.204.133.18)
  499. # [16:13] * Quits: zewt (~foo@ec2-50-17-220-142.compute-1.amazonaws.com) (Ping timeout: 246 seconds)
  500. # [16:13] * Joins: zewt (~foo@ec2-50-17-220-142.compute-1.amazonaws.com)
  501. # [16:20] * Joins: tantek (~tantek@89.202.203.51)
  502. # [16:26] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
  503. # [16:26] * Quits: stalled (~stalled@unaffiliated/stalled) (Ping timeout: 260 seconds)
  504. # [16:30] * Quits: zkis (~zkis@2001:998:22:0:5800:f5f7:cf4f:7c5e) (Ping timeout: 245 seconds)
  505. # [16:33] * Quits: Spedax (~spedax@5.149.138.2) (Remote host closed the connection)
  506. # [16:35] * Joins: scor (~scor@drupal.org/user/52142/view)
  507. # [16:37] * Joins: stalled (~stalled@unaffiliated/stalled)
  508. # [16:37] <Domenic_> annevk: you were probably planning on it already, but would love a cc on that www-style thread.
  509. # [16:38] <annevk> Domenic_: wasn't :)
  510. # [16:41] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
  511. # [16:41] <Domenic_> annevk: how are you handling people putting non-elements in Elements? The gist handles it by blowing up in the appropriate place.
  512. # [16:42] <annevk> Domenic_: I copy Element nodes from the array before doing anything
  513. # [16:42] <Domenic_> annevk: also to enable subclassing ideally `queryAll` should return an instance of `this.constructor`, not necessarily an `Elements`.
  514. # [16:43] <annevk> hmm yeah
  515. # [16:44] <Domenic_> somehow allen convinced me blowing up was better, i wonder why. will have to re-read.
  516. # [16:45] <annevk> Domenic_: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18878
  517. # [16:45] <annevk> Domenic_: you mean throw if something fails the brand check?
  518. # [16:45] <annevk> Domenic_: ooh, wait, just calling the internal thing
  519. # [16:46] <Domenic_> annevk: yeah like that, although it's essentially equivalent.
  520. # [16:46] <annevk> not quite
  521. # [16:46] <Domenic_> hmm right subclasses and such
  522. # [16:46] <Domenic_> well depends on how the brand is installed?
  523. # [16:47] <Domenic_> i mean the hard part is allowing implementations room for optimization
  524. # [16:48] <Domenic_> but then again i guess the es spec generally just says "do this" and implementations are like "i'll do something vaguely like that, but probably completely different under the covers, as long as the semantics are the same."
  525. # [16:48] <annevk> there's a whole bunch of these things we'll have to sort out in due course
  526. # [16:48] <annevk> for a whole lot of objects
  527. # [16:48] <annevk> I'm not too worried about this one right now
  528. # [16:48] <Domenic_> fair
  529. # [16:48] <Domenic_> i think the this.constructor thing would be nice to get in soon though
  530. # [16:49] <annevk> yeah, have to see what heycam|away has to say to the IDL bugs, and bz
  531. # [16:50] <annevk> Domenic_: I guess I could indicate the intent for now
  532. # [16:54] <annevk> TabAtkins: emailed www-style, figured I didn't need to add you in To: since it's kinda the same thing :p
  533. # [16:55] <TabAtkins> Yes, it's actually preferable that you don't, so I get the list version of the mail and can get at the archived-at header if necessary.
  534. # [16:57] * Joins: scor (~scor@drupal.org/user/52142/view)
  535. # [16:58] <annevk> TabAtkins: in replies, it's preferable you copy me, as I'm not on the list
  536. # [16:58] <TabAtkins> kk
  537. # [16:58] <TabAtkins> gmail does that automatically, so that's fine.
  538. # [16:58] * Joins: Spedax (~spedax@5.149.138.2)
  539. # [17:03] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Remote host closed the connection)
  540. # [17:06] <TabAtkins> Domenic_: Yeah, the "black box" clause is always in effect - you can do whatever you like, as long as it's not observably different from what the spec requires.
  541. # [17:06] * Joins: zkis (~zkis@2001:998:22:0:5800:f5f7:cf4f:7c5e)
  542. # [17:09] * Quits: mven (~mven@ip68-224-15-53.lv.lv.cox.net) (Remote host closed the connection)
  543. # [17:16] * Quits: TheGallery (~TheGaller@athedsl-218081.home.otenet.gr) (Quit: Leaving)
  544. # [17:17] * Joins: bkardell__ (uid10373@gateway/web/irccloud.com/x-sndaasnbuftvquoa)
  545. # [17:21] * Quits: jdaggett (~jdaggett@y230006.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
  546. # [17:22] * Joins: bradleymeck (~bradley.m@216-166-20-1.fwd.datafoundry.com)
  547. # [17:24] * Quits: baku (~baku@193.214.41.72) (Ping timeout: 264 seconds)
  548. # [17:25] * Joins: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginmedia.com)
  549. # [17:25] * Joins: baku (~baku@193.214.41.72)
  550. # [17:29] * Quits: zkis (~zkis@2001:998:22:0:5800:f5f7:cf4f:7c5e) (Ping timeout: 245 seconds)
  551. # [17:31] * Joins: sicking (~sicking@0.43.214.193.static.cust.telenor.com)
  552. # [17:32] * Quits: Spedax (~spedax@5.149.138.2) (Remote host closed the connection)
  553. # [17:34] * Joins: lmcliste_ (~lmclister@192.150.10.209)
  554. # [17:36] * Joins: brion (~brion@wikipedia/pdpc.professional.brion)
  555. # [17:43] * abarth is now known as abarth|gardener
  556. # [17:46] * Quits: Lachy (~textual@213.166.174.2) (Quit: Textual IRC Client: www.textualapp.com)
  557. # [17:46] * Joins: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net)
  558. # [17:48] * Quits: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginmedia.com) (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
  559. # [17:50] * Quits: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net) (Ping timeout: 276 seconds)
  560. # [17:52] * Joins: tobie_ (~tobielang@col74-1-88-183-112-72.fbx.proxad.net)
  561. # [17:57] * Joins: jsbell (jsbell@nat/google/x-ztvbmsmgwfqldsfo)
  562. # [17:59] * Quits: gavinc (~gavin@barad-dur.carothers.name) (Read error: Connection reset by peer)
  563. # [18:01] * Quits: sgalineau (~sylvaing@89.202.203.52) (Quit: Textual IRC Client: www.textualapp.com)
  564. # [18:01] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  565. # [18:03] * Quits: cabanier (~cabanier@c-98-237-137-173.hsd1.wa.comcast.net) (Quit: Leaving.)
  566. # [18:07] * Quits: darobin_ (~darobin@78.109.80.74) (Remote host closed the connection)
  567. # [18:07] * Quits: bradleymeck (~bradley.m@216-166-20-1.fwd.datafoundry.com) (Quit: bradleymeck)
  568. # [18:08] * Joins: darobin (~darobin@78.109.80.74)
  569. # [18:10] * Joins: bradleymeck (~bradley.m@216-166-20-1.fwd.datafoundry.com)
  570. # [18:12] * Quits: darobin (~darobin@78.109.80.74) (Ping timeout: 256 seconds)
  571. # [18:12] * Quits: sicking (~sicking@0.43.214.193.static.cust.telenor.com) (Quit: sicking)
  572. # [18:14] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
  573. # [18:15] * Quits: charl (~charl@2001:67c:2564:524:92b1:1cff:fe89:ae5) (Quit: leaving)
  574. # [18:15] * Quits: ehsan (~ehsan@230.43.214.193.static.cust.telenor.com) (Remote host closed the connection)
  575. # [18:16] * Joins: ehsan (~ehsan@230.43.214.193.static.cust.telenor.com)
  576. # [18:17] * Quits: brion (~brion@wikipedia/pdpc.professional.brion) (Quit: brion)
  577. # [18:19] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 256 seconds)
  578. # [18:20] * Quits: ehsan (~ehsan@230.43.214.193.static.cust.telenor.com) (Ping timeout: 256 seconds)
  579. # [18:24] * Joins: Lachy (~textual@cm-84.215.104.248.getinternet.no)
  580. # [18:24] * Quits: tantek (~tantek@89.202.203.51) (Quit: tantek)
  581. # [18:25] * Joins: shepazu (~shepazu@12.202.169.254)
  582. # [18:25] * Quits: baku (~baku@193.214.41.72) (Ping timeout: 264 seconds)
  583. # [18:26] * Quits: temp01 (~temp01@unaffiliated/temp01) (Read error: No route to host)
  584. # [18:26] * Joins: ehsan (~ehsan@148.122.12.62)
  585. # [18:27] * Joins: ehsan_ (~ehsan@148.122.12.62)
  586. # [18:28] * Quits: ehsan (~ehsan@148.122.12.62) (Read error: No route to host)
  587. # [18:28] * Quits: ehsan_ (~ehsan@148.122.12.62) (Remote host closed the connection)
  588. # [18:29] * Joins: nimbu (~nimbu@192.150.10.206)
  589. # [18:31] * Quits: Smylers (~smylers@81.143.60.194) (Ping timeout: 264 seconds)
  590. # [18:32] <smaug____> wycats: I assume http://w3ctag.github.io/jsidl/jsidl.html isn't updated actively anymore?
  591. # [18:32] * Joins: ap (~ap@17.202.44.214)
  592. # [18:33] * Joins: jwalden (~waldo@v-1045.fw1.sfo1.mozilla.net)
  593. # [18:33] <wycats> It will be shortly
  594. # [18:33] <wycats> Domenic_ is working on it
  595. # [18:33] * Quits: jwalden (~waldo@v-1045.fw1.sfo1.mozilla.net) (Client Quit)
  596. # [18:33] * Joins: ehsan (~ehsan@148.122.12.62)
  597. # [18:33] * Joins: jwalden (~waldo@v-1045.fw1.sfo1.mozilla.net)
  598. # [18:33] <wycats> ES6 deadlines are consuming my available time atm
  599. # [18:34] <Domenic_> indeed. sidetracked by promises-unwrapping but that has quieted.
  600. # [18:34] * Quits: scor (~scor@drupal.org/user/52142/view) (Ping timeout: 264 seconds)
  601. # [18:34] <wycats> same with dherman, who is also helping
  602. # [18:34] <wycats> Domenic_: psyched that you'll be at TC39
  603. # [18:34] * Joins: temp01 (~temp01@unaffiliated/temp01)
  604. # [18:35] <annevk> Domenic_: I feel like Streams would be a more effective use of your time ^_^
  605. # [18:35] * Quits: ehsan (~ehsan@148.122.12.62) (Remote host closed the connection)
  606. # [18:35] <Domenic_> annevk: oh right, hrmmmm
  607. # [18:35] <Domenic_> dammit i need a standards job
  608. # [18:35] <Domenic_> basically i need annevk's job
  609. # [18:35] * Quits: zcorpan (~zcorpan@89.202.203.52) (Remote host closed the connection)
  610. # [18:35] * Joins: ehsan (~ehsan@148.122.12.62)
  611. # [18:36] * Joins: zcorpan (~zcorpan@89.202.203.52)
  612. # [18:37] <smaug____> Domenic_: some reasoning in the spec would be nice
  613. # [18:37] <smaug____> in the spec or elsewhere
  614. # [18:37] <smaug____> would be easier to understand why that is needed when we have webidl spec too
  615. # [18:37] <Domenic_> smaug____: yeah definitely.
  616. # [18:38] <Domenic_> smaug____: I do like annevk's idea of nudging WebIDL more JS-ward though in the meantime.
  617. # [18:38] <annevk> smaug____: basically, there's an ever growing mismatch between IDL and JS; I don't really care how we fix that gap, but we need to fix it
  618. # [18:39] <smaug____> (currently I think some people just don't like some aspects of WebIDL, so another idl spec is need. But I could be very wrong , since I don't know where to read the reasoning. )
  619. # [18:39] <smaug____> annevk: that "ever growing mismatch between IDL and JS" is not clear to me
  620. # [18:39] <annevk> My bet is that fixing IDL is better, because IDL is implemented so the implications of changes are more apparent, but I'm not opposed to a dual strategy.
  621. # [18:40] <smaug____> I mean, is there a list of mismatches somewhere
  622. # [18:40] <Domenic_> i think people don't realize how far off WebIDL is from JS
  623. # [18:40] * Quits: ehsan (~ehsan@148.122.12.62) (Ping timeout: 245 seconds)
  624. # [18:40] <smaug____> and reasoning why something is a mismatch
  625. # [18:40] <Domenic_> smaug____: that would be a good idea
  626. # [18:40] <annevk> smaug____: e.g. subclassing of JavaScript types is not possible, defining reusable prototype methods as JavaScript does is not really possible
  627. # [18:40] * Quits: zcorpan (~zcorpan@89.202.203.52) (Ping timeout: 245 seconds)
  628. # [18:40] * Quits: dbaron (~dbaron@89.202.203.51) (Ping timeout: 264 seconds)
  629. # [18:41] <annevk> smaug____: a bunch of it is mostly due to changes in ES6, granted
  630. # [18:42] <Domenic_> well, before ES6, subclassing JS types was impossible :)
  631. # [18:43] <Domenic_> but yeah other things like argument defaulting semantics were clarified in ES6 whereas there were only 5 or 10 examples in the ES5 spec.
  632. # [18:43] * Joins: scor (~scor@drupal.org/user/52142/view)
  633. # [18:45] <smaug____> I assume these idl changes would be still backwards compatible
  634. # [18:46] <annevk> smaug____: right
  635. # [18:46] * Quits: qtax^w (~qtax@gw.ateles.se) (Quit: Leaving)
  636. # [18:47] <annevk> smaug____: potentially marking existing constructs "legacy" as we've done in the past if we really want something else and it's breaking
  637. # [18:47] <Domenic_> my hope would be to make all the backward-compat exceptions to ES semantics move to prose, but that might not be palatable by implementers, so a bevvy of [LegacyDefaultingSemantics] etc. annotations might be the way to go.
  638. # [18:47] <annevk> smaug____: not breaking the web is something TC39 shares
  639. # [18:48] <Domenic_> it's unclear though what's breaking, e.g. WebIDL is continually debating changing their function .length algorithm, so i guess they are assuming that doesn't break anything.
  640. # [18:48] <annevk> Domenic_: also consider people writing the specs, it'd be a lot of work to rewrite all those algorithms
  641. # [18:48] <Domenic_> annevk: for sure. it has to be usable to be useful.
  642. # [18:48] <annevk> Domenic_: breaking is measured by testing
  643. # [18:48] <annevk> Domenic_: ship and back out and such
  644. # [18:48] <Domenic_> annevk: yeah but deciding whether it's worth the time to try shipping is the step i'm talking about
  645. # [18:49] <annevk> Ah, that's cost benefit analysis
  646. # [18:49] <Domenic_> e.g. .length changes are presumed unlikely to break so they'll probably try it. Whereas I'm not so sure about switching from `null` to `undefined` as default-triggerer, that seems like it might not be possible.
  647. # [18:50] <annevk> A lot of people use null
  648. # [18:50] <smaug____> but how much of the old stuff would be "[legacy]"? It would be rather bad to end up to a situation where the platform has rather inconsistent semantics because of lots stuff is legacy and new stuff uses some other setup
  649. # [18:50] <annevk> smaug____: I think that's largely an unknown at this point
  650. # [18:50] <Domenic_> smaug____: unclear. but, is inconsistent with ES/consistent with itself better than the other way around?
  651. # [18:51] <smaug____> right, that is what I expected :)
  652. # [18:51] <annevk> If everything outside ES is consistent, maybe ES should change
  653. # [18:51] <annevk> I doubt that though
  654. # [18:51] <Domenic_> nah user-space libraries and ES are generally consistent
  655. # [18:53] <bradleymeck> ok, so, who do I talk to about host objects having getters/setters/properties and DOM attributes not matching up for various fun stuff like MutationObservers and tabIndex. spent some time a couple months back writing to the mailing list and basically got aback a "thats the way it works" so, onto round 2
  656. # [18:53] * Quits: marcosc (~marcosc@bl7-118-144.dsl.telepac.pt) (Remote host closed the connection)
  657. # [18:54] <smaug____> bradleymeck: you mean stuff like inputelement.value vs. <input value=""> ?
  658. # [18:54] <bradleymeck> the controls not matching up with change events is a big one, yes
  659. # [18:55] * Quits: jreading (~Adium@ip98-169-193-48.dc.dc.cox.net) (Ping timeout: 245 seconds)
  660. # [18:55] * Joins: jreading (~Adium@ip98-169-193-48.dc.dc.cox.net)
  661. # [18:56] <smaug____> well, .value handling can't be changed, and MutationObserver is about changes to DOM...so I'm not sure there is much to discuss there, unless you have some great proposal :)
  662. # [18:56] <Domenic_> bradleymeck: the problem is "don't break the web"; we can't change the value attribute to suddenly not be retarded.
  663. # [18:57] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
  664. # [18:57] * Parts: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  665. # [18:57] <Domenic_> bradleymeck: but most new attributes seem to work fine, e.g. <details> open attribute and .open property stay in sync.
  666. # [18:57] <Domenic_> this kind of sucks though since you can use MutationObserver on <details> but not on <input> :(
  667. # [18:59] * Quits: tobie_ (~tobielang@col74-1-88-183-112-72.fbx.proxad.net) (Ping timeout: 248 seconds)
  668. # [19:01] * Joins: brion (~brion@wikipedia/pdpc.professional.brion)
  669. # [19:03] <bradleymeck> well I don't want to change it from a getter, but setting does already tie into a change event, so I am looking more towards having a way for events hook into mutation observers
  670. # [19:03] * Joins: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp)
  671. # [19:04] <bradleymeck> cause the JS side notifying the DOM tree that something important has happened seems an ok use case
  672. # [19:04] * Joins: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net)
  673. # [19:05] <Domenic_> i am not sure i get it... you're talking about firing synthetic events on DOM elements?
  674. # [19:05] * Joins: jorgepedret (~jorgepedr@64-46-23-103.dyn.novuscom.net)
  675. # [19:05] * Joins: tantek (~tantek@69.121.19.93.rev.sfr.net)
  676. # [19:05] * Quits: mitemitreski (~mitemitre@212.120.17.179) (Read error: Connection reset by peer)
  677. # [19:06] * Quits: newtron (~newtron@199.71.174.103) (Ping timeout: 276 seconds)
  678. # [19:06] * Quits: nimbu (~nimbu@192.150.10.206) (Quit: Leaving.)
  679. # [19:07] <bradleymeck> Domenic_: i guess you could say it that way, notification for MutationObservers only, not quite full events
  680. # [19:07] <Domenic_> oh i think i see, so, artificially trigger a mutation observer callback?
  681. # [19:08] <bradleymeck> yes
  682. # [19:08] <smaug____> well, for now you could just call the callback manually
  683. # [19:08] <smaug____> but we could add a getter for the callback
  684. # [19:08] <bradleymeck> but detecting which mutation observers are observing a node?
  685. # [19:09] <smaug____> bradleymeck: you want something like https://bugzilla.mozilla.org/show_bug.cgi?id=912874 ?
  686. # [19:09] <smaug____> (in Gecko that is available for chrome code only, not for web pages)
  687. # [19:10] <smaug____> (the API in bug 912874 isn't super pretty but gives what devtools needed)
  688. # [19:11] <bradleymeck> you could perform this using MutationObserver enumeration, but I am hesitant about exposing what mutation observers are looking at a node, just sending a new MutationRecord to any observer listening to a node would seem less scope creep
  689. # [19:12] <smaug____> bradleymeck: the additions to MutationObserver let's one to get the callback
  690. # [19:12] * Joins: nimbu (~nimbu@192.150.10.206)
  691. # [19:12] <smaug____> you can skip the change to Node :)
  692. # [19:12] * Quits: odinho (odinho@dalvik.ping.uio.no) (Ping timeout: 264 seconds)
  693. # [19:12] <bradleymeck> something akin to EventTarget.dispatchEvent(VirtualMutationEvent) was what I was thinking
  694. # [19:13] <smaug____> oh, you want virtual MutationRecords
  695. # [19:13] <bradleymeck> cause telling people to iterate when a scripting property is the authority for mutation might be ugly
  696. # [19:13] * Joins: say2joe (~say2joe@209-253-225-97.ip.mcleodusa.net)
  697. # [19:14] * Parts: say2joe (~say2joe@209-253-225-97.ip.mcleodusa.net)
  698. # [19:15] <bradleymeck> it does not need to have bubble / propagation / etc, so I am unsure it should be an event even
  699. # [19:15] <smaug____> bradleymeck: something like somenode.notifyMutationObservers(new MutationRecord({type: "attributes", target: somenode, attributeName: "value"}))
  700. # [19:15] <bradleymeck> yes
  701. # [19:16] * Quits: nimbu (~nimbu@192.150.10.206) (Client Quit)
  702. # [19:16] <smaug____> or, perhaps no need for MutationRecord ctor, dictionary would be enough
  703. # [19:16] <bradleymeck> but since it is virtual I would constrain type, this should only be talking about the host object not the DOM side
  704. # [19:17] <bradleymeck> then we don't have to confuse attributes on host vs attributes on dom itself
  705. # [19:18] <bradleymeck> and we only really need this since history about change events and value attributes sigh
  706. # [19:20] <Domenic_> bradleymeck: right, sounds like your use case is firing artificial changes for `attributeName: "value"` from the `"input"` event, so that value behaves like everything else. opt-in fixing of `value` with respect to MutationObserver.
  707. # [19:20] <bradleymeck> thats the basic idea
  708. # [19:22] <Domenic_> seems great, now we just need to get the attention of whoever's in charge of mutationobservers. I think they're in DOM now, so maybe annevk?
  709. # [19:22] <Domenic_> (gtg, rejectjs afterparty.)
  710. # [19:24] * Joins: zkis (~zkis@188-67-161-229.bb.dnainternet.fi)
  711. # [19:28] * Quits: brion (~brion@wikipedia/pdpc.professional.brion) (Ping timeout: 256 seconds)
  712. # [19:29] * Joins: brion (~brion@wikipedia/pdpc.professional.brion)
  713. # [19:32] * Joins: Spedax (~spedax@5.149.138.2)
  714. # [19:36] * Joins: cabanier (~cabanier@192.150.22.55)
  715. # [19:36] * Joins: scor (~scor@LAubervilliers-153-51-19-234.w193-253.abo.wanadoo.fr)
  716. # [19:36] * Quits: scor (~scor@LAubervilliers-153-51-19-234.w193-253.abo.wanadoo.fr) (Changing host)
  717. # [19:36] * Joins: scor (~scor@drupal.org/user/52142/view)
  718. # [19:37] * Quits: Spedax (~spedax@5.149.138.2) (Ping timeout: 264 seconds)
  719. # [19:41] <annevk> Domenic_: they've always been in DOM, I thought we were going to wait for Object.observe()?
  720. # [19:42] <bradleymeck> annevk: are you talking about mutation observers?
  721. # [19:43] <annevk> bradleymeck: yeah
  722. # [19:44] <annevk> bradleymeck: just read scrollback, I suppose we could consider synthetic changes, not sure exactly what the best way forward is
  723. # [19:44] <annevk> bradleymeck: would you mind filing a bug against http://dom.spec.whatwg.org/ (link at the top) with some more detail? Emailing is fine too
  724. # [19:47] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  725. # [19:47] <bradleymeck> I can write up the history reasoning etc. tonight
  726. # [19:48] <bradleymeck> thanks annevk
  727. # [19:49] <annevk> bradleymeck: cool
  728. # [19:49] <Hixie_> annevk: what i meant by referencing SVG was e.g. http://hixie.ch/tests/adhoc/svg/use/001-with-base.html
  729. # [19:50] <Hixie_> annevk: chrome in particular is interesting on that test, since it does what we're talking about doing for everything _but_ hyperlinks
  730. # [19:50] <Hixie_> [24~in svg
  731. # [19:50] <annevk> Hixie_: ah, bz mentioned that too
  732. # [19:50] <annevk> my bad
  733. # [19:50] <Hixie_> anyway, i would imagine that anything we do here would happen for everything, not just links in one place
  734. # [19:50] <Hixie_> but i guess this is a url spec thing, so i'll leave you that thread :-)
  735. # [19:51] <annevk> potentially affects all callers
  736. # [19:51] <annevk> but yeah
  737. # [19:51] <annevk> I mostly feel inertia is like "meh"
  738. # [19:51] <annevk> fear*
  739. # [19:52] <Hixie_> yeah i admit i don't really care about what happens with <base>
  740. # [19:53] <Hixie_> what we're doing is pretty obviously bad, but i don't know what one would do about it
  741. # [19:53] <Hixie_> the alternative is pretty magical, and not in the ooooh shiny way
  742. # [19:54] <Hixie_> as to your other thread... i guess if resolving a url punycodes it already, then every address would already by punycoded, so it's a moot point
  743. # [19:54] <Hixie_> so i'll leave that as is for now
  744. # [19:56] <annevk> I did the thing you suggested btw and picked IDNA2003
  745. # [19:56] <annevk> turns out most people didn't like that, even though it's the most compatible
  746. # [19:57] <annevk> but then there's no real agreement on a replacement other than some variant of UTS #46 that might change over time
  747. # [19:57] * Quits: jreading (~Adium@ip98-169-193-48.dc.dc.cox.net) (Quit: Leaving.)
  748. # [19:57] <Hixie_> what do browsers do?
  749. # [19:58] <Hixie_> if they do what you specced, then people like it, by definition :-)
  750. # [19:59] * Quits: tantek (~tantek@69.121.19.93.rev.sfr.net) (Quit: tantek)
  751. # [20:05] <annevk> Hixie_: turns out no
  752. # [20:06] <Hixie_> they don't do what you specced? what do they do?
  753. # [20:07] <annevk> Hixie_: browsers do IDNA2003, except for IE11, which does some variant of UTS #46; Gerv from Mozilla is pushing another variant of UTS #46; Jungshik and Mark from Google want some variant of UTS #46, potentially more restrictive over time
  754. # [20:08] * Quits: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net) (Remote host closed the connection)
  755. # [20:08] <annevk> Hixie_: nobody is being very specific about the exact details of UTS #46 and clarifying the issues it has now
  756. # [20:08] <annevk> Hixie_: thread might revive in a bit once people are back from vacation, we'll see
  757. # [20:08] <Hixie_> all i heard there is "browsers do IDNA2003", and that's what matters. :-)
  758. # [20:08] <Hixie_> people can "push" anything they want, but if it doesn't get implemented, it's entirely academic
  759. # [20:09] <Hixie_> the IETF "pushed" IDNA2008 or whatever it's called
  760. # [20:09] <annevk> yeah, UTS #46 is an IDNA2003-compatible variant of IDNA2008
  761. # [20:10] <annevk> registrars are adopting IDNA2008 too, it's a mess
  762. # [20:11] <Hixie_> that just changes what you can put in a second-level domain label, right?
  763. # [20:16] * Quits: brion (~brion@wikipedia/pdpc.professional.brion) (Quit: brion)
  764. # [20:17] * Joins: jreading (~Adium@ip98-169-193-48.dc.dc.cox.net)
  765. # [20:17] <Hixie_> annevk: is the "iterators intead of live NodeLists" thread one you can deal with? looks like DOM Core stuff
  766. # [20:17] <dglazkov> good morning, Whatwg!
  767. # [20:18] * Joins: gavinc (~gavin@barad-dur.carothers.name)
  768. # [20:20] * Joins: jreading1 (~Adium@ip98-169-193-48.dc.dc.cox.net)
  769. # [20:20] * Parts: jreading1 (~Adium@ip98-169-193-48.dc.dc.cox.net)
  770. # [20:21] <Hixie_> i'm assuming the thread "BinaryEncoding for Typed Arrays using window.btoa and window.atob" is feedback on http://encoding.spec.whatwg.org/#textencoder and am therefore not responding to that either
  771. # [20:21] * Quits: jreading (~Adium@ip98-169-193-48.dc.dc.cox.net) (Ping timeout: 245 seconds)
  772. # [20:29] * Joins: brion (~brion@wikipedia/pdpc.professional.brion)
  773. # [20:30] <annevk> Hixie_: apparently they're considering obsoleting your portal domain too
  774. # [20:30] <annevk> Hixie_: they don't care
  775. # [20:30] <Hixie_> i don't think any browsers actually show the smiley anyway
  776. # [20:30] <Hixie_> but yeah, i know. they're lame.
  777. # [20:30] <Hixie_> boo.
  778. # [20:31] <annevk> Hixie_: and seemingly inmume to http://www.w3.org/Provider/Style/URI.html
  779. # [20:31] * Quits: scor (~scor@drupal.org/user/52142/view) (Ping timeout: 245 seconds)
  780. # [20:31] <annevk> Hixie_: yeah, both of those are on my radar
  781. # [20:33] * Joins: scor (~scor@drupal.org/user/52142/view)
  782. # [20:35] <Hixie_> who specs window.devicePixelRatio these days?
  783. # [20:35] * Joins: tobie_ (~tobielang@col74-1-88-183-112-72.fbx.proxad.net)
  784. # [20:35] * Joins: dbaron (~dbaron@89.202.203.51)
  785. # [20:37] * annevk nominates zcorpan
  786. # [20:38] <Hixie_> makes sense
  787. # [20:38] * Krinkle|detached is now known as Krinkle
  788. # [20:38] * Quits: annevk (~annevk@207.218.72.65) (Remote host closed the connection)
  789. # [20:38] * Joins: annevk (~annevk@207.218.72.65)
  790. # [20:43] * Quits: shepazu (~shepazu@12.202.169.254) (Quit: is sleepy)
  791. # [20:43] * Quits: annevk (~annevk@207.218.72.65) (Ping timeout: 264 seconds)
  792. # [20:44] * Joins: brion_ (~brion@wikipedia/pdpc.professional.brion)
  793. # [20:44] * Quits: brion (~brion@wikipedia/pdpc.professional.brion) (Disconnected by services)
  794. # [20:44] * brion_ is now known as brion
  795. # [20:45] * Quits: zkis (~zkis@188-67-161-229.bb.dnainternet.fi) (Ping timeout: 245 seconds)
  796. # [20:49] * Quits: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley) (Ping timeout: 268 seconds)
  797. # [20:52] * Quits: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp) (Remote host closed the connection)
  798. # [20:52] * Quits: lmcliste_ (~lmclister@192.150.10.209)
  799. # [20:52] * Joins: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp)
  800. # [20:53] * Joins: Smylers (~smylers@host86-152-155-75.range86-152.btcentralplus.com)
  801. # [20:54] * Quits: espadrine (~ttyl@AMontsouris-158-1-94-141.w90-2.abo.wanadoo.fr) (Ping timeout: 260 seconds)
  802. # [20:54] * Joins: myakura_ (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp)
  803. # [20:54] * Joins: GPHemsley (~GPHemsley@24-197-156-137.dhcp.gsvl.ga.charter.com)
  804. # [20:54] * Quits: GPHemsley (~GPHemsley@24-197-156-137.dhcp.gsvl.ga.charter.com) (Changing host)
  805. # [20:54] * Joins: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley)
  806. # [20:54] * Quits: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp) (Read error: Connection reset by peer)
  807. # [20:55] * Joins: scor_ (~scor@LAubervilliers-153-51-19-234.w193-253.abo.wanadoo.fr)
  808. # [20:55] * Quits: scor_ (~scor@LAubervilliers-153-51-19-234.w193-253.abo.wanadoo.fr) (Changing host)
  809. # [20:55] * Joins: scor_ (~scor@drupal.org/user/52142/view)
  810. # [20:55] * Quits: scor (~scor@drupal.org/user/52142/view) (Ping timeout: 256 seconds)
  811. # [20:55] * scor_ is now known as scor
  812. # [20:56] * Joins: tantek (~tantek@mon75-17-88-175-209-36.fbx.proxad.net)
  813. # [20:57] * Joins: zkis (~zkis@188-67-163-107.bb.dnainternet.fi)
  814. # [21:02] * Quits: tantek (~tantek@mon75-17-88-175-209-36.fbx.proxad.net) (Quit: tantek)
  815. # [21:03] <bkardell__> Hixie: 140 characters is hard ... moving question over here
  816. # [21:04] <bkardell__> Hixie_: page A is in example.com, it contains an iframe to page B in example.org - that page (B) has a manifest
  817. # [21:05] <bkardell__> Hixie_: B's manifest lists file X.js (in example.org) in both CACHE: and NETWORK:
  818. # [21:07] <Hixie_> what's the question?
  819. # [21:07] * Joins: espadrine (~ttyl@AMontsouris-158-1-94-230.w90-2.abo.wanadoo.fr)
  820. # [21:07] <bkardell__> Hixie_: now page B requests X.js via xhr. What should happen?
  821. # [21:07] <Hixie_> it gets it from the cache, like i said on twitter :-)
  822. # [21:08] <Hixie_> is the spec not clear?
  823. # [21:08] <bkardell__> Hixie_: but origin is null?
  824. # [21:08] <Hixie_> origin?
  825. # [21:09] <bkardell__> Hixie_: So there is no problem with page B xmlhttprequest acessing cache when it is in iframe from another page/diff domain?
  826. # [21:10] <Hixie_> i don't understand how the iframe changes anything. what in the spec makes you think it might?
  827. # [21:11] * bkardell__ tries to find logical response
  828. # [21:11] * Quits: tobie_ (~tobielang@col74-1-88-183-112-72.fbx.proxad.net) (Quit: tobie_)
  829. # [21:12] <bkardell__> Hixie_: In figuring something out, I thought I understood some things
  830. # [21:12] <bkardell__> Hixie_: Browsers in some cases aren't cooperating
  831. # [21:12] <bkardell__> Hixie_: Basically trying to figure out which is bug and which is me misunderstanding
  832. # [21:12] <Hixie_> heh
  833. # [21:12] <Hixie_> if there's a test case i can look at, that might bmake this easier :-)
  834. # [21:12] <bkardell__> ah!
  835. # [21:13] <bkardell__> Hixie_: I forgot to mention it was sandboxed?
  836. # [21:13] <Hixie_> oh! well
  837. # [21:13] <Hixie_> if it's sandboxed
  838. # [21:13] <Hixie_> all bets are off
  839. # [21:13] <bkardell__> haha!
  840. # [21:13] <Hixie_> what's the sandbox="" value?
  841. # [21:13] <bkardell__> right!
  842. # [21:13] <Hixie_> just allow-scripts?
  843. # [21:13] <bkardell__> no
  844. # [21:14] <bkardell__> allow-same-origin too
  845. # [21:14] <Hixie_> sandbox="allow-scripts allow-same-origin"?
  846. # [21:14] <Hixie_> that's generally a foot gun, but ok
  847. # [21:14] <Hixie_> i guess if you're loading a cross-origin file you're probably ok
  848. # [21:14] <bkardell__> hmm
  849. # [21:15] <bkardell__> just checked to make sure I didn't lie with all of the changes I made trying to figure this out
  850. # [21:15] <bkardell__> indeed, this iframe is not even sandboxed!
  851. # [21:15] <Hixie_> if you have allow-scripts allow-same-origin, or if you're not sandboxed at all, i don't see why there'd be a problem
  852. # [21:15] <bkardell__> ok, I will make a way stripped down test case with nothing but that and see if I can illustrate
  853. # [21:16] <Hixie_> if you're not allow-same-origin, then i think it's likely appcache will just fail
  854. # [21:16] <bkardell__> how much have you played with actual implementations of this?
  855. # [21:16] <Hixie_> but i'd have to audit the spec to be sure one way or the other on that
  856. # [21:16] <Hixie_> not... as much as you'd expect
  857. # [21:16] <bkardell__> ;)
  858. # [21:16] <Hixie_> in particular, not the combination of both
  859. # [21:17] <bkardell__> so like, mozilla is currently blocking idb access in all iframes in a diff origin regardless of any of this
  860. # [21:17] <Hixie_> i don't have many uses for sandboxing in my apps, and while appcache would be perfect for my projects, it's something i avoid doing until my apps are done, and, well, my apps are never done
  861. # [21:17] <bkardell__> basically, it works just like being sandboxed without the allow-same-origin in that respect
  862. # [21:17] <Hixie_> that's probably due to third-party cookie blocking
  863. # [21:17] <bkardell__> it is
  864. # [21:18] <bkardell__> but localStorage works..?
  865. # [21:18] <bkardell__> there is a bug, they'll address... it made more sense when they did it, but in retrospect, no
  866. # [21:19] <bkardell__> ok, let me see if I can make a simple stupid test to get to the bottom of this
  867. # [21:19] <bkardell__> I think when you combine these + browsers - there is incompat at the edges
  868. # [21:19] <bkardell__> significant in some cases
  869. # [21:19] <bkardell__> thx
  870. # [21:21] <Hixie_> good luck
  871. # [21:26] * Joins: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net)
  872. # [21:27] * Joins: tndrH (~Rob@cpc4-seac20-2-0-cust858.7-2.cable.virginmedia.com)
  873. # [21:27] * Quits: moo-_- (miohtama@lakka.kapsi.fi) (Ping timeout: 260 seconds)
  874. # [21:30] * Joins: moo-_- (miohtama@lakka.kapsi.fi)
  875. # [21:33] * Joins: frozenice (~frozenice@unaffiliated/fr0zenice)
  876. # [21:34] * Quits: frozenice (~frozenice@unaffiliated/fr0zenice) (Read error: Connection reset by peer)
  877. # [21:34] * Joins: zcorpan (~zcorpan@128.127.18.179)
  878. # [21:40] * Krinkle is now known as Krinkle|detached
  879. # [21:46] * Joins: krawchyk_ (~krawchyk@65.220.49.251)
  880. # [21:48] * Quits: krawchyk_ (~krawchyk@65.220.49.251) (Remote host closed the connection)
  881. # [21:49] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  882. # [21:50] * Quits: brion (~brion@wikipedia/pdpc.professional.brion) (Quit: brion)
  883. # [21:51] * Quits: krawchyk (~krawchyk@65.220.49.251) (Ping timeout: 276 seconds)
  884. # [21:53] * Quits: myakura_ (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp) (Remote host closed the connection)
  885. # [21:54] * Joins: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp)
  886. # [21:55] * Joins: lmcliste_ (~lmclister@192.150.10.209)
  887. # [21:58] * Quits: myakura (~myakura@FL1-125-197-193-40.tky.mesh.ad.jp) (Ping timeout: 260 seconds)
  888. # [22:01] * Quits: Adawerk_ (~ada@169.241.49.57) (Quit: Leaving)
  889. # [22:02] * Quits: lmcliste_ (~lmclister@192.150.10.209) (Ping timeout: 260 seconds)
  890. # [22:04] * Joins: Adawerk (~ada@169.241.49.57)
  891. # [22:07] * Joins: rniwa (~rniwa@17.212.154.114)
  892. # [22:07] * Joins: WeirdAl (~chatzilla@g2spf.ask.info)
  893. # [22:08] * jonlee|afk is now known as jonlee
  894. # [22:10] * Quits: Adawerk (~ada@169.241.49.57) (Quit: Leaving)
  895. # [22:11] * Joins: Maurice (copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
  896. # [22:16] <zcorpan> TabAtkins: i've been confused about the order argument because as far as i recall the discussion in both email and f2f was like "the set is unordered, this doesn't work for margin-start." "the set is ordered already." "yes." "..."
  897. # [22:17] <TabAtkins> I see why you're confused. The underlying declaration block is ordered, yes. The API exposed by gCS's return value, though, looks unordered.
  898. # [22:17] <TabAtkins> Since it's just an object map, iterated in alphabetical order.
  899. # [22:17] <zcorpan> the return value of getComputedStyle is not relevant since it's readonly so setProperty throws
  900. # [22:18] <TabAtkins> Sure, but the same is true of el.style.
  901. # [22:18] <zcorpan> no
  902. # [22:19] <zcorpan> el.style uses what cssom calls 'specified order', and setProperty either appends a new declaration to the end or updates a declaration's value without moving it in the list
  903. # [22:20] * jonlee is now known as jonlee|afk
  904. # [22:20] <TabAtkins> You can only observe that by iteration, though.
  905. # [22:20] <TabAtkins> That's a very weak form of ordering.
  906. # [22:20] * Quits: reyre (~reyre@142.204.133.18) (Remote host closed the connection)
  907. # [22:20] <TabAtkins> The normal interaction mode with it is as an object map, which is effectively unordered.
  908. # [22:21] * Joins: sgalineau (~sylvaing@bdv75-4-82-227-67-59.fbx.proxad.net)
  909. # [22:21] <zcorpan> yes? i'm still confused
  910. # [22:22] <zcorpan> does setProperty need to move an existing declaration to the end, or not? and why?
  911. # [22:25] <TabAtkins> My point is just that things like Arrays are strongly, observably ordered. Maps are weakly ordered at best, with the order only observable through iteration.
  912. # [22:25] <zcorpan> ok
  913. # [22:25] <TabAtkins> Basing semantics on a strongly-ordered set when it's usually exposed as a weakly-ordered thing isn't a great idea. That's why I still don't really like the resolution from the f2f, but I got something usable (setPropertyValue), so I can accept it.
  914. # [22:26] <TabAtkins> So to answer your question, I dunno.
  915. # [22:27] <zcorpan> k
  916. # [22:29] <Hixie_> bummer, i paged the parser out already and now i don't understand why we have "template" end tag entries everywhere
  917. # [22:29] <Hixie_> and why "template"'s end tag is handled in "in head" and not in "in template".
  918. # [22:29] * Joins: krit (~krit@86.215-31-46.rdns.acropolistelecom.net)
  919. # [22:33] * Quits: drollwit (~drollwit@c-67-183-156-240.hsd1.wa.comcast.net) (Remote host closed the connection)
  920. # [22:34] * heycam|away is now known as heycam
  921. # [22:35] * Quits: cheron (~cheron@unaffiliated/cheron) (Ping timeout: 276 seconds)
  922. # [22:37] * Joins: lmcliste_ (~lmclister@192.150.10.209)
  923. # [22:40] * Quits: bradleymeck (~bradley.m@216-166-20-1.fwd.datafoundry.com) (Quit: bradleymeck)
  924. # [22:42] * Joins: reyre (~reyre@out-on-231.wireless.telus.com)
  925. # [22:50] * Quits: sgalineau (~sylvaing@bdv75-4-82-227-67-59.fbx.proxad.net) (Quit: Textual IRC Client: www.textualapp.com)
  926. # [22:51] <krit> Hixie_: [CORS] says it references Cross-origin Resource Sharing but references Anne's fetch spec. The fetch spec does not describe terms like "omit credentials flag" as noted in http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#omit-credentials-flag (just as one example)
  927. # [22:51] * Joins: newtron (~newtron@199.71.174.103)
  928. # [22:51] <Hixie_> odd
  929. # [22:51] <Hixie_> why would anne drop the term
  930. # [22:52] <Hixie_> oh i don't use it anyway
  931. # [22:52] <Hixie_> any other examples?
  932. # [22:52] <Hixie_> looks like all those terms aren't used
  933. # [22:52] <Hixie_> wait wait wait
  934. # [22:52] <Hixie_> i was looking at a subset of the spec
  935. # [22:53] <Hixie_> duh
  936. # [22:53] * Quits: WeirdAl (~chatzilla@g2spf.ask.info) (Ping timeout: 245 seconds)
  937. # [22:53] * Hixie_ tries again
  938. # [22:53] <krit> Hixie_: hm, looks like the names are just slighlt off. cmd+f searched for the whole term
  939. # [22:53] <Hixie_> oh i'm guessing this is all gonna change once we reference his Fetch algorithm instead of defining our own
  940. # [22:53] * bkardell__ is happy hixie made a similar mistake just now to the one he made earlier
  941. # [22:54] <Hixie_> hehe
  942. # [22:54] <Hixie_> krit: the plan is to completely revamp how HTML does fetch once anne's spec is ready to take over
  943. # [22:54] <Hixie_> krit: so i'm ignoring this problem for now
  944. # [22:54] <krit> :)
  945. # [22:55] <krit> Hixie_: Question to SVG image fetching. SVG images can have resources them self (like references to other images)
  946. # [22:55] <Hixie_> TabAtkins: ping https://www.w3.org/Bugs/Public/show_bug.cgi?id=22118
  947. # [22:55] <krit> Hixie_: is there a defined restriction?
  948. # [22:56] <Hixie_> krit: i don't understand the question
  949. # [22:56] <krit> <img src="image.svg"> -> <svg><image xlink:href="image2.svg"/></svg>
  950. # [22:57] <krit> Hixie_: is image.svg allowed to fetch image2.svg?
  951. # [22:58] <Hixie_> that seems like an SVG question?
  952. # [22:58] <krit> Hixie_: or the following <img src="image.svg"> -> <svg><foreignObject><iframe src="index.html"/></foreignObject></svg>
  953. # [22:58] <Hixie_> i think <img> stops scripts in SVG, but that's all
  954. # [22:58] <Hixie_> check the spec
  955. # [22:58] <krit> Hixie_: I know that it is not specified in SVG :)
  956. # [22:59] <krit> Hixie_: but sounds like it wouldn't be anywhere else
  957. # [23:00] <Hixie_> check HTML's <img> section
  958. # [23:00] * Joins: WeirdAl (~chatzilla@g2spf.ask.info)
  959. # [23:02] * Quits: dbaron (~dbaron@89.202.203.51) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  960. # [23:03] * Quits: tlr (~roessler@88.207.142.77) (Quit: Lost terminal)
  961. # [23:05] <krit> Hixie_: "the img element's crossorigin attribute's mode, and, if that mode is not http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#attr-crossorigin-none" but I can not find the initial value of 'crossorigin' attribute. Just the defintion for this attribute
  962. # [23:05] <Hixie_> "initial value"?
  963. # [23:06] <krit> well, if it is not set, I assume it is No CORS, right?
  964. # [23:06] * encryptd_fractal is now known as jztn
  965. # [23:06] <krit> Hixie_: the algorithm for resolving states that it needs to identify an image by a topple
  966. # [23:06] <Hixie_> don't assume :-)
  967. # [23:07] <krit> Hixie_: and one part of the toople is the value of crossorigin attribtue
  968. # [23:07] <Hixie_> "The crossorigin attribute is a CORS settings attribute." => http://www.whatwg.org/specs/web-apps/current-work/#cors-settings-attribute
  969. # [23:07] * jztn is now known as Rusty_Elm
  970. # [23:07] * Quits: reyre (~reyre@out-on-231.wireless.telus.com) (Remote host closed the connection)
  971. # [23:07] <Hixie_> "A CORS settings attribute is an enumerated attribute." => http://www.whatwg.org/specs/web-apps/current-work/#enumerated-attribute
  972. # [23:08] <krit> Hixie_: ok, thanks
  973. # [23:08] <Hixie_> "When the attribute is not specified, if there is a missing value default state defined, then that is the state represented by the (missing) attribute."
  974. # [23:08] <Hixie_> then back to CORS setting attribute: "The missing value default, used when the attribute is omitted, is the No CORS state."
  975. # [23:08] * Rusty_Elm is now known as camsnap
  976. # [23:09] * camsnap is now known as BadgerFanatic
  977. # [23:10] * BadgerFanatic is now known as dece
  978. # [23:13] * jonlee|afk is now known as jonlee
  979. # [23:20] * Quits: newtron (~newtron@199.71.174.103) (Ping timeout: 276 seconds)
  980. # [23:20] <krit> Hixie_: yes, it is defined. Couldn't find it on the first try. But didn't see that there is another link to "CORS settings attribute"
  981. # [23:33] * Joins: Spedax (~spedax@5.149.138.2)
  982. # [23:34] <zcorpan> krit: crossorigin="" seems unrelated to the question you asked
  983. # [23:34] * Quits: Maurice (copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
  984. # [23:35] <krit> zcorpan: to the SVG example? yes. But I was trying to understand the algorithm for fetching. And this was a requirement.
  985. # [23:35] <zcorpan> ah, ok
  986. # [23:36] <zcorpan> i think the svg spec should define what the behavior should be when loaded via <img> or css background-image and similar
  987. # [23:37] * Quits: Spedax (~spedax@5.149.138.2) (Ping timeout: 246 seconds)
  988. # [23:37] <krit> zcorpan: I do not disagree. I wanted to check what already is defined and what isn't.
  989. # [23:38] * Joins: jreading (~Adium@ip98-169-193-48.dc.dc.cox.net)
  990. # [23:43] * heycam is now known as heycam|away
  991. # [23:44] * Quits: lmcliste_ (~lmclister@192.150.10.209)
  992. # [23:46] * Quits: TallTed (~Thud@31-34-45.wireless.csail.mit.edu)
  993. # [23:46] * Quits: jreading (~Adium@ip98-169-193-48.dc.dc.cox.net) (Quit: Leaving.)
  994. # [23:47] <jamesr_`> Hixie_: when does invoking the parser spin the event loop?
  995. # [23:51] * Joins: jreading (~Adium@ip98-169-193-48.dc.dc.cox.net)
  996. # Session Close: Fri Sep 13 00:00:00 2013

The end :)