/irc-logs / freenode / #whatwg / 2014-11-19 / end

Options:

Previous day, Next day

  1. # Session Start: Wed Nov 19 00:00:00 2014
  2. # Session Ident: #whatwg
  3. # [00:00] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 255 seconds)
  4. # [00:00] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
  5. # [00:03] * Quits: Una (~Una@107-194-77-68.lightspeed.austtx.sbcglobal.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
  6. # [00:03] * Quits: jsx (uid48919@fsf/intern/jsx) (Quit: Connection closed for inactivity)
  7. # [00:03] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
  8. # [00:04] * Joins: roc (~chatzilla@203.192.141.163)
  9. # [00:06] * Joins: Una (~Una@107-194-77-68.lightspeed.austtx.sbcglobal.net)
  10. # [00:07] * Quits: eric_carlson (~ericc@17.202.49.94) (Quit: eric_carlson)
  11. # [00:08] * Joins: newtron (~newtron@184.175.3.104)
  12. # [00:10] <Hixie> (and so friendly to copy-paste across whitespace-ignoring environments like HTML)
  13. # [00:12] * Joins: karlcow (~karl@nerval.la-grange.net)
  14. # [00:18] * Quits: abinader (sid21713@gateway/web/irccloud.com/x-dgzkxvktlgebipjc)
  15. # [00:19] * Joins: estellevw (~estellevw@86.Red-80-24-11.staticIP.rima-tde.net)
  16. # [00:20] * Joins: eric_carlson (~ericc@17.245.27.39)
  17. # [00:21] * Quits: eric_carlson (~ericc@17.245.27.39) (Client Quit)
  18. # [00:23] * Quits: jsbell (jsbell@nat/google/x-eacwtfdoyezfbqmt) (Quit: There's no place like home...)
  19. # [00:26] * Joins: woebtz (~woebtz@cpe-172-250-93-102.socal.res.rr.com)
  20. # [00:27] * Quits: Mso150 (~ctlM@80.83.238.51) (Remote host closed the connection)
  21. # [00:27] * Joins: Mso150 (~ctlM@80.83.238.51)
  22. # [00:32] * Joins: tantek (~tantek@209.129.91.3)
  23. # [00:41] * Joins: Mso150_g (~ctlM@80.83.239.36)
  24. # [00:42] * Quits: Mso150 (~ctlM@80.83.238.51) (Ping timeout: 240 seconds)
  25. # [00:42] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
  26. # [00:43] <TabAtkins> Hixie: Luckily, don't care! That's what <pre> is for. ^_^
  27. # [00:43] <TabAtkins> Or <plaintext> ^_^
  28. # [00:46] * Quits: newtron (~newtron@184.175.3.104) (Remote host closed the connection)
  29. # [00:49] * Quits: rubys (~rubys@cpe-098-027-051-253.nc.res.rr.com) (Ping timeout: 250 seconds)
  30. # [00:49] * Quits: tantek (~tantek@209.129.91.3) (Quit: tantek)
  31. # [00:50] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
  32. # [00:51] * Joins: weinig (~weinig@17.245.26.114)
  33. # [00:52] * Joins: jdaggett (~jdaggett@61-121-216-2.bitcat.net)
  34. # [00:53] * Joins: newtron (~newtron@184.175.3.104)
  35. # [00:53] * Quits: newtron (~newtron@184.175.3.104) (Remote host closed the connection)
  36. # [00:58] * Quits: weinig (~weinig@17.245.26.114) (Quit: weinig)
  37. # [00:59] * Quits: darobin (~darobin@2a01:e34:ed05:d180:e400:f5c2:e938:ce43) (Remote host closed the connection)
  38. # [00:59] * Joins: tantek (~tantek@209.129.91.3)
  39. # [01:02] * Quits: espadrine (~espadrine@dan75-7-88-166-187-54.fbx.proxad.net) (Quit: espadrine)
  40. # [01:03] <hober> <xmp> 4evah
  41. # [01:03] * Quits: Mso150_g (~ctlM@80.83.239.36) (Ping timeout: 240 seconds)
  42. # [01:04] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
  43. # [01:07] <caitp> "Blending of HTML and SVG elements" << is that part of what you were saying before about moving svg into the html namespace?
  44. # [01:08] <pdr> caitp, no, this is about blend modes
  45. # [01:08] <caitp> mm
  46. # [01:08] <caitp> if google groups notifications would link to the actual thread it would be easier to read the whole thing :>
  47. # [01:09] <pdr> caitp, https://groups.google.com/a/chromium.org/d/msg/blink-dev/WoLwgoPB-GE/KqAftxiogKMJ
  48. # [01:09] <pdr> caitp, agreed, google groups... ( ._.)
  49. # [01:09] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Ping timeout: 272 seconds)
  50. # [01:10] <caitp> so it's basically a feature, that's cool
  51. # [01:16] * Joins: plutoniix (~plutoniix@210.213.57.70)
  52. # [01:19] * Quits: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net) (Ping timeout: 245 seconds)
  53. # [01:19] * heycam is now known as heycam|away
  54. # [01:23] * Quits: bnicholson (~bnicholso@corp.mtv2.mozilla.com) (Quit: Leaving)
  55. # [01:24] * Joins: espadrine (~espadrine@dan75-7-88-166-187-54.fbx.proxad.net)
  56. # [01:24] * Joins: I (~bnicholso@corp.mtv2.mozilla.com)
  57. # [01:24] * Quits: I (~bnicholso@corp.mtv2.mozilla.com) (Client Quit)
  58. # [01:25] * Quits: espadrine_ (~ttyl@2a01:e35:8a6b:b360:59df:9212:6315:cfff) (Ping timeout: 272 seconds)
  59. # [01:30] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Read error: Connection reset by peer)
  60. # [01:30] * Joins: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  61. # [01:34] * Quits: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 255 seconds)
  62. # [01:35] * Joins: I (~bnicholso@corp.mtv2.mozilla.com)
  63. # [01:36] * I is now known as Guest16407
  64. # [01:36] * Quits: TuRnaD0 (~Thunderbi@x1-6-e0-46-9a-1e-fe-ca.cpe.webspeed.dk) (Remote host closed the connection)
  65. # [01:41] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
  66. # [01:53] * Joins: webtroll (~webtroll@96.24.28.144)
  67. # [01:56] * Quits: estellevw (~estellevw@86.Red-80-24-11.staticIP.rima-tde.net) (Quit: Snuggling with the puppies)
  68. # [01:56] * Quits: igoroliveira (uid20755@gateway/web/irccloud.com/x-hfbckobkskzajrkb) (Quit: Connection closed for inactivity)
  69. # [02:00] * Joins: pfefferle (~pfefferle@x2f57866.dyn.telefonica.de)
  70. # [02:02] * Joins: estellevw (~estellevw@86.Red-80-24-11.staticIP.rima-tde.net)
  71. # [02:03] * Joins: eric_carlson (~ericc@24.6.239.9)
  72. # [02:04] * Joins: newtron (~newtron@184.175.3.104)
  73. # [02:05] * Quits: ap (~ap@17.202.44.214)
  74. # [02:06] * Joins: jungkees (uid24208@gateway/web/irccloud.com/x-swjhadjcwscivfdo)
  75. # [02:08] * Quits: newtron (~newtron@184.175.3.104) (Ping timeout: 255 seconds)
  76. # [02:09] * Joins: jernoble (~jernoble@76.74.153.49)
  77. # [02:15] * Quits: pfefferle (~pfefferle@x2f57866.dyn.telefonica.de) (Quit: pfefferle)
  78. # [02:18] * Quits: jwalden (~waldo@2620:101:80fb:224:7e7a:91ff:fe25:a5a3) (Quit: back tomorrow)
  79. # [02:20] * Quits: jernoble (~jernoble@76.74.153.49) (Ping timeout: 256 seconds)
  80. # [02:23] * Joins: JosephSilber (~JosephSil@ool-44c3e80a.static.optonline.net)
  81. # [02:23] <MikeSmith> Hixie: CSSOM added now (and CSSOM Views)
  82. # [02:24] <JonathanNeal> A few of us are starting work on Element Queries. Your thoughts, concerns, questions, and feedback are most desired. https://github.com/ResponsiveImagesCG/eq-demos
  83. # [02:25] * Joins: jernoble (~jernoble@166.170.37.219)
  84. # [02:25] * Quits: jernoble (~jernoble@166.170.37.219) (Read error: Connection reset by peer)
  85. # [02:28] <Una> hey JonathanNeal can you give me a use case? I'm trying to understand better
  86. # [02:28] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
  87. # [02:29] * Joins: say2joe (~Adium@198-101-119-98.static-ip.telepacific.net)
  88. # [02:31] * Joins: jernoble (~jernoble@76.74.153.49)
  89. # [02:32] <JonathanNeal> Una: yes. You have a widget running in a web page that you do not control. The widget may be in a narrow column or a wide column. When the column is narrow, even though the screen is large, things go poorly for the widget.
  90. # [02:32] * Quits: tantek (~tantek@209.129.91.3) (Quit: tantek)
  91. # [02:33] <JonathanNeal> Una: there is also an effort in progress to formalize use cases @ http://responsiveimagescg.github.io/eq-usecases/
  92. # [02:33] <Una> JonathanNeal but if you don't control the widget, how are you going to style it with element queries?
  93. # [02:33] <JonathanNeal> The widget deploys its own HTML and CSS, but does not control where it lives on the page.
  94. # [02:34] <JonathanNeal> The admin who controls the page has the power to “deploy the widget here”, here being any kind of column.
  95. # [02:35] <JonathanNeal> This is the same need we have in media queries, but in context of the layout vs in context of the screen size.
  96. # [02:37] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
  97. # [02:40] * Quits: Garbee (uid21171@gateway/web/irccloud.com/x-lqdsjiwijqjunxzv) (Quit: Connection closed for inactivity)
  98. # [02:46] * Quits: jernoble (~jernoble@76.74.153.49) (Quit: Computer has gone to sleep.)
  99. # [02:46] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
  100. # [02:47] * Quits: Una (~Una@107-194-77-68.lightspeed.austtx.sbcglobal.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
  101. # [02:51] * Quits: lerc (~quassel@121-74-5-229.telstraclear.net) (Ping timeout: 258 seconds)
  102. # [02:56] * Quits: espadrine (~espadrine@dan75-7-88-166-187-54.fbx.proxad.net) (Quit: espadrine)
  103. # [02:58] <JonathanNeal> For Element Queries, I think the simpliest use case is: “I have a widget that needs to look good in any column of our layout, whether that column is small, medium, or large.”
  104. # [02:59] * Quits: Guest16407 (~bnicholso@corp.mtv2.mozilla.com) (Quit: This computer has gone to sleep)
  105. # [03:01] * Quits: mko (~mko@50.240.205.146) (Ping timeout: 255 seconds)
  106. # [03:02] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
  107. # [03:06] <Hixie> MikeSmith: cool, thanks
  108. # [03:14] * Joins: Guest16407 (~bnicholso@24.130.60.241)
  109. # [03:15] * Quits: jyasskin (jyasskin@nat/google/x-kxnzlrabxvhddhfv) (Quit: My computer has gone to sleep. ZZZzzz…)
  110. # [03:27] * Joins: yhirano (uid40668@gateway/web/irccloud.com/x-tlswhixndhxvuyth)
  111. # [03:32] * Joins: dwim (~dwim@210.94.41.89)
  112. # [03:33] * Quits: ambv (~ambv@206.108.217.134) (Quit: sys.exit(0) # app closed)
  113. # [03:47] * Quits: dbaron (~dbaron@2620:101:80fb:224:8936:dce1:3e16:a80a) (Ping timeout: 258 seconds)
  114. # [03:47] * Quits: say2joe (~Adium@198-101-119-98.static-ip.telepacific.net) (Quit: Leaving.)
  115. # [03:50] * Quits: webtroll (~webtroll@96.24.28.144) (Remote host closed the connection)
  116. # [03:50] * Joins: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
  117. # [03:51] * Joins: Goplat (~goplat@reactos/developer/Goplat)
  118. # [03:57] * Joins: rubys (~rubys@cpe-098-027-051-253.nc.res.rr.com)
  119. # [04:03] * Joins: estellevw_ (~estellevw@86.Red-80-24-11.staticIP.rima-tde.net)
  120. # [04:06] * Quits: estellevw (~estellevw@86.Red-80-24-11.staticIP.rima-tde.net) (Ping timeout: 264 seconds)
  121. # [04:06] * estellevw_ is now known as estellevw
  122. # [04:20] * heycam|away is now known as heycam
  123. # [04:25] * Joins: weinig (~weinig@98.234.191.242)
  124. # [04:25] * Quits: weinig (~weinig@98.234.191.242) (Client Quit)
  125. # [04:36] * Joins: Mso150 (~ctlM@80.83.239.72)
  126. # [04:41] * Quits: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
  127. # [04:49] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
  128. # [04:50] * Krinkle is now known as Krinkle|detached
  129. # [05:00] * Quits: rubys (~rubys@cpe-098-027-051-253.nc.res.rr.com) (Ping timeout: 250 seconds)
  130. # [05:02] * Quits: rektide_ (~rektide@eldergods.com) (Ping timeout: 240 seconds)
  131. # [05:02] * Quits: rektide (~rektide@eldergods.com) (Ping timeout: 245 seconds)
  132. # [05:08] * Joins: jamesheston (~jameshest@108-230-76-57.lightspeed.chtnsc.sbcglobal.net)
  133. # [05:10] * Joins: rektide_ (~rektide@eldergods.com)
  134. # [05:10] * Joins: rektide (~rektide@eldergods.com)
  135. # [05:10] * Joins: nephyrin (~neph@nemu.pointysoftware.net)
  136. # [05:13] * Quits: jochen__ (jochen@nat/google/x-iblvefwpfmmtxlbm) (Ping timeout: 255 seconds)
  137. # [05:13] * Joins: jochen__ (jochen@nat/google/x-okksvymufqffzlkj)
  138. # [05:16] * Quits: Mso150 (~ctlM@80.83.239.72) (Ping timeout: 264 seconds)
  139. # [05:17] * Joins: enaqx (~enaqx@user-206.98.infomir.com.ua)
  140. # [05:23] <jamesr_> JonathanNeal: how do you avoid creating cycles?
  141. # [05:25] * Joins: haydogsup (~haydogsup@24-155-228-156.dyn.grandenetworks.net)
  142. # [05:30] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: Textual IRC Client: www.textualapp.com)
  143. # [06:09] * Quits: CvP (~CvP@203.76.123.238) (Read error: Connection reset by peer)
  144. # [06:09] * Joins: CvP (~CvP@203.76.123.238)
  145. # [06:14] * Quits: eric_carlson (~ericc@24.6.239.9) (Quit: eric_carlson)
  146. # [06:24] * Quits: haydogsup (~haydogsup@24-155-228-156.dyn.grandenetworks.net) (Quit: haydogsup)
  147. # [06:25] * Quits: woebtz (~woebtz@cpe-172-250-93-102.socal.res.rr.com)
  148. # [06:27] * Joins: Una (~Una@cpe-70-117-78-235.austin.res.rr.com)
  149. # [06:28] * Joins: BigBangUDR (~Thunderbi@103.249.181.147)
  150. # [06:32] * Quits: nephyrin (~neph@nemu.pointysoftware.net) (Read error: Connection reset by peer)
  151. # [06:33] * Joins: nephyrin (~neph@nemu.pointysoftware.net)
  152. # [06:35] * Quits: nephyrin (~neph@nemu.pointysoftware.net) (Read error: Connection reset by peer)
  153. # [06:35] * Joins: nephyrin (~neph@nemu.pointysoftware.net)
  154. # [06:36] * Joins: haydogsup (~haydogsup@24-155-228-156.dyn.grandenetworks.net)
  155. # [06:41] * Quits: tav (~tav`@host86-185-186-215.range86-185.btcentralplus.com) (Quit: tav)
  156. # [06:44] * Quits: CvP (~CvP@203.76.123.238) (Read error: Connection reset by peer)
  157. # [06:44] * Joins: CvP (~CvP@203.76.123.238)
  158. # [06:51] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
  159. # [06:52] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Read error: Connection reset by peer)
  160. # [06:52] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
  161. # [06:54] * Joins: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net)
  162. # [06:56] * Quits: haydogsup (~haydogsup@24-155-228-156.dyn.grandenetworks.net) (Quit: haydogsup)
  163. # [06:57] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Ping timeout: 256 seconds)
  164. # [06:58] * Joins: lerc (~quassel@121-74-5-229.telstraclear.net)
  165. # [07:01] * Quits: roc (~chatzilla@203.192.141.163) (Remote host closed the connection)
  166. # [07:14] * Quits: jamesheston (~jameshest@108-230-76-57.lightspeed.chtnsc.sbcglobal.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
  167. # [07:18] * Quits: Una (~Una@cpe-70-117-78-235.austin.res.rr.com) (Quit: My Mac has gone to sleep. ZZZzzz…)
  168. # [07:45] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  169. # [07:48] * Joins: jamesheston (~jameshest@108-230-76-57.lightspeed.chtnsc.sbcglobal.net)
  170. # [07:52] * Joins: zdobersek (~zan@46.166.188.198)
  171. # [07:55] * Quits: bengl (~bengl@2001:4c48:2:8400:2197:a078:580a:4d16) (Ping timeout: 244 seconds)
  172. # [08:01] * Quits: Bass10_ (Bass10@c-73-37-130-61.hsd1.mn.comcast.net) (Ping timeout: 245 seconds)
  173. # [08:07] * Quits: rniwa (~rniwa@17.202.43.222) (Quit: rniwa)
  174. # [08:07] * Joins: bengl (~bengl@2001:4c48:2:8400:795e:295b:25c5:9c85)
  175. # [08:07] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
  176. # [08:09] * Joins: rniwa (~rniwa@17.202.43.222)
  177. # [08:11] <jamesheston> Can anyone recommend any alternatives to Filezilla for OSX? Want to try something different.
  178. # [08:14] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
  179. # [08:26] * Joins: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
  180. # [08:28] * heycam is now known as heycam|away
  181. # [08:29] * Quits: hsivonen (~hsivonen@bugzilla.validator.nu) (Remote host closed the connection)
  182. # [08:34] * Joins: espadrine (~espadrine@dan75-7-88-166-187-54.fbx.proxad.net)
  183. # [08:36] * Joins: espadrine_ (~ttyl@2a01:e35:8a6b:b360:59df:9212:6315:cfff)
  184. # [08:42] * Joins: cbr_ (~cbr@145.36.150.83.chzhher77.rootnet.ch)
  185. # [08:46] * Joins: annevk (~annevk@213.55.184.186)
  186. # [08:47] * Joins: roc (~chatzilla@121-99-82-169.bng1.tvc.orcon.net.nz)
  187. # [08:49] * Quits: estellevw (~estellevw@86.Red-80-24-11.staticIP.rima-tde.net) (Quit: estellevw)
  188. # [08:49] * Quits: jdaggett (~jdaggett@61-121-216-2.bitcat.net) (Quit: jdaggett)
  189. # [08:49] * Joins: jdaggett (~jdaggett@61-121-216-2.bitcat.net)
  190. # [08:51] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
  191. # [08:52] * Joins: dbaron (~dbaron@50-0-248-60.dsl.dynamic.fusionbroadband.com)
  192. # [09:01] * Joins: hsivonen (~hsivonen@fsf/member/hsivonen)
  193. # [09:02] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 258 seconds)
  194. # [09:02] <zcorpan> TabAtkins: is bikeshed responsible for this URL? https://github.com/whatwg/url/blob/bd3f0ce38f61db5cfa2c485fef7aec2e4bdb0182/url.html#L26
  195. # [09:06] <annevk> Hixie: https://github.com/whatwg/platform.html5.org/pull/7
  196. # [09:23] * Joins: Mso150 (~ctlM@80.83.238.77)
  197. # [09:28] * Joins: tripu (~tripu@ANice-653-1-470-156.w86-203.abo.wanadoo.fr)
  198. # [09:36] * Quits: espadrine (~espadrine@dan75-7-88-166-187-54.fbx.proxad.net) (Quit: espadrine)
  199. # [09:36] * Quits: jdaggett (~jdaggett@61-121-216-2.bitcat.net) (Ping timeout: 250 seconds)
  200. # [09:38] * Joins: pfefferle (~pfefferle@213.144.11.136)
  201. # [09:48] * Quits: dbaron (~dbaron@50-0-248-60.dsl.dynamic.fusionbroadband.com) (Ping timeout: 265 seconds)
  202. # [09:52] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  203. # [09:52] * Quits: annevk (~annevk@213.55.184.186) (Read error: Connection reset by peer)
  204. # [09:55] * Quits: zdobersek (~zan@46.166.188.198) (Ping timeout: 255 seconds)
  205. # [09:58] * Joins: calvaris (~calvaris@fanzine.igalia.com)
  206. # [10:00] * Livadaw is now known as Livadi
  207. # [10:00] * Joins: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si)
  208. # [10:00] * Quits: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si) (Client Quit)
  209. # [10:01] * Joins: laurensclaessen (~laurenscl@91.183.84.141)
  210. # [10:01] * Joins: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si)
  211. # [10:02] * Joins: pfefferle_ (~pfefferle@p5B02D2A5.dip0.t-ipconnect.de)
  212. # [10:03] * Quits: pfefferle (~pfefferle@213.144.11.136) (Ping timeout: 272 seconds)
  213. # [10:03] * pfefferle_ is now known as pfefferle
  214. # [10:07] * Quits: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Ping timeout: 240 seconds)
  215. # [10:07] * Quits: zdobersek (~zan@cpe-77.38.31.63.cable.t-1.si) (Ping timeout: 245 seconds)
  216. # [10:07] * Joins: annevk (~annevk@213.55.184.186)
  217. # [10:08] * Quits: laurensclaessen (~laurenscl@91.183.84.141)
  218. # [10:10] * Quits: espadrine_ (~ttyl@2a01:e35:8a6b:b360:59df:9212:6315:cfff) (Ping timeout: 258 seconds)
  219. # [10:12] * Quits: annevk (~annevk@213.55.184.186) (Read error: Connection reset by peer)
  220. # [10:13] * Quits: rniwa (~rniwa@17.202.43.222) (Quit: rniwa)
  221. # [10:26] * Joins: WesleyCrushed (~WesleyCru@host54-94-dynamic.59-82-r.retail.telecomitalia.it)
  222. # [10:26] * Joins: Lachy (~Lachy@213.166.174.2)
  223. # [10:27] * Quits: WesleyCrushed_ (~WesleyCru@host249-94-dynamic.59-82-r.retail.telecomitalia.it) (Read error: Connection reset by peer)
  224. # [10:33] * Quits: Mso150 (~ctlM@80.83.238.77) (Read error: Connection reset by peer)
  225. # [10:38] * Joins: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
  226. # [10:38] * Joins: rubys1 (~rubys@cpe-098-027-051-253.nc.res.rr.com)
  227. # [10:39] * Quits: CvP (~CvP@203.76.123.238) (Read error: Connection reset by peer)
  228. # [10:39] * Joins: CvP (~CvP@203.76.123.238)
  229. # [10:42] * Joins: aleray (~aleray@2a02:a03f:14b6:800:227:10ff:febc:7038)
  230. # [10:44] * Joins: annevk (~annevk@213.55.184.186)
  231. # [10:47] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
  232. # [10:58] * Joins: espadrine_ (~ttyl@LMontsouris-656-1-02-84.w80-12.abo.wanadoo.fr)
  233. # [11:02] * Joins: charl (~charl@524A9047.cm-4-3c.dynamic.ziggo.nl)
  234. # [11:17] * Joins: darobin (~darobin@78.109.80.74)
  235. # [11:18] <annevk> rubys1: "If the @ flag is set, parse error, prepend "%40" to buffer." does not cause reordering...
  236. # [11:19] * rubys1 is now known as rubys
  237. # [11:20] <rubys> annevk: can you explain? If buffer has characters, and you put another character in front of those characters, doesn't that re-order?
  238. # [11:20] * Quits: tripu (~tripu@ANice-653-1-470-156.w86-203.abo.wanadoo.fr) (Ping timeout: 264 seconds)
  239. # [11:20] <annevk> rubys: it only puts it in front if the flag was set, meaning it has to be in front
  240. # [11:21] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  241. # [11:21] <rubys> https://url.spec.whatwg.org/#authority-state
  242. # [11:22] <rubys> step 1.1; prepend. step 1.2, sets the flag. Next time through the loop, the flag is still set?
  243. # [11:22] * Joins: tripu (~tripu@ANice-653-1-470-156.w86-203.abo.wanadoo.fr)
  244. # [11:23] <rubys> by the way, testing with chrome and firefox shows that re-ordering does occur.
  245. # [11:25] <rubys> (it also shows that browsers don't implement this interoperably)
  246. # [11:25] * Quits: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net) (Quit: sicking)
  247. # [11:29] <annevk> hmm, yeah, there's a bug there, I can't reproduce reordering in Firefox
  248. # [11:30] <rubys> ah, cool!. I'll change mine to simply string.replace('@', '%40')
  249. # [11:30] * Quits: jamesheston (~jameshest@108-230-76-57.lightspeed.chtnsc.sbcglobal.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
  250. # [11:30] <rubys> er, /@/g
  251. # [11:30] <annevk> rubys: btw, we say that diagrams are non-normative, yet you want to introduce normative ones...
  252. # [11:31] <annevk> rubys: and that spec is still lacking normative statements, and has some normative statements in notes, doesn't really seem ready
  253. # [11:31] <rubys> ack
  254. # [11:31] <rubys> I still have that on the todo list. I also don't really understand the comment, so some concrete suggestions would be helpful.
  255. # [11:32] * Quits: BigBangUDR (~Thunderbi@103.249.181.147) (Remote host closed the connection)
  256. # [11:35] * Joins: tav (~tav`@host86-185-186-215.range86-185.btcentralplus.com)
  257. # [11:35] * Joins: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net)
  258. # [11:35] * Quits: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net) (Client Quit)
  259. # [11:36] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
  260. # [11:36] * Joins: cheron (~cheron@unaffiliated/cheron)
  261. # [11:38] <annevk> Also, a concern was raised that these productions are not accessible and that therefore it's hard to treat them as normative
  262. # [11:39] <annevk> s/productions/diagrams/
  263. # [11:39] <annevk> rubys: what is unclear about the comment?
  264. # [11:40] <rubys> valid concern. I can provide BNF-like notation as an alternate. Might need to work with TabAtkins to make that so.
  265. # [11:40] <MikeSmith> yeah seems like the CSS spec has the same issue if so
  266. # [11:40] <MikeSmith> specs
  267. # [11:41] <rubys> First, I don't understand how you have normative statements that say that you MUST do x, and then follow up with a statement that you don't need to do x, you just need to produce the same results as x.
  268. # [11:41] <MikeSmith> or are the railroad diagrams in the CSS specs never normative?
  269. # [11:41] <rubys> in CSS, they are not normative
  270. # [11:41] <MikeSmith> ok
  271. # [11:42] <rubys> MikeSmith: even so, it probably would be good if they were accessible.
  272. # [11:43] <MikeSmith> trueーunless it's clear from the context that they're simply illustrating some normative part of the spec
  273. # [11:44] * Quits: plutoniix (~plutoniix@210.213.57.70) (Quit: จรลี จรลา)
  274. # [11:45] <rubys> MikeSmith: my understanding is that the normative part describes the full grammar (with error correction), and the non-normative diagrams are a simplified form explaining correct usage.
  275. # [11:45] <MikeSmith> ok
  276. # [11:45] <MikeSmith> makes sense
  277. # [11:45] <rubys> In the URL space, the grammar is much smaller
  278. # [11:47] <MikeSmith> sure
  279. # [11:47] * Joins: Lachy (~Lachy@213.166.174.2)
  280. # [11:50] <annevk> rubys: you MUST do x or equivalent and for brevity "or equivalent" is omitted and expanded upon elsewhere; that's pretty normal
  281. # [11:50] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
  282. # [11:51] <rubys> annevk: can you identify a case where a MUST is missing? I work best from examples.
  283. # [11:52] <annevk> rubys: I thought you wanted to do the heavy lifting
  284. # [11:52] <annevk> rubys: if I still have to shift through everything and explain how to write a specification, I'm not sure it's going to be much quicker than just doing it myself
  285. # [11:53] <rubys> I didn't think asking for a single example was asking too much.
  286. # [11:53] <annevk> rubys: well currently the only places the spec uses MUST is in the conformance section and parse exceptions
  287. # [11:53] * Joins: davidyezsetz (~davidyezs@mail1.powerflasher.de)
  288. # [11:54] <annevk> rubys: it seems pretty self-evident that requirements are missing in that case
  289. # [11:55] <annevk> rubys: it's not entirely clear to me currently what the entry point is
  290. # [11:55] <rubys> annevk: ok. It is still on the todo list (as listed in the spec). I fear that I'm playing "fetch me a rock", but I'll try.
  291. # [11:55] <annevk> rubys: I have the same feeling, whenever I point out something that's wrong, I get asked for examples, tests, and demonstrations
  292. # [11:55] * Joins: SkireM (~skirem@static.161.53.4.46.clients.your-server.de)
  293. # [11:56] <MikeSmith> incidentally, looking back at the CSS Syntax spec now, I wonder if I'm the only only who doesn't find it so useful that following a hyperlink for, e.g., "<string-token>" doesn't actually take me to any kind of definition of what a <string-token> isーnot even to an (informative) railroad diagram; instead it takes to me to... I don't know what http://dev.w3.org/csswg/css-syntax/#typedef-string-token And i
  294. # [11:56] <MikeSmith> f I want the actual normative definition of what a <string-token> is, there's nothing directly hyperlinked toーI just have to somehow know I need to read "Consume a string token" http://dev.w3.org/csswg/css-syntax/#consume-string-token
  295. # [11:57] <annevk> MikeSmith: that is pretty confusing
  296. # [11:58] <MikeSmith> annevk: yeah I am recalling now just how confusing I really find it when I was trying to understand the formalism for the "sizes" attribute value (which normatively refers to the CSS specs)
  297. # [11:58] <MikeSmith> *found it
  298. # [12:03] <annevk> rubys: I guess I should also say that I'm not okay with encouraging the W3C to fork whatwg/url
  299. # [12:03] <annevk> rubys: that happening just after I accepted working with you is rather surprising and discomforting, I'm not entirely sure if I want to proceed
  300. # [12:05] <rubys> annevk: two things. (1) I intend to work with everybody and anybody; and (2) I am entirely unimpressed with the lack of response by the webapps (in particular, the webapps chairs).
  301. # [12:06] <rubys> If Mike cares to, he can confirm that I have expressed my displeasure on this matter to all levels of W3C management.
  302. # [12:09] <rubys> regarding the timing, I had published my plan to do exactly what I am doing three weeks ago
  303. # [12:10] <rubys> http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0315.html
  304. # [12:10] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
  305. # [12:11] <rubys> My experience is that when I ask questions in the WHATWG, I get answers. When I ask questions in WebApps, I get... silence.
  306. # [12:11] <MikeSmith> rubys: You may have noticed that I've stayed completely out of that conversation. Also I can imagine that Anne probably couldn't care less about the lack of response from the the webapps chairs or the WG on this because I can imagine he doesn't see what problem needs to be solved here, and he clearly doesn't think the solution is for the webapps WG to publish a copy of the URL spec
  307. # [12:12] <rubys> MikeSmith: ack
  308. # [12:12] <rubys> I do think that's a discussion we ought to have. Meanwhile, I plan to make my work available to everybody who might be interested.
  309. # [12:13] <rubys> My making it available to the WHATWG is not meant to be an exclusive arrangement.
  310. # [12:13] <MikeSmith> rubys: you're making to available to everybody simply by it being published at url.spec.whatwg.org under cc0
  311. # [12:14] <rubys> MikeSmith: actually, I'm making it available to everybody simply by publishing it at intertwingly.net under cc0.
  312. # [12:14] <MikeSmith> that works too
  313. # [12:14] <annevk> rubys: euhm, whatwg/url is not your work
  314. # [12:15] <rubys> I'm going back to working on code. I will arrange to have the proper people in this discussion, including the Director.
  315. # [12:16] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  316. # [12:16] <annevk> rubys: W3C's the Director has not written whatwg/url either
  317. # [12:17] <MikeSmith> rubys: the discussion you seemed to be having here seemed to be a useful one for you and anne to have as co-editors and seems like it could be had separately from any other people or from the W3C Director
  318. # [12:19] * jgraham wonders if MikeSmith has "W3C Director" as an irc keyword ;)
  319. # [12:23] * Quits: annevk (~annevk@213.55.184.186) (Remote host closed the connection)
  320. # [12:23] * Joins: annevk (~annevk@80-218-216-100.dclient.hispeed.ch)
  321. # [12:23] <rubys> annevk: an example of my confusion: I don't see a single "MUST" here: https://url.spec.whatwg.org/#percent-decode
  322. # [12:24] <annevk> rubys: as I said, it depends on the entry point
  323. # [12:26] <rubys> entry point? The only other mention to this is in the index.
  324. # [12:26] <annevk> rubys: that's not true
  325. # [12:26] <annevk> rubys: click on it
  326. # [12:27] <rubys> weird. firefox couldn't find that.
  327. # [12:27] <rubys> ah, "percent decoding"
  328. # [12:27] <rubys> "Let domain be the result of utf-8 decode without BOM on the percent decoding of utf-8 encode on input. "
  329. # [12:27] <rubys> Still no must
  330. # [12:28] <annevk> rubys: still no entry point :-) it's mostly the API that requires things
  331. # [12:28] <annevk> rubys: and other specs that reference these algorithms
  332. # [12:28] * Joins: Lachy (~Lachy@213.166.174.2)
  333. # [12:28] * Quits: davidyezsetz (~davidyezs@mail1.powerflasher.de) (Quit: davidyezsetz)
  334. # [12:28] <rubys> what I have is a spec fragment, rewriting the parsing logic. Logic that doesn't have musts in either the current url standard or in my proposed replacement.
  335. # [12:29] <jgraham> annevk: I can't see any text in url that explicitly says that when you are asked to run an algorithm only black-box indistinguishability matters
  336. # [12:29] <annevk> jgraham: "Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)"
  337. # [12:29] <rubys> jgraham: https://url.spec.whatwg.org/#conformance
  338. # [12:29] * Quits: Lachy (~Lachy@213.166.174.2) (Client Quit)
  339. # [12:30] <jgraham> Oh, that's at the bottom now? How very confusing
  340. # [12:30] <annevk> rubys: it might be okay, though then that lone MUST is confusing
  341. # [12:31] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Quit: Ex-Chat)
  342. # [12:31] <rubys> jgraham: bikeshed templates do that, not sure why.
  343. # [12:31] <annevk> jgraham: blame TabAtkins
  344. # [12:32] <rubys> perhaps we need to add "This specification should be read like all other specifications. First, it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections from the contents list and following all the cross-references."
  345. # [12:32] <jgraham> I guess someone thought that getting to the actual spec without the boilerplate stuff was a good idea. But having the "important stuff you need to know to understand the spec" at the top of the spec rather than at the bottom does seem to make more sense
  346. # [12:34] <jgraham> Or there could be a meta-specification and the top of the spec could just say "this spec must be read according to the WHATWG specification specification"
  347. # [12:34] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
  348. # [12:34] <jgraham> (that is essentially what RFC 2119 is ofc)
  349. # [12:34] <annevk> jgraham: I have at times wanted to write the "Boilerplate Standard" that also includes common terminology
  350. # [12:38] * Quits: tripu (~tripu@ANice-653-1-470-156.w86-203.abo.wanadoo.fr) (Ping timeout: 265 seconds)
  351. # [12:40] <rubys> MikeSmith, annevk: since you are both here, I appear to have update access to web-platform-tests; should I still do pull requests for changes to url/urltestdata.txt?
  352. # [12:40] <jgraham> rubys: Yes, see my message to whatwg
  353. # [12:41] <rubys> jgraham: ok, I can work with that.
  354. # [12:41] <rubys> jgraham: should I do one pull request or three?
  355. # [12:44] * Joins: abinader (sid21713@gateway/web/irccloud.com/x-rliacfmcozzecuth)
  356. # [12:44] * Joins: danbri (Adium@nat/google/x-gilinxmbxlhzhajg)
  357. # [12:47] * Quits: annevk (~annevk@80-218-216-100.dclient.hispeed.ch) (Quit: Leaving...)
  358. # [12:47] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
  359. # [12:48] <jgraham> rubys: That's up to you
  360. # [12:48] * Joins: hasather_ (~hasather@guest.schibsted.no)
  361. # [12:48] * Joins: Lachy (~Lachy@213.166.174.2)
  362. # [12:49] * Joins: davidyezsetz (~davidyezs@mail1.powerflasher.de)
  363. # [12:50] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 250 seconds)
  364. # [12:50] * Joins: calvaris (~calvaris@fanzine.igalia.com)
  365. # [12:51] * Joins: annevk (~annevk@80-218-216-100.dclient.hispeed.ch)
  366. # [12:54] * Joins: pfefferle_ (~pfefferle@213.144.11.130)
  367. # [12:55] * Quits: pfefferle (~pfefferle@p5B02D2A5.dip0.t-ipconnect.de) (Ping timeout: 264 seconds)
  368. # [12:55] * pfefferle_ is now known as pfefferle
  369. # [13:00] * Quits: CvP (~CvP@203.76.123.238) (Read error: Connection reset by peer)
  370. # [13:00] * Joins: CvP (~CvP@203.76.123.238)
  371. # [13:05] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  372. # [13:17] * Quits: jungkees (uid24208@gateway/web/irccloud.com/x-swjhadjcwscivfdo) (Quit: Connection closed for inactivity)
  373. # [13:20] * Quits: davidyezsetz (~davidyezs@mail1.powerflasher.de) (Quit: davidyezsetz)
  374. # [13:24] * Joins: jahman (~woops@129.175.204.73)
  375. # [13:39] * Quits: aleray (~aleray@2a02:a03f:14b6:800:227:10ff:febc:7038) (Ping timeout: 272 seconds)
  376. # [13:39] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
  377. # [13:40] * Joins: Lachy (~Lachy@213.166.174.2)
  378. # [13:40] * Joins: Smylers (~smylers@81.143.60.194)
  379. # [13:43] * Joins: plutoniix (~plutoniix@node-3su.pool-125-25.dynamic.totbb.net)
  380. # [13:43] * Quits: SkireM (~skirem@static.161.53.4.46.clients.your-server.de) (Quit: Nettalk6 - www.ntalk.de)
  381. # [13:45] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
  382. # [13:46] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
  383. # [13:48] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
  384. # [13:55] * Joins: davidyezsetz (~davidyezs@mail1.powerflasher.de)
  385. # [13:55] * Quits: hasather_ (~hasather@guest.schibsted.no) (Remote host closed the connection)
  386. # [13:55] * Joins: eBureau (~Bruno@181.164.77.172)
  387. # [13:56] * Quits: davidyezsetz (~davidyezs@mail1.powerflasher.de) (Client Quit)
  388. # [13:57] * Joins: hasather (~hasather@guest.schibsted.no)
  389. # [14:03] * Joins: davidyezsetz (~davidyezs@mail1.powerflasher.de)
  390. # [14:13] <annevk> hsivonen: https://news.ycombinator.com/item?id=8624160 is terrible
  391. # [14:13] <annevk> hsivonen: trying very hard to not 386 the entire thread
  392. # [14:15] <annevk> hsivonen: it has everything, praising EV, dissing DV, suggestions to replace the entire crypto stack because it's too complicated, ...
  393. # [14:15] * Joins: samn (~samn@gateway.creuna.se)
  394. # [14:15] * Quits: samn (~samn@gateway.creuna.se) (Remote host closed the connection)
  395. # [14:16] * Joins: tripu (~tripu@ANice-653-1-606-231.w86-205.abo.wanadoo.fr)
  396. # [14:18] <annevk> hsivonen: I was going to tweet HN jumped the shark, but then I found https://news.ycombinator.com/item?id=1339857
  397. # [14:18] * Joins: ^esc (~esc-ape@178.115.131.113.wireless.dyn.drei.com)
  398. # [14:23] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
  399. # [14:27] <jgraham> The other possible response is to assume that this represents the real opinions of a subset of the relatively-tech-literate population and work out how to fix that, if necessary
  400. # [14:29] * Joins: eric_carlson (~ericc@38.104.134.62)
  401. # [14:29] <jgraham> I'm guessing a post suggesting that forum jumped the shark isn't going to help (c.f. the fact that post got modded into grey). I'm guessing a more informative post written there would help more, but not that much, since it comes across as no more authoratative than any other post
  402. # [14:30] * Joins: Ms2ger (~Ms2ger@nata206.ugent.be)
  403. # [14:35] <Ms2ger> MikeSmith, thanks again :)
  404. # [14:36] <MikeSmith> Ms2ger: happy to help
  405. # [14:39] * Joins: aleray (~aleray@2a02:a03f:14b6:800:227:10ff:febc:7038)
  406. # [14:39] * Joins: tj_vantoll (~Adium@2601:4:5380:2ec:b89e:8f5:9b67:d34c)
  407. # [14:46] * Quits: eric_carlson (~ericc@38.104.134.62) (Quit: eric_carlson)
  408. # [14:47] <rubys> annevk: OK, I've had my coffee. If you want to talk about copying, let me know if you are available.
  409. # [14:49] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
  410. # [14:51] <MikeSmith> rubys: see critic for comments on the urltestdata.txt PR
  411. # [14:51] * Joins: zdobersek (~zan@185.3.135.138)
  412. # [14:53] * Joins: Garbee (uid21171@gateway/web/irccloud.com/x-wnbhcvapczrffanx)
  413. # [14:53] <rubys> MikeSmith: wierd. I copy and pasted from working code. Odd that I lost spaces in that process. Good catch!
  414. # [14:53] <MikeSmith> rubys: and btw thanks extremely much for providing the relevant citations/links for the changes. I wish everybody would do that, and I hope you keep doing it. It saves a lot of reviewing time.
  415. # [14:53] <rubys> MikeSmith: yw. It is second nature to me to do so, and I plan to continue.
  416. # [14:54] <MikeSmith> cool
  417. # [14:56] <MikeSmith> rubys: btw I notice also that there's some unrelated borkedness in the expected behavior of the harness in Chrome at least. Compare the results for the last test (Parsing: <x> against <test:test>) in Chrome and Firefox
  418. # [14:56] * Quits: CvP (~CvP@203.76.123.238) (Read error: Connection reset by peer)
  419. # [14:57] * Joins: CvP (~CvP@203.76.123.238)
  420. # [14:57] <MikeSmith> rubys: in my Chromium build at least, it says 'assert_equals: href expected "x" but got ""' but that's clearly not what the test is actually saying
  421. # [14:57] * MikeSmith re-checks it in stable Chrome
  422. # [14:58] <MikeSmith> yeah, same thing in stable Chrome
  423. # [14:59] <rubys> MikeSmith: try it here: https://url.spec.whatwg.org/reference-implementation/liveview2.html (it isn't just the harness)
  424. # [14:59] <MikeSmith> rubys: also, in all UAs, the "assert_unreached: Expected URL to fail parsing Reached unreachable code" fails are all wrong. They should all be passes.
  425. # [14:59] <MikeSmith> rubys: looking now
  426. # [15:01] <rubys> MikeSmith: FYI, I haven't actually looked at test harness. Ever. I've only "adopted" the test data.
  427. # [15:02] <rubys> MikeSmith: OK, I've updated the pull request. What do I need to do with the critic comments?
  428. # [15:02] <MikeSmith> rubys: OK. and yeah of course I didn't mean to suggest that the harness problems were something for you to fix
  429. # [15:02] <MikeSmith> rubys: they should be resolved automatically
  430. # [15:03] <MikeSmith> that's one of the nice features of critic
  431. # [15:03] <rubys> MikeSmith: it seems possible that there isn't a harness problem; as a "black box", Chrome behaves a bit unpredictably when dealing with unknown url schemes.
  432. # [15:04] <MikeSmith> ah
  433. # [15:04] <MikeSmith> yeah that makes sense
  434. # [15:05] * Quits: sarri (~sari@unaffiliated/sarri) (Ping timeout: 245 seconds)
  435. # [15:06] * Quits: tj_vantoll (~Adium@2601:4:5380:2ec:b89e:8f5:9b67:d34c) (Read error: Connection reset by peer)
  436. # [15:08] <MikeSmith> rubys: I can't tell from https://url.spec.whatwg.org/reference-implementation/liveview2.html whether I'm seeing the expected result for the "Parsing: <x> against <test:test>" case
  437. # [15:08] * Joins: sarri (~sari@unaffiliated/sarri)
  438. # [15:08] <rubys> do you see any red?
  439. # [15:08] <MikeSmith> rubys: no but I guess I expect it would clearly say "Parsing failed as expected" or something
  440. # [15:09] <MikeSmith> instead it says "href https://url.spec.whatwg.org/reference-implementation/liveview2.html" and "hostname url.spec.whatwg.org" etc.
  441. # [15:09] * Joins: tj_vantoll (~Adium@c-98-250-130-237.hsd1.mi.comcast.net)
  442. # [15:09] * Joins: jdaggett (~jdaggett@ae031063.dynamic.ppp.asahi-net.or.jp)
  443. # [15:09] <MikeSmith> which to mean implies that it's successfully parsing a URL, though not the URL I asked it to parse
  444. # [15:09] <rubys> MikeSmith: you are using chrome?
  445. # [15:10] <MikeSmith> I see the same thing in both Firefox and Chrome for this
  446. # [15:10] <rubys> MikeSmith: In Chrome do exactly what I say, in this order:
  447. # [15:10] * MikeSmith nods
  448. # [15:10] <rubys> 1) refresh. 2) enter test:test in base, 3) enter x in the first input field
  449. # [15:10] * Joins: igoroliveira (uid20755@gateway/web/irccloud.com/x-ulqtiktvsjlvioun)
  450. # [15:11] <rubys> my conclusion: order matters, and this "black box" is unpredictable.
  451. # [15:12] <rubys> when parsing fails, you shouldn't see https://url.spec.whatwg.org/reference-implementation/liveview2.html, you should see ":" for protocol, what you specified in href, and nothing else different.
  452. # [15:12] <rubys> s/else different/else/
  453. # [15:13] <rubys> For example, try http://foo:x/ as the input, which fails predictably.
  454. # [15:13] <rubys> Chrome gives a port number of 0 in that case, which is out of spec, but at least sane.
  455. # [15:14] <MikeSmith> rubys: OK yeah I see different results now when I fill in the base URL field first, then the URL field
  456. # [15:14] <MikeSmith> rubys: but I see different results in Firefox also, when I change the order
  457. # [15:14] * Joins: prosper (~prosper@142.150.23.90)
  458. # [15:15] * prosper is now known as Guest27368
  459. # [15:15] <rubys> frameworks don't always do well when the function they are testing behave unpredictably :-)
  460. # [15:15] <MikeSmith> sure
  461. # [15:15] <rubys> MikeSmith: see pm
  462. # [15:17] * Quits: Ms2ger (~Ms2ger@nata206.ugent.be) (Ping timeout: 250 seconds)
  463. # [15:19] <annevk> MikeSmith: the test format is very peculiar, I can take a look later
  464. # [15:21] * Quits: Guest27368 (~prosper@142.150.23.90) (Ping timeout: 258 seconds)
  465. # [15:21] * Quits: CvP (~CvP@203.76.123.238) (Ping timeout: 272 seconds)
  466. # [15:23] * Joins: CvP (~CvP@203.76.123.238)
  467. # [15:25] * Joins: Una (~Una@cpe-70-117-78-235.austin.res.rr.com)
  468. # [15:30] * Quits: Una (~Una@cpe-70-117-78-235.austin.res.rr.com) (Quit: My Mac has gone to sleep. ZZZzzz…)
  469. # [15:30] <annevk> rubys: I'm mostly available now, is there anything more to say?
  470. # [15:31] <rubys> I have plenty to say. How would you like to have the discussion? PM, here, email, ... ?
  471. # [15:31] * Joins: TallTed (~Thud@63.119.36.36)
  472. # [15:33] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
  473. # [15:34] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 272 seconds)
  474. # [15:34] * Joins: Una (~Una@cpe-70-117-78-235.austin.res.rr.com)
  475. # [15:35] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
  476. # [15:35] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
  477. # [15:36] * Quits: Una (~Una@cpe-70-117-78-235.austin.res.rr.com) (Client Quit)
  478. # [15:36] * Joins: boogyman (~boogyman@38.88.11.131)
  479. # [15:36] * Quits: boogyman (~boogyman@38.88.11.131) (Changing host)
  480. # [15:36] * Joins: boogyman (~boogyman@pdpc/supporter/professional/boogyman)
  481. # [15:37] * Joins: haydogsup (~haydogsup@rrcs-97-77-44-2.sw.biz.rr.com)
  482. # [15:44] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
  483. # [15:46] * Joins: hasather_ (~hasather@80.91.33.141)
  484. # [15:47] * Quits: jahman (~woops@129.175.204.73) (Read error: Connection reset by peer)
  485. # [15:48] * Joins: jahman (~woops@129.175.204.73)
  486. # [15:48] * Quits: haydogsup (~haydogsup@rrcs-97-77-44-2.sw.biz.rr.com) (Quit: haydogsup)
  487. # [15:49] <annevk> rubys: www-archive or here would be fine
  488. # [15:50] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 240 seconds)
  489. # [15:50] <rubys> annevk: give me a sec, I'll post to www-archive, and then we can discuss here (it is a half-dozen paragraphs+ of material at this point)
  490. # [15:51] * Quits: tj_vantoll (~Adium@c-98-250-130-237.hsd1.mi.comcast.net) (Quit: Leaving.)
  491. # [15:54] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
  492. # [15:55] <rubys> http://lists.w3.org/Archives/Public/www-archive/2014Nov/0023.html
  493. # [15:56] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
  494. # [15:57] * Quits: TallTed (~Thud@63.119.36.36)
  495. # [16:01] * Joins: Ms2ger (~Ms2ger@nata200.ugent.be)
  496. # [16:05] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
  497. # [16:06] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 245 seconds)
  498. # [16:11] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
  499. # [16:11] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  500. # [16:12] * Joins: mven (~textual@32.97.110.57)
  501. # [16:13] * Joins: Una (~Una@32.97.110.57)
  502. # [16:15] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Ping timeout: 255 seconds)
  503. # [16:21] * Quits: cbr_ (~cbr@145.36.150.83.chzhher77.rootnet.ch) (Quit: cbr_)
  504. # [16:22] * Joins: cbr_ (~cbr@145.36.150.83.chzhher77.rootnet.ch)
  505. # [16:26] * Quits: shepazu (~shepazu@108-70-132-46.lightspeed.rlghnc.sbcglobal.net) (Quit: shepazu)
  506. # [16:28] * Joins: shepazu (~shepazu@108-70-132-46.lightspeed.rlghnc.sbcglobal.net)
  507. # [16:34] * Joins: jyasskin (~jyasskin@207.198.105.19)
  508. # [16:37] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
  509. # [16:42] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
  510. # [16:43] <annevk> rubys: I don't really see it addresses the point, other than you disagreeing with my position
  511. # [16:44] * Joins: TallTed (~Thud@63.119.36.36)
  512. # [16:46] * Joins: thinkxl (~thinkxl@2602:30a:c00c:59:c4d8:6c61:a169:d57d)
  513. # [16:47] <rubys> annevk: I would be sad if the only solution I had available to fixing the problems I see in the URL spec is to rewrite everything myself.
  514. # [16:48] <annevk> rubys: that seems like a non-sequitur given that I gave you commit access
  515. # [16:48] <rubys> annevk: It seems that commit access was given with a string that I wasn't aware of. And that you are reconsidering that. I'd like to discuss.
  516. # [16:49] <rubys> we clearly have philosophical differences; but I'm convinced that operationally they don't matter.
  517. # [16:50] <rubys> you'd prefer an approach which actively denies WebApps the ability to work on the URL spec; I'd prefer an approach which gives them the opportunity to do so, with the expectation that they won't.
  518. # [16:50] <Ms2ger> rubys, nobody denies anyone any ability
  519. # [16:50] <Ms2ger> rubys, that doesn't mean it's a good idea
  520. # [16:51] <annevk> rubys: you offered to be editor
  521. # [16:51] <annevk> rubys: and I don't think that is what I prefer as "approach"
  522. # [16:51] <rubys> annevk: I made that offer to both the W3C and the WHATWG
  523. # [16:53] <annevk> rubys: what I prefer is that we have a single version of the specification, available under CC0; and I want that idea to be shared by any active collaborators (e.g. those that commit)
  524. # [16:54] <annevk> rubys: it was not clear to me what upon getting commit access you would ship the repository around to other standards bodies
  525. # [16:55] <rubys> annevk: I agree with that goal. The proposal to update the WebApps version predated my contributions and eventual acceptance as editor.
  526. # [16:55] <annevk> rubys: that is in your right of course, but then I would prefer that we go back to the PR-style way of working together
  527. # [16:55] * Domenic reminds everyone to assume good intent...
  528. # [16:55] <rubys> I will state that I agree with "a single version of the specification, available under CC0; and I want that idea to be shared by any active collaborators (e.g. those that commit)"
  529. # [16:56] <rubys> I will also state that I don't think it quite is there yet, but I am hopeful that it will be.
  530. # [16:56] <annevk> rubys: given point bad-3 in your email that seems untrue
  531. # [16:56] * Joins: newtron (~newtron@199.71.174.203)
  532. # [16:56] <rubys> annevk: ok, then let me explain
  533. # [16:56] <annevk> rubys: unless my sentence was not specific enough...
  534. # [16:57] <Domenic> (I didn't interpret bad-3 that way.)
  535. # [16:57] <annevk> Domenic: how did you interpret it?
  536. # [16:57] <rubys> I believe that the barrier to entry for participation is too high on some specs at the WHATWG. Dominic's spec work is an example that others should follow.
  537. # [16:58] <rubys> What I see in streams is a signs of a true meritocracy, much like I see at the Apache Software Foundation.
  538. # [16:58] <Domenic> annevk: I interpreted bad-3 as he does not agree with the general WHATWG stance on copying in principle, but in combination with good-3, rubys seems fine going along with that stance in practice.
  539. # [16:58] <rubys> The fact that I am able to scale that barrier to entry isn't evidence that the barrier to entry is too high.
  540. # [16:59] <rubys> If the barrier remains too high, I'll eventually decide to work elsewhere and accept a suboptimal license.
  541. # [17:00] <rubys> And that would make me sad.
  542. # [17:00] * Joins: dbaron (~dbaron@50-0-248-60.dsl.dynamic.fusionbroadband.com)
  543. # [17:00] <annevk> rubys: how is Streams different?
  544. # [17:01] <rubys> https://github.com/whatwg/streams - 8 contributors. https://github.com/whatwg/url - 2 contributors.
  545. # [17:02] <rubys> I will state this: if you allow me to continue to co-edit, I WILL build a community. I WILL have the meeting with the W3C Director and actively challenge the need for a copy.
  546. # [17:03] <rubys> And I will do that based on evidence, not philosophy.
  547. # [17:03] * Quits: aleray (~aleray@2a02:a03f:14b6:800:227:10ff:febc:7038) (Ping timeout: 258 seconds)
  548. # [17:04] <annevk> rubys: okay, sounds good, make it happen
  549. # [17:04] <rubys> sweet!
  550. # [17:05] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
  551. # [17:05] <annevk> Looking at https://github.com/whatwg/streams/graphs/contributors though it's not that diverse, but at least the number is higher :-)
  552. # [17:05] <rubys> Note: this conversation is publicly archived. If I don't follow through, feel free to call me on it.
  553. # [17:06] <Domenic> streams has good diversity in the issue tracker. the actual contributions are mostly takeshi and I, plus a few editorial corrections.
  554. # [17:06] <Domenic> also lol how you can see when i joined google from that graph :P
  555. # [17:07] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
  556. # [17:07] * Quits: Una (~Una@32.97.110.57) (Read error: Connection reset by peer)
  557. # [17:13] * Quits: darobin (~darobin@78.109.80.74) (Remote host closed the connection)
  558. # [17:13] <hsivonen> jgraham: do you have ideas how to make the relatively tech literate crowd see that certifying the binding between a public key and a host name has value?
  559. # [17:15] * Quits: markkes (~markkes@62.207.90.201) (Quit: markkes)
  560. # [17:17] <wilhelm> hsivonen: Which additional attack vectors are possible without that certification?
  561. # [17:17] * Quits: Ms2ger (~Ms2ger@nata200.ugent.be) (Ping timeout: 250 seconds)
  562. # [17:17] * Joins: jwalden (~waldo@2620:101:80fb:224:7e7a:91ff:fe25:a5a3)
  563. # [17:18] <hsivonen> wilhelm: a MITM establishing an encrypted connection with the browser and another with the origin server and either reading or modifying the traffic as the MITM moves it from one pipe into the other
  564. # [17:18] <hsivonen> wilhelm: (or the MITM establishing an encrypted connection with the browser and not even bothering with taking any data from the real server)
  565. # [17:19] <hsivonen> wilhelm: so without authenticity, a MITM can compromise both integrity and confidentiality
  566. # [17:20] <hsivonen> on the topic of https, an https-enabled validator.nu exist but DNS doesn't point to it yet, because I want to avoid breaking legacy API clients
  567. # [17:20] <hsivonen> so I want a redirect from http to https that only happens if the method is GET and there is no query string
  568. # [17:20] <hsivonen> can someone teach me how to do that in nginx?
  569. # [17:21] <hsivonen> I can do a redirect conditional on the method being GET
  570. # [17:21] * Joins: jsx (uid48919@fsf/intern/jsx)
  571. # [17:21] <hsivonen> and I can do a redirect conditional on the query string being empty
  572. # [17:21] <hsivonen> but I don't know how to check for both conditions at the same time
  573. # [17:23] <wilhelm> hsivonen: That's the attack vector I assumed. Wouldn't merely pointing to that convince the audience?
  574. # [17:25] * Quits: cbr_ (~cbr@145.36.150.83.chzhher77.rootnet.ch) (Quit: cbr_)
  575. # [17:25] * Quits: jyasskin (~jyasskin@207.198.105.19) (Ping timeout: 255 seconds)
  576. # [17:27] <hsivonen> wilhelm: apparently not. people seem to assume that the set of MITMs that can only read and not write is significant
  577. # [17:27] * Joins: jyasskin (~jyasskin@207.198.105.19)
  578. # [17:28] <annevk> hsivonen: it seems to me so much that's like flipping a switch, maybe not quite right now, but definitely down the line
  579. # [17:30] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
  580. # [17:38] <hsivonen> annevk: the notion that backbone MITMs can't write *as much* data at a given time as they can read seems believable
  581. # [17:38] * Quits: davidyezsetz (~davidyezs@mail1.powerflasher.de) (Quit: davidyezsetz)
  582. # [17:38] <hsivonen> annevk: so it's probably not a flip of the switch for equal amounts of MITMing in all cases
  583. # [17:39] <hsivonen> annevk: but it does seem naive to assume that a MITM who can read can't write at all
  584. # [17:39] <hsivonen> annevk: and then you don't know when the MITM is writing
  585. # [17:40] <annevk> hsivonen: was it claimed that you could detect MITM?
  586. # [17:40] <hsivonen> annevk: with TOFU, you can detect if your first connection happened to be clean
  587. # [17:42] <hsivonen> of course, with TOFU, people just assume that the key changed for benign reasons
  588. # [17:45] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: Textual IRC Client: www.textualapp.com)
  589. # [17:45] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
  590. # [17:46] <hsivonen> nginx is usually awesome, but the redirect stuff is remarkably inflexible (likely to be very fast)
  591. # [17:47] * Quits: jyasskin (~jyasskin@207.198.105.19) (Quit: My computer has gone to sleep. ZZZzzz…)
  592. # [17:47] * Joins: jernoble (~jernoble@76.74.153.49)
  593. # [17:52] <jgraham> hsivonen: publicise a tool that makes MITMing a site served using a self-signed cert trivial (c.f. firesheep)?
  594. # [17:55] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  595. # [17:57] * Joins: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com)
  596. # [17:59] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  597. # [18:05] <TabAtkins> jgraham: Don't blame me, it's a result of the boilerplate that Domenic wrote for WHATWG specs. (Which he partially based on the CSSWG boilerplate, probably.)
  598. # [18:07] * Joins: zcorpan (~zcorpan@c-5eeaaa20-74736162.cust.telenor.se)
  599. # [18:11] * Joins: thinkxl_ (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net)
  600. # [18:13] * Quits: zcorpan (~zcorpan@c-5eeaaa20-74736162.cust.telenor.se) (Ping timeout: 265 seconds)
  601. # [18:13] * Joins: Una (~Una@32.97.110.57)
  602. # [18:14] * Quits: thinkxl (~thinkxl@2602:30a:c00c:59:c4d8:6c61:a169:d57d) (Ping timeout: 258 seconds)
  603. # [18:14] * Joins: Ms2ger (~Ms2ger@8.210-242-81.adsl-dyn.isp.belgacom.be)
  604. # [18:14] * thinkxl_ is now known as thinkxl
  605. # [18:14] * Joins: zcorpan (~zcorpan@81-231-171-143-no135.tbcn.telia.com)
  606. # [18:15] * Quits: pfefferle (~pfefferle@213.144.11.130) (Ping timeout: 255 seconds)
  607. # [18:15] * Joins: Maurice` (copyman@unaffiliated/maurice)
  608. # [18:15] * Joins: pfefferle (~pfefferle@p5B02D2A5.dip0.t-ipconnect.de)
  609. # [18:15] * Joins: jyasskin (~jyasskin@216.239.45.222)
  610. # [18:16] * Joins: aleray (~aleray@ip-83-101-33-131.customer.schedom-europe.net)
  611. # [18:19] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
  612. # [18:29] * Quits: Smylers (~smylers@81.143.60.194) (Ping timeout: 272 seconds)
  613. # [18:30] * Krinkle|detached is now known as Krinkle
  614. # [18:36] * Quits: pfefferle (~pfefferle@p5B02D2A5.dip0.t-ipconnect.de) (Ping timeout: 255 seconds)
  615. # [18:39] * Quits: hasather_ (~hasather@80.91.33.141) (Remote host closed the connection)
  616. # [18:40] * Joins: hasather (~hasather@80.91.33.141)
  617. # [18:40] <gsnedders> zcorpan: grattis!
  618. # [18:40] <zcorpan> gsnedders: tack!
  619. # [18:41] <TabAtkins> jgraham: But it's also a good idea, in general, to move that crap out of the top of the spec. You read it once, you internalize it, you're done. Requiring people to scroll past it every time is a bit reader-hostile. (At least, that was our reasoning in the CSSWG when we rejiggered our boilerplate.)
  620. # [18:43] * Quits: newtron (~newtron@199.71.174.203) (Quit: Leaving...)
  621. # [18:44] * Quits: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com) (Ping timeout: 265 seconds)
  622. # [18:45] <TabAtkins> zcorpan: That url comes from WHATWG's boilerplate files in Bikeshed. If something's wrong with it, it can be corrected.
  623. # [18:45] * Quits: CvP (~CvP@203.76.123.238) (Quit: [ UPP ] > all)
  624. # [18:45] * Joins: eric_carlson (~ericc@156.39.191.244)
  625. # [18:46] <zcorpan> TabAtkins: it should be https://whatwg.org/
  626. # [18:46] <wilhelm> hsivonen: Setting up a rogue access point just to MITM people is trivial.
  627. # [18:47] * Joins: CvP (~CvP@203.76.123.238)
  628. # [18:47] <TabAtkins> zcorpan: Fixed.
  629. # [18:48] <TabAtkins> rubys: What's this about BNF-like notation?
  630. # [18:48] <zcorpan> TabAtkins: thx
  631. # [18:48] <rubys> TabAtkins: there needs to be an accessible alternative to the railroad diagrams
  632. # [18:48] <TabAtkins> rubys: If I'm understanding correctly, it's about you wanting to define some things in terms of a normative railroad diagram?
  633. # [18:49] <rubys> whether it is normative or not, if it is useful, it should be accessible
  634. # [18:49] <TabAtkins> Ah, kk. I'd like to have such a thing, so I can add a <title> to the SVG.
  635. # [18:49] * Quits: eric_carlson (~ericc@156.39.191.244) (Client Quit)
  636. # [18:49] <TabAtkins> I'll bet I could auto-generate BNF from the diagram code.
  637. # [18:49] * Quits: jernoble (~jernoble@76.74.153.49) (Quit: Computer has gone to sleep.)
  638. # [18:50] <rubys> I also can meet you half way if you like. I generate the Railroad diagrams from peg.js input, so if you provide me a means to provide extra input, I can likely do so in a few lines of code.
  639. # [18:50] <zcorpan> i recall a proposal at tpac about an svg <connector> or something, to connect things in a way that can be communicated to AT
  640. # [18:51] <rubys> TabAtkins: very low on the priority list, but I've seen a few cases where the vertical alignment is off. I've rejiggered some to avoid the problem, but a few remain.
  641. # [18:51] <TabAtkins> Yes.
  642. # [18:51] <TabAtkins> rubys: Ooh, point out when you find them.
  643. # [18:51] <rubys> http://intertwingly.net/projects/pegurl/url.html#host
  644. # [18:52] <rubys> File had a vertical gap (extra whitespace) and overlap. By reordering, I made that go away.
  645. # [18:53] * Quits: Ducki (~Ducki@191.233.66.1) (Ping timeout: 244 seconds)
  646. # [18:55] <TabAtkins> rubys: Hmm, I see.
  647. # [18:57] <rubys> I'll open two issues to track this? Make railroad diagrams accessible, and fix vertical alignment? Or is that unnecessary/unhelpful?
  648. # [18:57] <TabAtkins> Go for it!
  649. # [18:57] <TabAtkins> Issues are always good.
  650. # [18:58] * Joins: eric_carlson (~ericc@156.39.191.244)
  651. # [18:58] * Joins: Jirka (~Jirka@95.85.233.233)
  652. # [19:01] <rubys> done
  653. # [19:07] * Joins: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com)
  654. # [19:08] * Quits: eric_carlson (~ericc@156.39.191.244) (Quit: eric_carlson)
  655. # [19:08] * Quits: zcorpan (~zcorpan@81-231-171-143-no135.tbcn.telia.com) (Ping timeout: 250 seconds)
  656. # [19:08] * Joins: jarek (~jarek@unaffiliated/jarek)
  657. # [19:08] <jarek> Hi
  658. # [19:08] * Joins: eric_carlson (~ericc@156.39.191.244)
  659. # [19:08] <jarek> What is the difference between node.prototype.querySelector() and node.prototype.query() ?
  660. # [19:09] <Domenic> jarek: query() isn't implemented yet, but when it is, it'll be better in a few ways:
  661. # [19:09] <Domenic> 1) it'll work with selector strings like "> div", which QS fails on
  662. # [19:09] <Domenic> oh wait I think that's most of it because you asked about query vs. querySelector not queryAll vs. querySelectorAll
  663. # [19:09] <jarek> Domenic: what about queryAll? How is it better than querySelectorAll?
  664. # [19:10] <Domenic> jarek: it returns an instance of Elements, which is a proper Array subclass, which is awesome.
  665. # [19:10] <terinjokes> Domenic: you mean qS(A) doesn't support the exact string of "> div"?
  666. # [19:11] <Domenic> terinjokes: yeah it uses "selector" instead of "relative selector"
  667. # [19:11] <jarek> Domenic: is it safe to shim query()/queryAll() by just aliasing it to querySelector()/querySelectorAll()?
  668. # [19:11] <Domenic> jarek: no, definitely not.
  669. # [19:11] <Domenic> jarek: use https://github.com/barberboy/dom-elements, it's pretty OK
  670. # [19:12] * Joins: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
  671. # [19:12] <jarek> there was another collection class introduced in DOM? Why not just make NodeList inherit from Array?
  672. # [19:13] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Remote host closed the connection)
  673. # [19:14] <annevk> jarek: there's no "just"
  674. # [19:14] <Domenic> jarek: that breaks the web... lemme find the bug
  675. # [19:14] <Domenic> wow all of these answers are wrong http://stackoverflow.com/questions/13433799/why-doesnt-nodelist-have-foreach
  676. # [19:15] <Domenic> ah here we go https://esdiscuss.org/topic/why-does-legacy-content-break-when-making-array-likes-real-arrays
  677. # [19:15] * Quits: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com) (Ping timeout: 256 seconds)
  678. # [19:15] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
  679. # [19:17] <caitp> it's hard not to be wrong when talking about js
  680. # [19:17] <jarek> is there also some alternative to node.children that would give Elements instance instead of NodeList?
  681. # [19:18] <Domenic> node.queryAll("> *")
  682. # [19:18] <jarek> Domenic: uhm... for (let child of this.queryAll("> *")) doesn't look very readable
  683. # [19:19] <Domenic> seems fine to me
  684. # [19:20] * Joins: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com)
  685. # [19:20] <jarek> I think I'm sticking with NodeList, with ES6 it will be very easy to convert NodeList to Array, e.g. let childrenArray = [...element.children]
  686. # [19:20] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
  687. # [19:20] <Domenic> *shrug*
  688. # [19:20] <jarek> [...this.children].forEach( (child) => console.log(child))
  689. # [19:21] <Domenic> You can't convert children to an array unless we make children iterable
  690. # [19:21] <Domenic> s/children iterable/NodeList iterable/
  691. # [19:21] <caitp> which would probably be a good idea, I mean
  692. # [19:21] <Domenic> yeah
  693. # [19:21] <TabAtkins> Domenic: Which I assume we'd do, since it's a symbol property and so won't be problematic int he same way.
  694. # [19:21] <jarek> Domenic: I can make NodeList iterable myself :P
  695. # [19:21] <Domenic> in which case it's just for (const child of this.children) { ... }
  696. # [19:22] <caitp> it would kind of suck to have to manually polyfill NodeList / HTMLCollection / etc to be iterable
  697. # [19:26] * Quits: Una (~Una@32.97.110.57) (Quit: My Mac has gone to sleep. ZZZzzz…)
  698. # [19:29] <annevk> jgraham: specification authors not maintaining their specification is also bad, though ;-)
  699. # [19:29] <annevk> NodeList is already iterable
  700. # [19:31] <Hixie> not that my opinion matters on this, but fwiw, i prefer conformance at the top, and for the bottom to be indices, references, acks, in that order.
  701. # [19:31] <Hixie> conformance at the bottom in particular is quite confusing to me at first :-)
  702. # [19:31] <TabAtkins> Hixie: I can definitely say I'm happy that our conformance moved to the bottom, because it means less PgDn necessary to get to the spec text.
  703. # [19:32] <jgraham> annevk: Right, but most bugs in implementations aren't bugs in specifications
  704. # [19:32] <Hixie> tab: yeah, i guess it depends on the spec. when you have the table of contents and then a multipage intro before anything else, the issue of whether the conformance section is before or after the rest of the spec text is pretty moot.
  705. # [19:32] <annevk> jgraham: do we have data on that? Often a clearer specification would help
  706. # [19:33] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
  707. # [19:33] <Hixie> tab: (and HTML's conformance section is pretty big in practice, it's not really just boilerplate)
  708. # [19:33] <annevk> jgraham: oops, I don't have data either, so I should not have said that second thing :-)
  709. # [19:33] <jgraham> annevk: I have a hard time believing that most platform bugs in Gecko (for example) were actually spec bugs
  710. # [19:34] <jgraham> It's certainly *sometimes* true, but you have a huge observer bias since you almost only see bugs where it is true
  711. # [19:34] * Joins: ap_ (~ap@17.202.44.214)
  712. # [19:34] * Ms2ger must be missing context
  713. # [19:34] <jgraham> But yeah I can't prove it
  714. # [19:34] <jgraham> Ms2ger: whatwg@
  715. # [19:35] <jgraham> Well I assume, either that or I have no idea waht annevk is on about :)
  716. # [19:35] * Quits: tripu (~tripu@ANice-653-1-606-231.w86-205.abo.wanadoo.fr) (Quit: Leaving)
  717. # [19:35] * annevk isn't sure what jgraham is on about either
  718. # [19:35] <Ms2ger> Ha
  719. # [19:35] * Joins: eBureau (~Bruno@181.164.77.172)
  720. # [19:37] <annevk> Hixie: it certainly seems that in practice "Conformance" being boilerplate would help implementers, as they are unlikely to read the whole document
  721. # [19:37] * Quits: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
  722. # [19:37] * Joins: tantek (~tantek@70-36-197-247.dsl.dynamic.fusionbroadband.com)
  723. # [19:37] <annevk> Hixie: not that I'm particularly happy about the new section ordering, but I haven't really put time into appreciating it either
  724. # [19:38] <jarek> I recall there were some plans to introduce document.createElement("svg:rect") in place of document.createElement("http://www.w3.org/2000/svg", "rect")
  725. # [19:38] <Hixie> my "conformance" section includes pages and pages of terminology definitions that other specs rely on, as well as references to other specs that i rely on, a long description of all the conformance classes which is pretty html-specific, etc.
  726. # [19:38] <jarek> ^ is this standarized anywhere already?
  727. # [19:38] <TabAtkins> jarek: No.
  728. # [19:38] <Ms2ger> No
  729. # [19:38] <Hixie> the actual boilerplate is only a few paragraphs but having that specifically moved elsewhere would be really weird and wouldn't really help tab's page-down-count issue.
  730. # [19:38] <jarek> it should be document.createElementNS("http://www.w3.org/2000/svg", "rect")
  731. # [19:38] <tantek> qnames lol
  732. # [19:39] <jarek> TabAtkins: how likely is this proposal to get accepted? Would it be reasonable to shim it already?
  733. # [19:39] <jarek> createElementNS feels out of place in HTML5, there has to be better API introduced
  734. # [19:39] <Ms2ger> Quite unlikely
  735. # [19:40] <TabAtkins> Nobody's really picked it up after the initial thread wound down, so no clue what it'll eventually look like. Do whatever you want for your own APIs, though. No need to shim document.createElement(), that's a terrible long name anyway.
  736. # [19:40] <tantek> you had me at NS feels out of place in HTML5
  737. # [19:40] <Hixie> document.createElementNetscape() ? :-)
  738. # [19:40] <TabAtkins> In my Python code I have an E class, so I can write `E.div({"class":"foo"}, "some text")`
  739. # [19:41] * Joins: Mso150 (~ctlM@80.83.239.11)
  740. # [19:41] <TabAtkins> Making your own element-creation helper in that vein would be better.
  741. # [19:41] * Hixie uses an E function, as in E('div', {class:'foo'}, 'some text', ...)
  742. # [19:41] <Hixie> where "some text" is any child elements
  743. # [19:41] <Hixie> including further nested E()s
  744. # [19:41] <Hixie> better than DOM, but still worse than E4H
  745. # [19:42] <jarek> Hixie: did you mean E4X?
  746. # [19:43] <jarek> Hixie: with ES6 E4X-like element creation is already possible
  747. # [19:43] <Hixie> i meant http://hixie.ch/specs/e4h/strawman
  748. # [19:44] <Hixie> as far as i can tell, that is incorrect. es6 lacks the key feature that i need, compile-time syntax checking.
  749. # [19:44] <jarek> Hixie: I see, I hope this was proposed before work on ES6 started?
  750. # [19:44] <Hixie> it was proposed in 2012ish
  751. # [19:44] <Hixie> but based on e4x which long predates es6
  752. # [19:45] * Quits: danbri (Adium@nat/google/x-gilinxmbxlhzhajg) (Quit: Leaving.)
  753. # [19:46] * Quits: eric_carlson (~ericc@156.39.191.244) (Quit: eric_carlson)
  754. # [19:48] <annevk> jarek: Hixie also proposed Element.create()
  755. # [19:48] * Quits: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net) (Read error: Connection reset by peer)
  756. # [19:48] <annevk> jarek: there's also some push for new HTMLDivElement() and friends
  757. # [19:49] <jarek> annevk: yeah, that would make a lot of sense since custom elements can be already "newed"
  758. # [19:49] <annevk> jarek: none have made it far enough so far
  759. # [19:50] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
  760. # [19:51] * Joins: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net)
  761. # [19:51] <terinjokes> what's the browser interest in sendBeacon?
  762. # [19:51] <jarek> let element = new SVGComponentTransferFunctionElement();
  763. # [19:52] <jarek> feels very semantic and obvious, but verbose
  764. # [19:52] * Quits: espadrine_ (~ttyl@LMontsouris-656-1-02-84.w80-12.abo.wanadoo.fr) (Ping timeout: 240 seconds)
  765. # [19:52] * Joins: Una (~Una@32.97.110.57)
  766. # [19:53] <Ms2ger> jarek, new HTMLHeadingElement()?
  767. # [19:54] * Joins: jernoble (~jernoble@17.202.49.229)
  768. # [19:55] <jarek> Ms2ger: I believe both verbose semantic syntax and shorthand concise E4X-like syntax are needed
  769. # [19:56] <jarek> depending on context in which elements are created
  770. # [19:59] <jarek> I would expect abstract interfaces like HTMLHeadingElement to just throw an error when used with "new"
  771. # [20:04] * Quits: jyasskin (~jyasskin@216.239.45.222) (Quit: My computer has gone to sleep. ZZZzzz…)
  772. # [20:05] * Joins: eric_carlson (~ericc@156.39.191.244)
  773. # [20:07] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  774. # [20:08] <Domenic> terinjokes: landed in CHrome 39
  775. # [20:08] <Domenic> terinjokes: I think Mozilla is on track to ship too?
  776. # [20:10] * Quits: nephyrin (~neph@nemu.pointysoftware.net) (Read error: Connection reset by peer)
  777. # [20:10] * Joins: nephyrin (~neph@nemu.pointysoftware.net)
  778. # [20:15] <wanderview> Domenic: terinjokes: looks like it shipped if FF30: https://bugzilla.mozilla.org/show_bug.cgi?id=936340
  779. # [20:15] <wanderview> ah, not enabled until FF31
  780. # [20:17] * Joins: ambv (~ambv@206.108.217.134)
  781. # [20:19] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: jarek)
  782. # [20:19] * Quits: jernoble (~jernoble@17.202.49.229) (Quit: Textual IRC Client: www.textualapp.com)
  783. # [20:20] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
  784. # [20:23] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
  785. # [20:23] * Quits: Una (~Una@32.97.110.57) (Quit: My Mac has gone to sleep. ZZZzzz…)
  786. # [20:24] * Joins: say2joe (~Adium@198-101-119-98.static-ip.telepacific.net)
  787. # [20:25] * Joins: espadrine (~espadrine@dan75-7-88-166-187-54.fbx.proxad.net)
  788. # [20:25] * Quits: Mso150 (~ctlM@80.83.239.11) (Ping timeout: 240 seconds)
  789. # [20:26] * Joins: Una (~Una@32.97.110.57)
  790. # [20:27] * Joins: Mso150 (~ctlM@80.83.239.56)
  791. # [20:28] * Quits: CvP (~CvP@203.76.123.238) (Disconnected by services)
  792. # [20:28] * Joins: xCG (~CvP@sgp.sin.winterei.se)
  793. # [20:29] * Joins: jyasskin (~jyasskin@216.239.45.222)
  794. # [20:29] * Quits: Una (~Una@32.97.110.57) (Client Quit)
  795. # [20:29] * Quits: dbaron (~dbaron@50-0-248-60.dsl.dynamic.fusionbroadband.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  796. # [20:29] * xCG is now known as CvP
  797. # [20:30] * Joins: mko (~mko@50.240.205.146)
  798. # [20:33] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: Textual IRC Client: www.textualapp.com)
  799. # [20:33] * Quits: eric_carlson (~ericc@156.39.191.244) (Quit: eric_carlson)
  800. # [20:35] * Joins: eric_carlson (~ericc@156.39.191.244)
  801. # [20:36] * Joins: Una (~Una@32.97.110.57)
  802. # [20:36] * Joins: ehynds (~ehynds@64.206.121.41)
  803. # [20:38] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  804. # [20:39] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  805. # [20:44] * Quits: frivoal (~frivoal@cm-84.211.98.39.getinternet.no) (Remote host closed the connection)
  806. # [20:44] * Joins: frivoal (~frivoal@cm-84.211.98.39.getinternet.no)
  807. # [20:46] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  808. # [20:47] <terinjokes> Domenic: Chrome/40 seems non-compliant
  809. # [20:47] <terinjokes> at least w/r/t Blob
  810. # [20:57] * Quits: Una (~Una@32.97.110.57) (Quit: My Mac has gone to sleep. ZZZzzz…)
  811. # [21:00] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Ping timeout: 240 seconds)
  812. # [21:06] * Joins: eBureau (~Bruno@181.164.77.172)
  813. # [21:13] * Quits: bholley (~bholley@c-50-131-239-99.hsd1.ca.comcast.net)
  814. # [21:14] * Quits: eric_carlson (~ericc@156.39.191.244) (Quit: eric_carlson)
  815. # [21:15] * Joins: dbaron (~dbaron@2620:101:80fb:224:8936:dce1:3e16:a80a)
  816. # [21:26] * Quits: aleray (~aleray@ip-83-101-33-131.customer.schedom-europe.net) (Ping timeout: 255 seconds)
  817. # [21:26] * Joins: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon)
  818. # [21:26] <zcorpan> jarek: i think changing document.createElement("svg:rect") might not be possible but we could use a space or so instead of colon
  819. # [21:28] <Hixie> oh hey, a zcorpan
  820. # [21:28] <zcorpan> sup Hixie
  821. # [21:28] <Hixie> zcorpan: one sec, loading conversation
  822. # [21:28] <Hixie> zcorpan: https://html.spec.whatwg.org/#processing-model-9
  823. # [21:29] <Hixie> zcorpan: note step 8's new steps (work in progress, not yet checked in)
  824. # [21:29] <Hixie> zcorpan: i'm interested in your input on how you'd like to integrate this into cssom-view
  825. # [21:29] <Hixie> zcorpan: basically, this provides a specific place for scroll and resize events
  826. # [21:29] <Hixie> zcorpan: (and many other things)
  827. # [21:29] <zcorpan> Hixie: multipage is up to date?
  828. # [21:29] <Hixie> zcorpan: so that we don't have to use tasks for things that are rendering-specific
  829. # [21:29] <Hixie> yes
  830. # [21:29] <Hixie> multipage updates with single page now
  831. # [21:29] <Hixie> same tool outputs both at once
  832. # [21:32] <zcorpan> Hixie: this looks great
  833. # [21:33] * Joins: calvaris (~calvaris@158.124.27.77.dynamic.mundo-r.com)
  834. # [21:33] <Hixie> cool
  835. # [21:34] <Hixie> zcorpan: let me know if you think anything should change, i'm completely open to doing this however you want
  836. # [21:35] <zcorpan> Hixie: i guess "Evaluate media queries and report changes" is something that HTML in turn hooks into for <link media>, <source media> etc?
  837. # [21:36] <zcorpan> Hixie: did you base the order on something or is it arbitrary?
  838. # [21:36] <Hixie> zcorpan: mostly that was intended for MediaQueryList's events, but I hadn't thought of <link> and <source> etc
  839. # [21:36] * Quits: roc (~chatzilla@121-99-82-169.bng1.tvc.orcon.net.nz) (Remote host closed the connection)
  840. # [21:36] <Hixie> zcorpan: it's more or less the superset of the orders that people seemed to give in various e-mails and specs I found
  841. # [21:37] <Hixie> zcorpan: mostly the order is arbitrary except that: resize is before scroll, animation frame callbacks are the last script thing in the list
  842. # [21:37] <zcorpan> ok. might be interesting to check what order e.g. Blink uses. i think blink syncs some of these things with rAF these days
  843. # [21:38] <Hixie> step 6 is rAF
  844. # [21:38] <Hixie> i spoke to one of the blink guys about this, and to dbaron
  845. # [21:38] * Joins: eric_carlson (~ericc@156.39.191.244)
  846. # [21:38] <zcorpan> ok
  847. # [21:38] <Hixie> i believe it's consistent with what they said
  848. # [21:38] <Hixie> though mistakes are always possible!
  849. # [21:42] <zcorpan> Hixie: ok so let me think out loud about how to spec the resize event...
  850. # [21:42] <Hixie> shoot
  851. # [21:47] <zcorpan> Run the resize steps are as follows: for each browsing context associated with the given event loop, if it has a viewport and it has had its width or height changed since the last time these steps were run, fire an event named resize at the Window object associated with that viewport.
  852. # [21:48] <zcorpan> except maybe resize events need to be throttled
  853. # [21:50] <Hixie> seems reasonable
  854. # [21:51] <Hixie> no need for throttling; this only happens at 60Hz anyway
  855. # [21:51] <Hixie> or rather, the throttling is taken care of on my side
  856. # [21:52] <zcorpan> if we want 60Hz for resize, sure
  857. # [21:53] <zcorpan> but if there are sites doing expensive things in onresize, might want to throttle more than that
  858. # [21:53] <zcorpan> i'll have to check what browsers do
  859. # [21:53] * Krinkle is now known as Krinkle|detached
  860. # [21:54] * Quits: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Ping timeout: 240 seconds)
  861. # [21:54] <Hixie> well you want it to be possible to resize at 60Hz, otherwise it'll be impossible for a web app to have clean resize behaviour
  862. # [21:54] <Hixie> but sure
  863. # [21:55] <Hixie> that's why browsers are allowed to throttle the whole rendering loop further
  864. # [21:55] <astearns_> "...if it has a viewport and that viewport has had..."
  865. # [21:55] * Quits: jyasskin (~jyasskin@216.239.45.222) (Quit: My computer has gone to sleep. ZZZzzz…)
  866. # [21:57] * Joins: newtron (~newtron@199.71.174.203)
  867. # [22:00] <annevk> zcorpan: happy b-day
  868. # [22:01] <Hixie> anyone know if https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html is the latest version of that spec?
  869. # [22:02] <Hixie> http://www.w3.org/TR/hr-time/ is dated later, but presumably if an error was found that's not hte spec that would be updated..
  870. # [22:02] <Hixie> gah, w3c doc policy grr
  871. # [22:02] <annevk> I recommend emailing the WG
  872. # [22:03] * Quits: ehynds (~ehynds@64.206.121.41)
  873. # [22:03] <zcorpan> annevk: thanks!
  874. # [22:04] <Hixie> annevk: i've never had any luck mailing that wg
  875. # [22:04] <zcorpan> Hixie: actually i'd like the "for each browsing context" to be on your side, so that these things get consistent order across browsing contexts
  876. # [22:04] * Quits: boogyman (~boogyman@pdpc/supporter/professional/boogyman) (Quit: Leaving.)
  877. # [22:04] <annevk> Hixie: email plh directly?
  878. # [22:04] <Hixie> zcorpan: fair enough
  879. # [22:04] <annevk> Web Performance is not particularly great indeed :/
  880. # [22:05] <zcorpan> Hixie: and maybe say what the order should be (creation order?)
  881. # [22:05] * Quits: Mso150 (~ctlM@80.83.239.56) (Ping timeout: 250 seconds)
  882. # [22:05] <Hixie> zcorpan: what do you want to be called for? Documents? browsing contexts? does it differ based on which hook we're talking about?
  883. # [22:05] <Hixie> for rAF i want to be called for documents
  884. # [22:06] * Joins: Mso150 (~ctlM@217.118.64.42)
  885. # [22:07] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  886. # [22:08] <zcorpan> Hixie: i think document works for scroll/resize/matchMedia. i can always get the viewport or browsing context from a document if i need it, right?
  887. # [22:08] <Hixie> yup
  888. # [22:08] <Hixie> do you want to be called with a list, or called once for each doc? (if you're doing anything per top-level-b-c, you'll have to track which you've done)
  889. # [22:09] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Remote host closed the connection)
  890. # [22:09] <Hixie> i think for rAF i'm going to have the event loop loop over docs, and the rAF handling be per-doc
  891. # [22:11] * Joins: aleray (~aleray@ip-83-101-33-131.customer.schedom-europe.net)
  892. # [22:11] <zcorpan> per-doc is OK
  893. # [22:13] * Joins: xiinotulp (~plutoniix@node-1cbm.pool-101-108.dynamic.totbb.net)
  894. # [22:14] * Joins: satazor (~satazor@102.99.136.95.rev.vodafone.pt)
  895. # [22:16] * Joins: danbri (~Adium@87.113.221.2)
  896. # [22:16] * Quits: plutoniix (~plutoniix@node-3su.pool-125-25.dynamic.totbb.net) (Ping timeout: 264 seconds)
  897. # [22:18] * Quits: satazor (~satazor@102.99.136.95.rev.vodafone.pt) (Ping timeout: 255 seconds)
  898. # [22:21] <terinjokes> xhr.send(blob) is supposed to send the contents of the blob, correct?
  899. # [22:23] <annevk> terinjokes: yes
  900. # [22:24] <terinjokes> any ideas why I might be doing wrong if instead Chrome/40 serializes/stringifies the blob instance?
  901. # [22:25] <annevk> terinjokes: Chrome might not support it
  902. # [22:27] * Quits: ambv (~ambv@206.108.217.134) (Quit: sys.exit(0) # app closed)
  903. # [22:27] <annevk> terinjokes: we still haven't really clarified what happens if someone closed the blob I think
  904. # [22:28] <annevk> terinjokes: could be that by not addressing that quickly enough I delayed implementation, I was trying to get answers elsewhere, but no luck thus far, I should probably just decide on something
  905. # [22:29] * terinjokes smashes head against desk
  906. # [22:29] <terinjokes> i found the error was between the chair and the keyboard
  907. # [22:30] * Quits: aleray (~aleray@ip-83-101-33-131.customer.schedom-europe.net) (Ping timeout: 264 seconds)
  908. # [22:30] <Domenic> ah phew i was scared
  909. # [22:30] <terinjokes> i was as well
  910. # [22:30] <annevk> hmm okay
  911. # [22:31] <terinjokes> forgot that there was stupid serialization code happening elsewhere
  912. # [22:31] <annevk> if you find out how the dealt with that case I'd be interested in specifying it :-)
  913. # [22:31] <annevk> they*
  914. # [22:31] * Joins: rniwa (~rniwa@17.202.43.222)
  915. # [22:32] * Quits: cheron (~cheron@unaffiliated/cheron) (Ping timeout: 240 seconds)
  916. # [22:35] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  917. # [22:37] <Hixie> zcorpan: reload html spec for new hooks
  918. # [22:37] * Joins: ambv (~ambv@206.108.217.134)
  919. # [22:42] * Joins: laurensclaessen (~laurenscl@2a02:1810:1005:2600:3048:d4:786d:84a9)
  920. # [22:42] <zcorpan> Hixie: looks good
  921. # [22:44] * Quits: eric_carlson (~ericc@156.39.191.244) (Quit: eric_carlson)
  922. # [22:46] * Quits: zdobersek (~zan@185.3.135.138) (Quit: Leaving.)
  923. # [22:48] * Krinkle|detached is now known as Krinkle
  924. # [22:52] * Quits: Jirka (~Jirka@95.85.233.233) (Ping timeout: 245 seconds)
  925. # [22:52] * Joins: Una (~Una@32.97.110.57)
  926. # [22:53] * Quits: danbri (~Adium@87.113.221.2) (Quit: Leaving.)
  927. # [22:57] <Hixie> ok rAF is specced in HTML now
  928. # [22:57] <Hixie> annevk: see the event loop section for stuff you probably want to use for fullscreen
  929. # [22:58] <annevk> Hixie: oh cool
  930. # [22:58] <annevk> Hixie++
  931. # [22:59] * Joins: eric_carlson (~ericc@156.39.191.244)
  932. # [23:01] * Quits: ambv (~ambv@206.108.217.134) (Read error: Connection reset by peer)
  933. # [23:01] * Joins: ambv (~ambv@206.108.217.134)
  934. # [23:03] * Quits: jsx (uid48919@fsf/intern/jsx) (Quit: Connection closed for inactivity)
  935. # [23:05] * heycam|away is now known as heycam
  936. # [23:05] * Quits: TallTed (~Thud@63.119.36.36)
  937. # [23:06] * Quits: newtron (~newtron@199.71.174.203) (Ping timeout: 255 seconds)
  938. # [23:08] * Joins: Una_ (~Una@32.97.110.57)
  939. # [23:08] * Quits: Una (~Una@32.97.110.57) (Read error: Connection reset by peer)
  940. # [23:09] <jamesr_> Hixie: the storage mutex text is all dead code, but you know that
  941. # [23:09] * Joins: Una (~Una@32.97.110.55)
  942. # [23:09] <Hixie> jamesr_: one day browsers will realise that data corruption is bad :-P
  943. # [23:10] <jamesr_> that's a guess on your part :)
  944. # [23:10] <jamesr_> Hixie: the "update the rendering" step will in practice happen independently of any explicitly queued "task" running
  945. # [23:10] <gsnedders> it's a nice guess :)
  946. # [23:11] <Hixie> jamesr_: not sure what you mean by your last comment, can you elaborate?
  947. # [23:11] * Quits: dbaron (~dbaron@2620:101:80fb:224:8936:dce1:3e16:a80a) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  948. # [23:11] <jamesr_> i.e. if the only thing on your page is a rAF() loop, it never puts a 'task' into any queue
  949. # [23:11] <jamesr_> it adds things to the raf list
  950. # [23:11] <jamesr_> so you basically want to run step 8 of the event loop processing model
  951. # [23:11] <jamesr_> without having anything in 1
  952. # [23:12] <jamesr_> Hixie: your spec for requestAnimationFrame() simply adds an entry to the list (which is correct, it doesn't really queue a task) but there's nothing that explicitly says "the browser then has to go and run through the processing model"
  953. # [23:13] <jamesr_> and i don't see a way to get to step 8 in that algorithm without a task around to run step 3
  954. # [23:13] * Quits: Una_ (~Una@32.97.110.57) (Ping timeout: 255 seconds)
  955. # [23:14] <Hixie> jamesr_: oh, right, that's the long-standing issue that step 1 should happen even if it's got no tasks to run
  956. # [23:14] <Hixie> jamesr_: yeah, i should fix that
  957. # [23:15] <Hixie> step 6 already admits that no task might be run
  958. # [23:15] <jamesr_> yeah
  959. # [23:15] <jamesr_> just need to teach steps 2-4 about that factoid
  960. # [23:15] <jamesr_> each of the "For each Document in docs" should go in the same order, right?
  961. # [23:15] <Hixie> yeah
  962. # [23:16] <Hixie> see the last paragraph of 8.2
  963. # [23:16] <jamesr_> what happens if you add or remove a new document in one of the step 8 substeps?
  964. # [23:16] <Hixie> that doc is ignored
  965. # [23:16] <Hixie> for that rendering loop
  966. # [23:16] <jamesr_> and if you remove one?
  967. # [23:16] <jamesr_> i guess it's pretty clearly not run
  968. # [23:17] <jamesr_> less obvious is what happens if you rejigger the tree such that the invariants in step 8.1 no longer hold for the list you generated
  969. # [23:17] <Hixie> i guess removing it would still run the steps, hmm
  970. # [23:17] <Hixie> the order is maintained for all the steps regardless of what you do
  971. # [23:17] <jamesr_> like the event chain?
  972. # [23:17] <Hixie> yeah
  973. # [23:17] <jamesr_> makes sense
  974. # [23:17] * Quits: Maurice` (copyman@unaffiliated/maurice)
  975. # [23:18] <Hixie> i didn't add in any of the "hidden" logic from your draft btw
  976. # [23:18] <Hixie> i suppose i should have that too
  977. # [23:18] <Hixie> does that handle "the document is removed from the dom"?
  978. # [23:18] <jamesr_> hmm, not sure if that is covered
  979. # [23:18] <jamesr_> but it should
  980. # [23:18] <jamesr_> a document that isn't in the dom isn't visible
  981. # [23:19] <jamesr_> Hixie: i think it'd be reasonable for a UA to handle "hidden" under the "run these steps if necessary" clause
  982. # [23:19] <jamesr_> and choose not to run step 8 at all if it decided that the things it cared about were not visible
  983. # [23:19] <jamesr_> that determination can be tricky sometimes
  984. # [23:20] <jamesr_> for instance we have a feature in chrome where we can "cast" a tab to a remote screen
  985. # [23:20] <jamesr_> and that works even if you "background" the tab
  986. # [23:20] <Hixie> instead of "For each document" i'll say "For each visible document", which will handle removing documents. Need to define "visible" somehow.
  987. # [23:20] <jamesr_> so if you're looking at the computer screen it appears to be not visible, but it is
  988. # [23:20] <jamesr_> somewhere else
  989. # [23:20] <jamesr_> Hixie: that's not what you want actually
  990. # [23:20] <jamesr_> raf runs in frames that are not "visible" by a reasonable definition if the parent frame is
  991. # [23:21] <Hixie> s/visible/relevant/
  992. # [23:21] <jamesr_> the defiintion of "hidden" that the w3c RAF spec used defers to the top-level document or some such
  993. # [23:21] <jamesr_> i think boris disagrees with me here on the desirable behavior here
  994. # [23:22] <jamesr_> but there are common cases like "you load all your JS code in a same-origin 0x0 iframe and drive the parent frame from it" where you want the behavior the w3c spec specifies
  995. # [23:22] * Quits: eric_carlson (~ericc@156.39.191.244) (Quit: eric_carlson)
  996. # [23:23] * Quits: Mso150 (~ctlM@217.118.64.42) (Ping timeout: 255 seconds)
  997. # [23:23] <Hixie> how about: a document is "relevant" if it is a fully active document that the user agent believes would benefit from having its rendering updated?
  998. # [23:26] <jamesr_> i think you do want to specify the set of documents exactly, since at least in the same origin case it's very easy to detect whether things happened in different documents in the same context
  999. # [23:26] * Joins: roc (~chatzilla@203.192.141.163)
  1000. # [23:27] <zcorpan> Hixie: timers should also be slower in background tabs iirc
  1001. # [23:28] * Joins: saba (~foo@unaffiliated/saba)
  1002. # [23:29] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  1003. # [23:30] * Hixie tries a different approach
  1004. # [23:33] * Joins: Smylers (~smylers@host86-147-46-136.range86-147.btcentralplus.com)
  1005. # [23:33] <jamesr_> zcorpan: they are. the timer spec allows the UA to add whatever delay they want, which allows the slower in background tabs behavior
  1006. # [23:34] <jamesr_> but i think browsers have roughly stabilized
  1007. # [23:34] <Hixie> jamesr_, zcorpan: ok look now. https://html.spec.whatwg.org/multipage/#processing-model-9
  1008. # [23:35] <jamesr_> hah - why does #processing-model-9 go to step 8.1.4.2?
  1009. # [23:35] <Hixie> cos there's 8 earlier sections titled "processing model" :-)
  1010. # [23:36] <jamesr_> hm, so you null out the docs list as a way to skip the rest of the steps?
  1011. # [23:37] <Hixie> not null out necessarily
  1012. # [23:37] <zcorpan> Hixie: doesn't rAF drop to 0Hz for background tabs? while timers are 1Hz. and i don't know about scroll/resize/etc
  1013. # [23:37] <Hixie> if there's two tabs, and one is to be updated and the other not, then only the background tab's docs get removed
  1014. # [23:37] <Hixie> zcorpan: the spec leaves this open to the browser
  1015. # [23:38] <Hixie> zcorpan: (i hate how chrome doesn't update background tabs, it means that when i switch to a tab, i get the old picture for a frame and then i see the new frame, it's ugly)
  1016. # [23:38] <jamesr_> the timers spec says "take the |timeout| value from script. if you feel like it, add an arbitrary amount to |timeout|"
  1017. # [23:39] <jamesr_> Hixie: that's a slightly different issue
  1018. # [23:39] <jamesr_> you wouldn't want the background tab to be continuously rendering as if it was visible
  1019. # [23:39] <jamesr_> but when you do decide to switch to the tab, there's a choice a browser can make between janking the tab switch until the tab's new contents is ready or showing you whatever it has
  1020. # [23:39] <zcorpan> Hixie: the spec seems to require the same interval for resize/scroll/MQ/fullscreen/rAF
  1021. # [23:40] * Quits: laurensclaessen (~laurenscl@2a02:1810:1005:2600:3048:d4:786d:84a9)
  1022. # [23:40] <Hixie> no, but you might want to update all the tabs once as soon as the user hits command, in case the user then hits tab to switch to the other tabs, or something
  1023. # [23:40] <Hixie> anyway the point is the browser just allows it
  1024. # [23:40] <Hixie> zcorpan: right.
  1025. # [23:40] <Hixie> zcorpan: that's what we want, no?
  1026. # [23:40] <jamesr_> in practice we've been moving to that in blink and been pretty happy
  1027. # [23:41] <jamesr_> Hixie: yeah or start rendering the new tab on the mouse/touch-down even though the switch doesn't happen until the -up
  1028. # [23:41] <jamesr_> Hixie: or start rendering when you over or whatever
  1029. # [23:41] <Hixie> yeah
  1030. # [23:41] <jamesr_> there's a lot we could do predictively
  1031. # [23:41] <zcorpan> Hixie: i don't know. maybe
  1032. # [23:41] <jamesr_> but #lifeishard
  1033. # [23:41] <Hixie> jamesr_: i just want to make sure we don't prevent those. especially since there's no obvious interop need for a particular speed here.
  1034. # [23:42] * Quits: Una (~Una@32.97.110.55) (Read error: Connection reset by peer)
  1035. # [23:42] <Hixie> zcorpan: seems like it's a much better authoring experience if you can rely on all of these happening in order together every time
  1036. # [23:42] * Joins: Una (~Una@32.97.110.55)
  1037. # [23:43] <Hixie> i'm amused at https://www.w3.org/Bugs/Public/show_bug.cgi?id=27347, which says a majority of browsers (browser a, browser b) do one thing and a minority of browsers (browser c, browser d) do another
  1038. # [23:43] <jamesr_> sure
  1039. # [23:43] <jamesr_> heh
  1040. # [23:43] <jamesr_> browser counting
  1041. # [23:43] <jamesr_> hard to do
  1042. # [23:43] <Hixie> i think they meant majority by usage share
  1043. # [23:43] <Hixie> but still, it reads funny
  1044. # [23:44] <Hixie> ok, event loop updates are committed
  1045. # [23:45] <Hixie> i've no idea what https://www.w3.org/Bugs/Public/show_bug.cgi?id=27367 means
  1046. # [23:46] <zcorpan> Hixie: looks like chrome and firefox don't fire resize until the tab is activated again, so that one seems OK
  1047. # [23:46] <Hixie> do they fire anything else?
  1048. # [23:47] <zcorpan> i can try testing the other things tomorrow
  1049. # [23:47] <zcorpan> right now i need to get some sleep :-)
  1050. # [23:48] <Hixie> nn!
  1051. # [23:48] <zcorpan> thanks for fixing this btw
  1052. # [23:48] <Hixie> np
  1053. # [23:49] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 244 seconds)
  1054. # [23:50] <zcorpan> i've sent an email to www-style about this btw for cssom-view and animations
  1055. # [23:52] * Quits: rubys (~rubys@cpe-098-027-051-253.nc.res.rr.com) (Ping timeout: 244 seconds)
  1056. # [23:56] * Joins: weinig (~weinig@17.245.26.114)
  1057. # [23:56] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  1058. # [23:58] * Quits: jdaggett (~jdaggett@ae031063.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
  1059. # [23:59] * Quits: Una (~Una@32.97.110.55) (Quit: My Mac has gone to sleep. ZZZzzz…)
  1060. # Session Close: Thu Nov 20 00:00:00 2014

Previous day, Next day