/irc-logs / freenode / #whatwg / 2014-07-14 / end

Options:

  1. # Session Start: Mon Jul 14 00:00:00 2014
  2. # Session Ident: #whatwg
  3. # [00:00] * Joins: tantek (~tantek@rrcs-64-183-1-195.west.biz.rr.com)
  4. # [00:01] <jgraham> caitp: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13 seems pretty specific. I haven't checked the updates.
  5. # [00:02] <caitp> there's nothing in any of those RFCs which says anything like "a client MUST not send an entity body if the request method is HEAD or GET"
  6. # [00:02] <caitp> at best there's a "should not", or "probably not a good idea"
  7. # [00:02] <gsnedders> I thought one the httpbis things changed that?
  8. # [00:03] <caitp> but if it weren't a good idea, the big 3 browsers would probably be thoroughly broken any time anyone ever wanted to send a HEAD request
  9. # [00:05] <caitp> basically http just doesn't care if there's a payload or not
  10. # [00:05] <caitp> http doesn't care, and xhr doesn't care, so it's not clear why we're making any assertion in the first place
  11. # [00:06] <jgraham> caitp: Anyway what zcorpan says in that bug is right
  12. # [00:07] <jgraham> The goal is to get interop
  13. # [00:07] <caitp> yes, I agree with that
  14. # [00:07] <caitp> but my position is still that we should be testing compliance with the spec
  15. # [00:07] <caitp> not with a particular implementation
  16. # [00:07] <jgraham> In this case it seems like specs are half-assing things and we should just agree what the right behaviour is and get everyone to implement it
  17. # [00:08] <jgraham> caitp: We're not
  18. # [00:08] <jgraham> You are assuming some sort of malice here when there is none
  19. # [00:08] * Quits: Ablu (~ablu@141.0.21.24) (Ping timeout: 240 seconds)
  20. # [00:08] <caitp> oh no no no
  21. # [00:08] <caitp> i'm not assuming malice
  22. # [00:08] <caitp> it's not "malice", it seems like an honest mistake, like maybe it's testing something that _should_ be specified but isn't
  23. # [00:09] <caitp> but regardless, no implementation that I've seen (not tested netsurf, does netsurf even have XHR yet?) passes that test, apart from gecko
  24. # [00:10] <caitp> the comment which explains this reasoning for this behaviour in chromium is interesting, I linked to it in either the issue or PR
  25. # [00:10] * Joins: Fusl (Fusl@unaffiliated/fusl)
  26. # [00:10] <caitp> http://mxr.mozilla.org/chromium/source/src/net/http/http_network_transaction.cc#866
  27. # [00:10] * Joins: Ablu (~ablu@quassel.woboq.de)
  28. # [00:11] <caitp> when you word the reasoning like that, it's almost a "feature" to send the header
  29. # [00:11] <jgraham> Presto passes
  30. # [00:11] <caitp> okay, opera might still pass without opera, since it's not blink which breaks this
  31. # [00:12] <caitp> er
  32. # [00:12] <caitp> opera might still pass without presto*
  33. # [00:12] <caitp> not sure if modern opera shares more of the chromium tree or if it's just blink
  34. # [00:12] <gsnedders> it's the chromium content api
  35. # [00:12] <caitp> ah
  36. # [00:12] * wilhelm is now known as Guest14397
  37. # [00:13] <gsnedders> (which was why when Blink happened there was no practical choice)
  38. # [00:14] <caitp> interesting =)
  39. # [00:17] <jgraham> Anyway, I don't think it's reasonable to assume that Blink behaviour is somehow more authorative than Gecko. The only relevant question is "what will everyone agree to implement". If you think gecko should change, file a bug. Or if you think that Blink+etc. should, file bugs there. It seems like there can't be a strong compat. argument either way, so there ought not to be too much resistance to changing. Reality might not be so straightforward.
  40. # [00:17] <jgraham> Also yell at the IETF for not specifying anything clear and unambiguous here
  41. # [00:17] * Joins: weinig (~weinig@98.234.191.242)
  42. # [00:18] <caitp> that's not it, per se, i am just not sure it's right to assert things which aren't specified anywhere
  43. # [00:18] <caitp> i agree that changing the test to assert for just a falsy content-length request header isn't right
  44. # [00:19] <caitp> hmm webkit nightly and ie11 still fail that test, so I guess it's still true
  45. # [00:19] <jgraham> I think it's better to have tests and argue about what the result should be than weaken the test just because people have failed to achieve interop
  46. # [00:20] <gsnedders> caitp: webkit doesn't have a single network layer, FWIW, depends on port
  47. # [00:21] <caitp> if one line of code was changed in a fork of chromium, "chromium would pass", too :p
  48. # [00:21] <caitp> but yeah you're right
  49. # [00:22] <caitp> primarily referring to http://nightly.webkit.org/, which is basically safari afaict
  50. # [00:23] <gsnedders> IIRC it uses the system Safari with a bit of magic
  51. # [00:23] <gsnedders> so yeah, that uses NSURL
  52. # [00:24] <SimonSapin> MikeSmith: Galimatias does have code for parsing IPv4, but seems to handle none of the funny cases I mentioned in the bug
  53. # [00:25] <caitp> anyhow, in the case of that particular issue, I'm not sure it matters a whole lot if browsers behave identically or not. like, the web doesn't care
  54. # [00:25] <caitp> so it's just a weird assertion to make
  55. # [00:25] <caitp> anyways, time to drop it and make dinner, fun chat \o
  56. # [00:27] <jgraham> Every time we decide that poor interop is OK, the web gets a little bit harder to author content for, and other platforms get a little more compelling
  57. # [00:27] <jgraham> So it's not a great position to take
  58. # [00:29] <MikeSmith> SimonSapin: ok, so yeah, would be good to hear back from smola
  59. # [00:31] * Krinkle is now known as Krinkle|detached
  60. # [00:31] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 264 seconds)
  61. # [00:33] * Quits: rego (~rego@192.193.27.77.dynamic.mundo-r.com) (Ping timeout: 260 seconds)
  62. # [00:43] * Quits: yoav_ (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 256 seconds)
  63. # [00:45] * Joins: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net)
  64. # [00:46] * Quits: raidendev (~raidendev@broadband-46-242-56-184.nationalcablenetworks.ru) (Ping timeout: 240 seconds)
  65. # [00:54] * Quits: tantek (~tantek@rrcs-64-183-1-195.west.biz.rr.com) (Quit: tantek)
  66. # [00:57] * Joins: KevinMarks (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net)
  67. # [00:57] * Krinkle|detached is now known as Krinkle
  68. # [00:58] * Quits: cheron (~cheron@unaffiliated/cheron) (Ping timeout: 240 seconds)
  69. # [00:58] * Joins: satazor (~satazor@26.186.108.93.rev.vodafone.pt)
  70. # [00:58] * Joins: rego (~rego@192.193.27.77.dynamic.mundo-r.com)
  71. # [00:58] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  72. # [01:03] * Quits: jeremyj (~jeremyj@17.202.49.56) (Quit: Textual IRC Client: www.textualapp.com)
  73. # [01:08] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 264 seconds)
  74. # [01:11] * Joins: jarek (~jarek@unaffiliated/jarek)
  75. # [01:22] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  76. # [01:23] * Krinkle is now known as Krinkle|detached
  77. # [01:24] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Ping timeout: 240 seconds)
  78. # [01:32] * Joins: thinkxl (~thinkxl@207-91-184-235.nstci.net)
  79. # [01:35] * Quits: roc (~chatzilla@121.98.106.217) (Remote host closed the connection)
  80. # [01:38] * Krinkle|detached is now known as Krinkle
  81. # [01:46] * Quits: kangil (~kangil@210.94.41.89) (Remote host closed the connection)
  82. # [01:47] * Joins: kangil (~kangil@210.94.41.89)
  83. # [01:48] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 264 seconds)
  84. # [01:48] * Joins: tantek (~tantek@rrcs-64-183-1-195.west.biz.rr.com)
  85. # [02:09] * Quits: satazor (~satazor@26.186.108.93.rev.vodafone.pt) (Remote host closed the connection)
  86. # [02:10] * Joins: satazor (~satazor@26.186.108.93.rev.vodafone.pt)
  87. # [02:12] * Joins: encryptd_fractl (~encryptd_@209.201.113.2)
  88. # [02:14] * Quits: satazor (~satazor@26.186.108.93.rev.vodafone.pt) (Ping timeout: 264 seconds)
  89. # [02:16] * Quits: encryptd_fractl (~encryptd_@209.201.113.2) (Ping timeout: 240 seconds)
  90. # [02:20] * Joins: jacobolus (~jacobolus@173-13-172-189-sfba.hfc.comcastbusiness.net)
  91. # [02:23] * Joins: satazor (~satazor@26.186.108.93.rev.vodafone.pt)
  92. # [02:23] * Quits: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net) (Ping timeout: 260 seconds)
  93. # [02:27] * Joins: jacobolu_ (~jacobolus@173-13-172-189-sfba.hfc.comcastbusiness.net)
  94. # [02:27] * Joins: roc (~chatzilla@203.192.141.163)
  95. # [02:28] * Quits: satazor (~satazor@26.186.108.93.rev.vodafone.pt) (Ping timeout: 264 seconds)
  96. # [02:28] * Quits: jacobolu_ (~jacobolus@173-13-172-189-sfba.hfc.comcastbusiness.net) (Remote host closed the connection)
  97. # [02:30] * Quits: jacobolus (~jacobolus@173-13-172-189-sfba.hfc.comcastbusiness.net) (Ping timeout: 260 seconds)
  98. # [02:33] * Joins: encryptd_fractl (~encryptd_@209.201.113.2)
  99. # [02:36] * Quits: encryptd_fractl (~encryptd_@209.201.113.2) (Remote host closed the connection)
  100. # [02:36] * Joins: marcosc_ (~marcosc@135-23-143-163.cpe.pppoe.ca)
  101. # [02:36] * Joins: encryptd_fractl (~encryptd_@209.201.113.2)
  102. # [02:38] * Quits: encryptd_fractl (~encryptd_@209.201.113.2) (Remote host closed the connection)
  103. # [02:40] * Joins: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net)
  104. # [02:49] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  105. # [02:55] * Quits: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  106. # [02:57] * Joins: karlcow (~karl@nerval.la-grange.net)
  107. # [03:01] * Quits: tantek (~tantek@rrcs-64-183-1-195.west.biz.rr.com) (Quit: tantek)
  108. # [03:05] * Krinkle is now known as Krinkle|detached
  109. # [03:17] * Joins: satazor (~satazor@26.186.108.93.rev.vodafone.pt)
  110. # [03:18] * Joins: danja (~danny@host74-61-dynamic.23-79-r.retail.telecomitalia.it)
  111. # [03:21] * Quits: satazor (~satazor@26.186.108.93.rev.vodafone.pt) (Ping timeout: 240 seconds)
  112. # [03:38] * Krinkle|detached is now known as Krinkle
  113. # [03:53] * Quits: newtron (~newtron@76-10-135-135.dsl.teksavvy.com) (Remote host closed the connection)
  114. # [03:53] * Joins: newtron (~newtron@76-10-135-135.dsl.teksavvy.com)
  115. # [03:56] * Joins: jungkees (uid24208@gateway/web/irccloud.com/x-wnyntntxpznakjsd)
  116. # [03:57] * Quits: newtron (~newtron@76-10-135-135.dsl.teksavvy.com) (Ping timeout: 240 seconds)
  117. # [03:59] * Quits: Areks (~Areks@95-28-254-201.broadband.corbina.ru) (Ping timeout: 264 seconds)
  118. # [04:05] * Krinkle is now known as Krinkle|detached
  119. # [04:06] * Joins: Goplat (~goplat@reactos/developer/Goplat)
  120. # [04:09] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: jarek)
  121. # [04:11] * Joins: satazor (~satazor@26.186.108.93.rev.vodafone.pt)
  122. # [04:16] * Quits: satazor (~satazor@26.186.108.93.rev.vodafone.pt) (Ping timeout: 264 seconds)
  123. # [04:30] * Joins: jingtaoliu (~technommy@61.144.248.40)
  124. # [04:34] * Joins: jarek (~jarek@unaffiliated/jarek)
  125. # [04:43] * Quits: yutak (~yutak@2401:fa00:4:1000:8d6a:e506:3ab7:ba47) (Ping timeout: 240 seconds)
  126. # [04:47] * Joins: KevinMarks2 (~yaaic@207.47.22.242.static.nextweb.net)
  127. # [04:47] * Quits: KevinMarks2 (~yaaic@207.47.22.242.static.nextweb.net) (Remote host closed the connection)
  128. # [04:48] * Joins: KevinMarks2 (~yaaic@207.47.22.242.static.nextweb.net)
  129. # [04:52] * Joins: newtron (~newtron@76-10-135-135.dsl.teksavvy.com)
  130. # [04:56] * Joins: yutak (~yutak@2401:fa00:4:1000:d526:8937:2e22:5aff)
  131. # [05:05] * Joins: satazor (~satazor@26.186.108.93.rev.vodafone.pt)
  132. # [05:09] * Quits: satazor (~satazor@26.186.108.93.rev.vodafone.pt) (Ping timeout: 240 seconds)
  133. # [05:14] * Joins: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net)
  134. # [05:14] * Quits: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net) (Client Quit)
  135. # [05:19] * Joins: raidendev (~raidendev@broadband-46-242-56-184.nationalcablenetworks.ru)
  136. # [05:19] * Quits: KevinMarks2 (~yaaic@207.47.22.242.static.nextweb.net) (Ping timeout: 240 seconds)
  137. # [05:20] * Joins: KevinMarks2 (~yaaic@2607:fb90:2201:bbba:bed4:388b:17d1:5ef0)
  138. # [05:29] * Joins: encryptd_fractl (~encryptd_@209.201.113.2)
  139. # [05:34] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: jarek)
  140. # [05:37] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
  141. # [05:37] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
  142. # [05:37] * Joins: scor (~scor@drupal.org/user/52142/view)
  143. # [05:46] * Quits: newtron (~newtron@76-10-135-135.dsl.teksavvy.com) (Remote host closed the connection)
  144. # [05:47] * Joins: newtron (~newtron@76-10-135-135.dsl.teksavvy.com)
  145. # [05:48] * Quits: jingtaoliu (~technommy@61.144.248.40) (Remote host closed the connection)
  146. # [05:48] * Joins: jingtaoliu (~technommy@li576-119.members.linode.com)
  147. # [05:51] * Quits: newtron (~newtron@76-10-135-135.dsl.teksavvy.com) (Ping timeout: 240 seconds)
  148. # [05:51] * Quits: encryptd_fractl (~encryptd_@209.201.113.2) (Remote host closed the connection)
  149. # [05:52] * Joins: newtron (~newtron@76-10-135-135.dsl.teksavvy.com)
  150. # [05:55] * Quits: roc (~chatzilla@203.192.141.163) (Remote host closed the connection)
  151. # [05:58] * Joins: jingtaol_ (~technommy@61.144.248.40)
  152. # [05:59] * Joins: roc (~chatzilla@2001:cb0:b202:232:2677:3ff:fece:dc64)
  153. # [06:02] * Quits: jingtaoliu (~technommy@li576-119.members.linode.com) (Ping timeout: 256 seconds)
  154. # [06:06] * Joins: encryptd_fractl (~encryptd_@209.201.113.2)
  155. # [06:08] * Quits: encryptd_fractl (~encryptd_@209.201.113.2) (Remote host closed the connection)
  156. # [06:08] * Joins: encryptd_fractl (~encryptd_@209.201.113.2)
  157. # [06:11] * Quits: encryptd_fractl (~encryptd_@209.201.113.2) (Remote host closed the connection)
  158. # [06:22] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
  159. # [06:22] * Joins: satazor (~satazor@26.186.108.93.rev.vodafone.pt)
  160. # [06:27] * Quits: satazor (~satazor@26.186.108.93.rev.vodafone.pt) (Ping timeout: 264 seconds)
  161. # [06:33] * Quits: lerc (~quassel@121.74.2.8) (Quit: No Ping reply in 180 seconds.)
  162. # [06:33] * Joins: lerc (~quassel@121-74-2-8.telstraclear.net)
  163. # [06:34] * Quits: KevinMarks2 (~yaaic@2607:fb90:2201:bbba:bed4:388b:17d1:5ef0) (Ping timeout: 240 seconds)
  164. # [06:38] * Quits: newtron (~newtron@76-10-135-135.dsl.teksavvy.com) (Remote host closed the connection)
  165. # [06:38] * Joins: newtron (~newtron@76-10-135-135.dsl.teksavvy.com)
  166. # [06:43] * Quits: newtron (~newtron@76-10-135-135.dsl.teksavvy.com) (Ping timeout: 240 seconds)
  167. # [06:46] * Joins: encryptd_fractl (~encryptd_@209.201.113.2)
  168. # [06:48] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  169. # [06:50] * Quits: encryptd_fractl (~encryptd_@209.201.113.2) (Ping timeout: 240 seconds)
  170. # [06:52] * Quits: seventh (seventh@206.222.164.252) (Remote host closed the connection)
  171. # [07:00] * Joins: BigBangUDR (~Thunderbi@103.249.181.147)
  172. # [07:00] * Joins: toydestroyer (~toydestro@mail.moneks.ru)
  173. # [07:02] * Quits: toydestroyer (~toydestro@mail.moneks.ru) (Client Quit)
  174. # [07:02] * Quits: BigBangUDR (~Thunderbi@103.249.181.147) (Remote host closed the connection)
  175. # [07:03] * Joins: KevinMarks2 (~yaaic@2607:fb90:2203:e5e2:faa5:3e93:1fae:b0df)
  176. # [07:05] * Joins: tantek (~tantek@rrcs-64-183-1-195.west.biz.rr.com)
  177. # [07:05] * Joins: toydestroyer (~toydestro@mail.moneks.ru)
  178. # [07:07] * Quits: tantek (~tantek@rrcs-64-183-1-195.west.biz.rr.com) (Client Quit)
  179. # [07:07] * Joins: BigBangUDR (~Thunderbi@103.249.181.147)
  180. # [07:08] * Quits: scrollback1 (scrollback@conference/jsconf/x-zpsprhsmvysoavvs) (Remote host closed the connection)
  181. # [07:10] * Joins: scrollback (scrollback@conference/jsconf/x-jtxmdxzhiryxplck)
  182. # [07:23] * Joins: yoav_ (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  183. # [07:25] * yoav_ is now known as yoav
  184. # [07:26] * Joins: Smylers (~smylers@host86-159-66-158.range86-159.btcentralplus.com)
  185. # [07:33] * Quits: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net) (Ping timeout: 260 seconds)
  186. # [07:33] * Quits: BigBangUDR (~Thunderbi@103.249.181.147) (Ping timeout: 256 seconds)
  187. # [07:35] * Joins: xiinotulp (~plutoniix@node-jn1.pool-101-108.dynamic.totbb.net)
  188. # [07:37] * Quits: raidendev (~raidendev@broadband-46-242-56-184.nationalcablenetworks.ru) (Ping timeout: 264 seconds)
  189. # [07:38] * Quits: plutoniix (~plutoniix@node-11dp.pool-180-180.dynamic.totbb.net) (Ping timeout: 240 seconds)
  190. # [07:44] * Quits: toydestroyer (~toydestro@mail.moneks.ru)
  191. # [07:45] * Joins: BigBangUDR (~Thunderbi@103.249.181.147)
  192. # [07:48] * Quits: weinig (~weinig@98.234.191.242) (Quit: weinig)
  193. # [07:52] * Joins: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net)
  194. # [07:55] * Quits: thinkxl (~thinkxl@207-91-184-235.nstci.net)
  195. # [07:58] * Joins: toydestroyer (~toydestro@mail.moneks.ru)
  196. # [07:59] * Quits: Smylers (~smylers@host86-159-66-158.range86-159.btcentralplus.com) (Quit: Leaving.)
  197. # [08:05] * Quits: toydestroyer (~toydestro@mail.moneks.ru)
  198. # [08:16] * Joins: raidendev (~raidendev@188.92.107.182)
  199. # [08:17] * Quits: roc (~chatzilla@2001:cb0:b202:232:2677:3ff:fece:dc64) (Remote host closed the connection)
  200. # [08:20] * Joins: toydestroyer (~toydestro@mail.moneks.ru)
  201. # [08:29] * Joins: arpitab__ (uid10516@gateway/web/irccloud.com/x-uafgiweqpzbcielk)
  202. # [08:32] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  203. # [08:38] * Joins: zdobersek (~zan@46.166.186.239)
  204. # [08:48] * cryptic_ is now known as cryptic
  205. # [08:51] * Quits: markkes (~markkes@62.207.90.201) (Quit: Nettalk6 - www.ntalk.de)
  206. # [08:53] * Joins: markkes (~markkes@62.207.90.201)
  207. # [09:00] * Quits: jingtaol_ (~technommy@61.144.248.40) (Remote host closed the connection)
  208. # [09:00] * Joins: jingtaoliu (~technommy@li576-119.members.linode.com)
  209. # [09:01] * Quits: dbaron (~dbaron@50-0-128-161.dsl.dynamic.sonic.net) (Ping timeout: 240 seconds)
  210. # [09:02] * Quits: KevinMarks2 (~yaaic@2607:fb90:2203:e5e2:faa5:3e93:1fae:b0df) (Ping timeout: 240 seconds)
  211. # [09:04] * xiinotulp is now known as plutoniix
  212. # [09:05] * Joins: KevinMarks2 (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  213. # [09:11] * Joins: annevk (~annevk@185.28.53.106)
  214. # [09:12] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
  215. # [09:13] * Joins: a-ja (~Instantbi@70.230.146.131)
  216. # [09:17] * Joins: jingtaol_ (~technommy@61.144.248.40)
  217. # [09:18] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Remote host closed the connection)
  218. # [09:19] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  219. # [09:21] * Quits: jingtaoliu (~technommy@li576-119.members.linode.com) (Ping timeout: 264 seconds)
  220. # [09:23] * Joins: Kolombiken (~Adium@gateway.creuna.se)
  221. # [09:26] * Joins: Smylers (~smylers@31.55.33.254)
  222. # [09:32] * Quits: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon) (Quit: Connection closed for inactivity)
  223. # [09:32] * Quits: Smylers (~smylers@31.55.33.254) (Ping timeout: 264 seconds)
  224. # [09:41] * Joins: Ms2ger (~Ms2ger@148.253-64-87.adsl-dyn.isp.belgacom.be)
  225. # [09:44] * Guest14397 is now known as wilhelm
  226. # [09:45] * Joins: Smylers (~smylers@81.143.60.194)
  227. # [09:47] * Joins: cheron (~cheron@unaffiliated/cheron)
  228. # [09:49] * Joins: encryptd_fractl (~encryptd_@209.201.113.2)
  229. # [09:50] * Quits: jingtaol_ (~technommy@61.144.248.40) (Remote host closed the connection)
  230. # [09:50] * Quits: annevk (~annevk@185.28.53.106) (Remote host closed the connection)
  231. # [09:50] * Joins: jingtaoliu (~technommy@li576-119.members.linode.com)
  232. # [09:52] * Quits: BigBangUDR (~Thunderbi@103.249.181.147) (Ping timeout: 240 seconds)
  233. # [09:54] * Quits: encryptd_fractl (~encryptd_@209.201.113.2) (Ping timeout: 264 seconds)
  234. # [10:06] * Joins: Ducki (~Ducki@191.233.66.1)
  235. # [10:08] * Joins: annevk (~annevk@185.28.53.106)
  236. # [10:10] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  237. # [10:12] * Quits: annevk (~annevk@185.28.53.106) (Ping timeout: 240 seconds)
  238. # [10:20] * Quits: Somatt_wrk (~somattwrk@130.193.24.135) (Read error: Connection reset by peer)
  239. # [10:20] * Joins: Somatt_wrk (~somattwrk@130.193.24.135)
  240. # [10:22] * Joins: jingtaol_ (~technommy@61.144.248.40)
  241. # [10:26] * Quits: jingtaoliu (~technommy@li576-119.members.linode.com) (Ping timeout: 240 seconds)
  242. # [10:29] * Joins: richt (~richt@83.218.67.123)
  243. # [10:29] * Joins: BigBangUDR (~Thunderbi@115.246.141.189)
  244. # [10:37] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  245. # [10:42] * Joins: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  246. # [10:43] * Joins: satazor (~satazor@26.186.108.93.rev.vodafone.pt)
  247. # [10:44] * Quits: KevinMarks2 (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
  248. # [10:45] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  249. # [10:46] * Joins: sankha93 (uid12218@fsf/emeritus/sankha93)
  250. # [10:46] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Ping timeout: 264 seconds)
  251. # [10:50] * Joins: KevinMarks2 (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  252. # [10:51] * Quits: jingtaol_ (~technommy@61.144.248.40) (Remote host closed the connection)
  253. # [10:51] * Joins: jingtaoliu (~technommy@li576-119.members.linode.com)
  254. # [10:56] * Joins: jingtaol_ (~technommy@61.144.248.40)
  255. # [10:59] * Joins: annevk5 (~annevk5@185.28.53.106)
  256. # [10:59] * Quits: jingtaoliu (~technommy@li576-119.members.linode.com) (Ping timeout: 256 seconds)
  257. # [10:59] * Quits: annevk5 (~annevk5@185.28.53.106) (Client Quit)
  258. # [11:01] * Quits: broquaint (~dbrook@static.94.217.47.78.clients.your-server.de) (Ping timeout: 260 seconds)
  259. # [11:01] * Quits: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Read error: Connection reset by peer)
  260. # [11:02] * Joins: broquaint (~dbrook@static.94.217.47.78.clients.your-server.de)
  261. # [11:04] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  262. # [11:06] * Quits: MikeSmith (~mike@80.68.92.65) (Ping timeout: 240 seconds)
  263. # [11:06] * Quits: BigBangUDR (~Thunderbi@115.246.141.189) (Ping timeout: 240 seconds)
  264. # [11:07] * Joins: MikeSmith (~mike@sideshowbarker.net)
  265. # [11:17] * Quits: sangwhan (sid12645@gateway/web/irccloud.com/x-nepgwpsqzoblsaek) (Ping timeout: 252 seconds)
  266. # [11:17] * Joins: sangwhan (sid12645@gateway/web/irccloud.com/x-btaszxipmuzdmlgr)
  267. # [11:18] * Quits: tobie_ (sid5692@gateway/web/irccloud.com/x-iuuiybbquvdrmplk) (Ping timeout: 252 seconds)
  268. # [11:18] * Quits: twisted`_ (sid6794@gateway/web/irccloud.com/x-vjggfwsybchzkjgt) (Ping timeout: 252 seconds)
  269. # [11:18] * Quits: FerasM (sid28672@gateway/web/irccloud.com/x-qgltsngvhknyywii) (Ping timeout: 252 seconds)
  270. # [11:18] * Joins: FerasM (sid28672@gateway/web/irccloud.com/x-hiyocbjksbcziuxd)
  271. # [11:19] * Joins: tobie_ (sid5692@gateway/web/irccloud.com/x-itwahlcxyanyritv)
  272. # [11:25] * Quits: kochi1 (~kochi@2401:fa00:4:1000:6585:51fa:8ccd:6574) (Ping timeout: 260 seconds)
  273. # [11:25] * Quits: kochi (~kochi@2401:fa00:4:1000:6585:51fa:8ccd:6574) (Ping timeout: 260 seconds)
  274. # [11:26] * Joins: kochi (~kochi@2401:fa00:4:1000:f0c6:ba2a:2ca:fda2)
  275. # [11:26] * Joins: kochi1 (~kochi@2401:fa00:4:1000:f0c6:ba2a:2ca:fda2)
  276. # [11:28] * Joins: twisted`_ (sid6794@gateway/web/irccloud.com/x-cxwhhrhawrmgjmgm)
  277. # [11:32] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Remote host closed the connection)
  278. # [11:35] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  279. # [11:35] * Joins: adactio (~adactio@212.42.170.121)
  280. # [11:41] * Joins: richt_ (~richt@83.218.67.123)
  281. # [11:41] * Joins: roc (~chatzilla@121-98-106-217.bng1.tvc.orcon.net.nz)
  282. # [11:41] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  283. # [11:42] * Parts: a-ja (~Instantbi@70.230.146.131)
  284. # [11:43] <Ms2ger> I guess all the webperf stuff is not exposed in workers?
  285. # [11:44] * Quits: richt (~richt@83.218.67.123) (Ping timeout: 260 seconds)
  286. # [11:47] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  287. # [12:08] * Quits: raidendev (~raidendev@188.92.107.182) (Ping timeout: 264 seconds)
  288. # [12:14] * Joins: raidendev (~raidendev@188.92.107.182)
  289. # [12:22] * Quits: tav (~tav`@host109-154-0-16.range109-154.btcentralplus.com) (Quit: tav)
  290. # [12:22] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Remote host closed the connection)
  291. # [12:23] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  292. # [12:23] * Quits: kochi1 (~kochi@2401:fa00:4:1000:f0c6:ba2a:2ca:fda2) (Quit: Leaving.)
  293. # [12:24] * Joins: kochi1 (~kochi@2401:fa00:4:1000:f0c6:ba2a:2ca:fda2)
  294. # [12:25] * Joins: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  295. # [12:25] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Read error: Connection reset by peer)
  296. # [12:34] * Quits: jingtaol_ (~technommy@61.144.248.40) (Remote host closed the connection)
  297. # [12:34] * Joins: jingtaoliu (~technommy@61.144.248.40)
  298. # [12:35] * Quits: satazor (~satazor@26.186.108.93.rev.vodafone.pt) (Remote host closed the connection)
  299. # [12:36] * Joins: satazor (~satazor@26.186.108.93.rev.vodafone.pt)
  300. # [12:38] * Quits: jingtaoliu (~technommy@61.144.248.40) (Ping timeout: 240 seconds)
  301. # [12:40] * Quits: satazor (~satazor@26.186.108.93.rev.vodafone.pt) (Ping timeout: 260 seconds)
  302. # [12:44] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
  303. # [12:44] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  304. # [12:48] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 256 seconds)
  305. # [12:49] * Quits: mounir (~mounir@oldworld.fr) (Quit: leaving)
  306. # [12:51] * Joins: encryptd_fractl (~encryptd_@209.201.113.2)
  307. # [12:52] * Joins: jarek (~jarek@unaffiliated/jarek)
  308. # [12:55] <Ms2ger> Should one expose MouseEvent in workers?
  309. # [12:55] * Quits: encryptd_fractl (~encryptd_@209.201.113.2) (Ping timeout: 240 seconds)
  310. # [12:57] * Joins: satazor (~satazor@239.201.37.188.rev.vodafone.pt)
  311. # [13:02] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: :tiuQ tiuq sah woclrak)
  312. # [13:15] * Joins: tav (~tav`@host109-154-0-16.range109-154.btcentralplus.com)
  313. # [13:19] * Quits: jochen__ (jochen@nat/google/x-nasufvxdowocuery) (Remote host closed the connection)
  314. # [13:22] * Joins: jingtaoliu (~technommy@183.37.190.14)
  315. # [13:22] * Quits: jingtaoliu (~technommy@183.37.190.14) (Remote host closed the connection)
  316. # [13:23] * Joins: jingtaoliu (~technommy@183.37.190.14)
  317. # [13:27] * Joins: jochen__ (jochen@nat/google/x-pijqdcymvnhywztm)
  318. # [13:30] * Quits: tav (~tav`@host109-154-0-16.range109-154.btcentralplus.com) (Quit: tav)
  319. # [13:38] * Quits: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Remote host closed the connection)
  320. # [13:39] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  321. # [13:41] * Joins: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  322. # [13:41] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Read error: Connection reset by peer)
  323. # [13:42] <satazor> hey guys
  324. # [13:42] <satazor> I'm having an issue with fs.utimes because it is messing with ctime
  325. # [13:43] <satazor> is it expected? Or was it expected to change only the mtime & atime as the documentation says?
  326. # [13:44] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  327. # [13:46] <satazor> oops
  328. # [13:46] <satazor> wrong channel
  329. # [13:46] <satazor> ahahz
  330. # [13:49] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Ping timeout: 240 seconds)
  331. # [13:58] * Quits: Smylers (~smylers@81.143.60.194) (Ping timeout: 240 seconds)
  332. # [13:59] * Joins: scor (scor@nat/acquia/x-eugzihasjhoqpfxl)
  333. # [13:59] * Quits: scor (scor@nat/acquia/x-eugzihasjhoqpfxl) (Changing host)
  334. # [13:59] * Joins: scor (scor@drupal.org/user/52142/view)
  335. # [14:00] * Quits: scor (scor@drupal.org/user/52142/view) (Client Quit)
  336. # [14:07] * Quits: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Remote host closed the connection)
  337. # [14:08] * Joins: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  338. # [14:08] * Quits: satazor (~satazor@239.201.37.188.rev.vodafone.pt) (Remote host closed the connection)
  339. # [14:08] * Quits: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Read error: Connection reset by peer)
  340. # [14:08] * Joins: satazor (~satazor@bl16-81-102.dsl.telepac.pt)
  341. # [14:08] * Joins: scor (scor@nat/acquia/x-fcthmqhnnnjxedsy)
  342. # [14:08] * Quits: scor (scor@nat/acquia/x-fcthmqhnnnjxedsy) (Changing host)
  343. # [14:08] * Joins: scor (scor@drupal.org/user/52142/view)
  344. # [14:09] * Joins: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  345. # [14:13] * Quits: satazor (~satazor@bl16-81-102.dsl.telepac.pt) (Ping timeout: 240 seconds)
  346. # [14:15] * Joins: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com)
  347. # [14:18] * Joins: tj_vantoll (~Adium@2601:4:5380:2ec:dded:a3f9:736d:3fce)
  348. # [14:20] * Quits: jensnockert_ (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Remote host closed the connection)
  349. # [14:20] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  350. # [14:35] * Joins: tav (~tav`@93-152-5-50.v.managedbroadband.co.uk)
  351. # [14:36] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Remote host closed the connection)
  352. # [14:43] * Joins: BigBangUDR (~Thunderbi@103.249.181.147)
  353. # [14:44] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: jarek)
  354. # [14:45] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  355. # [14:48] * Joins: ehynds (~ehynds@64.206.121.41)
  356. # [14:50] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Ping timeout: 264 seconds)
  357. # [14:52] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  358. # [14:54] * Quits: BigBangUDR (~Thunderbi@103.249.181.147) (Quit: BigBangUDR)
  359. # [14:54] * Quits: tj_vantoll (~Adium@2601:4:5380:2ec:dded:a3f9:736d:3fce) (Read error: Connection reset by peer)
  360. # [14:56] * Joins: tj_vantoll (~Adium@2601:4:5380:2ec:dded:a3f9:736d:3fce)
  361. # [15:02] * Joins: newtron (~newtron@199.71.174.203)
  362. # [15:03] * Joins: Smylers (~smylers@81.143.60.194)
  363. # [15:07] <JakeA> If the browser receives "<body>Hello w" is there any way to tell that's an incomplete response vs the server intending to send that?
  364. # [15:07] <JakeA> Assuming Content-Length is not to be trusted
  365. # [15:07] <jgraham> Content-Length has to be trusted
  366. # [15:08] <jgraham> At least in HTTP 1.1
  367. # [15:08] <jgraham> In 1.0 you could theoretically rely on the server to close the connection I think
  368. # [15:08] <JakeA> So if we get a response longer/shorter than Content-Length, what happens?
  369. # [15:09] <gsnedders> shorter you just hang until you timeout
  370. # [15:10] <gsnedders> longer is more complex :P
  371. # [15:11] * Joins: satazor (~satazor@26.186.108.93.rev.vodafone.pt)
  372. # [15:13] <JakeA> Then I shall build a test. Quick, to the local server! *nodejs logo zooms into the screen & back out again*
  373. # [15:13] <jgraham> You could build a test that you could submit to web-platform-test, you know
  374. # [15:14] <jgraham> Like http://w3c-test.org/http/
  375. # [15:15] <jgraham> The test there is a simple "too long" test
  376. # [15:16] <jgraham> From when annevk was asking about the same things
  377. # [15:20] <gsnedders> JakeA: longer depends on things like whether pipelining support is enabled, IIRC
  378. # [15:23] <JakeA> jgraham: Is that documented somewhere, like how to get a local version running for development
  379. # [15:23] * Joins: abinader (sid21713@gateway/web/irccloud.com/x-yqwerdvubnsoznve)
  380. # [15:24] * Joins: TallTed (~Thud@63.119.36.36)
  381. # [15:24] <jgraham> https://github.com/w3c/web-platform-tests has basic documentation
  382. # [15:25] * Quits: satazor (~satazor@26.186.108.93.rev.vodafone.pt) (Remote host closed the connection)
  383. # [15:25] <jgraham> http://wptserve.readthedocs.org/en/latest/ has more detailed server documentation
  384. # [15:25] * Joins: satazor (~satazor@26.186.108.93.rev.vodafone.pt)
  385. # [15:25] <jgraham> It should all end up on testthewebforward.org, but unfortunately I* need to do quite a bit of infrastructure work on the site to make that happen
  386. # [15:25] <jgraham> *Or someone else of course
  387. # [15:30] * Quits: satazor (~satazor@26.186.108.93.rev.vodafone.pt) (Ping timeout: 272 seconds)
  388. # [15:38] * Joins: satazor (~satazor@bl16-81-102.dsl.telepac.pt)
  389. # [15:41] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Remote host closed the connection)
  390. # [15:42] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  391. # [15:45] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  392. # [15:46] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Ping timeout: 240 seconds)
  393. # [15:49] * Quits: toydestroyer (~toydestro@mail.moneks.ru)
  394. # [15:50] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Ping timeout: 256 seconds)
  395. # [15:52] * Joins: karlcow (~karl@nerval.la-grange.net)
  396. # [15:53] * Quits: jungkees (uid24208@gateway/web/irccloud.com/x-wnyntntxpznakjsd) (Quit: Connection closed for inactivity)
  397. # [16:02] * Joins: toydestroyer (~toydestro@194.186.53.92)
  398. # [16:02] * Joins: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi)
  399. # [16:03] * Joins: encryptd_fractl (~encryptd_@209.201.113.2)
  400. # [16:04] * `nik`_ is now known as `nik`
  401. # [16:05] * Quits: toydestroyer (~toydestro@194.186.53.92) (Client Quit)
  402. # [16:10] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 260 seconds)
  403. # [16:13] <smaug____> why do we need Fetch API?
  404. # [16:13] * Joins: karlcow (~karl@nerval.la-grange.net)
  405. # [16:15] * Joins: annevk (~annevk@185.28.53.106)
  406. # [16:19] * Quits: annevk (~annevk@185.28.53.106) (Remote host closed the connection)
  407. # [16:25] * Joins: annevk (~annevk@185.28.53.106)
  408. # [16:28] * Quits: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com) (Remote host closed the connection)
  409. # [16:28] * Joins: weinig (~weinig@98.234.191.242)
  410. # [16:29] * Quits: mven_ (~textual@ip68-104-38-84.lv.lv.cox.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  411. # [16:30] <jgraham> smaug____: I think it's fair to say we don't *need* it. We might want it though.
  412. # [16:30] <smaug____> ok, why do we want it
  413. # [16:31] <smaug____> XHR isn't too good, sure
  414. # [16:31] <smaug____> but so aren't many other APIs
  415. # [16:33] * Quits: KevinMarks2 (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
  416. # [16:34] * Joins: BigBangUDR (~Thunderbi@101.60.16.141)
  417. # [16:34] * Quits: BigBangUDR (~Thunderbi@101.60.16.141) (Client Quit)
  418. # [16:35] <jgraham> I believe "we have lots of crappy APIs therefore having crappy APIs is OK" isn't universially considered to be a winning argument
  419. # [16:35] * Joins: KevinMarks2 (~yaaic@2607:fb90:404:4b36:fdae:e455:1c6d:7c14)
  420. # [16:39] * Joins: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com)
  421. # [16:39] * Joins: raiden (~raidendev@188.92.107.182)
  422. # [16:42] * Quits: raidendev (~raidendev@188.92.107.182) (Ping timeout: 240 seconds)
  423. # [16:42] <annevk> SimonSapin: sounds like those IPv4 tests are broken
  424. # [16:42] <annevk> SimonSapin: IPv4 is basically no different from a domain per the specification in terms of parsing
  425. # [16:42] <annevk> SimonSapin: resolving any other numeric sequence as IPv4 is bad for security
  426. # [16:43] <SimonSapin> annevk: looks like at least Firefox and Chrome do it
  427. # [16:43] * Quits: tav (~tav`@93-152-5-50.v.managedbroadband.co.uk) (Quit: tav)
  428. # [16:44] <annevk> SimonSapin: I know, Safari doesn't
  429. # [16:45] * Joins: nicolasbadia (~nicolasba@78.209.78.103)
  430. # [16:45] <JakeA> smaug____: ServiceWorker needs Request/Response. Also opaque responses for corss-origin no-cors requests
  431. # [16:46] <jgraham> JakeA: In principle you could add Request/Response to XHR, so it doesn't fully justify Fetch
  432. # [16:46] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  433. # [16:46] <jgraham> And certainly not Fetch-in-document
  434. # [16:48] <JakeA> I suppose you could hack it on, but ugh
  435. # [16:48] <jgraham> Speaking of Service Worker, is there a mechanism for communicating from the main thread to a service worker when it is launched? e.g. could you use the document fragment?
  436. # [16:48] <jgraham> s/document/URL/
  437. # [16:49] <SimonSapin> annevk: So Safary tries to resolves these addresses from DNS?
  438. # [16:49] <SimonSapin> Safari
  439. # [16:49] <annevk> SimonSapin: not sure exactly how the network layer deals with the address given
  440. # [16:50] <annevk> SimonSapin: file a bug if it's still unclear, I got some tea and chocolate to take care of
  441. # [16:50] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Ping timeout: 240 seconds)
  442. # [16:50] <JakeA> jgraham: you could use fragment, but that can only be set at registration time
  443. # [16:51] <SimonSapin> annevk: I filed https://github.com/w3c/web-platform-tests/issues/1104 , should it be in the spec’s bugzilla instead?
  444. # [16:51] <jgraham> JakeA: I think that might be OK here?
  445. # [16:51] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  446. # [16:52] <JakeA> jgraham: What's the use-case?
  447. # [16:52] <annevk> SimonSapin: maybe, let's talk about it two weeks from now
  448. # [16:52] <jgraham> The context is a mechanism to pass harness configuration parameters in to testcases. In particular the timeout. For normal tests this is set in a meta element in the HTML document so that it can be read by the manifest generation stuff
  449. # [16:53] <jgraham> So only being able to specify it in JS isn't very helpful
  450. # [16:53] <SimonSapin> annevk: who two weeks, are you gonna be in London?
  451. # [16:53] * Quits: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com) (Remote host closed the connection)
  452. # [16:53] <jgraham> In the worst case, I guess I could use specially formatted comments or similar
  453. # [16:53] <annevk> SimonSapin: no, but I won't be on vacation
  454. # [16:53] <SimonSapin> eh, ok :)
  455. # [16:54] * Quits: annevk (~annevk@185.28.53.106) (Remote host closed the connection)
  456. # [16:56] * Joins: tj_vantoll1 (~Adium@c-98-250-130-237.hsd1.mi.comcast.net)
  457. # [16:57] * Quits: Ducki (~Ducki@191.233.66.1) (Remote host closed the connection)
  458. # [16:58] * Quits: tj_vantoll (~Adium@2601:4:5380:2ec:dded:a3f9:736d:3fce) (Ping timeout: 260 seconds)
  459. # [16:58] * Quits: newtron (~newtron@199.71.174.203) (Ping timeout: 240 seconds)
  460. # [17:02] <JakeA> jgraham: Yeah, fragment or querystring would work then.
  461. # [17:02] * Joins: dawhite (~dawhite@74.118.22.223)
  462. # [17:02] * Joins: BigBangUDR (~Thunderbi@101.60.16.141)
  463. # [17:03] * Quits: BigBangUDR (~Thunderbi@101.60.16.141) (Client Quit)
  464. # [17:08] <smaug____> JakeA: why does serviceworker even need Request/Response ? (but yes, those could be hacked into XHR)
  465. # [17:08] * smaug____ is just trying to understand the reasoning behind Fetch API
  466. # [17:08] * smaug____ doesn't have any opinion whether the API is a good or bad thing
  467. # [17:09] * Joins: toydestroyer (~toydestro@46.39.35.204)
  468. # [17:10] <JakeA> smaug____: the fetch event of the serviceworker allows developers to hijack a request and respond differently. Request lets them get information about the intended request, Response lets them construct their own.
  469. # [17:10] * Quits: toydestroyer (~toydestro@46.39.35.204) (Client Quit)
  470. # [17:12] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Read error: Connection reset by peer)
  471. # [17:13] * Joins: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi)
  472. # [17:14] * Quits: markkes (~markkes@62.207.90.201) (Ping timeout: 264 seconds)
  473. # [17:15] * Joins: lmclister (~lmclister@192.150.10.209)
  474. # [17:17] * Joins: ehsan (~ehsan@2001:450:1f:224:e421:b39d:6fa3:3279)
  475. # [17:18] * Joins: toydestroyer (~toydestro@95.85.2.130)
  476. # [17:20] * Quits: KevinMarks2 (~yaaic@2607:fb90:404:4b36:fdae:e455:1c6d:7c14) (Ping timeout: 240 seconds)
  477. # [17:23] * Joins: KevinMarks2 (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  478. # [17:30] <Domenic> JakeA: why do both Request and Response have a .body?
  479. # [17:30] * Quits: richt_ (~richt@83.218.67.123) (Remote host closed the connection)
  480. # [17:30] <JakeA> Domenic: If I'm posting formdata to a server, that request has a body
  481. # [17:31] <JakeA> Domenic: if the server responds with "yay everything's great", that response has a body
  482. # [17:31] <Domenic> JakeA: OK, but why would you readAsJSON() the request body?
  483. # [17:32] <JakeA> Domenic: If the content type of the body is json & you want to read it
  484. # [17:32] <Domenic> JakeA: but you put the data there, so you shouldn't need to read it...
  485. # [17:32] <Domenic> JakeA: and in fact having the ability to read it means that you must buffer it all in memory in case someone does read it
  486. # [17:33] <JakeA> Domenic: The page may have put it there, but you still may want to read it, or pipe it into another request with a transform in the middle
  487. # [17:33] <JakeA> Eg, convert formdata into JSON for another endpoint
  488. # [17:34] <Domenic> JakeA: then you should do that before writing it to the request
  489. # [17:34] <Domenic> JakeA: forcing buffering of all the data in memory that you write to the request is quite bad
  490. # [17:34] <JakeA> Domenic: Where is that being forced?
  491. # [17:35] <Domenic> JakeA: the fact that you can call readAsJSON() at any time on the request body stream forces that
  492. # [17:35] <Domenic> JakeA: it means you can't fire-and-forget bytes over the wire
  493. # [17:36] <JakeA> Domenic: if you call asJSON you're consuming the stream & yes you'll have to read it into memory. If you don't call that, you don't.
  494. # [17:36] <JakeA> Domenic: Same with responses
  495. # [17:37] <Domenic> JakeA: that doesn't make sense. The fact that someone *could* call readAsJSON() means that the socket can never consume data from the request body directly. You need to copy all the buffers that are written to the request body somewhere temporary in case someone calls requestBody.readAsJSON() later, even after the HTTP connection is closed, as long as
  496. # [17:37] <Domenic> requestBody is not GCed
  497. # [17:38] <jgraham> That's true, but is it a problem?
  498. # [17:38] * Quits: weinig (~weinig@98.234.191.242) (Quit: weinig)
  499. # [17:38] <jgraham> It *might* be
  500. # [17:38] <JakeA> Domenic: once the request is given to something like fetch(), its body stream is consumed
  501. # [17:38] <Domenic> JakeA: so calling readAsJSON() errors?
  502. # [17:39] <JakeA> Domenic: yes
  503. # [17:39] <Domenic> JakeA: so that means FetchBodyStream is a readable stream. So how do you write to it?
  504. # [17:39] * Joins: dbaron (~dbaron@50-0-128-161.dsl.dynamic.sonic.net)
  505. # [17:40] <JakeA> Domenic: new Request(url, {body: stream})
  506. # [17:40] <Domenic> JakeA: how do you write to stream? Since it is readable, not writable
  507. # [17:42] <JakeA> Domenic: I'm not up-to-date on the plans for the streaming API. If I wanted to create my own readable stream, how would I do that?
  508. # [17:42] <Domenic> JakeA: https://whatwg.github.io/streams/#rs-intro
  509. # [17:44] <JakeA> Domenic: start(enqueue, close, error) { - is that creating a "start" property on that object?
  510. # [17:47] <JakeA> Domenic: Assuming yes, you could create a readable stream like that & use it when constructing a Request object
  511. # [17:47] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  512. # [17:47] <JakeA> Domenic: You should be able to pipe a response body into a new request
  513. # [17:48] <Domenic> JakeA: that's the thing though. You pipe to writable streams, not to readable streams
  514. # [17:48] <Domenic> JakeA: see my latest email to whatwg@
  515. # [17:49] <Domenic> you are proposing option 2 in my email, I guess. Which is kinda annoying and unidiomatic, from a streams point of view.
  516. # [17:49] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
  517. # [17:49] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  518. # [17:49] <JakeA> Domenic: you're not piping to a readable stream, you're passing a stream into the constructor (which will also take a blob, arraybuffer etc)
  519. # [17:50] <Domenic> JakeA: yes, that is the problem, you can no longer pipe or write directly, you have to wrap things into readable streams
  520. # [17:51] <Domenic> JakeA: ideally things you can write to are represented as writable streams, not as functions accepting readable streams
  521. # [17:52] <JakeA> Domenic: ahh ok, understanding better now
  522. # [17:53] <JakeA> reading that thread…
  523. # [17:54] * Joins: annevk (~annevk@185.28.53.106)
  524. # [17:56] * Joins: mven_ (~textual@169.241.49.198)
  525. # [17:57] * Quits: encryptd_fractl (~encryptd_@209.201.113.2) (Remote host closed the connection)
  526. # [17:57] * Joins: Maurice` (copyman@5ED5617C.cm-7-6b.dynamic.ziggo.nl)
  527. # [18:00] * Quits: satazor (~satazor@bl16-81-102.dsl.telepac.pt) (Remote host closed the connection)
  528. # [18:00] * Joins: satazor (~satazor@bl16-81-102.dsl.telepac.pt)
  529. # [18:01] * Joins: encryptd_fractl (~encryptd_@209.201.113.2)
  530. # [18:02] * Joins: tav (~tav`@575193a2.skybroadband.com)
  531. # [18:05] * Quits: satazor (~satazor@bl16-81-102.dsl.telepac.pt) (Ping timeout: 240 seconds)
  532. # [18:07] * Quits: zdobersek (~zan@46.166.186.239) (Quit: Leaving.)
  533. # [18:07] * Quits: mven_ (~textual@169.241.49.198) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  534. # [18:10] * Quits: annevk (~annevk@185.28.53.106) (Remote host closed the connection)
  535. # [18:13] <JakeA> Domenic: If a request comes into a serviceworker, you don't want that to have a writable stream. Its data is already being provided by something else.
  536. # [18:14] <Domenic> JakeA: ah, the old client-request vs. server-request thing...
  537. # [18:14] <Domenic> fetch(request) should take a client-request
  538. # [18:14] <Domenic> service workers should get a server-request
  539. # [18:14] <JakeA> hmm, I should be able to do fetch(event.request)
  540. # [18:16] <Domenic> you should?
  541. # [18:16] <Domenic> from a server's point of view, a request contains data to read
  542. # [18:17] <Domenic> from a client's point of view, a request is something you write to
  543. # [18:17] <Domenic> i am not sure how you would reconcile that
  544. # [18:17] <Domenic> one is mutable, the other is immutable
  545. # [18:18] * Joins: satazor (~satazor@239.201.37.188.rev.vodafone.pt)
  546. # [18:18] <JakeA> Domenic: Say I get a fetch event, which gives me a request object, how should I then fetch it so I can look at headers before doing something with the response?
  547. # [18:20] <Domenic> JakeA: well, yeah, I see the use case. My only answer is a bad one... essentially copying over the relevant info (URL, headers, body, ...) from the request-to-the-service-worker into a new request-to-the-remote-server
  548. # [18:20] * Quits: satazor (~satazor@239.201.37.188.rev.vodafone.pt) (Remote host closed the connection)
  549. # [18:21] * Joins: satazor (~satazor@239.201.37.188.rev.vodafone.pt)
  550. # [18:21] * Joins: markkes (~markkes@62.207.90.201)
  551. # [18:21] <Domenic> Let me see if I can recall how/if Node does this... it might be just copying though, which is bad, in which case we'll have to think of something else
  552. # [18:23] * Quits: dawhite (~dawhite@74.118.22.223) (Read error: Connection reset by peer)
  553. # [18:23] <Domenic> JakeA: yeah, it is pretty much just copying, meh... http://stackoverflow.com/a/20354642/3191
  554. # [18:25] * Quits: cfq_ (sid18398@gateway/web/irccloud.com/x-sgkwulqdzqtnyetl) (Ping timeout: 260 seconds)
  555. # [18:25] * Quits: satazor (~satazor@239.201.37.188.rev.vodafone.pt) (Ping timeout: 240 seconds)
  556. # [18:26] * Joins: cfq_ (sid18398@gateway/web/irccloud.com/x-ywvyvejarnkqfjyt)
  557. # [18:26] * Quits: Smylers (~smylers@81.143.60.194) (Ping timeout: 240 seconds)
  558. # [18:27] <Domenic> JakeA: ends up looking like https://gist.github.com/domenic/1bbec0f341ae3cfb3a8f in service-worker land...
  559. # [18:28] <Domenic> JakeA: now I am thinking making it a writable stream is not worth the trouble...
  560. # [18:28] <Domenic> JakeA: or maybe we should make it a duplex stream
  561. # [18:29] <Domenic> (i.e. { input, output } pair, possibly { input, output, readAsJSON, ... }, or maybe put readAsJSON on output, at the cost of more typing...)
  562. # [18:30] <JakeA> Domenic: Would that be a different type to the request I get on the fetch event?
  563. # [18:30] <Domenic> JakeA: in the gist? yeah it should say ClientRequest; ev.request is a ServerRequest
  564. # [18:30] <Domenic> JakeA: the difference being that req.body is writable for ClientRequest, readable for ServerRequest
  565. # [18:30] <JakeA> Domenic: I mean your duplex idea
  566. # [18:31] * Joins: satazor (~satazor@bl16-81-102.dsl.telepac.pt)
  567. # [18:31] <Domenic> JakeA: the duplex idea would be that both client and servers re-use the same Request class, but req.body = { WritableStream input, ReadableStream output }
  568. # [18:32] <Domenic> JakeA: conceptually, a client will start with an "empty" stream, and write things into input
  569. # [18:32] <Domenic> JakeA: whereas a server will start with a "full" stream and read things from output
  570. # [18:32] <Domenic> JakeA: for a client, once they write things into input, the computer then reads from output to consume the data. (Or, they could muck things up by consuming from output themselves, ensuring the network never sees that data.)
  571. # [18:33] <Domenic> JakeA: similarly for a server, the computer is writing things into input---or they could do so themselves, creating some chaos by mixing up computer-generated stream data with their own
  572. # [18:35] <JakeA> Domenic: I'm trying to get my head around why var req = new Request(url, {method: "POST"}); stream.pipeTo(req.body); is better than var req = new Request(url, {method: "POST", body: stream});
  573. # [18:35] * Joins: KevinMarks3 (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  574. # [18:36] * Quits: KevinMarks2 (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 272 seconds)
  575. # [18:36] <Domenic> JakeA: in the simplest case, it is not any better. But if you want to allow the full flexibility of a writable stream---it's own buffer, potentially combining input from multiple sources, setting up a pipe chain through several transforms, ... then having a writable destination is nice.
  576. # [18:39] <Domenic> JakeA: the duplex idea was designed to avoid such shenanigans
  577. # [18:39] <Domenic> JakeA: since you could just pass the duplex stream from ev.request into fetch(), since fetch() reads from the output side
  578. # [18:47] * Quits: raiden (~raidendev@188.92.107.182) (Ping timeout: 264 seconds)
  579. # [18:49] * Quits: sankha93 (uid12218@fsf/emeritus/sankha93)
  580. # [18:50] * Parts: adactio (~adactio@212.42.170.121)
  581. # [18:52] <JakeA> Domenic: still want to support setting the body as a blob, but I guess you'd still have an input, it'd just mess things up in new & interesting ways if you tried to use it
  582. # [18:54] * Quits: tj_vantoll1 (~Adium@c-98-250-130-237.hsd1.mi.comcast.net) (Quit: Leaving.)
  583. # [18:54] * Quits: Ms2ger (~Ms2ger@148.253-64-87.adsl-dyn.isp.belgacom.be) (Quit: Leaving)
  584. # [18:57] * Joins: shepazu (~shepazu@108-70-132-46.lightspeed.rlghnc.sbcglobal.net)
  585. # [19:00] * Joins: dawhite (~dawhite@74.118.22.223)
  586. # [19:03] * Joins: weinig (~weinig@17.202.50.223)
  587. # [19:05] * Krinkle|detached is now known as Krinkle
  588. # [19:09] * Quits: bnicholson (~bnicholso@24.130.57.109) (Ping timeout: 264 seconds)
  589. # [19:14] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  590. # [19:16] * Joins: bholley (~bholley@corp.mtv2.mozilla.com)
  591. # [19:21] * Quits: mmun (mmun@2600:3c03::f03c:91ff:fe69:74b6) (Quit: ZNC - http://znc.in)
  592. # [19:21] * Joins: raidendev (~raidendev@broadband-46-242-56-184.nationalcablenetworks.ru)
  593. # [19:23] * Joins: jsbell (jsbell@nat/google/x-rsjvsextlnqbvohs)
  594. # [19:26] * Joins: Areks (~Areks@95-28-254-201.broadband.corbina.ru)
  595. # [19:29] * Quits: cheron (~cheron@unaffiliated/cheron) (Ping timeout: 264 seconds)
  596. # [19:31] * Quits: m4nu (~manu@216.252.204.51) (Ping timeout: 240 seconds)
  597. # [19:31] * Joins: manu (~manu@216.252.204.51)
  598. # [19:34] * Joins: bnicholson (~bnicholso@2620:101:80fc:224:3e97:eff:feef:9aba)
  599. # [19:37] * Quits: dbaron (~dbaron@50-0-128-161.dsl.dynamic.sonic.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  600. # [19:42] * Quits: toydestroyer (~toydestro@95.85.2.130)
  601. # [19:44] * Quits: wilhelm (~wilhelm@178.255.149.100) (Disconnected by services)
  602. # [19:54] <Hixie> so what do people think cross-spec references should look like?
  603. # [19:55] <Hixie> should every link to "URL" in the URL spec have a [URL] reference?
  604. # [19:55] <Hixie> should i not bother with [FOO] references except where there's no direct link to the spec?
  605. # [19:55] <Hixie> should i drop [FOO]-style refs entirely?
  606. # [19:56] <caitp> cross-spec references should: not require you to scroll to the end of the (likely very, very long document) to find links to the specs
  607. # [19:56] <Hixie> yeah that's a given
  608. # [19:57] <Hixie> assume that the links are now real cross-spec links
  609. # [19:58] * Joins: rniwa (~rniwa@17.202.43.222)
  610. # [20:01] * Quits: KevinMarks3 (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
  611. # [20:05] * Joins: anchnk (~anchnk@static-176-182-127-143.ncc.abo.bbox.fr)
  612. # [20:08] * Quits: TallTed (~Thud@63.119.36.36)
  613. # [20:08] * Joins: TallTed (~Thud@63.119.36.36)
  614. # [20:09] * Joins: BigBangUDR (~Thunderbi@101.60.16.141)
  615. # [20:11] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Remote host closed the connection)
  616. # [20:11] * Joins: KevinMarks2 (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
  617. # [20:11] * Quits: BigBangUDR (~Thunderbi@101.60.16.141) (Client Quit)
  618. # [20:14] * Joins: dbaron (~dbaron@2620:101:80fb:224:c5a1:c95a:6622:1af0)
  619. # [20:21] * Quits: weinig (~weinig@17.202.50.223) (Quit: weinig)
  620. # [20:23] * Joins: mmun (~textual@199.119.233.153)
  621. # [20:24] * Joins: estellevw (~estellewy@209.49.66.106)
  622. # [20:28] * Quits: encryptd_fractl (~encryptd_@209.201.113.2) (Remote host closed the connection)
  623. # [20:30] * Joins: weinig (~weinig@17.114.1.232)
  624. # [20:32] * Quits: satazor (~satazor@bl16-81-102.dsl.telepac.pt) (Remote host closed the connection)
  625. # [20:33] * Joins: satazor (~satazor@bl16-81-102.dsl.telepac.pt)
  626. # [20:34] * Quits: bholley (~bholley@corp.mtv2.mozilla.com) (Quit: Textual IRC Client: www.textualapp.com)
  627. # [20:37] * Quits: satazor (~satazor@bl16-81-102.dsl.telepac.pt) (Ping timeout: 240 seconds)
  628. # [20:44] * Joins: satazor (~satazor@bl16-81-102.dsl.telepac.pt)
  629. # [20:46] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 256 seconds)
  630. # [20:46] * Quits: satazor (~satazor@bl16-81-102.dsl.telepac.pt) (Read error: Connection reset by peer)
  631. # [20:47] * Joins: satazor (~satazor@239.201.37.188.rev.vodafone.pt)
  632. # [20:49] * Quits: mmun (~textual@199.119.233.153) (Quit: My MacBook has gone to sleep. ZZZzzz…)
  633. # [20:50] * Quits: weinig (~weinig@17.114.1.232) (Quit: weinig)
  634. # [20:51] * Joins: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon)
  635. # [20:55] <jgraham> Hixie: What do you mean by "[FOO]" references? i.e. what's the distinguishing feature that you have in mind?
  636. # [20:57] * Joins: weinig (~weinig@17.114.1.232)
  637. # [20:59] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  638. # [20:59] <Hixie> jgraham: so right now the spec says things like "The foobar is a blooberry. [FOO]"
  639. # [20:59] <Hixie> jgraham: which then links to the References section and describes the Foo spec
  640. # [21:00] <Hixie> so i'd like "foobar" here to link directly to the definition of "foobar" in the Foo spec
  641. # [21:00] <Hixie> but what about the next paragraph, which also has a "foobar" in it? Should it also say [FOO]? Should neither say [FOO]?
  642. # [21:00] <Hixie> the [FOO] right now is just included where i made an editorial decision to include it
  643. # [21:00] <Hixie> it's somewhat arbitrary
  644. # [21:01] <Hixie> also, what about cases where there's no specific term, but still a reference to another spec, e.g.: "Implementations that support the XHTML syntax must support some version of XML, as well as its corresponding namespaces specification, because that syntax uses an XML serialisation with namespaces. [XML] [XMLNS]"
  645. # [21:02] <Hixie> basically i'm asking what you think cross-spec references should look like if we forget our legacy
  646. # [21:02] <jgraham> Well arguably in that case "XML" and "namespaces" should be linked
  647. # [21:02] <Hixie> to just the specs?
  648. # [21:02] <jgraham> Yeah
  649. # [21:02] <caitp> Hixie: from my perspective, in a single paragraph, you shouldn't have multiple links to the same section of a referenced spec
  650. # [21:02] <caitp> maybe in the same group of paragraphs
  651. # [21:03] <Hixie> caitp: well i want every reference to a term to link to the same place
  652. # [21:03] <jgraham> ink consistently linking terms defined elsewhere like you would terms defined in the spec makes much more sense
  653. # [21:03] <jgraham> *I think
  654. # [21:03] <Hixie> so drop the whole [FOO]-style refernece thing and the references section?
  655. # [21:04] <caitp> what I mean is, `The foobar is a blooberry. The foobar makes a delicious pie.` should end up as `The [FOO#foobar] is a blooberry. the foobar makes a delicious pie.` and not The [FOO#foobar] is a blooberry. the [FOO#foobar] makes a delicious pie.`
  656. # [21:04] <jgraham> Well you could have a references section that would just be a list of other specs that get referenced
  657. # [21:05] <jgraham> But I don't know how useful it is
  658. # [21:05] <caitp> otherwise it just gets a bit link-spammy
  659. # [21:05] <jgraham> caitp: It shouldn't use a different style compared to internal references
  660. # [21:05] <Hixie> jgraham: but not link to it?
  661. # [21:06] <caitp> the notation is just indicating that it's a link to the foobar section of the FOO spec
  662. # [21:06] <caitp> not that it's a different style
  663. # [21:06] <jgraham> Hixie: I don't think linking to it is all that practical
  664. # [21:06] <Hixie> jgraham: k
  665. # [21:06] <jgraham> caitp: Right, I meant "style" in the sense of "how often it links"
  666. # [21:07] <Hixie> caitp: the problem is that if different occurences of the term look different (e.g. one is a link, one is not) then it's confusing.
  667. # [21:07] <jgraham> i.e. my suggestion is "do what you already do and ignore the difference between internal and external references"
  668. # [21:07] <caitp> hmm, that's true
  669. # [21:07] <Hixie> caitp: i think with the current underline-less style, link-spamminess is much less of a problem
  670. # [21:07] <caitp> well you probably do want to clearly identify that it's a link to somewhere else
  671. # [21:07] <jsbell> The reasons I can think of to maintain [FOO]-style links to a references section are (1) use of the spec when printed and (2) adding additional metadata, such as a specific version/date. Neither of which seem to be worth the visual noise and maintenance burden, but YMMV.
  672. # [21:07] <jgraham> In terms of visual style a small marker to indicate an external link might be nice. Maybe *that* could link to the references section, if you want such a thing
  673. # [21:08] * Joins: encryptd_fractl (~encryptd_@209.201.113.2)
  674. # [21:08] <Hixie> jsbell: well we don't include the version or date anyway, since we're always linking to the latest revision
  675. # [21:08] <jsbell> Yep.
  676. # [21:09] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  677. # [21:09] <Hixie> jgraham: it's been suggested that links to terms should have a popup that inline the definition and text around it. i figured for external links this would include the reference or something.
  678. # [21:09] <Hixie> though kittens know how i figure out what reference to actually use
  679. # [21:10] <Hixie> but that's a separate issue
  680. # [21:10] <Hixie> one thing is that MikeSmith wanted the references section to link to all the sections that referenced the spec in question
  681. # [21:10] <Hixie> which would be harder if there's no marker to link back to...
  682. # [21:10] <jgraham> Hixie: Oh well if you are going fancy, that could work. But it's not clear to me that inlining the reference is at all practical
  683. # [21:10] <jgraham> e.g. if it's the whole XML spec
  684. # [21:10] <Hixie> jgraham: i just meant the title and editor names and so on
  685. # [21:11] * Quits: estellevw (~estellewy@209.49.66.106) (Quit: estellevw)
  686. # [21:11] <Hixie> ok i guess for now i'm going to leave the [FOO] links alone and think about it some more, and i'll make the cross-spec links completely independent of this
  687. # [21:11] * Joins: jernoble (~jernoble@17.202.46.221)
  688. # [21:12] <Hixie> no magic to autoinsert the right [FOO]s when there's a cross-spec cross-ref or whatever
  689. # [21:14] * Joins: bholley (~bholley@corp.mtv2.mozilla.com)
  690. # [21:16] * Joins: mmun (~textual@38.116.199.130)
  691. # [21:18] * Quits: dbaron (~dbaron@2620:101:80fb:224:c5a1:c95a:6622:1af0) (Ping timeout: 240 seconds)
  692. # [21:18] <astearns> Hixie: FWIW, I use real cross-ref links everywhere, and only add a [FOO] to the first instance where a particular spec is linked
  693. # [21:18] <Hixie> that makes sense
  694. # [21:18] <astearns> mainly to build the reference index
  695. # [21:22] <smaug____> dglazkov_: ping
  696. # [21:27] * Quits: encryptd_fractl (~encryptd_@209.201.113.2) (Remote host closed the connection)
  697. # [21:27] <Hixie> man there sure are a lot of <dfn>s in the HTML spec that aren't used by anything in the spec
  698. # [21:29] * Quits: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr) (Ping timeout: 256 seconds)
  699. # [21:29] * Joins: encryptd_fractl (~encryptd_@209.201.113.2)
  700. # [21:30] * Joins: estellevw (~estellewy@209.49.66.106)
  701. # [21:33] * Joins: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr)
  702. # [21:34] * Quits: satazor (~satazor@239.201.37.188.rev.vodafone.pt) (Ping timeout: 240 seconds)
  703. # [21:34] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
  704. # [21:36] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Remote host closed the connection)
  705. # [21:41] * Joins: Smylers (~smylers@host86-159-66-158.range86-159.btcentralplus.com)
  706. # [21:47] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  707. # [21:49] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Remote host closed the connection)
  708. # [21:50] * Joins: tj_vantoll (~Adium@2601:4:5380:2ec:10cd:f94f:c0c9:70f2)
  709. # [21:51] * Krinkle is now known as Krinkle|detached
  710. # [21:57] * Quits: lmclister (~lmclister@192.150.10.209)
  711. # [21:59] * Quits: CvP (~CvP@27.147.199.131) (Disconnected by services)
  712. # [21:59] * Joins: xCG (~CvP@27.147.199.131)
  713. # [22:00] * xCG is now known as CvP
  714. # [22:01] * Joins: raiden (~raidendev@broadband-46-242-56-184.nationalcablenetworks.ru)
  715. # [22:02] * Quits: weinig (~weinig@17.114.1.232) (Quit: weinig)
  716. # [22:03] * Quits: raidendev (~raidendev@broadband-46-242-56-184.nationalcablenetworks.ru) (Ping timeout: 264 seconds)
  717. # [22:05] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  718. # [22:07] * Krinkle|detached is now known as Krinkle
  719. # [22:08] * Quits: raiden (~raidendev@broadband-46-242-56-184.nationalcablenetworks.ru) (Ping timeout: 264 seconds)
  720. # [22:11] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Ping timeout: 240 seconds)
  721. # [22:12] * Quits: ehynds (~ehynds@64.206.121.41)
  722. # [22:14] * Joins: othermaciej (~mjs@17.114.217.113)
  723. # [22:16] * Joins: benjamingr (uid23465@gateway/web/irccloud.com/x-yuqgxmdiarrjgmis)
  724. # [22:27] * Joins: cheron (~cheron@unaffiliated/cheron)
  725. # [22:27] * Quits: CvP (~CvP@27.147.199.131) (Quit: [ UPP ] > all)
  726. # [22:30] * Joins: CvP (~CvP@27.147.199.131)
  727. # [22:31] * Joins: paintedbicycle (~paintedbi@S01067cb21bd8ee9a.vc.shawcable.net)
  728. # [22:32] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  729. # [22:32] * Quits: cheron (~cheron@unaffiliated/cheron) (Ping timeout: 240 seconds)
  730. # [22:40] * Quits: estellevw (~estellewy@209.49.66.106) (Quit: estellevw)
  731. # [22:42] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
  732. # [22:48] * Quits: TallTed (~Thud@63.119.36.36)
  733. # [22:50] * Joins: awrbgh (~awrbgh@197.195.69.253)
  734. # [22:50] <awrbgh> تحذير
  735. # [22:50] <awrbgh> warning
  736. # [22:50] <awrbgh> you may be watched
  737. # [22:50] <awrbgh> do usa&israel use the internet(facebook,youtube,twitter, chat rooms ..ect)to spy??
  738. # [22:50] <awrbgh> do usa&israel use the internet 2 collect informations,,can we call that spying??
  739. # [22:50] * Quits: awrbgh (~awrbgh@197.195.69.253) (Excess Flood)
  740. # [22:50] * Joins: awrbgh (~awrbgh@197.195.69.253)
  741. # [22:50] * Quits: awrbgh (~awrbgh@197.195.69.253) (Excess Flood)
  742. # [22:50] * Joins: awrbgh (~awrbgh@197.195.69.253)
  743. # [22:50] * Quits: awrbgh (~awrbgh@197.195.69.253) (Excess Flood)
  744. # [22:51] * Joins: awrbgh (~awrbgh@197.195.69.253)
  745. # [22:51] * Quits: awrbgh (~awrbgh@197.195.69.253) (Excess Flood)
  746. # [22:51] * Joins: awrbgh (~awrbgh@197.195.69.253)
  747. # [22:51] * Quits: awrbgh (~awrbgh@197.195.69.253) (Excess Flood)
  748. # [22:51] * Joins: awrbgh (~awrbgh@197.195.69.253)
  749. # [22:51] * Quits: awrbgh (~awrbgh@197.195.69.253) (Excess Flood)
  750. # [22:51] * Joins: awrbgh (~awrbgh@197.195.69.253)
  751. # [22:52] * Quits: awrbgh (~awrbgh@197.195.69.253) (Excess Flood)
  752. # [22:52] * Joins: awrbgh (~awrbgh@197.195.69.253)
  753. # [22:56] * Joins: dbaron (~dbaron@2620:101:80fb:232:ad93:477e:2eca:c864)
  754. # [22:57] * Quits: awrbgh (~awrbgh@197.195.69.253) (Ping timeout: 264 seconds)
  755. # [22:59] * Quits: othermaciej (~mjs@17.114.217.113) (Quit: othermaciej)
  756. # [23:04] <Hixie> not just usa&israel, i would imagine...
  757. # [23:04] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
  758. # [23:05] <caitp> well that was interesting
  759. # [23:05] * Joins: tav_ (~tav`@575193a2.skybroadband.com)
  760. # [23:06] * Quits: tav (~tav`@575193a2.skybroadband.com) (Ping timeout: 240 seconds)
  761. # [23:06] * tav_ is now known as tav
  762. # [23:09] <marcosc> Thinking of standardizing Wake Locks. Use cases: https://w3c-webmob.github.io/wake-lock-use-cases/
  763. # [23:09] <marcosc> would appreciate any feedback before proposing an API
  764. # [23:11] * Joins: othermaciej (~mjs@17.114.217.113)
  765. # [23:11] * Quits: Smylers (~smylers@host86-159-66-158.range86-159.btcentralplus.com) (Quit: Leaving.)
  766. # [23:13] * Joins: lmclister (~lmclister@192.150.10.209)
  767. # [23:15] <caitp> books doesn't seem like a good use case, you don't want to fall asleep reading a book on your ipad and have the system prevented from going to sleep o_o
  768. # [23:16] <Hixie> marcosc: my immediate reaction to the first sentence ("The web platform currently lacks a means to prevent a device from entering a power-saving state (i.e., some means that prevents an aspect of the system from "going to sleep").") was "and that's why i love the web"
  769. # [23:17] <caitp> don't media elements offer an attribute or something to prevent sleep? I thought they did but can't recall
  770. # [23:18] * Quits: Maurice` (copyman@5ED5617C.cm-7-6b.dynamic.ziggo.nl)
  771. # [23:18] <Hixie> marcosc: your document seems woefully short on abuse considerations
  772. # [23:18] <caitp> maybe it's just a default chosen by the implementation, I dunno
  773. # [23:19] <Hixie> marcosc: i would have an additional requirement, namely "the page must not be able to get any kind of wake lock without user opt-in"
  774. # [23:20] <caitp> really video elements seem like the only legitimate use case where you're going to leave the browser running for a specific use in the platform
  775. # [23:22] <caitp> otherwise, if you're a kiosk, you're disabling sleep on the system itself, if you're a videogame you're getting user input periodically, if you're a book you're turning pages, if you're a map/gps you're probably not a web browser unless someone is just printing directions out or something
  776. # [23:23] <Hixie> i don't see why Google Maps shouldn't support navigation on a phone
  777. # [23:23] <Hixie> i think that use case makes emminent sense
  778. # [23:23] <Hixie> i mean there's nothing really about the native Android Google Maps app that shouldn't be possible from a web app, imho
  779. # [23:25] <caitp> Hixie: you might use google maps on a phone, that would be fine
  780. # [23:25] * Joins: Smylers (~smylers@host86-159-66-158.range86-159.btcentralplus.com)
  781. # [23:25] <caitp> but you probably are using the android or ios app
  782. # [23:25] <caitp> which can keep the device awake natively
  783. # [23:25] <Hixie> but why should google need to make two or more navigation apps? instead of just a web app?
  784. # [23:25] <caitp> easier on the battery too, quite likely
  785. # [23:26] <caitp> well, google already does
  786. # [23:26] <Hixie> i see no reason why a web app shouldn't be able to do everything a native maps app can do, with no compromises (e.g. no worse battery usage)
  787. # [23:26] <caitp> and if they didn't, someone else would
  788. # [23:26] <caitp> (and someone else does, actually)
  789. # [23:26] <Hixie> but why is that a good thing?
  790. # [23:26] <caitp> because it is
  791. # [23:26] <Hixie> ...
  792. # [23:26] <Hixie> game over: you have lost your argument
  793. # [23:27] <caitp> lol
  794. # [23:27] <caitp> it's a good thing because other platforms do more than the web platform without going through the process of needing to get other implementations working the same way
  795. # [23:27] <caitp> and without being blocked on bugs in different implementations
  796. # [23:27] <Hixie> that arguments generalises to all features, and suggests the web shouldn't exist.
  797. # [23:28] <caitp> and that's really a logical conclusion, when you get down to it
  798. # [23:28] <marcosc> Hixie: true about abuse cases. Will add that.
  799. # [23:28] <Hixie> caitp: the web provides a key feature that none of the other platforms provides: it's vendor-neutral. the same app can work on any platform.
  800. # [23:29] <Hixie> caitp: that alone justifies its existence, imho
  801. # [23:29] <caitp> it's not really vendor-neutral, though
  802. # [23:29] <caitp> it's not
  803. # [23:29] <caitp> we try, we do try
  804. # [23:29] <caitp> but it's not
  805. # [23:29] <caitp> with simple documents we get pretty close
  806. # [23:29] <marcosc> caitp: did you read the document?
  807. # [23:29] <Hixie> caitp: by definition, anything that isn't interoperable across multiple vendors isn't part of the web. :-)
  808. # [23:31] <caitp> Hixie, when you add things to the web platform, you have this huge pile of constraints which aren't related whatsoever to the problem you're actually trying to solve
  809. # [23:31] <caitp> because of this, the web is not the single platform for all things
  810. # [23:31] <Hixie> that also describes every other platform, especially the old ones
  811. # [23:31] <caitp> it can't be, it's not possible :(
  812. # [23:31] <caitp> it would be cool if it were possible
  813. # [23:32] <Hixie> your argument is essentially "the web isn't perfect, therefore it's got no value"
  814. # [23:32] <caitp> I never said it had no value =)
  815. # [23:32] <Hixie> and things aren't that black and white
  816. # [23:32] <caitp> but it's got too many problems which will keep it from progressing in a meaningful way for some of these things
  817. # [23:32] <caitp> security issues, limitations of imperative languages, lack of imperative languages, etc
  818. # [23:32] <caitp> performance issues, energy cost issues
  819. # [23:33] <marcosc> caitp: about games, search for Magic the gathering. Also, see the first example in "other applications".
  820. # [23:33] <caitp> too many responsibilities -> never going to be good at everything you need it to be
  821. # [23:33] <Hixie> we're literally working on every single one of those
  822. # [23:33] <caitp> i know they're being worked on, but it's never really going to "work"
  823. # [23:34] <caitp> right now I'm risking a chemical and electrical fire because a web application is heating my laptop to 160F while I'm sitting in a meeting
  824. # [23:34] <Hixie> caitp: https://www.youtube.com/watch?v=pWdd6_ZxX8c
  825. # [23:34] <caitp> this is a prime example of the web not doing a great job for all things
  826. # [23:34] <caitp> not that the web is bad
  827. # [23:34] <caitp> the web is awesome
  828. # [23:34] <Hixie> you realise that _no_ platform does "a great job for all things" right
  829. # [23:34] <caitp> but it's not the be-all-end-all solution for everything
  830. # [23:35] <caitp> no, but sometimes C# or ObjC or Java or C++ does a better job of solving a given problem
  831. # [23:35] <caitp> (easier than say, javascript + API bindings into someone elses C++)
  832. # [23:36] <Hixie> sure. there are multiple projects ongoing for providing ways to compile C++ to a form that runs on any browser.
  833. # [23:36] <Hixie> not to mention that many web apps are now written in Java using GWT, etc.
  834. # [23:36] <caitp> yeah but that's not really a solution :p
  835. # [23:36] <caitp> running in a browser isn't really any better than running in anything else
  836. # [23:36] <Hixie> well, again, https://www.youtube.com/watch?v=pWdd6_ZxX8c
  837. # [23:36] * Quits: tj_vantoll (~Adium@2601:4:5380:2ec:10cd:f94f:c0c9:70f2) (Quit: Leaving.)
  838. # [23:37] <caitp> there's nothing that makes an app that runs in IE any better than an app that runs in MS-DOS
  839. # [23:37] <Hixie> ...
  840. # [23:37] <Hixie> that's just objectively false
  841. # [23:37] <caitp> it could be the exact same application, running it in IE wouldn't be any better
  842. # [23:37] <caitp> it wouldn't necessarily be worse, but it wouldn't be better
  843. # [23:37] <caitp> running in a browser doesn't "improve" anything
  844. # [23:38] <Hixie> the browser is just the runtime
  845. # [23:38] <marcosc> hixie, adding the user opt-in requirement also. Thanks for the feedback.
  846. # [23:39] <Hixie> i don't care if it's IE or Chrome OS or whatever
  847. # [23:39] <hober> ISTM that wake lock shouldn't be API, but should simply be something UAs do themselves
  848. # [23:39] <caitp> yes, it's the runtime
  849. # [23:39] <Hixie> in fact the whole point is that it can be any of the browsers
  850. # [23:39] <caitp> and the runtime doesn't matter
  851. # [23:39] <caitp> the browser being a runtime isn't an improvement
  852. # [23:39] <caitp> it's not a detriment in all cases, but it's not an improvement
  853. # [23:39] <Hixie> the improvement is that there's multiple runtimes
  854. # [23:39] <hober> like, if i take a <video> full screen, a reasonable UA should wake lock while it's playing
  855. # [23:39] <hober> without the author doing anything
  856. # [23:40] <Hixie> hober: yeah but e.g. for a navigation web app, how does the browser know to wake lock?
  857. # [23:40] <marcosc> hober: yes
  858. # [23:40] <caitp> you're a website running in an airport kiosk
  859. # [23:40] * Quits: paintedbicycle (~paintedbi@S01067cb21bd8ee9a.vc.shawcable.net) (Quit: Textual IRC Client: www.textualapp.com)
  860. # [23:40] <hober> Hixie: because the user activated a control in the UA chrome? :)
  861. # [23:40] <caitp> the sysadmin controlling the kiosk has disabled sleep
  862. # [23:40] <caitp> problem solved
  863. # [23:40] <Hixie> hober: Safari is going to have a "wake lock" button? :-)
  864. # [23:41] <caitp> sysadmin/IT grunt/whoever
  865. # [23:41] <Hixie> yeah kiosks aren't a good use case
  866. # [23:41] <hober> Hixie: you know us. we love adding lots of random ui buttons :)
  867. # [23:41] <Hixie> hober: i rest my case... :-P
  868. # [23:41] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  869. # [23:41] <marcosc> yeah, I didn't include them... though I do have a picture of one that we use at the office here.
  870. # [23:42] <marcosc> (we use an app for meeting rooms.... but the screen could shut off after hours)
  871. # [23:42] <marcosc> so they are not a terrible use case
  872. # [23:44] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: :tiuQ tiuq sah woclrak)
  873. # [23:44] * Joins: karlcow (~karl@nerval.la-grange.net)
  874. # [23:44] <caitp> there are cases where it's obvious you want to disable sleep, like videos
  875. # [23:44] <caitp> but I don't think the other cases are that obvious
  876. # [23:44] <caitp> that's all
  877. # [23:44] <Hixie> how is maps not obvious
  878. # [23:45] <caitp> because you're probably issuing inputs
  879. # [23:45] <caitp> I mean the only case where you'd ever do that is on your mobile phone, and your mobile phone isn't going to sleep, unless you leave it alone for a minute, and if it does, who cares
  880. # [23:45] <caitp> you could disable sleep if you need to use it as your car GPS or something
  881. # [23:46] <caitp> (which you shouldn't)
  882. # [23:46] <Hixie> uh
  883. # [23:46] <Hixie> let me tell you how i am NOT issuing inputs while driving...
  884. # [23:46] <Hixie> why "which you shouldn't"
  885. # [23:46] <Hixie> i don't get it
  886. # [23:46] <caitp> don't use your phone as a GPS while driving =) and if you can avoid it, don't use GPS at all
  887. # [23:47] <caitp> people grow overly dependent on these things, you know
  888. # [23:47] <Hixie> uh
  889. # [23:47] <Hixie> ok
  890. # [23:48] * Hixie is going to keep using a navigation app until such time as his car drives itself, thanks
  891. # [23:48] <caitp> i'm sure it will only be a few years
  892. # [23:48] <Hixie> especially with google maps being so freaking awesome at it these days
  893. # [23:48] <Hixie> navigating around traffic dynamically and giving lane guidance and all that
  894. # [23:48] <Hixie> it's freaking fantastic
  895. # [23:48] <caitp> and then we'll forget all about reading paper maps, street signs and landmarks, and celestial navigation
  896. # [23:48] <caitp> and it will be terrible
  897. # [23:48] <Hixie> you'd have to be crazy to not use it
  898. # [23:49] <caitp> and more importantly, we'll start to forget to look away from the screen
  899. # [23:49] <caitp> wouldn't that be awful?
  900. # [23:49] <caitp> oh man
  901. # [23:49] <Hixie> oh man, yeah, how will we ever survive as a species if we forget how to use logarithm tables, slide rules, punch cards, pedal looms or how to ride a horse
  902. # [23:49] <caitp> yes
  903. # [23:49] <caitp> darned right
  904. # [23:49] <caitp> no sarcasm
  905. # [23:50] <caitp> it will be a sad day when that knowledge disappears =)
  906. # [23:51] <Hixie> luckily for us, that knowledge will forever live on since we now have near-infinite archival storage and no longer depend on flammable paper for our backups
  907. # [23:51] <caitp> archived knowledge is not necessarily living knowledge
  908. # [23:52] <caitp> anyway I think this got a bit sidetracked =)
  909. # [23:52] <Hixie> do you know how to use a slide rule?
  910. # [23:53] <marcosc> caitp: you didn't even read the document, did you?
  911. # [23:53] <caitp> in its entirety? heck no, I was in a meeting =)
  912. # [23:54] <marcosc> ok, most of the things you mentioned are addressed in the document
  913. # [23:54] <caitp> but I'm still not really buying it, I don't want any web app that wants to disabling sleep on my system, and I don't want to let a web app disable sleep
  914. # [23:54] <marcosc> caitp: that's fine. You can opt out
  915. # [23:54] <marcosc> but other people would want it
  916. # [23:54] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Remote host closed the connection)
  917. # [23:54] <caitp> for obvious cases like videos, the UA can disable sleep, but otherwise I'd prefer to do that myself
  918. # [23:55] <marcosc> caitp: ok, that's fine. But do you acknowledge that other people might not want that?
  919. # [23:55] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com)
  920. # [23:55] <marcosc> (i.e., a lot of people don't even know how to do that(
  921. # [23:55] <marcosc> )
  922. # [23:55] <caitp> if someone doesn't know how to disable sleep, do you think they really know what they're doing allowing a random web app to disable sleep?
  923. # [23:55] <marcosc> caitp: again, see the document
  924. # [23:56] <marcosc> e.g., the app for cooking and the Brazil 2014 app
  925. # [23:56] <caitp> the document explains how it makes up for other peoples lack of knowledge?
  926. # [23:56] <caitp> o_o
  927. # [23:56] <marcosc> yes
  928. # [23:56] <caitp> which section would I find that snippet, is there another spec proposed for interfacing directly with a user's brain?
  929. # [23:57] <marcosc> I think that's called interaction design
  930. # [23:57] * Quits: dbaron (~dbaron@2620:101:80fb:232:ad93:477e:2eca:c864) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  931. # [23:57] <marcosc> seems you are not really interested in actually providing constructive feedback.
  932. # [23:58] * Quits: roc (~chatzilla@121-98-106-217.bng1.tvc.orcon.net.nz) (Remote host closed the connection)
  933. # [23:58] <caitp> it's not that it's not constructive, it's that it's not what you want to hear
  934. # [23:58] <caitp> which is fine, I can't stop ya
  935. # [23:58] <Domenic> no, this is pretty much the definition of non-constructive feedback right here
  936. # [23:59] <caitp> there's no way to make this work in a good way within the constraints of the platform, domenic, that would never be appropriate
  937. # [23:59] <marcosc> caitp: why is it then possible to do it effectively on Android and iOS?
  938. # [23:59] <marcosc> Or even in Firefox OS?
  939. # [23:59] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.cust.bredband2.com) (Ping timeout: 256 seconds)
  940. # [00:00] <caitp> well, it's not as effective on the android store because the play store isn't policed as effectively
  941. # Session Close: Tue Jul 15 00:00:01 2014

The end :)