/irc-logs / freenode / #whatwg / 2014-05-20 / end

Options:

  1. # Session Start: Tue May 20 00:00:00 2014
  2. # Session Ident: #whatwg
  3. # [00:01] * Joins: jernoble (~jernoble@17.114.2.168)
  4. # [00:01] * Quits: mven (~textual@169.241.49.202) (Read error: Connection reset by peer)
  5. # [00:01] * Joins: mven (~textual@169.241.49.202)
  6. # [00:01] * Quits: mven (~textual@169.241.49.202) (Max SendQ exceeded)
  7. # [00:02] * Joins: weinig (~weinig@17.114.216.37)
  8. # [00:02] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  9. # [00:02] * Joins: mven (~textual@169.241.49.202)
  10. # [00:02] * Quits: jernoble (~jernoble@17.114.2.168) (Client Quit)
  11. # [00:04] * Quits: systematik (~nick@thunder.nickmerrill.co) (Quit: leaving)
  12. # [00:05] * Quits: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com) (Read error: Connection reset by peer)
  13. # [00:05] * Joins: tantek_ (~tantek@corp-nat.p2p.sfo1.mozilla.com)
  14. # [00:06] * Quits: weinig (~weinig@17.114.216.37) (Client Quit)
  15. # [00:10] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
  16. # [00:13] * Quits: mven (~textual@169.241.49.202) (Ping timeout: 265 seconds)
  17. # [00:16] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  18. # [00:18] * Quits: lokling (~quassel@quassel.woboq.de) (Read error: Operation timed out)
  19. # [00:20] * Joins: lokling (~quassel@quassel.woboq.com)
  20. # [00:21] * Joins: weinig (~weinig@17.114.216.37)
  21. # [00:21] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  22. # [00:22] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  23. # [00:29] <TabAtkins> Hixie: What is FontLoader and what were you using it for? If you just want to load a font via JS, FontFace is constructable.
  24. # [00:29] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  25. # [00:29] <TabAtkins> Hixie: There is no way to position the top and left of an element relative to different things at the moment.
  26. # [00:33] * Quits: weinig (~weinig@17.114.216.37) (Quit: weinig)
  27. # [00:34] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
  28. # [00:34] * Quits: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley) (Ping timeout: 240 seconds)
  29. # [00:34] * Joins: systematik (~nick@thunder.nickmerrill.co)
  30. # [00:40] <Hixie> TabAtkins: i don't recall. something in HTML. i filed a bug on myself to figure it out.
  31. # [00:40] <Hixie> TabAtkins: re positioning: k. anything on the radar for that?
  32. # [00:43] * Joins: weinig (~weinig@17.114.216.37)
  33. # [00:43] * Quits: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95) (Remote host closed the connection)
  34. # [00:43] * Joins: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95)
  35. # [00:47] * Joins: GPHemsley (~GPHemsley@pdpc/supporter/student/GPHemsley)
  36. # [00:48] <JonathanNeal> To whomever it concerns, I have filed my latest element query pleas @ http://discourse.specifiction.org/t/element-queries/26/last
  37. # [00:51] * Quits: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com) (Ping timeout: 258 seconds)
  38. # [00:54] * Joins: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com)
  39. # [00:55] <TabAtkins> Hixie: Nope, nothing right now. I have plans, but no timeline for achieving them.
  40. # [00:55] <Hixie> k
  41. # [00:56] * Joins: karlcow (~karl@nerval.la-grange.net)
  42. # [00:57] <Domenic> http://gridstylesheets.org/ is a related prolyfill/ideation exercise
  43. # [00:57] <Domenic> i want to try it on a small project and see how i feel afterward
  44. # [00:58] <Domenic> i could easily see it either being "wow this is amazing we must have this" or "meh that really doesn't work in practice, nice try"
  45. # [00:59] * Guest19805 is now known as jory
  46. # [01:01] * Joins: ap_ (~ap@17.114.219.248)
  47. # [01:03] * Quits: plutoniix (~plutoniix@node-nc3.pool-101-108.dynamic.totbb.net) (Quit: จรลี จรลา)
  48. # [01:04] * Quits: ap (~ap@17.202.44.214) (Ping timeout: 264 seconds)
  49. # [01:04] * ap_ is now known as ap
  50. # [01:04] * Quits: weinig (~weinig@17.114.216.37) (Quit: weinig)
  51. # [01:09] <JonathanNeal> Domenic: were you the one who replied to me?
  52. # [01:10] <JonathanNeal> If it was, I appreciate you citing TabAtkins’ blog as the canonical reply. But, at the same time, arrrrr! I had a bunch of links in my post, but discourse doesn’t let me add more than one or two.
  53. # [01:18] <zewt> are clipboard events those sort of broken ancient events that have side-effects when fired from script (like click)?
  54. # [01:19] <zewt> it doesn't seem like they are in testing, but hallvord implied that they are on the list (and he's apparently the editor of the clipboard spec)
  55. # [01:20] * Joins: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  56. # [01:25] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
  57. # [01:25] <JonathanNeal> Domenic: re: gss, it’s amazing that we can think up entirely different ways to write stylesheets, and its best marketing is still “now you can vertically center something”
  58. # [01:29] * Krinkle is now known as Krinkle|detached
  59. # [01:29] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Quit: leaving)
  60. # [01:32] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
  61. # [01:32] * Quits: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  62. # [01:32] <gsnedders> Okay then, to continue my questioning from yesterday: which Chromebook do I want? Given they basically all have 1366x768 displays, I guess there's no point in going for one of the larger ones? AFAICT, the HP Chromebook 11 seems to have the best screen of them, but it does have a now ancient SoC in it…
  63. # [01:34] * Joins: weinig (~weinig@17.114.216.37)
  64. # [01:35] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Client Quit)
  65. # [01:35] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
  66. # [01:36] * Quits: bholley (~bholley@corp.mtv2.mozilla.com) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  67. # [01:36] * Quits: jeffreyatw (~jeffreyat@173.247.197.10) (Quit: jeffreyatw)
  68. # [01:37] * Quits: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net) (Remote host closed the connection)
  69. # [01:37] * Joins: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon)
  70. # [01:38] <JonathanNeal> gsnedders: that sounds all right. I’m very productive on 1440x900.
  71. # [01:41] * gsnedders vaguely wonders about selling his tablet
  72. # [01:42] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Quit: leaving)
  73. # [01:42] <gsnedders> I just don't use it that much…
  74. # [01:42] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
  75. # [01:44] * Joins: lmclister (~lmclister@192.150.10.205)
  76. # [01:48] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Ping timeout: 240 seconds)
  77. # [01:51] <JonathanNeal> gsnedders: i used mine for one project, and my 1 year old found a better use for it, namely the tinkerbell film series.
  78. # [01:52] * Quits: victorbjelkholm (~victorbje@41.Red-83-60-204.dynamicIP.rima-tde.net) (Quit: ZZZzzz…)
  79. # [01:52] <gsnedders> All the Chromebooks seem to be somewhat flawed. The HP Chromebook 11 has a wonderful screen, but opinions are mixed on the keyboard, and apparently performance isn't brilliant with a few tabs open… On the other hand, the Dell Chromebook 11 has a less good screen but better everything else…
  80. # [01:53] * Joins: jdaggett (~jdaggett@q023013.dynamic.ppp.asahi-net.or.jp)
  81. # [01:57] * Quits: cheron (~cheron@unaffiliated/cheron) (Ping timeout: 265 seconds)
  82. # [01:58] * Joins: mven (~textual@ip68-104-38-84.lv.lv.cox.net)
  83. # [02:00] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: Textual IRC Client: www.textualapp.com)
  84. # [02:02] * Joins: jeremyj (~jeremyj@17.202.44.231)
  85. # [02:04] * Joins: abinader (sid21713@gateway/web/irccloud.com/x-bbomruskdbappzel)
  86. # [02:05] * Joins: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net)
  87. # [02:07] <TabAtkins> gsnedders: Buy a Pixel.
  88. # [02:08] <gsnedders> TabAtkins: no. :)
  89. # [02:09] <TabAtkins> Too pricey, or does it fail one of your other criteria?
  90. # [02:09] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Quit: leaving)
  91. # [02:09] <gsnedders> Too pricey. If I'm dropping that money, I'd get a Macbook of some variety.
  92. # [02:11] * Quits: jsbell (jsbell@nat/google/x-gzonfgsawpjtulso) (Quit: There's no place like home...)
  93. # [02:12] <gsnedders> (and then just entirely replace my existing MBP, instead of getting something more to replace my tablet than anything else)
  94. # [02:13] * Joins: zcorpan (~zcorpan@113.199.41.81)
  95. # [02:14] * Quits: zcorpan (~zcorpan@113.199.41.81) (Remote host closed the connection)
  96. # [02:15] * Joins: zcorpan (~zcorpan@113.199.41.81)
  97. # [02:15] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  98. # [02:17] * Quits: tav (~tav`@host31-52-138-103.range31-52.btcentralplus.com) (Read error: Connection reset by peer)
  99. # [02:17] * Joins: ap_ (~ap@2620:149:4:304:60b2:7b5b:c970:cd45)
  100. # [02:17] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  101. # [02:17] * Joins: tav (~tav`@host31-52-138-103.range31-52.btcentralplus.com)
  102. # [02:18] * Joins: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com)
  103. # [02:19] * Joins: bholley (~bholley@98.210.101.88)
  104. # [02:19] * Quits: ap (~ap@17.114.219.248) (Ping timeout: 240 seconds)
  105. # [02:19] * ap_ is now known as ap
  106. # [02:19] * Quits: zcorpan (~zcorpan@113.199.41.81) (Ping timeout: 276 seconds)
  107. # [02:20] * Quits: satazor (~satazor@80.78.37.188.rev.vodafone.pt) (Remote host closed the connection)
  108. # [02:22] * Quits: weinig (~weinig@17.114.216.37) (Quit: weinig)
  109. # [02:23] * Quits: bholley (~bholley@98.210.101.88) (Ping timeout: 252 seconds)
  110. # [02:25] * Joins: weinig (~weinig@17.114.216.37)
  111. # [02:26] * Joins: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net)
  112. # [02:27] * Quits: othermaciej (~mjs@17.114.217.202) (Quit: othermaciej)
  113. # [02:28] * Joins: othermaciej (~mjs@17.114.217.202)
  114. # [02:47] * Joins: scor (~scor@drupal.org/user/52142/view)
  115. # [02:49] * Joins: zcorpan (~zcorpan@113.199.42.59)
  116. # [02:54] * Quits: weinig (~weinig@17.114.216.37) (Quit: weinig)
  117. # [02:54] <zewt> the Most Annoying Thing On The Internet: http://social.msdn.microsoft.com/Forums/en-US/53ae87d1-dd83-4a44-8303-4a31c9c37015/stopping-scrollviewer-from-auto-scrolling-when-item-gets-focus
  118. # [02:55] <zewt> "how do I do this thing?" "never mind, here's the solution" *404*
  119. # [02:58] <caitp> there are many annoying things on the internet, there will be many more in the future
  120. # [02:58] <caitp> exponentially more
  121. # [02:59] * Quits: zcorpan (~zcorpan@113.199.42.59) (Remote host closed the connection)
  122. # [03:00] * Quits: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net)
  123. # [03:00] * Joins: zcorpan (~zcorpan@113.199.42.59)
  124. # [03:03] * Quits: tantek_ (~tantek@corp-nat.p2p.sfo1.mozilla.com) (Quit: tantek_)
  125. # [03:04] * Quits: zcorpan (~zcorpan@113.199.42.59) (Ping timeout: 258 seconds)
  126. # [03:06] * Quits: ap (~ap@2620:149:4:304:60b2:7b5b:c970:cd45) (Quit: ap)
  127. # [03:09] * Joins: marbleEye (~marbleEye@host86-145-211-9.range86-145.btcentralplus.com)
  128. # [03:13] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: This computer has gone to sleep)
  129. # [03:15] * Quits: lmclister (~lmclister@192.150.10.205)
  130. # [03:21] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  131. # [03:21] * Joins: a-ja (~Instantbi@70.230.147.189)
  132. # [03:30] * Quits: a-ja (~Instantbi@70.230.147.189) (Read error: Connection reset by peer)
  133. # [03:31] * Joins: a-ja (~Instantbi@70.230.147.189)
  134. # [03:31] * Joins: othermaciej_ (~mjs@17.202.49.252)
  135. # [03:32] * Quits: othermaciej (~mjs@17.114.217.202) (Ping timeout: 240 seconds)
  136. # [03:32] * othermaciej_ is now known as othermaciej
  137. # [03:33] * Quits: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net) (Ping timeout: 255 seconds)
  138. # [03:39] * Joins: Goplat (~goplat@reactos/developer/Goplat)
  139. # [03:40] * Joins: lmclister (~lmclister@192.150.10.205)
  140. # [03:40] * Joins: karlcow (~karl@nerval.la-grange.net)
  141. # [03:41] * Joins: jungkees (uid24208@gateway/web/irccloud.com/x-plzzkzllmyxakhha)
  142. # [03:46] * Quits: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon) (Quit: Connection closed for inactivity)
  143. # [03:49] * Quits: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95) (Quit: coolbot95)
  144. # [03:56] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
  145. # [03:57] * Quits: newtron (~newtron@184.175.16.140) (Remote host closed the connection)
  146. # [03:58] * htmelvis_zzz is now known as htmelvis
  147. # [04:02] * Joins: othermaciej_ (~mjs@17.114.217.202)
  148. # [04:02] * Quits: othermaciej_ (~mjs@17.114.217.202) (Client Quit)
  149. # [04:04] * Quits: morrita_ (uid16889@gateway/web/irccloud.com/x-wchgzlklpxvcwoxj) (Ping timeout: 264 seconds)
  150. # [04:04] * Quits: othermaciej (~mjs@17.202.49.252) (Ping timeout: 252 seconds)
  151. # [04:06] * Parts: a-ja (~Instantbi@70.230.147.189)
  152. # [04:07] * Joins: morrita_ (uid16889@gateway/web/irccloud.com/x-phemqzbmcrmyjkta)
  153. # [04:18] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  154. # [04:18] * Joins: zcorpan (d25fff95@gateway/web/freenode/ip.210.95.255.149)
  155. # [04:19] <zcorpan> Hixie: i can fix the autorotate thing relatively soon i think
  156. # [04:19] * Joins: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net)
  157. # [04:29] <MikeSmith> zcorpan John told me he'd replied -- replied to you, I think.
  158. # [04:34] <zcorpan> MikeSmith: i don't see anything in my inbox and i don't see anything in http://lists.w3.org/Archives/Public/www-archive/2014May/thread.html
  159. # [04:35] <zcorpan> MikeSmith: he had replied to denis in private before all three of us emailed him and cc-ed www-archive i think, but i wanted a public record
  160. # [04:36] <zcorpan> MikeSmith: so the critic issue actually isn't resolved yet afaict
  161. # [04:37] <Hixie> zcorpan: cool. it sounds pretty straightforward. file a bug on me once you've done it to add it to the index. thanks!
  162. # [04:37] <zcorpan> Hixie: ok
  163. # [04:38] <MikeSmith> zcorpan: OK, when we have cases like this I'd like to suggest we open separate issues and then close the PR, if this kind of problem is the only thing blocking it
  164. # [04:39] <MikeSmith> zcorpan: I think it's bad for everybody to keep PRs hanging open for months on end
  165. # [04:39] <MikeSmith> zcorpan: they get stale and people lose interest in following up on them
  166. # [04:40] <MikeSmith> zcorpan: or in in this specific case, the guy who was responsible for that PR no longer is paid to work on testing, and has moved on
  167. # [04:40] <zcorpan> MikeSmith: i don't disagree that it's bad to have PRs open for a long time
  168. # [04:41] <MikeSmith> zcorpan: I'll ping John again and ask him if he can reply to your www-archive message
  169. # [04:41] <zcorpan> ok great
  170. # [04:42] <zcorpan> Hixie: as for styling, e.g. the stylesheet for http://dev.w3.org/csswg/cssom/ is a lot less busy than the whatwg stylesheet, but still has enough visible cue (at least for me) to see where the links are
  171. # [04:44] <zcorpan> Hixie: i'm not saying that stylesheet is without problems, but i agree with jgraham that it should be possible to create a stable and subtle yet usable style. i'm not sure i agree with jgraham about the underline, it doesn't bother me and something other than color is necessary for people with some color-blindnesses (unless you can find a color that works for all common color blindnesses)
  172. # [04:45] <zcorpan> (maybe a lighter shade would work to make a contrast difference even if you can't distinguish the color?)
  173. # [04:46] <MikeSmith> Hixie: as far as the undelrines, what zcorpan said
  174. # [04:46] <MikeSmith> people who have a problem with underlines are going to have a hard time on the internet
  175. # [04:48] <MikeSmith> Hixie: the underlines have a utility -- exactly the utility that you mentioned earlier (distinguishing, e.g., between hyperlinked <code> and unhyperlinked -- or whatever specific case you mentioned)
  176. # [04:49] <MikeSmith> Hixie: I think some people are willing to sacrifice the utility of the spec to aesthetics or making it look less "busy" or however they're stating it
  177. # [04:50] <SamB> hey, I've heard of this thing called alternate stylesheets
  178. # [04:50] <zcorpan> (i don't personally have a problem with the "busy" style, so long as it doesn't do the fading thing)
  179. # [04:50] <MikeSmith> zcorpan: yeah
  180. # [04:50] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  181. # [04:50] <zewt> things nobody should ever have to use: alternate stylesheets
  182. # [04:51] <zcorpan> SamB: that has already been brought up
  183. # [04:51] <SamB> 'kay
  184. # [04:52] <zewt> don't know what's changed, but the main TOC is pretty hard to look at right now, probably too much space around everything
  185. # [04:53] <MikeSmith> zcorpan: I could live without the fading thing, but I thought it was a good clever solution to the problem Hixie was trying to solve. Now, I think, it would be nice to solve that problem if it's solvable, but I'm not sure it is, and maybe it's not worth spending a lot of time trying to solve.
  186. # [04:53] * Quits: rniwa (~rniwa@17.202.43.222) (Quit: rniwa)
  187. # [04:53] <MikeSmith> zewt: hmm yeah maybe there's too much line space there now
  188. # [04:53] <zewt> looks like all numbered lists have that problem
  189. # [04:54] <MikeSmith> zewt: ah yeah, seems so
  190. # [04:54] <MikeSmith> I guess Hixie should just rachet that back down a bit
  191. # [04:54] <zewt> dotted lists are fine
  192. # [04:55] <MikeSmith> anyway it would be a shame to see that spec change in ways that it less usable for implementors, even it if it made it slightly more usable for others
  193. # [04:57] <MikeSmith> I've never had any problem with the colors or anything else. in fact, the opposite -- I really appreciate that all those various cues are there are value them. I couldn't care less if it looks "busy" as long as it makes it easier for me to find what I need
  194. # [04:57] <MikeSmith> I'm not reading it for fun
  195. # [04:58] <MikeSmith> if people want less busy, there's always IETF style
  196. # [04:58] <zewt> 80 column with hardcoded page breaks for 80x55 daisy wheel printers?
  197. # [04:59] <MikeSmith> zewt: yeah but I meant more the lack of colors and the lack of hyperlinks
  198. # [05:00] <SamB> I like it how zewt says it though
  199. # [05:00] <SamB> I mean, it's funnier that way
  200. # [05:01] <SamB> not that I'd want to see the spec like that
  201. # [05:01] <zewt> i didn't have any issues with the formatting, my main issue with the spec is just wishing it loaded faster, heh
  202. # [05:01] <zewt> (maybe if the multipage referencing worked better i'd use it, though being able to text search the whole spec is probably also hard to do without)
  203. # [05:01] <SamB> so you want it to be less busy on the *inside*
  204. # [05:02] <SamB> me too
  205. # [05:02] <zewt> i don't know the first thing about why it's so slow, heh ("it's huge" is obviously a part, but I assume it's more complicated than that)
  206. # [05:02] <SamB> I remember a time when I could actually load the single-page spec
  207. # [05:03] <zewt> guess I could load it with no styles or scripts and find out
  208. # [05:03] <TabAtkins> It's huge, it does some JS loops over the whole document, and I'd bet the selectors aren't well-optimized.
  209. # [05:06] <zewt> "no copyright is asserted on this file"? is that really a valid way to disclaim copyright? heh
  210. # [05:10] <MikeSmith> Hixie: about the validator not catching the <dd> thing before you fixed it, I think it might have been because validator.nu hasn't been synched for a while and has an older version of the schema that wasn't going <dl><dt><dd> checking correctly for a while after we made the change to allow <script> and <template> in there
  211. # [05:10] * marbleEye is now known as blindCode
  212. # [05:12] <MikeSmith> Hixie: I think it works as expected in the current source and at http://sideshowbarker.net:8888/ and http://validator.w3.org/nu/
  213. # [05:12] * Quits: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com) (Remote host closed the connection)
  214. # [05:14] * Joins: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net)
  215. # [05:16] * Quits: tav (~tav`@host31-52-138-103.range31-52.btcentralplus.com) (Quit: tav)
  216. # [05:19] * Quits: jwalden (~waldo@corp.mtv2.mozilla.com) (Quit: ChatZilla 0.9.87-8.1450hg.fc20 [XULRunner 29.0/20140428110119])
  217. # [05:23] <TabAtkins> zewt: No, it's not a valid way. Copyright is automatic regardless of what you say.
  218. # [05:23] <TabAtkins> At least in US law, and most other countries.
  219. # [05:25] <Hixie> MikeSmith: cool
  220. # [05:25] <Hixie> i should probably change to ssb.n:8888
  221. # [05:26] <Hixie> btw re the style sheet, there were some substantial changes earlier today, so i'm letting it sit for a few days to see how people like it
  222. # [05:27] <Hixie> (in particular, i think it might be less busy that the /csswg/cssom/ style sheet at this point)
  223. # [05:28] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
  224. # [05:35] <TabAtkins> Still super-hate the fading thing.
  225. # [05:35] <TabAtkins> I didn't hate it earlier, but it's fading on me. ^_^
  226. # [05:36] * Joins: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net)
  227. # [05:36] <Hixie> it's long gone
  228. # [05:39] * Quits: blindCode (~marbleEye@host86-145-211-9.range86-145.btcentralplus.com) (Quit: Leaving)
  229. # [05:43] * Joins: newtron (~newtron@184.175.16.140)
  230. # [05:45] * Joins: bholley (~bholley@98.210.101.88)
  231. # [05:50] * Quits: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net) (Remote host closed the connection)
  232. # [05:54] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  233. # [05:55] * Joins: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net)
  234. # [05:57] * Quits: newtron (~newtron@184.175.16.140) (Remote host closed the connection)
  235. # [06:10] * Joins: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net)
  236. # [06:14] <TabAtkins> Oh, hm, must need to force-refresh.
  237. # [06:17] * Quits: morrita_ (uid16889@gateway/web/irccloud.com/x-phemqzbmcrmyjkta) (Quit: Connection closed for inactivity)
  238. # [06:20] * Quits: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net) (Ping timeout: 240 seconds)
  239. # [06:20] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  240. # [06:21] * Joins: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net)
  241. # [06:31] * Quits: lmclister (~lmclister@192.150.10.205)
  242. # [06:33] <zcorpan> MikeSmith: can you look into the w3c-test:mirror thing? i want some people to look at the tests without having them clone and get wptserve running
  243. # [06:34] <zcorpan> MikeSmith: the PR is https://github.com/w3c/web-platform-tests/pull/996
  244. # [06:36] <zcorpan> oh i see you replied in #testing
  245. # [06:36] * Joins: lmclister (~lmclister@192.150.10.205)
  246. # [06:36] * Quits: lmclister (~lmclister@192.150.10.205) (Remote host closed the connection)
  247. # [06:41] <MikeSmith> zcorpan: checkong on it now
  248. # [06:44] * Quits: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net) (Ping timeout: 240 seconds)
  249. # [06:51] <zcorpan> MikeSmith: thanks!
  250. # [06:51] <zcorpan> MikeSmith: maybe i don't have the right permissions, like jgraham said?
  251. # [06:53] <MikeSmith> yeah checking on that too
  252. # [06:56] * Quits: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net) (Remote host closed the connection)
  253. # [06:56] <MikeSmith> zcorpan: http://w3c-test.org/submissions/996/
  254. # [06:56] <MikeSmith> still working on the underlying cause
  255. # [06:56] <zcorpan> MikeSmith: thank you
  256. # [06:59] <MikeSmith> zcorpan: fwiw as far as the underlying cause, I think it might be a github bug
  257. # [06:59] <MikeSmith> because the script relies on https://api.github.com/repos/w3c/web-platform-tests/collaborators
  258. # [06:59] <MikeSmith> the sync script
  259. # [07:00] <MikeSmith> zcorpan: and you're not listed there and neither am I
  260. # [07:00] <zcorpan> weird
  261. # [07:00] <MikeSmith> yeah
  262. # [07:00] <zcorpan> i can report it to github if you like
  263. # [07:01] <MikeSmith> zcorpan: yeah please do if you have time
  264. # [07:01] * Joins: gavin___ (~gavin@76.14.87.162)
  265. # [07:01] * Quits: gavin__ (~gavin@76.14.87.162) (Read error: Connection reset by peer)
  266. # [07:02] <MikeSmith> zcorpan: and in the mean time I guess the workaround to get something mirrored is to ask somebody who's actually listed there to add a comment
  267. # [07:03] <MikeSmith> jgraham is not there either, no Ms2ger, so I guess we really should be checking it against some other list if there is one
  268. # [07:03] <zcorpan> MikeSmith: what's your github handle?
  269. # [07:03] <MikeSmith> zcorpan: sideshowbarker
  270. # [07:05] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 245 seconds)
  271. # [07:05] * Joins: BigBangUDR (~Thunderbi@220.225.242.27)
  272. # [07:08] <zcorpan> MikeSmith: ok reported. didn't get a URL or anything for the issue and i failed to get under 140 chars so i didn't get a gold star
  273. # [07:09] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
  274. # [07:09] <zcorpan> but i'll let you know when i get a reply
  275. # [07:09] * Quits: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net)
  276. # [07:10] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
  277. # [07:12] * Quits: nicolasbadia (~nicolasba@78.209.78.103) (Quit: nicolasbadia)
  278. # [07:13] <MikeSmith> zcorpan: thanks
  279. # [07:13] <MikeSmith> win 27
  280. # [07:14] * Joins: nicolasbadia (~nicolasba@78.209.78.103)
  281. # [07:21] * htmelvis is now known as htmelvis_zzz
  282. # [07:24] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  283. # [07:25] * Joins: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  284. # [07:28] * Quits: bholley (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  285. # [07:30] * Joins: bholley (~bholley@98.210.101.88)
  286. # [07:30] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  287. # [07:30] * Joins: IZh (~Igor_Zhba@0897578511.static.corbina.ru)
  288. # [07:37] * Joins: bholley (~bholley@98.210.101.88)
  289. # [07:39] * Joins: zdobersek (~zan@185.3.135.82)
  290. # [07:40] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  291. # [07:44] * Joins: bholley (~bholley@98.210.101.88)
  292. # [07:44] * Joins: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com)
  293. # [07:49] * Quits: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com) (Ping timeout: 252 seconds)
  294. # [07:50] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  295. # [07:50] * Quits: bholley (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  296. # [07:52] * Quits: nicolasbadia (~nicolasba@78.209.78.103) (Quit: nicolasbadia)
  297. # [07:54] * Quits: roc (~chatzilla@60.234.66.18) (Ping timeout: 255 seconds)
  298. # [07:55] * Joins: ambv (~ambv@173.252.71.129)
  299. # [07:56] * Joins: bholley (~bholley@98.210.101.88)
  300. # [07:56] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  301. # [07:56] * Quits: ambv (~ambv@173.252.71.129) (Client Quit)
  302. # [07:57] * Joins: nicolasbadia (~nicolasba@78.209.78.103)
  303. # [08:03] * Quits: aretecode (~aretecode@64.120.6.170) (Remote host closed the connection)
  304. # [08:05] <zcorpan> Hixie: i think i didn't write ""; but actually wrote "list of available images"; in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25797
  305. # [08:06] <zcorpan> Hixie: is there a bug somewhere tampering with it or am i mistaken about what i wrote? :-)
  306. # [08:06] * Joins: roc (~chatzilla@60.234.66.18)
  307. # [08:07] <Hixie> i don't log anything for file-bug.cgi, so dunno
  308. # [08:07] <zcorpan> ok
  309. # [08:07] <Hixie> but i can't imagine what i could do to cause that :-)
  310. # [08:08] <zcorpan> yeah i dunno either
  311. # [08:08] <zcorpan> maybe it was what i wrote
  312. # [08:08] <Hixie> wait, i do log something
  313. # [08:08] <Hixie> when did you file this? just now?
  314. # [08:08] <zcorpan> 2014-05-19 07:37:09 UTC
  315. # [08:09] * Hixie tries to work out what time zone he's in
  316. # [08:10] <Hixie> that's either two minutes in the future or an hour ago
  317. # [08:10] * Quits: CvP (~CvP@27.147.199.131) (Disconnected by services)
  318. # [08:10] <Hixie> wait wtf
  319. # [08:10] * Joins: xCG (~CvP@27.147.199.131)
  320. # [08:10] <Hixie> this computer's clock is WAY off
  321. # [08:11] * xCG is now known as CvP
  322. # [08:12] <IZh> Hixie: Hi. Last PDF was not generated because of missing fonts. It seems there are new rare characters in the spec. :-) I'll find suitable font and regenerate it.
  323. # [08:12] <Hixie> hehe thanks :-)
  324. # [08:13] <Hixie> zcorpan: ok according to the logs if there's a bug it's somewhere in Apache or Perl's core libraries
  325. # [08:13] <Hixie> zcorpan: because my code gets the text, then logs it immediately before fiddling with it, and it logged "".
  326. # [08:14] <zcorpan> Hixie: so that means it's unlikely that there is a bug
  327. # [08:15] <zcorpan> i can try filing a new bug with what i think i wrote, and see if it reproduces
  328. # [08:15] <Hixie> occam's razor suggests there isn't a bug. murphy's law suggests there is. your call. :-)
  329. # [08:17] <zcorpan> didn't reproduce
  330. # [08:18] * Joins: bholley (~bholley@98.210.101.88)
  331. # [08:18] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  332. # [08:19] <IZh> I have written a script that looks for missing characters and prints font list that contains it sorted by number of missing characters found in each font. :-)
  333. # [08:23] * Joins: Ducki (~Ducki@137.116.197.171)
  334. # [08:23] * Joins: bholley (~bholley@98.210.101.88)
  335. # [08:23] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  336. # [08:24] * Joins: bholley (~bholley@98.210.101.88)
  337. # [08:25] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  338. # [08:27] * Quits: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  339. # [08:27] * Joins: bholley (~bholley@98.210.101.88)
  340. # [08:27] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  341. # [08:35] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  342. # [08:36] * Joins: bholley (~bholley@98.210.101.88)
  343. # [08:36] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  344. # [08:39] * Joins: zaal_ (~zaal@cpc65346-nrwh11-2-0-cust48.4-4.cable.virginm.net)
  345. # [08:43] * Joins: markkes (~markkes@62.207.90.201)
  346. # [08:50] <IZh> Hixie: I've fixed it. :-)
  347. # [08:50] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  348. # [08:52] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  349. # [08:52] <IZh> Hixie: Currently the document needs 15 fonts. (And some web-fonts too.)
  350. # [09:14] * Joins: KevinMarks2 (~yaaic@2607:fb90:500:d238:e1a8:433a:b442:3f2e)
  351. # [09:14] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
  352. # [09:16] * Quits: IZh (~Igor_Zhba@0897578511.static.corbina.ru) (Quit: ChatZilla 0.9.90.1 [SeaMonkey 2.26/20140428215944])
  353. # [09:25] * Joins: victorbjelkholm (~victorbje@41.Red-83-60-204.dynamicIP.rima-tde.net)
  354. # [09:28] * Joins: gavin__ (~gavin@76.14.87.162)
  355. # [09:32] * Joins: espadrine` (~ttyl@AMontsouris-158-1-15-151.w92-128.abo.wanadoo.fr)
  356. # [09:34] * Joins: Dashiva_j (Dashiva@wikia/Dashiva)
  357. # [09:34] * Quits: abinader (sid21713@gateway/web/irccloud.com/x-bbomruskdbappzel)
  358. # [09:37] * Quits: gavin___ (~gavin@76.14.87.162) (*.net *.split)
  359. # [09:37] * Quits: Dashiva (Dashiva@wikia/Dashiva) (*.net *.split)
  360. # [09:37] * Quits: espadrine (~ttyl@AMontsouris-158-1-15-151.w92-128.abo.wanadoo.fr) (*.net *.split)
  361. # [09:37] * Quits: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net) (*.net *.split)
  362. # [09:37] * Quits: Garbee (uid21171@gateway/web/irccloud.com/x-ydafuxmgkkjmfmjb) (*.net *.split)
  363. # [09:37] * Dashiva_j is now known as Dashiva
  364. # [09:38] * Quits: jdaggett (~jdaggett@q023013.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
  365. # [09:39] * Joins: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net)
  366. # [09:43] * Joins: Garbee (uid21171@gateway/web/irccloud.com/session)
  367. # [09:43] * Quits: Garbee (uid21171@gateway/web/irccloud.com/session) (Changing host)
  368. # [09:43] * Joins: Garbee (uid21171@gateway/web/irccloud.com/x-dsoytojouwletajb)
  369. # [09:43] * Garbee is now known as Guest57780
  370. # [09:43] * Quits: zcorpan (d25fff95@gateway/web/freenode/ip.210.95.255.149) (Ping timeout: 240 seconds)
  371. # [09:47] <annevk> Hixie: I think the only reason you wanted FontLoader or some such is to be able to have a solution for fonts in workers
  372. # [09:47] <annevk> Hixie: in combination with <canvas> in workers
  373. # [09:49] * Quits: victorbjelkholm (~victorbje@41.Red-83-60-204.dynamicIP.rima-tde.net) (Quit: ZZZzzz…)
  374. # [09:49] * Quits: Streusel (~Anonymous@unaffiliated/streusel) (Quit: Computer has gone to sleep.)
  375. # [09:51] * Quits: beverloo_ (beverloo@nat/google/x-efyrfutrbymkovva) (Read error: Operation timed out)
  376. # [09:51] * Joins: beverloo_ (beverloo@nat/google/x-labaagdtgnhweotc)
  377. # [09:53] * Joins: richt (~richt@83.218.67.123)
  378. # [09:57] <TabAtkins> Which exists!
  379. # [09:58] <TabAtkins> I need to make FontFace objects transferable, but you can definitely construct them inside of a worker and add them to the font source.
  380. # [09:58] <TabAtkins> Hm, I'm adding a .fonts property to the worker global. Is that okay? Should I be doing something else?
  381. # [09:59] <TabAtkins> It's added to document in normal pages.
  382. # [09:59] * Joins: TuRnaD0 (~Thunderbi@x1-6-e0-46-9a-1e-fe-ca.cpe.webspeed.dk)
  383. # [10:00] * Joins: yoav_ (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  384. # [10:02] * Quits: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com) (Ping timeout: 240 seconds)
  385. # [10:03] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  386. # [10:05] * Joins: Ms2ger (~Ms2ger@134.199-242-81.adsl-dyn.isp.belgacom.be)
  387. # [10:07] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
  388. # [10:07] * Quits: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net) (Quit: tantek)
  389. # [10:11] <annevk> TabAtkins: why not CSS.fonts ?
  390. # [10:12] <TabAtkins> annevk: Good question, I guess.
  391. # [10:16] * Joins: darobin (~darobin@78.109.80.74)
  392. # [10:16] * Joins: jeremyj (~jeremyj@17.202.44.231)
  393. # [10:21] <annevk> TabAtkins: I guess another thing to think about is how this would work with modules
  394. # [10:22] <annevk> TabAtkins: presumably once you import "css" this should be imported as well, but we haven't really explored the layering of the subsystems I suppose
  395. # [10:22] <JakeA> Hixie: What's your take on promise-vending .loaded() methods (http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-March/253949.html)? The HTML Imports spec wants it (https://www.w3.org/Bugs/Public/show_bug.cgi?id=25007) but it'd be great to have it on other <link> elements too (and maybe img, script)
  396. # [10:23] * Joins: zcorpan (~zcorpan@113.199.42.54)
  397. # [10:24] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  398. # [10:25] * Quits: zcorpan (~zcorpan@113.199.42.54) (Remote host closed the connection)
  399. # [10:25] * Joins: zcorpan (~zcorpan@113.199.42.54)
  400. # [10:29] * Quits: zcorpan (~zcorpan@113.199.42.54) (Ping timeout: 240 seconds)
  401. # [10:30] * Joins: bholley (~bholley@98.210.101.88)
  402. # [10:34] * Quits: bholley (~bholley@98.210.101.88) (Ping timeout: 252 seconds)
  403. # [10:38] * amtiskaw__ is now known as amtiskaw
  404. # [10:47] <annevk> JakeA: why methods?
  405. # [10:51] * Joins: Lachy (~Lachy@213.166.174.2)
  406. # [10:52] <JakeA> annevk: because they're of the moment. As in, img.src = foo; img.loaded().then(...); img.src = bar; img.loaded().then(...)
  407. # [10:53] <JakeA> felt like methods made more sense, but it wouldn't break my world if they were properties :D
  408. # [11:03] * Quits: roven (~roven@78-20-24-80.access.telenet.be) (Remote host closed the connection)
  409. # [11:07] * Quits: Kolombiken (~Adium@gateway.creuna.se) (Quit: Leaving.)
  410. # [11:09] <annevk> JakeA: if you invoke loaded() multiple times, do you get the same object?
  411. # [11:10] <JakeA> annevk: Yes, unless there's a good reason not to. Of course, as soon as you change "src" the promise vended by loaded() changes
  412. # [11:11] <annevk> JakeA: in that case a property seems fine
  413. # [11:12] <JakeA> annevk: navigator.serviceWorker.whenReady should be the same I guess
  414. # [11:12] <JakeA> (although I hate that API with a passion, but don't have a better idea)
  415. # [11:12] <annevk> JakeA: yeah makes sense
  416. # [11:17] * Joins: IZh (~IZh@213.33.220.118)
  417. # [11:27] * Quits: darobin (~darobin@78.109.80.74) (Quit: Leaving...)
  418. # [11:27] * Joins: darobin (~darobin@78.109.80.74)
  419. # [11:31] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
  420. # [11:35] <tobie> It feels kind of weird to have a promised not related to the action itself.
  421. # [11:35] <tobie> As in: img.loadResource(url).then(...
  422. # [11:42] <JakeA> tobie: I don't think it's a big deal. People have been using whatever.ready(callback) in various libraries
  423. # [11:43] <annevk> tobie: it's just status observation, seems fine for one-offs
  424. # [11:45] <tobie> Yeah. There seems to be cases where there's no other solution than that one. Thinking out loud really, but it seems it would help if we can classify those.
  425. # [11:47] * Joins: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com)
  426. # [11:48] <hsivonen> mathiasbynens: validator.nu seems to be up for me. maybe it was just busy earlier?
  427. # [11:49] * Joins: satazor (~satazor@239.201.37.188.rev.vodafone.pt)
  428. # [11:49] * Quits: roc (~chatzilla@60.234.66.18) (Ping timeout: 255 seconds)
  429. # [11:51] <tobie> Seems most of them are around the declarative/imperative boundary (not sure whether this helps).
  430. # [11:52] * Quits: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com) (Ping timeout: 255 seconds)
  431. # [11:55] <mathiasbynens> hsivonen: yeah, works fine now. I’ll keep an eye on it
  432. # [12:01] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  433. # [12:03] * Guest57780 is now known as Garbee
  434. # [12:06] * Joins: satazor_ (~satazor@239.201.37.188.rev.vodafone.pt)
  435. # [12:07] <annevk> tobie: well, serviceWorker.whenReady is not on that boundary I think
  436. # [12:07] <JakeA> Neither is document.ready()
  437. # [12:07] <annevk> tobie: I think the pattern is more that if you have something that multiple parties might want to observe, you need to expose it independently from the action
  438. # [12:07] <tobie> doc.ready is.
  439. # [12:07] <annevk> tobie: as a status-promise
  440. # [12:08] <JakeA> Or anyParserInsertedElement.loaded()
  441. # [12:08] <annevk> (again, I'd prefer document.ready and ele.loaded)
  442. # [12:08] <JakeA> ah yes, sorry
  443. # [12:08] <tobie> you mean props?
  444. # [12:08] <tobie> I agree.
  445. # [12:08] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  446. # [12:09] <JakeA> document.querySelector('img').loaded.then(...)
  447. # [12:09] <mathiasbynens> document.images[0].loaded.then(…)
  448. # [12:09] * Quits: satazor (~satazor@239.201.37.188.rev.vodafone.pt) (Ping timeout: 265 seconds)
  449. # [12:09] <mathiasbynens> </code-golf>
  450. # [12:10] <JakeA> haha
  451. # [12:10] <JakeA> but your IRC handle is longer, so it almost balances out
  452. # [12:13] <tobie> None of these (.ready, .ready() .whenReady()) are particularly nice. :(
  453. # [12:14] <JakeA> What's not nice about it? Do you feel the same about jquery's $(document).ready(callback)?
  454. # [12:14] <tobie> yeah. it's terrible.
  455. # [12:15] <tobie> but less ugly with a callback then with a promise.
  456. # [12:16] <JakeA> Got anything more constructive? :D
  457. # [12:17] <tobie> Man, I wish I had.
  458. # [12:18] * Joins: barnabywalters (~barnabywa@46-239-239-203.tal.is)
  459. # [12:18] * Quits: richt (~richt@83.218.67.123) (Quit: Leaving...)
  460. # [12:18] <TabAtkins> FontFace uses a .loaded attribute to expose a promise.
  461. # [12:18] <TabAtkins> tobie: A promise is a callback. ^_^
  462. # [12:20] <JakeA> TabAtkins: Ohh, I didn't realise that. Well, that's all the more reason for these to be attributes & not methods
  463. # [12:20] <tobie> agreed.
  464. # [12:20] <annevk> Oh right, TabAtkins is in Seoul, it all makes sense now
  465. # [12:20] <TabAtkins> Hah, wondering about my timezone?
  466. # [12:20] <tobie> when(font.loaded).then
  467. # [12:20] <TabAtkins> tobie: ??? No, font.loaded.then(...)
  468. # [12:20] <tobie> (sorry, toying with stuff)
  469. # [12:20] <annevk> TabAtkins: I was doing the math and at 3-4AM you're usually not around
  470. # [12:21] <TabAtkins> annevk: Yeah, checking gavin's stats I'm virtually never around in the 12am to 6am block.
  471. # [12:22] <TabAtkins> Still a good bit behind jgraham in the stats. I don't think I'll ever move past 5th place.
  472. # [12:22] <annevk> Whoa, Hixie made a solid comeback :-)
  473. # [12:22] <JakeA> await img.loaded;
  474. # [12:23] <annevk> JakeA: you can almost read it
  475. # [12:23] <JakeA> wfm
  476. # [12:23] <tobie> Only concern I still have is loaded feels a tad like a boolean
  477. # [12:24] <TabAtkins> tobie: Was my concern too, but shrug.
  478. # [12:24] <tobie> yeah.
  479. # [12:24] <tobie> What's gavin's stats?
  480. # [12:24] <annevk> tobie: see /topic
  481. # [12:24] <tobie> duh
  482. # [12:25] * Joins: richt (~richt@83.218.67.123)
  483. # [12:26] * Joins: richt_ (~richt@91.216.105.52)
  484. # [12:27] * Joins: richt__ (~richt@83.218.67.123)
  485. # [12:27] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 240 seconds)
  486. # [12:27] * Joins: zcorpan (~zcorpan@113.199.41.81)
  487. # [12:28] <jgraham> Also glob has stats under "about". Not as detailed as gavin's though
  488. # [12:29] <jgraham> But using more data, I think?
  489. # [12:29] <TabAtkins> dear gavin (or gavin__ ), your stats page doesn't handle unicode properly.
  490. # [12:29] * Joins: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95)
  491. # [12:29] <TabAtkins> Saw some curly quotes turned into “
  492. # [12:30] * TabAtkins will never get over that Divya holds both first and second place for most all-caps shouting.
  493. # [12:30] * Joins: karlcow (~karl@nerval.la-grange.net)
  494. # [12:30] * Quits: richt_ (~richt@91.216.105.52) (Ping timeout: 240 seconds)
  495. # [12:30] * Quits: richt (~richt@83.218.67.123) (Ping timeout: 276 seconds)
  496. # [12:30] * Quits: BigBangUDR (~Thunderbi@220.225.242.27) (Quit: BigBangUDR)
  497. # [12:31] <TabAtkins> Even when you cut her shouting in half, she beats everyone else.
  498. # [12:34] <jgraham> I have a theory that the most productive place to write documentation is on the train. Maybe I should just go and sit on the circle line for the rest of the day.
  499. # [12:35] <jgraham> (yes, I know you can't actually just go round and round the circle line anymore)
  500. # [12:35] <Ms2ger> Sounds like a theory to be tested
  501. # [12:35] <TabAtkins> I certainly like writing on the train.
  502. # [12:35] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  503. # [12:37] * Joins: adactio (~adactio@212.42.170.181)
  504. # [12:43] <JakeA> annevk: Looking at https://github.com/slightlyoff/ServiceWorker/issues/235#issuecomment-40742195 - agree the tagging thing is weird, but what can fetchEvent.default() resolve to?
  505. # [12:49] <JakeA> annevk: event.default() could do a fetch but return OpaqueResponse for redirects. Could say that OpaqueResponse redirects don't go back through the serviceworker
  506. # [12:50] <JakeA> feels like trading one kind of magic for another
  507. # [12:51] <annevk> JakeA: I think part of the problem is that you're not observing this from the perspective of how APIs use Fetch (the platform layer, not the API)
  508. # [12:51] <annevk> JakeA: most APIs use Fetch and have it follow redirects
  509. # [12:51] <annevk> JakeA: the navigate action uses Fetch and explicitly tells it to not follow redirects, it's the only part of the platform that does that as far as I know (and maybe AppCache now?)
  510. # [12:52] <annevk> JakeA: so in the typical case all redirects will be followed and you get back a normal Response
  511. # [12:53] <annevk> JakeA: in the navigate case you can already get back an OpaqueResponse as the user can navigate away from your site
  512. # [12:54] <annevk> JakeA: so there we'd hand back an OpaqueResponse for redirects (because Fetch was instructed not to follow them) and allow the navigate action to inspect that and take appropriate action
  513. # [12:55] <annevk> JakeA: but I don't think explaining this in terms of fetch() helps, as that might throw away CSP things, priorities, etc.
  514. # [12:56] <annevk> JakeA: also, there's some things we need to consider with respect to what happens when the user navigates away and the service worker hands back a generated response or some such
  515. # [12:57] <JakeA> annevk: So, if I have <link rel=stylesheet href=blah>, it goes off into the fetch layer, does its redirects, and gives the page its response. How is the base url of the CSS handled, via the response url?
  516. # [12:58] <annevk> JakeA: yes
  517. # [12:59] <annevk> (assuming no service workers in play)
  518. # [13:09] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  519. # [13:12] <zcorpan> Hixie: i ran a screenshot of the spec through a color blindness simulator, and it seems OK with protanopia and deuteranopia (1-5% in males), but the link is almost the same as the surrounding text with tritanopia (< 0.003% of males and females)
  520. # [13:12] <zcorpan> (unvisited link, didn't include a visited link in the image)
  521. # [13:14] <wilhelm> jgraham: So like Yamanote parties, just more boring? :D
  522. # [13:15] <zcorpan> http://www.etre.com/simulate.php?image=defa540b013c2e5c3fdfcbd79b63c773&condition=tritanopia&type=jpeg - tritanopia (zoom in, i guess the blurry result can simulate some other visual impairedness :-P)
  523. # [13:18] * Joins: Kolombiken (~Adium@94.137.124.2)
  524. # [13:26] <zcorpan> Hixie: that said, i think the current style is an improvement
  525. # [13:29] <jgraham> wilhelm: I'm not sure I would want to try and work on the Tokyo metro
  526. # [13:33] * Joins: scor (scor@nat/acquia/x-msuwjnnemddsrper)
  527. # [13:33] * Quits: scor (scor@nat/acquia/x-msuwjnnemddsrper) (Changing host)
  528. # [13:33] * Joins: scor (scor@drupal.org/user/52142/view)
  529. # [13:34] * Quits: satazor_ (~satazor@239.201.37.188.rev.vodafone.pt) (Remote host closed the connection)
  530. # [13:34] * Quits: scor (scor@drupal.org/user/52142/view) (Client Quit)
  531. # [13:36] <JakeA> annevk: Can I get a sanity check of this? https://github.com/slightlyoff/ServiceWorker/issues/235#issuecomment-43614413
  532. # [13:38] * Quits: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95) (Quit: coolbot95)
  533. # [13:38] <zcorpan> Hixie: i'm not entirely sure about the :target styling. i think i'd want the arrow and its box to be smaller. some color for that thing seems OK to me
  534. # [13:39] * Joins: satazor (~satazor@bl17-218-25.dsl.telepac.pt)
  535. # [13:41] <wilhelm> zcorpan: It could be fun to have a designer play with a revision of the stylesheet.
  536. # [13:41] * wilhelm has one in mind. (c:
  537. # [13:42] <zcorpan> wilhelm: like http://developers.whatwg.org ?
  538. # [13:44] <wilhelm> Oh, I hadn't seen that one. That's certainly more readable. (c:
  539. # [13:45] <zcorpan> Hixie: the "next" link at the bottom is a nice thing in the dev version
  540. # [13:45] * Joins: scor (scor@nat/acquia/x-uileqqgtxmhzupup)
  541. # [13:45] * Quits: scor (scor@nat/acquia/x-uileqqgtxmhzupup) (Changing host)
  542. # [13:45] * Joins: scor (scor@drupal.org/user/52142/view)
  543. # [13:49] <annevk> JakeA: looks wrong
  544. # [13:50] <annevk> JakeA: default() just needs to use incoming "fetchStandardRequest" that could have manualRedirect either set to true or false
  545. # [13:50] <zcorpan> benschwarz_: seems like the svg doesn't load/exist in http://developers.whatwg.org/content-models.html#kinds-of-content
  546. # [13:51] <annevk> JakeA: e.g. <img src=...> comes in SW, SW does default(), redirects will be followed
  547. # [13:52] <JakeA> annevk: isn't that correct?
  548. # [13:53] <annevk> JakeA: oh wait, I missed the if statement
  549. # [13:54] <zcorpan> annevk: so <img> is going to be able to load two resources in parallel
  550. # [13:54] <zcorpan> in case that affects things for SW
  551. # [13:54] <annevk> JakeA: even so, there's no castToOpaqueResponse needed, that should be wrapped automagically
  552. # [13:54] <annevk> zcorpan: that'll just be two events quickly after another
  553. # [13:55] <annevk> zcorpan: SW can't do true parallel
  554. # [13:55] * Quits: adactio (~adactio@212.42.170.181) (Quit: adactio)
  555. # [13:56] <annevk> JakeA: as in, the way I think this should work is that .default() just hands the request back to Fetch and Fetch does the rest
  556. # [13:56] <jgraham> wilhelm++ for getting a designer to play with the stylesheet. Although they have to understand the functional requirements (most of the things that have style have it for a reason, but the styles that they have aren't necessarily good)
  557. # [13:57] <annevk> JakeA: and then Fetch hands a Response, potentially Opaque, back to .default()'s promise
  558. # [13:57] <zcorpan> annevk: not sure i follow, but then i basically know nothing about SW :-)
  559. # [13:57] <annevk> zcorpan: the network stack is still on a single thread
  560. # [13:58] <annevk> zcorpan: anyway, it should be fine
  561. # [13:58] <zcorpan> annevk: so you can only fetch one thing at a time in a SW?
  562. # [13:58] * Joins: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi)
  563. # [13:58] <annevk> zcorpan: you can queue one thing at a time
  564. # [13:59] <annevk> zcorpan: it's a subtle but important difference, and that's not really limited to SW
  565. # [13:59] <zcorpan> but then you could have mutliple things fetching at the same time?
  566. # [14:00] <annevk> zcorpan: yeah, it's not really different from constructing several XHRs in a row and then invoking send() in them in a row and waiting for data to come back
  567. # [14:01] <zcorpan> ok. so i didn't mean that <img> is able to queue two things in parallel. i meant that it could start fetch A at time T and start fetch B at time T+x which would not necessarily abort A
  568. # [14:02] <wilhelm> jgraham: Indeed. (c:
  569. # [14:03] <annevk> zcorpan: I can't think offhand of places that assume 1 API : 1 fetch
  570. # [14:03] <zcorpan> ok
  571. # [14:03] <annevk> zcorpan: well... sounds like a potential problem for integrity=""
  572. # [14:04] <annevk> zcorpan: and of course you can't control crossorigin for each fetch
  573. # [14:05] <annevk> zcorpan: you might want to email public-webappsec@w3.org with regards to integrity="" I suppose, given that this kind of loading is actually a feature people want to use
  574. # [14:05] <annevk> s/given/provided/
  575. # [14:05] <zcorpan> annevk: do you have a pointer to integrity=""?
  576. # [14:05] <zcorpan> annevk: it's not so much want to use, more required for web compat
  577. # [14:05] <annevk> zcorpan: http://w3c.github.io/webappsec/specs/subresourceintegrity/
  578. # [14:06] <annevk> zcorpan: basically allows you to specify a hash for the resource
  579. # [14:06] * Quits: satazor (~satazor@bl17-218-25.dsl.telepac.pt) (Remote host closed the connection)
  580. # [14:06] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  581. # [14:07] * Joins: satazor (~satazor@bl17-218-25.dsl.telepac.pt)
  582. # [14:09] <zcorpan> so... for example let's say you have <img src=foo integrity=bar> and then, while foo is loading but the dimensions are known, you do .src = 'baz'; .integrity = 'quux'; which starts a pending fetch. then foo completes loading and the UA compares the hash and finds that it doesn't match quux?
  583. # [14:09] * Joins: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com)
  584. # [14:11] * Quits: satazor (~satazor@bl17-218-25.dsl.telepac.pt) (Ping timeout: 258 seconds)
  585. # [14:12] <zcorpan> maybe the integrity thing could check the value of the integrity attribute at the time you resolve the URL or at the time you start the fetch, instead of when you're done fetching
  586. # [14:13] <annevk> zcorpan: it could be an argument for tight coupling the integrity data with the fetch
  587. # [14:14] <zcorpan> seems like it does take the integrity at the time of start of fetch
  588. # [14:15] <zcorpan> also: monkey patching
  589. # [14:15] <annevk> zcorpan: yeah, temporarily
  590. # [14:16] <annevk> Temporarily monkey patching is actually somewhat beneficial, it's just that people don't always follow up on cleaning up
  591. # [14:16] <zcorpan> it seems like the general approach is compatible with <img>'s dual fetching
  592. # [14:16] <zcorpan> yeah
  593. # [14:17] * Quits: jahman (~woops@129.175.204.73) (Remote host closed the connection)
  594. # [14:18] * Quits: IZh (~IZh@213.33.220.118) (Quit: ChatZilla 0.9.90.1 [SeaMonkey 2.26/20140428215651])
  595. # [14:18] <zcorpan> do people want to use integrity together with picture/srcset ?
  596. # [14:19] * Joins: jahman (~woops@129.175.204.73)
  597. # [14:19] <annevk> prolly
  598. # [14:19] <zcorpan> <img srcset="foo.jpg 100w integrity(foo), bar.jpg 200w integrity(bar)"> maybe
  599. # [14:20] <annevk> if that works that could be nice
  600. # [14:20] <annevk> can you do url(foo.jpg) too?
  601. # [14:20] <zcorpan> no
  602. # [14:20] <annevk> oh
  603. # [14:21] <annevk> I would expect CSS to end up with fetch(foo.jpg, other stuff here)
  604. # [14:21] <annevk> and deal with integrity that way if we want it there
  605. # [14:22] <zcorpan> can you give an example of how it would work together with some property (like background-image, say)?
  606. # [14:23] * Quits: roven (~roven@78-20-24-80.access.telenet.be) (Remote host closed the connection)
  607. # [14:24] * Quits: ^esc (~esc-ape@178.115.131.194.wireless.dyn.drei.com) (Ping timeout: 252 seconds)
  608. # [14:26] <annevk> background-image:fetch(foo.jpg, some new syntax)
  609. # [14:26] <jgraham> that's pretty ugly
  610. # [14:27] <jgraham> (using "fetch" there sounds very imperative whereas css is typically declarative)
  611. # [14:29] <zcorpan> annevk: i think foo.jpg will need to be either a string or a url() to remain sanity
  612. # [14:29] <zcorpan> but i also agree with jgraham about the imperative part
  613. # [14:30] <annevk> zcorpan: I'm sort of indifferent on the name and the syntax particulars
  614. # [14:30] <zcorpan> ok
  615. # [14:30] <zcorpan> so now there's a thing called image() in css
  616. # [14:30] <zcorpan> with some new syntax
  617. # [14:30] <annevk> it's more that we need to be able to pass more data along with a URL
  618. # [14:30] <zcorpan> so maybe integrity can go in that
  619. # [14:31] <annevk> can image() be used for SVG subresources and shapes and things?
  620. # [14:31] <annevk> also doesn't work for @import
  621. # [14:33] * Joins: BigBangUDR (~Thunderbi@220.225.242.27)
  622. # [14:33] * Joins: deane (~Thunderbi@124-197-19-37.callplus.net.nz)
  623. # [14:34] <zcorpan> yeah i guess we've deferred on supporting crossorigin for @import
  624. # [14:37] * Joins: tav (~tav`@host31-52-138-103.range31-52.btcentralplus.com)
  625. # [14:37] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  626. # [14:38] <annevk> :/
  627. # [14:39] <zcorpan> maybe i can bring it up tomorrow
  628. # [14:39] <zcorpan> is there an email somewhere about this?
  629. # [14:39] <annevk> don't think so
  630. # [14:39] <zcorpan> can you send one to www-style? :-)
  631. # [14:39] <annevk> well, there's a long thread on public-fx somewhere
  632. # [14:40] <annevk> regarding what to do with shapes and SVG and what not and how they can all work together
  633. # [14:41] <annevk> how can you figure out if two things happen in the same task?
  634. # [14:42] * zcorpan doesn't follow
  635. # [14:44] * Quits: tav (~tav`@host31-52-138-103.range31-52.btcentralplus.com) (Quit: tav)
  636. # [14:44] <annevk> http://dump.testsuite.org/xhr/upload-events.html I want to know if (upload) "loadend: 1" is in the same task as "xhr onreadystatechange: 2"
  637. # [14:45] * Quits: deane (~Thunderbi@124-197-19-37.callplus.net.nz) (Read error: Connection reset by peer)
  638. # [14:46] <annevk> Hmm, in Chrome they are not
  639. # [14:47] * Joins: jdaggett (~jdaggett@q023013.dynamic.ppp.asahi-net.or.jp)
  640. # [14:51] * Quits: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com) (Ping timeout: 240 seconds)
  641. # [14:51] * Quits: zcorpan (~zcorpan@113.199.41.81) (Ping timeout: 252 seconds)
  642. # [14:53] * Joins: zcorpan (~zcorpan@113.199.41.81)
  643. # [14:55] <zcorpan> annevk: like load() a video in the first event and check the networkState in the second event
  644. # [14:55] <annevk> zcorpan: for next time :-)
  645. # [14:56] <zcorpan> annevk: if it's NETWORK_NO_SOURCE then they were the same task, if it's NETWORK_EMPTY then they were separate tasks
  646. # [14:56] <zcorpan> for a <video> without src or source
  647. # [14:56] * Krinkle|detached is now known as Krinkle
  648. # [14:59] <zcorpan> annevk: do you have a pointer to public-fx thread?
  649. # [15:00] * yoav_ is now known as yoav
  650. # [15:01] <zcorpan> annevk: otherwise, please send a short message to www-style so i can bring it up tomorrow. now i need to sleep
  651. # [15:02] * Joins: tav (~tav`@37.157.36.218)
  652. # [15:03] <annevk> zcorpan: around http://lists.w3.org/Archives/Public/public-fx/2013AprJun/thread.html#msg176
  653. # [15:04] * Joins: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com)
  654. # [15:07] * Quits: Areks (~Areks@rs.gridnine.com) (Read error: Connection reset by peer)
  655. # [15:10] * Joins: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net)
  656. # [15:11] <zcorpan> annevk: thx
  657. # [15:14] * Quits: npcomp (~eldon@50-13-195-119.gar.clearwire-wmx.net) (Client Quit)
  658. # [15:14] * Quits: CvP (~CvP@27.147.199.131) (Ping timeout: 255 seconds)
  659. # [15:15] * Joins: plutoniix (~plutoniix@node-l8i.pool-101-108.dynamic.totbb.net)
  660. # [15:15] * Joins: CvP (~CvP@27.147.199.131)
  661. # [15:15] * Joins: newtron (~newtron@199.71.174.204)
  662. # [15:15] * Quits: newtron (~newtron@199.71.174.204) (Remote host closed the connection)
  663. # [15:16] * Joins: newtron (~newtron@199.71.174.203)
  664. # [15:18] * Quits: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  665. # [15:25] * Quits: zcorpan (~zcorpan@113.199.41.81) (Remote host closed the connection)
  666. # [15:25] * Joins: zcorpan (~zcorpan@113.199.41.81)
  667. # [15:26] * Joins: tj_vantoll (~Adium@2601:4:5380:eba:7c7b:d7ac:5969:7195)
  668. # [15:30] * Quits: zcorpan (~zcorpan@113.199.41.81) (Ping timeout: 240 seconds)
  669. # [15:31] * Quits: tav (~tav`@37.157.36.218) (Quit: tav)
  670. # [15:32] * Joins: satazor (~satazor@bl17-218-25.dsl.telepac.pt)
  671. # [15:35] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  672. # [15:36] * Joins: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95)
  673. # [15:38] * Quits: KevinMarks2 (~yaaic@2607:fb90:500:d238:e1a8:433a:b442:3f2e) (Ping timeout: 240 seconds)
  674. # [15:39] <foolip> annevk: but note that <video> doesn't use tasks as per spec in at least WebKit, Blink and Presto, so if it doesn't work be careful about which code to blame :)
  675. # [15:40] <jgraham> foolip: That sounded a lot like "if it doesn't work, blame foolip" :)
  676. # [15:43] * Joins: Areks (~Areks@rs.gridnine.com)
  677. # [15:43] <foolip> jgraham: that wouldn't be entirely unfair :)
  678. # [15:43] * Quits: Areks (~Areks@rs.gridnine.com) (Client Quit)
  679. # [15:44] * Joins: Areks (~Areks@rs.gridnine.com)
  680. # [15:45] * Joins: bholley (~bholley@98.210.101.88)
  681. # [15:45] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  682. # [15:47] * Joins: izhak (~izhak@92.248.142.152)
  683. # [15:48] * Joins: KevinMarks2 (~yaaic@2607:fb90:500:d238:e1a8:433a:b442:3f2e)
  684. # [15:50] * Joins: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com)
  685. # [15:53] <annevk> I wonder what happend to HTTPbis https://www.w3.org/Bugs/Public/show_bug.cgi?id=25097#c0
  686. # [15:53] <JakeA> annevk: if the request is to the same origin, but it responds with a redirect to /somewhere-else/?secret=1234567890, will that be an OpaqueResponse?
  687. # [15:54] <JakeA> annevk: I thought it wouldn't be, which is why I added the cast
  688. # [15:54] * Quits: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com) (Ping timeout: 240 seconds)
  689. # [15:55] <annevk> JakeA: yeah, currently Fetch does not say that because the redirect would not be exposed to script, but once that's an option I'll make sure to do that right at the source
  690. # [15:55] * Joins: encryptd_fractl (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com)
  691. # [15:56] <MikeSmith> annevk: yeah I thought I remembered seeing a tweet from Julian months ago that implied it had been sent to the IETF editor for publication
  692. # [15:57] <MikeSmith> annevk: btw html5.org/tools/web-apps-tracker is hanging atm
  693. # [15:58] <annevk> MikeSmith: prolly means svn.whatwg.org is hanging
  694. # [15:58] <annevk> hmm no
  695. # [15:58] * Quits: jdaggett (~jdaggett@q023013.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
  696. # [15:59] <annevk> MikeSmith: seems to work again
  697. # [16:00] <MikeSmith> annevk: yeah wfm too now
  698. # [16:01] * Joins: bholley (~bholley@98.210.101.88)
  699. # [16:02] * Quits: satazor (~satazor@bl17-218-25.dsl.telepac.pt) (Remote host closed the connection)
  700. # [16:02] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  701. # [16:06] * Joins: bholley (~bholley@98.210.101.88)
  702. # [16:06] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  703. # [16:07] * Joins: bholley (~bholley@98.210.101.88)
  704. # [16:07] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  705. # [16:07] * Joins: bholley (~bholley@98.210.101.88)
  706. # [16:08] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  707. # [16:08] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  708. # [16:08] * Joins: bholley (~bholley@98.210.101.88)
  709. # [16:09] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  710. # [16:09] * Joins: bholley (~bholley@98.210.101.88)
  711. # [16:10] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  712. # [16:10] * Joins: bholley (~bholley@98.210.101.88)
  713. # [16:10] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  714. # [16:10] * Quits: fredy (~fredy@snf-8914.vm.okeanos.grnet.gr) (Excess Flood)
  715. # [16:11] * Joins: bholley (~bholley@98.210.101.88)
  716. # [16:11] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  717. # [16:11] * Joins: bholley (~bholley@98.210.101.88)
  718. # [16:12] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  719. # [16:12] * Joins: fredy (~fredy@snf-8914.vm.okeanos.grnet.gr)
  720. # [16:15] * Joins: bholley (~bholley@98.210.101.88)
  721. # [16:15] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  722. # [16:19] * Joins: bholley (~bholley@98.210.101.88)
  723. # [16:19] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  724. # [16:23] * Quits: mven (~textual@ip68-104-38-84.lv.lv.cox.net) (Ping timeout: 265 seconds)
  725. # [16:24] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
  726. # [16:25] * Joins: bholley (~bholley@98.210.101.88)
  727. # [16:25] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  728. # [16:26] * Joins: bholley (~bholley@98.210.101.88)
  729. # [16:26] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  730. # [16:27] * Joins: satazor (~satazor@239.201.37.188.rev.vodafone.pt)
  731. # [16:28] * Quits: roven (~roven@78-20-24-80.access.telenet.be) (Ping timeout: 255 seconds)
  732. # [16:28] * Joins: deane (~Thunderbi@124-197-19-37.callplus.net.nz)
  733. # [16:31] * Quits: KevinMarks (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 255 seconds)
  734. # [16:36] * Quits: BigBangUDR (~Thunderbi@220.225.242.27) (Quit: BigBangUDR)
  735. # [16:36] * Quits: jungkees (uid24208@gateway/web/irccloud.com/x-plzzkzllmyxakhha) (Quit: Connection closed for inactivity)
  736. # [16:37] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  737. # [16:37] * Quits: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net) (Ping timeout: 276 seconds)
  738. # [16:41] <zewt> annevk: whew? (re: dodging another onclick)
  739. # [16:41] <annevk> zewt: I have no idea what is going on
  740. # [16:41] <annevk> zewt: I blame DOM Level 3 Events for not cleaning this up
  741. # [16:41] <zewt> i think we should discourage people from ever using the phrase "default action"
  742. # [16:42] <annevk> I have been trying to call it out each time I see it
  743. # [16:42] <annevk> zewt: what onclick behavior though?
  744. # [16:42] * Joins: diffalot (~diffalot@c-76-107-128-104.hsd1.ms.comcast.net)
  745. # [16:42] <zewt> the fact that onclick does have "in-dispatch" behavior
  746. # [16:43] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
  747. # [16:43] * Quits: deane (~Thunderbi@124-197-19-37.callplus.net.nz) (Read error: Connection reset by peer)
  748. # [16:43] <zewt> i think we need a new name for that, to clearly distinguish it from what people think of as "default actions"
  749. # [16:44] <annevk> zewt: pointer to the spec for that? I think I'm missing something
  750. # [16:44] <JakeA> annevk: if a fetch is performed as part of a navigation, is the responses url redundant?
  751. # [16:44] <zewt> i don't know if it's specced anywhere
  752. # [16:44] <JakeA> response's*
  753. # [16:44] <annevk> JakeA: could still be relevant if the SW returned something unexpected
  754. # [16:45] <JakeA> annevk: like?
  755. # [16:45] <annevk> JakeA: navigate to /bar SW returns response for http://www.google.com/
  756. # [16:46] <zewt> annevk: https://zewt.org/~glenn/test-stupid-click-event.html
  757. # [16:46] <JakeA> annevk: I think the exception there is OpaqueResponse, not url
  758. # [16:46] <Domenic> annevk: I think it was good guidance that events are for notification, not actions. I hadn't read that anywhere before.
  759. # [16:46] * Joins: bholley (~bholley@98.210.101.88)
  760. # [16:46] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  761. # [16:47] <annevk> JakeA: it's not really an exception
  762. # [16:47] <annevk> JakeA: but it would be a CORSResponse
  763. # [16:47] <JakeA> That's fine though, isn't it?
  764. # [16:47] * Joins: bholley (~bholley@98.210.101.88)
  765. # [16:47] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  766. # [16:47] <annevk> JakeA: but in that case you want to look at the url of the response
  767. # [16:47] <zewt> i think there are a couple other events like that but I don't know what they are
  768. # [16:47] <annevk> JakeA: you being the navigate algorithm
  769. # [16:48] <annevk> Domenic: yeah, maybe I should add that more explicitly to the DOM specification
  770. # [16:48] <zewt> i wonder if that could be explained in terms of capturing the event on the link, then queuing a task to look at defaultPrevented after the event finishes... probably not, since that could be broken by stopPropagationImmediate
  771. # [16:48] * Joins: deane (~Thunderbi@124-197-19-37.callplus.net.nz)
  772. # [16:49] <Domenic> annevk: +1, that would be excellent.
  773. # [16:50] <annevk> zewt: so when I tested myself I forgot to generate an event that is a MouseEvent
  774. # [16:50] <zewt> sorry, I thought we talked about this before or I'd have made more noise about it
  775. # [16:50] <JakeA> annevk: I'm wondering if we can ditch fetchEvent.default(). If subresources have a base url of response.url, but navigations use window.location.href (as in, what's in the url bar), I don't think we need .default()
  776. # [16:51] <Domenic> annevk: oh wow, i was wondering when someone would bring up the ArrayBuffer mess
  777. # [16:52] <annevk> JakeA: default() is for preserving the request instance
  778. # [16:53] <annevk> JakeA: so you preserve e.g. that redirects are not to be followed
  779. # [16:53] <annevk> JakeA: and that CSP applies
  780. # [16:54] <annevk> zewt: HTML has a bunch of stuff around "synthetic click"
  781. # [16:56] <annevk> Domenic: I'm not sure what is going on there
  782. # [16:56] * Joins: bholley (~bholley@98.210.101.88)
  783. # [16:56] <annevk> Domenic: or how their implementations have been moved to ES without anyone else noticing this
  784. # [16:56] <zewt> html spec seems to be thrashing chrome on load way more than it was
  785. # [16:56] <Domenic> annevk: my guess is that they only looked at the Khronos spec, which doesn't contain neutering? (Is that true?)
  786. # [16:57] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  787. # [16:57] <zewt> heh now I'm scrolling the spec and getting a transparent background
  788. # [16:57] * Joins: bholley (~bholley@98.210.101.88)
  789. # [16:57] <annevk> Domenic: no Khronos defines what to do when something is neutered
  790. # [16:57] <annevk> Domenic: http://www.khronos.org/registry/typedarray/specs/latest/
  791. # [16:57] <JakeA> annevk: hmm, true
  792. # [16:57] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  793. # [16:57] <zewt> annevk: there's "synthetic click activation steps", which has nothing to do with events I think
  794. # [16:58] * Joins: bholley (~bholley@98.210.101.88)
  795. # [16:58] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  796. # [16:58] <zewt> (click-like things to do when other things happen, not when the user dispatches his own click event)
  797. # [16:58] * Joins: bholley (~bholley@98.210.101.88)
  798. # [16:59] <Domenic> annevk: welp... more cases where Allen is not properly integrating with existing systems, IMO.
  799. # [16:59] * Domenic is still disgruntled about ES tasks vs. HTML microtasks
  800. # [16:59] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  801. # [16:59] <zewt> why would the language level have tasks? that doesn't even make sense
  802. # [16:59] * Joins: bholley (~bholley@98.210.101.88)
  803. # [16:59] <zewt> tasks are part of the event loop, which don't belong at the language layer
  804. # [16:59] * Joins: JosephSilber (~Joseph@ool-44c3e80a.static.optonline.net)
  805. # [17:00] <annevk> zewt: how can you have asynchronous language then?
  806. # [17:00] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  807. # [17:00] <zewt> that doesn't belong at the language layer either
  808. # [17:00] * Joins: bholley (~bholley@98.210.101.88)
  809. # [17:00] <annevk> zewt: I think you're right that HTML basically does not define this; I slowly start to remember a long time ago when we looked at this and decided it was for DOM Level 3 Events to define and that of course never happened
  810. # [17:00] <annevk> zewt: see async/await syntax
  811. # [17:00] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  812. # [17:01] * Joins: bholley (~bholley@98.210.101.88)
  813. # [17:01] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  814. # [17:01] <zewt> especially here, where the web has a complex event loop mechanism; the language is at a lower layer than it
  815. # [17:01] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  816. # [17:01] <zewt> annevk: i don't think an external spec could define it without monkey patching, since it seems to need a hook in dispatchEvent
  817. # [17:02] * Joins: bholley (~bholley@98.210.101.88)
  818. # [17:02] * Quits: markkes (~markkes@62.207.90.201) (Quit: Nettalk6 - www.ntalk.de)
  819. # [17:02] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  820. # [17:02] * Joins: bholley (~bholley@98.210.101.88)
  821. # [17:03] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  822. # [17:03] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  823. # [17:03] * Joins: bholley (~bholley@98.210.101.88)
  824. # [17:04] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  825. # [17:04] * Joins: bholley (~bholley@98.210.101.88)
  826. # [17:04] <annevk> zewt: I found https://www.w3.org/Bugs/Public/show_bug.cgi?id=10897
  827. # [17:04] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  828. # [17:05] * Joins: bholley (~bholley@98.210.101.88)
  829. # [17:05] * Quits: deane (~Thunderbi@124-197-19-37.callplus.net.nz) (Read error: Connection reset by peer)
  830. # [17:05] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  831. # [17:05] * Joins: bholley (~bholley@98.210.101.88)
  832. # [17:06] <zewt> don't think the popup counterexample is valid (just check the trusted flag)
  833. # [17:06] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  834. # [17:06] * Joins: bholley (~bholley@98.210.101.88)
  835. # [17:06] <zewt> i wrote code myself that dispatched click myself (before I knew what I was doing), so it seems guaranteed that other people have too
  836. # [17:07] * Joins: ehynds (~ehynds@64.206.121.41)
  837. # [17:07] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  838. # [17:07] <zewt> (i was capturing events on document, cancelling them, doing other stuff, then re-dispatching them later; it worked for click, and I recall being annoyed that it didn't work with submit)
  839. # [17:07] <annevk> zewt: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12230 seems to be master bug
  840. # [17:07] * Joins: bholley (~bholley@98.210.101.88)
  841. # [17:07] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  842. # [17:08] <zewt> (it does work with submit? maybe it was some other event I had trouble with)
  843. # [17:09] * Joins: bholley (~bholley@98.210.101.88)
  844. # [17:09] <zewt> or maybe not (according to comment 10); retesting...
  845. # [17:09] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  846. # [17:09] * Joins: bholley (~bholley@98.210.101.88)
  847. # [17:10] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  848. # [17:10] * Joins: bholley (~bholley@98.210.101.88)
  849. # [17:11] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  850. # [17:11] * Joins: deane (~Thunderbi@124-197-19-37.callplus.net.nz)
  851. # [17:11] * Joins: bholley (~bholley@98.210.101.88)
  852. # [17:11] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  853. # [17:12] * Joins: bholley (~bholley@98.210.101.88)
  854. # [17:12] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  855. # [17:12] <zewt> submits for me in firefox, but not chrome
  856. # [17:12] * Joins: bholley (~bholley@98.210.101.88)
  857. # [17:13] <zewt> (maybe that's what I was annoyed about--probably wrote the code in firefox first)
  858. # [17:13] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  859. # [17:13] <zewt> (test at same url)
  860. # [17:13] <dglazkov> good morning, Whatwg!
  861. # [17:13] * Joins: bholley (~bholley@98.210.101.88)
  862. # [17:14] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  863. # [17:14] * Joins: bholley (~bholley@98.210.101.88)
  864. # [17:14] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  865. # [17:15] * Joins: bholley (~bholley@98.210.101.88)
  866. # [17:15] <caitp> i need to script my client to say good morning like that in every channel, it's so charming
  867. # [17:15] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  868. # [17:15] * Joins: jwalden (~waldo@corp.mtv2.mozilla.com)
  869. # [17:15] <JakeA> annevk: if I do event.respondWith(caches.match('/fallback.html')), what's the base url for the resulting page (assuming no <base> element)? Is it event.request.url or the cachedRepsonse.url?
  870. # [17:15] <zewt> (don't, it's really annoying; highlights everyone's window for no reason)
  871. # [17:15] * Joins: jsbell (jsbell@nat/google/x-jrbkufctaojtophx)
  872. # [17:16] * Joins: bholley (~bholley@98.210.101.88)
  873. # [17:16] <JakeA> annevk: Feels like it should be the former
  874. # [17:16] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  875. # [17:16] * Joins: bholley (~bholley@98.210.101.88)
  876. # [17:17] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  877. # [17:17] <annevk> JakeA: yes
  878. # [17:17] * Joins: bholley (~bholley@98.210.101.88)
  879. # [17:18] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  880. # [17:19] <annevk> JakeA: I think we jotted this on the etherpad at some point
  881. # [17:19] * Joins: bholley (~bholley@98.210.101.88)
  882. # [17:19] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  883. # [17:19] * Joins: bholley (~bholley@98.210.101.88)
  884. # [17:20] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  885. # [17:20] <JakeA> annevk: What if fetch(request) didn't follow redirects if the context was one of the navigation ones? Then the only benefit of event.default() is CSP, right?
  886. # [17:20] * Joins: bholley (~bholley@98.210.101.88)
  887. # [17:21] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  888. # [17:21] * Joins: bholley (~bholley@98.210.101.88)
  889. # [17:21] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  890. # [17:22] * Joins: bholley (~bholley@98.210.101.88)
  891. # [17:22] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  892. # [17:23] * Joins: bholley (~bholley@98.210.101.88)
  893. # [17:23] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  894. # [17:23] * Joins: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se)
  895. # [17:23] <annevk> JakeA: prioritization
  896. # [17:23] * Joins: bholley (~bholley@98.210.101.88)
  897. # [17:24] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  898. # [17:24] * Joins: bholley (~bholley@98.210.101.88)
  899. # [17:25] * Joins: NDoc (~NDoc@68.80.107.173)
  900. # [17:25] <annevk> JakeA: oh, and default() follows redirects for subresources and updates the resulting url
  901. # [17:25] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  902. # [17:25] * Joins: bholley (~bholley@98.210.101.88)
  903. # [17:25] <annevk> JakeA: e.g. if you do respondWith(fetch("something-that-redirects")) it wasn't clear to me we'd use the response's url as base URL
  904. # [17:25] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  905. # [17:26] * Joins: bholley (~bholley@98.210.101.88)
  906. # [17:26] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 255 seconds)
  907. # [17:26] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  908. # [17:26] * Joins: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com)
  909. # [17:27] * Joins: bholley (~bholley@98.210.101.88)
  910. # [17:27] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  911. # [17:27] * Joins: bholley (~bholley@98.210.101.88)
  912. # [17:27] <JakeA> annevk: I think using the responses url as base url for non-navigations is fine. I wasn't keen on that at first, but it fits in with the fetch spec nicely
  913. # [17:28] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  914. # [17:28] * Joins: bholley (~bholley@98.210.101.88)
  915. # [17:28] <annevk> but not with typical server setups
  916. # [17:28] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  917. # [17:29] * Joins: bholley (~bholley@98.210.101.88)
  918. # [17:29] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  919. # [17:30] * Joins: bholley (~bholley@98.210.101.88)
  920. # [17:30] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  921. # [17:30] * Joins: bholley (~bholley@98.210.101.88)
  922. # [17:31] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  923. # [17:31] * Quits: deane (~Thunderbi@124-197-19-37.callplus.net.nz) (Ping timeout: 240 seconds)
  924. # [17:32] * Joins: bholley (~bholley@98.210.101.88)
  925. # [17:32] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  926. # [17:32] <JakeA> annevk: yeah, the concept of responses with a url property felt really alien to me at first
  927. # [17:33] * Joins: bholley (~bholley@98.210.101.88)
  928. # [17:33] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  929. # [17:33] <JakeA> annevk: But then, in a typical server setup, the base url would be event.request.url, but if I did event.respondWith(fetch(url)) the base would be url & not event.request.url, right?
  930. # [17:33] * Joins: deane (~Thunderbi@124-197-19-37.callplus.net.nz)
  931. # [17:34] <JakeA> unless respondWith overrides the response url, but then how can it tell the difference between event.default() and fetch()
  932. # [17:34] * Joins: bholley (~bholley@98.210.101.88)
  933. # [17:34] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  934. # [17:35] * Quits: NDoc (~NDoc@68.80.107.173) (Quit: leaving)
  935. # [17:35] * Quits: jsbell (jsbell@nat/google/x-jrbkufctaojtophx) (Quit: There's no place like home...)
  936. # [17:36] * Quits: KevinMarks2 (~yaaic@2607:fb90:500:d238:e1a8:433a:b442:3f2e) (Ping timeout: 240 seconds)
  937. # [17:37] <Domenic> response URLs make sense to me, they're the URL after all redirects, right?
  938. # [17:37] * Joins: KevinMarks (~yaaic@2607:fb90:2201:a156:fbd2:98bc:7719:330)
  939. # [17:38] <JakeA> Domenic: yeah, but they don't exist in the traditional client/server model
  940. # [17:39] <Domenic> JakeA: right, but there's a difference between ClientRequest/ClientResponse and ServerRequest/ServerResponse
  941. # [17:39] <Domenic> if writing a web server, you use the latter; if sending requests as a client, you use the former
  942. # [17:39] <Domenic> Node.js actually has 4 different classes for this
  943. # [17:39] * Joins: bholley (~bholley@98.210.101.88)
  944. # [17:39] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  945. # [17:40] <annevk> JakeA: Fetch uses the latest url of Request, as url for Response
  946. # [17:40] <annevk> JakeA: but note that SW sits a layer deeper
  947. # [17:40] <annevk> JakeA: so the latest url of Request is the one that the SW was opened for
  948. # [17:41] <annevk> JakeA: if you use default() however, the url of that Request will be updated further
  949. # [17:41] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
  950. # [17:42] <JakeA> Domenic: right, so here's the question, if I do fetchEvent.respondWith(fetch(url)), assuming the fetch is for some CSS, what's the base-url for the response? a) fetchEvent.request.url b) url c) the final redirect while fetching url
  951. # [17:44] <Domenic> JakeA: I don't feel qualified to give an answer that fits well with the rest of the moving parts involved, but my gut instinct is c).
  952. # [17:45] * Joins: Maurice (copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
  953. # [17:45] <JakeA> Domenic: Gut instinct is fine. I think my original instinct was a), but I'm coming round to c)
  954. # [17:47] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Quit: leaving)
  955. # [17:47] <JakeA> annevk: wouldn't fetch take the response url from response.url, as provided by the serviceworker?
  956. # [17:52] * Quits: ehynds (~ehynds@64.206.121.41)
  957. # [17:52] * Quits: tj_vantoll (~Adium@2601:4:5380:eba:7c7b:d7ac:5969:7195) (Quit: Leaving.)
  958. # [17:53] <gavin> TabAtkins: blame pisg, probably
  959. # [17:53] * Joins: tav (~tav`@37.157.36.218)
  960. # [17:54] <annevk> JakeA: not how it's currently written
  961. # [17:56] * Joins: ehynds (~ehynds@64.206.121.41)
  962. # [17:56] <annevk> JakeA: I feel like I/we should create a series of examples of request / response flows when there's a SW and figure out what all the various parties want to know
  963. # [17:56] <JakeA> annevk: I'll make a ticket to try and summarise this. I'd love to kill event.default() if we can
  964. # [17:57] <annevk> JakeA: I was hoping that would be done as part of providing hooks for Fetch, but I can take a stab at it too I suppose
  965. # [17:57] <annevk> JakeA: killing that does not make much sense to me, I'd prefer we focus on understanding the problem space first
  966. # [17:58] <JakeA> annevk: Ok, I'll provide examples in the ticket and see what we're left with
  967. # [17:59] * htmelvis_zzz is now known as htmelvis
  968. # [18:01] * Joins: bholley (~bholley@98.210.101.88)
  969. # [18:01] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  970. # [18:02] * Quits: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se) (Remote host closed the connection)
  971. # [18:02] * Joins: bholley (~bholley@98.210.101.88)
  972. # [18:02] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  973. # [18:02] * Quits: tav (~tav`@37.157.36.218) (Quit: tav)
  974. # [18:02] * Joins: bholley (~bholley@98.210.101.88)
  975. # [18:03] * Quits: izhak (~izhak@92.248.142.152) (Quit: exit(0);)
  976. # [18:03] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  977. # [18:03] * Joins: bholley (~bholley@98.210.101.88)
  978. # [18:04] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  979. # [18:05] <JakeA> annevk: event.default(), .installing/waiting/active/controller, and serviceWorker.waitUntil are keeping me awake at night
  980. # [18:05] * Joins: bholley (~bholley@98.210.101.88)
  981. # [18:05] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  982. # [18:06] * Joins: bholley (~bholley@98.210.101.88)
  983. # [18:06] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  984. # [18:07] * Joins: bholley (~bholley@98.210.101.88)
  985. # [18:08] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  986. # [18:08] * Joins: bholley (~bholley@98.210.101.88)
  987. # [18:09] <Domenic> JakeA: this reminds me, we need to figure out our story for .loaded vs. .loaded()
  988. # [18:09] <Domenic> I was going to comment in bug, I should probably do that so that there's a record.
  989. # [18:09] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  990. # [18:09] <Domenic> but basically https://github.com/w3ctag/promises-guide/issues/25
  991. # [18:09] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  992. # [18:11] * Joins: bholley (~bholley@98.210.101.88)
  993. # [18:11] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  994. # [18:11] <Hixie> why would loaded() be a method?
  995. # [18:11] <Hixie> shouldn't there be one promise per load attempt?
  996. # [18:12] <Hixie> the FontFace API approach seems sensible
  997. # [18:12] * Joins: bholley (~bholley@98.210.101.88)
  998. # [18:12] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  999. # [18:12] * Quits: richt__ (~richt@83.218.67.123) (Remote host closed the connection)
  1000. # [18:13] * Quits: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com) (Remote host closed the connection)
  1001. # [18:13] <JakeA> There was a conversation around this earlier http://krijnhoetmer.nl/irc-logs/whatwg/20140520#l-395
  1002. # [18:14] <Hixie> yes that's what led to my question
  1003. # [18:14] <JakeA> Doing the same as FontFace is compelling
  1004. # [18:15] * Joins: lmclister (~lmclister@192.150.10.210)
  1005. # [18:15] <Hixie> well they should clearly be consistent, but if a method makes more sense thenwe should do that
  1006. # [18:15] <Hixie> i just don't see why a method would make sense here
  1007. # [18:15] <Hixie> since it's vending the same value each time
  1008. # [18:15] <Hixie> a method implies that work is done
  1009. # [18:15] <Hixie> whereas here no work is done except "return the cached value"
  1010. # [18:15] <JakeA> well, the value can change
  1011. # [18:15] <JakeA> if .src is changed
  1012. # [18:15] <JakeA> but that's easy enough
  1013. # [18:16] <Hixie> right, but that's the .src setter doing work
  1014. # [18:16] <JakeA> yeah
  1015. # [18:16] <Hixie> not loaded()/.loaded
  1016. # [18:16] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  1017. # [18:16] <Hixie> in totally different news, i must admit to something. this no-underline style is actually growing on me. i was clearly wrong about that.
  1018. # [18:17] <JakeA> For the record, I've never found a style-related readability problem with the html spec. Except for that bit where there was a gradient at the top. Those were dark times for the web.
  1019. # [18:17] <Hixie> the backgrounds on examples and notes are prettier too.
  1020. # [18:18] * Joins: bholley (~bholley@98.210.101.88)
  1021. # [18:18] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1022. # [18:18] <Hixie> JakeA: there's actually a gradient there still. :-D
  1023. # [18:18] <Hixie> JakeA: and yeah, me either, but we consistently get feedback about it
  1024. # [18:19] <Hixie> JakeA: i did a survey a few months ago, and it was funny, i got a bunch of feedback "this spec is really pretty" and a bunch of feedback "this spec is really ugly"
  1025. # [18:19] * Joins: ap (~ap@2620:149:4:304:60b2:7b5b:c970:cd45)
  1026. # [18:19] <JakeA> ohh, the gradient is at the bottom now. Hadn't noticed that
  1027. # [18:20] <Hixie> i figured it was more subtle than the line that we had before
  1028. # [18:20] * Joins: bholley (~bholley@98.210.101.88)
  1029. # [18:20] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1030. # [18:20] <Hixie> (the line got harder to do right after i added a max-width on body)
  1031. # [18:20] * Joins: bholley (~bholley@98.210.101.88)
  1032. # [18:20] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1033. # [18:21] * Joins: bholley (~bholley@98.210.101.88)
  1034. # [18:21] * Quits: ehynds (~ehynds@64.206.121.41)
  1035. # [18:21] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1036. # [18:22] * Joins: bholley (~bholley@98.210.101.88)
  1037. # [18:23] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1038. # [18:24] * Joins: roven (~roven@78-20-24-80.access.telenet.be)
  1039. # [18:28] * Joins: bholley (~bholley@98.210.101.88)
  1040. # [18:28] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1041. # [18:28] * Joins: bholley (~bholley@98.210.101.88)
  1042. # [18:29] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1043. # [18:29] * Joins: bholley (~bholley@98.210.101.88)
  1044. # [18:30] * Quits: Ducki (~Ducki@137.116.197.171) (Ping timeout: 265 seconds)
  1045. # [18:30] <TabAtkins> Hixie: FontFace returns a promise from the .load() method, but also exposes a .loaded promise for when you want to listen for the load status without actually triggering a load.
  1046. # [18:30] <Hixie> right
  1047. # [18:30] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1048. # [18:30] <Hixie> same promise right?
  1049. # [18:30] <Hixie> .loaded just returns the last value .load() created?
  1050. # [18:30] * Joins: bholley (~bholley@98.210.101.88)
  1051. # [18:31] <TabAtkins> No, it was easier to just return a fresh promise that is resolved to the .loaded promise.
  1052. # [18:31] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1053. # [18:31] <Hixie> that seems confusing
  1054. # [18:31] <Hixie> why would it be easier?
  1055. # [18:31] * Joins: bholley (~bholley@98.210.101.88)
  1056. # [18:31] <TabAtkins> .loaded is the same promise all the time.
  1057. # [18:31] <TabAtkins> .load() returns fresh promises, I think. Lemme see...
  1058. # [18:31] <Hixie> until the next load, right?
  1059. # [18:31] <TabAtkins> A given font only loads once.
  1060. # [18:31] <Hixie> ah ok
  1061. # [18:31] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1062. # [18:31] * Joins: Somatt_wrk (~somattwrk@130.193.24.135)
  1063. # [18:32] <Hixie> well then why have more than one promise?
  1064. # [18:32] <Hixie> just have The One Promise Of The FontLoad Object
  1065. # [18:32] <TabAtkins> Oh, no, they all return the same promise.
  1066. # [18:32] <TabAtkins> Yes.
  1067. # [18:32] <Hixie> or if you're doing it the JS style, [[The One Promise Of The FontLoad Object]]
  1068. # [18:32] * Joins: bholley (~bholley@98.210.101.88)
  1069. # [18:32] <TabAtkins> Every call to .load() returns the .loaded promise.
  1070. # [18:32] <TabAtkins> That's the [[FontStatusPromise]]
  1071. # [18:32] <Hixie> called it
  1072. # [18:32] <Hixie> :-P
  1073. # [18:32] <TabAtkins> hehe
  1074. # [18:32] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1075. # [18:33] * Joins: bholley (~bholley@98.210.101.88)
  1076. # [18:33] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1077. # [18:33] <Domenic> I dunno, I kind of feel that for things that could change, a method might be better?
  1078. # [18:34] * Joins: bholley (~bholley@98.210.101.88)
  1079. # [18:34] <Domenic> That way, if it's a property, it's the same every time, whereas if it's a method, it's more like "getPromiseForNextTransitionToLoadedState()"
  1080. # [18:34] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1081. # [18:34] <Domenic> except we shorten that to ".loaded()"
  1082. # [18:34] * Joins: bholley (~bholley@98.210.101.88)
  1083. # [18:35] <Domenic> (or, "whenLoaded()" or "waitForLoad()"??)
  1084. # [18:35] <Hixie> when* and wait* are ugly
  1085. # [18:35] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1086. # [18:35] <Domenic> when doesn't seem so bad. but yes.
  1087. # [18:35] <Hixie> but i don't understand what you mean
  1088. # [18:35] <Hixie> attributes can change
  1089. # [18:35] * Joins: bholley (~bholley@98.210.101.88)
  1090. # [18:36] <Hixie> if they couldn't, we'd call them constants :-)
  1091. # [18:36] <Hixie> the thing to avoid with attributes is not that they change when state changes, but that they change every time they are called
  1092. # [18:36] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1093. # [18:36] <Hixie> that is, the getter should be idempotent
  1094. # [18:36] <Domenic> yeah, that's true
  1095. # [18:36] <Hixie> but that's all really
  1096. # [18:36] <Domenic> i think i am just trying to use the method vs. attribute designation to signal something only tangentially-related
  1097. # [18:37] * Quits: darobin (~darobin@78.109.80.74) (Remote host closed the connection)
  1098. # [18:37] <Domenic> i.e. we have to classes of these promises: "generic state transitions" for state machines that could go back and forth, or "intrinsic properties of the object" for whether something has completed its one-time transition from not-loaded to loaded, or similar.
  1099. # [18:38] <Domenic> s/to/two
  1100. # [18:38] * Joins: bholley (~bholley@98.210.101.88)
  1101. # [18:38] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1102. # [18:39] <Domenic> but the methods i am proposing are definitely not actions, so that's a point against methods
  1103. # [18:39] <Domenic> most getter-methods get named with a `get` prefix, and `.getLoaded()` is horrible...
  1104. # [18:40] <Domenic> .nextLoad property maybe??
  1105. # [18:40] <TabAtkins> Domenic: In support of your point, the promise for "are there are pending font loads, or are we cool?" is returned by a method.
  1106. # [18:40] <Domenic> or i can just be ok with the fact that there will be slightly different types of promises returned, both by getters...
  1107. # [18:40] <Hixie> i think we should be consistent between one-shot objects and reusable objects, and for one-shot objects "nextLoad" is confusing
  1108. # [18:41] * Joins: ehsan (~ehsan@66.207.208.102)
  1109. # [18:41] <Hixie> 'loaded' seems fine to me
  1110. # [18:41] <TabAtkins> I return a fresh promise with every call there, though.
  1111. # [18:41] <Domenic> Hixie: I think it is exactly that consistency I am arguing against, actually.
  1112. # [18:41] <JakeA> await document.ready
  1113. # [18:41] <TabAtkins> I made most of these choices without conscious attempts at consistency, though.
  1114. # [18:41] <Hixie> most reusable objects are treated by most authors as one-shot objects
  1115. # [18:41] <Domenic> that is true
  1116. # [18:42] <Hixie> so i don't think optimising e.g. img for people using it for multiple loads is a good idea
  1117. # [18:42] * Joins: bholley (~bholley@98.210.101.88)
  1118. # [18:42] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1119. # [18:42] <Domenic> i kind of liked the idea of force-feeding authors the knowledge that they are reusable, heh.
  1120. # [18:42] <Domenic> but in practice, thinking about the dev experience, i guess it's bad
  1121. # [18:43] <Domenic> you have to keep a table in your head of reusable vs. one-shot objects
  1122. # [18:43] * Joins: bholley (~bholley@98.210.101.88)
  1123. # [18:43] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1124. # [18:43] <Domenic> "use .nextLoad for img, but .loaded for documents..."
  1125. # [18:43] <Domenic> or, probably worst, "use .loaded() for img, but .loaded for documents..."
  1126. # [18:44] <JakeA> "await img.loaded" seems better than "await img.nextLoad"
  1127. # [18:44] <caitp> it doesn't really matter what the API looks like, it's going to both suck and be adequate and even enjoyable simultaneously, depending on who uses it and what problem they're solving
  1128. # [18:44] * Joins: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se)
  1129. # [18:45] <JakeA> I might get a tattoo of that
  1130. # [18:45] <Hixie> Domenic: documents can be reused
  1131. # [18:45] <Domenic> welp
  1132. # [18:45] <Domenic> what *can't* be reused, actually...
  1133. # [18:45] <Hixie> which i think is a solid argument against making a distinction in the api :-)
  1134. # [18:46] * Joins: bholley (~bholley@98.210.101.88)
  1135. # [18:46] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1136. # [18:46] <Hixie> even xhr can be reused
  1137. # [18:46] <Hixie> websocket can't
  1138. # [18:48] * Joins: bholley (~bholley@98.210.101.88)
  1139. # [18:49] <Domenic> JakeA: you have too many internet names
  1140. # [18:50] <JakeA> Domenic: yeahhhhh, I should probably drop the jaffathecake thing
  1141. # [18:50] <caitp> why would you want to do that
  1142. # [18:51] * Quits: bholley (~bholley@98.210.101.88) (Client Quit)
  1143. # [18:51] * Quits: ehsan (~ehsan@66.207.208.102) (Remote host closed the connection)
  1144. # [18:52] <JakeA> consistency?
  1145. # [18:53] <JakeA> it's all the rage these days
  1146. # [18:53] <Hixie> it's been "all the rage" for a long time :-)
  1147. # [18:53] <JakeA> how appropriate!
  1148. # [18:54] <caitp> every nickname is just a different expression of a different facet of a different side of your personality's current mood, as it should be
  1149. # [18:55] * Joins: ehsan (~ehsan@66.207.208.102)
  1150. # [18:57] * Quits: Somatt_wrk (~somattwrk@130.193.24.135) (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com ))
  1151. # [18:58] * Joins: tj_vantoll (~Adium@70-88-93-238-lansing-mi.hfc.comcastbusiness.net)
  1152. # [18:59] * Joins: weinig (~weinig@17.202.50.223)
  1153. # [19:02] * Joins: mven (~textual@169.241.49.196)
  1154. # [19:03] * Joins: annevk_ (~annevk@77-57-114-66.dclient.hispeed.ch)
  1155. # [19:03] * Quits: annevk (~annevk@77-57-114-66.dclient.hispeed.ch) (Read error: Connection reset by peer)
  1156. # [19:03] * Quits: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se) (Remote host closed the connection)
  1157. # [19:07] * Joins: aiglesias (~aiglesias@147-195-17-190.fibertel.com.ar)
  1158. # [19:09] * Quits: weinig (~weinig@17.202.50.223) (Quit: weinig)
  1159. # [19:11] * Joins: weinig (~weinig@17.114.217.5)
  1160. # [19:18] * Quits: satazor (~satazor@239.201.37.188.rev.vodafone.pt) (Remote host closed the connection)
  1161. # [19:19] * Joins: jsbell (jsbell@nat/google/x-pvabvuvmhmtwilyw)
  1162. # [19:20] * Joins: KevinMarks2 (~yaaic@50-0-120-82.dedicated.static.sonic.net)
  1163. # [19:20] * Joins: jernoble (~jernoble@17.202.46.221)
  1164. # [19:20] * Quits: KevinMarks (~yaaic@2607:fb90:2201:a156:fbd2:98bc:7719:330) (Ping timeout: 240 seconds)
  1165. # [19:22] * Joins: satazor (~satazor@239.201.37.188.rev.vodafone.pt)
  1166. # [19:27] * Quits: deane (~Thunderbi@124-197-19-37.callplus.net.nz) (Ping timeout: 240 seconds)
  1167. # [19:29] * Joins: jeremyj (~jeremyj@17.202.44.231)
  1168. # [19:29] * Joins: deane (~Thunderbi@124-197-19-37.callplus.net.nz)
  1169. # [19:29] * Joins: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se)
  1170. # [19:31] <Hixie> Domenic: i don't understand why you keep saying "JavaScript does not make such a distinction"
  1171. # [19:32] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  1172. # [19:33] <Hixie> Domenic: it doesn't make a distinction between functions that return a value and functions that don't return a value either, but i hope you agree that to programmers they are different things nonetheless.
  1173. # [19:33] <Ms2ger> No
  1174. # [19:33] * Ms2ger ducks
  1175. # [19:34] <Hixie> Ms2ger: context is https://github.com/domenic/promises-unwrapping/issues/24#issuecomment-43657022
  1176. # [19:34] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Client Quit)
  1177. # [19:34] * Quits: satazor (~satazor@239.201.37.188.rev.vodafone.pt) (Remote host closed the connection)
  1178. # [19:34] <Domenic> I don't agree with that. All functions return a value; sometimes that value is `undefined`.
  1179. # [19:34] <Ms2ger> See?
  1180. # [19:34] <Hixie> ...
  1181. # [19:35] <Hixie> Domenic: that is entirely my point.
  1182. # [19:35] <Hixie> Domenic: all functions return something in JS. but programmers ignore the return values of functions that return undefined.
  1183. # [19:35] <Hixie> they are different to the programmer.
  1184. # [19:35] <Ms2ger> inb4 "No"
  1185. # [19:35] <Domenic> Sure. But language-level features do not do different things with undefined-returning functions vs. anything-else-returning functions.
  1186. # [19:35] <caitp> where would we be if we weren't putting a reference to an undefined JSValue into EAX after every function call
  1187. # [19:35] * Quits: barnabywalters (~barnabywa@46-239-239-203.tal.is) (Quit: barnabywalters)
  1188. # [19:36] <caitp> it would be chaos
  1189. # [19:36] * Quits: weinig (~weinig@17.114.217.5) (Quit: weinig)
  1190. # [19:36] <Hixie> Domenic: i don't understand the relevance of your statement
  1191. # [19:36] * Quits: mven (~textual@169.241.49.196) (Ping timeout: 240 seconds)
  1192. # [19:37] <Domenic> Hixie: Language-level features like promises are not designed to handle different types of errors in different ways
  1193. # [19:37] <Domenic> Hixie: all errors that an async function can result in go through the promise, just like all errors that a sync function can throw get bubbled as exceptions
  1194. # [19:37] * Joins: cheron (~cheron@unaffiliated/cheron)
  1195. # [19:37] <Domenic> We don't e.g. return some as return values and some as thrown exceptions
  1196. # [19:37] <Hixie> Domenic: well, a, promised shouldn't be a language-level feature imho. but b, yes, that's the bug.
  1197. # [19:37] <Domenic> We just throw them all
  1198. # [19:37] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  1199. # [19:38] <Hixie> Domenic: i understand what you want. i'm saying it's bad.
  1200. # [19:38] <Domenic> So similarly deciding to use throw vs. reject as a channel to interject your preference for dividing up errors into two categories is not really good language design
  1201. # [19:38] <Domenic> ok. well I am saying it's good.
  1202. # [19:38] <Hixie> i pretty fundamentally disagree here.
  1203. # [19:38] <Domenic> I can offer years of experience working with promise APIs, if it helps?
  1204. # [19:39] <Hixie> it does not.
  1205. # [19:39] <Ms2ger> Your brain must be fried by now :)
  1206. # [19:39] <Hixie> Domenic: did some promise APIs send TypeErrors on the promises?
  1207. # [19:39] * Joins: weinig (~weinig@17.114.217.5)
  1208. # [19:39] <Domenic> Hixie: of course, whenever there was a TypeError.
  1209. # [19:40] <Hixie> how did you implement that?
  1210. # [19:40] <Domenic> I don't understand the question
  1211. # [19:41] <Hixie> well your years of using promises in JS had to be built on top of a non-promise-native JS, right?
  1212. # [19:41] <Domenic> sure
  1213. # [19:41] <Hixie> and you had IDL-like APIs that did type checking?
  1214. # [19:41] <Domenic> in some cases, yeah
  1215. # [19:42] <Hixie> so how did you send the type checks to the promises? they'd be caught before the function's code ran.
  1216. # [19:42] <Domenic> wait what?
  1217. # [19:42] <Domenic> i'm in javascript; there are no type checks before the function's code runs
  1218. # [19:42] <Domenic> the functions code is the thing doing the type checks
  1219. # [19:42] <Hixie> maybe that's where the disagreement stems from
  1220. # [19:42] <Hixie> i'm not in JavaScript.
  1221. # [19:42] <Hixie> i'm in WebIDL.
  1222. # [19:43] <Domenic> Which is a macro system for writing JavaScript ;)
  1223. # [19:43] <Hixie> not really, it's usually implemented in C++.
  1224. # [19:43] <Domenic> Yes, but that C++ just invokes JS engine C++ APIs
  1225. # [19:43] <Ms2ger> Or Rust
  1226. # [19:43] <Domenic> And the spec is done in terms of JS semantics
  1227. # [19:43] <Hixie> i'm finding it hard to express just how much i would hate to use an API where a type error would get sent to a promise.
  1228. # [19:43] <Hixie> i hate it enough that it's run-time not compile-time
  1229. # [19:44] * Quits: weinig (~weinig@17.114.217.5) (Ping timeout: 240 seconds)
  1230. # [19:44] <Hixie> but this is like an order of magnitude worse.
  1231. # [19:44] <Domenic> i mean, i can say the same thing about how much i would hate apis that force me to handle errors through two channels
  1232. # [19:44] <Hixie> you don't have to handle the errors i'm talking abuot.
  1233. # [19:44] <Hixie> that's the _entire_ point.
  1234. # [19:44] <Domenic> you do!
  1235. # [19:44] <Domenic> when building robust systems, you *definitely* need to handle errors
  1236. # [19:44] * Joins: weinig (~weinig@17.202.50.223)
  1237. # [19:44] <caitp> why not push for dart then, then you can at least get some level of static typechecking and throw these errors during parsing/compilation rather than at runtime
  1238. # [19:44] <Hixie> (dart's not even remotely enough.)
  1239. # [19:44] <caitp> change the web!
  1240. # [19:45] <caitp> I joke, I joke
  1241. # [19:45] <Hixie> Domenic: if you call a function with bogus data, but the bogus data is not fatal, then you're just going to call more and more functions with that bogus data. it's going to propagate the errors throughout the system.
  1242. # [19:45] <Hixie> Domenic: if you instead throw an exception, the code will crash.
  1243. # [19:45] <Hixie> Domenic: and the damage will be limited.
  1244. # [19:46] <Domenic> rejections are just as fatal to async systems as exceptions are to sync ones
  1245. # [19:46] <Domenic> you literally cannot do any more work until you handle the rejection
  1246. # [19:46] <Hixie> no they're not
  1247. # [19:46] <Hixie> sure you can
  1248. # [19:46] <Hixie> var promise = func();
  1249. # [19:46] <Hixie> moreCode();
  1250. # [19:46] <caitp> presumably if you get a rejection that you care about, you don't recover
  1251. # [19:46] <Domenic> you cannot do any more work that depends on the result of that computation
  1252. # [19:47] <Hixie> sure, but you can do lots more work with the original bad data.
  1253. # [19:47] <caitp> you don't always care about rejections
  1254. # [19:47] <Domenic> caitp: you recover, or don't recover, in the same way you would at sync code: add judicious catches at the boundaries of the system to encapsulate parts that can be wrapped and retried/signaled to the user without breaking the rest of the program.
  1255. # [19:47] <caitp> that's what I'm saying
  1256. # [19:47] <caitp> it's not too different from regular try/catch
  1257. # [19:47] * Quits: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se) (Remote host closed the connection)
  1258. # [19:47] <Domenic> it's exactly the same :)
  1259. # [19:48] <Hixie> you don't have to recover from logic errors at all in sync code. The code is bad. There's by definition no way to recover sanely. The best you can do is catch onerror and send a report to the server, then tell the user that the code is bad.
  1260. # [19:48] <Domenic> that's just not true. you can easily recover from logic errors
  1261. # [19:48] * Joins: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se)
  1262. # [19:48] <Domenic> this keeps webpages running without breaking at the first sign of things going wrong
  1263. # [19:48] <caitp> there are a lot of errors that you can recover from
  1264. # [19:48] <caitp> like JSON.parse() throwing
  1265. # [19:48] <Hixie> JSON.parse() throwing isn't a logic error.
  1266. # [19:48] <caitp> not everything is necessarily fatal
  1267. # [19:48] <Hixie> it's a data error.
  1268. # [19:49] <Hixie> i'm talking about things like null derefs, calling a function with the wrong arguments, etc.
  1269. # [19:49] <Hixie> stuff that should never have gotten checked in in the first place.
  1270. # [19:49] <Domenic> there is no distinction.
  1271. # [19:49] <Domenic> (in JavaScript)
  1272. # [19:49] <Hixie> agreed
  1273. # [19:49] <Hixie> the distinction is a programmer-level distinction.
  1274. # [19:49] <Hixie> even more important.
  1275. # [19:50] <Domenic> the user can click into a rare code path that generates a TypeError, and it's nice to be able to say "oops, we couldn't load the current bid right now!" without crashing the entire app/server.
  1276. # [19:50] <Domenic> you'd give the same error for a NetworkError
  1277. # [19:50] <caitp> much like you can distinguish from a catch block, you can also distinguish from a rejection handler
  1278. # [19:50] <caitp> at the programmer-level
  1279. # [19:50] <Domenic> yeah, in both cases, you might log the NetworkError, but not the TypeError, to the server.
  1280. # [19:50] * Joins: barnabywalters (~barnabywa@89.17.128.127)
  1281. # [19:51] <Domenic> er,,, other way around
  1282. # [19:51] <Hixie> the distinction is at the API level, and it does exist.
  1283. # [19:51] <Hixie> it's the difference between firing onerror and throwing, today.
  1284. # [19:51] * Quits: tj_vantoll (~Adium@70-88-93-238-lansing-mi.hfc.comcastbusiness.net) (Quit: Leaving.)
  1285. # [19:51] <Hixie> all i'm saying is that I want my APIs to maintain that difference.
  1286. # [19:51] * Joins: llkats (~llkats@h-64-236-138-1.aoltw.net)
  1287. # [19:52] <caitp> maybe some day people will be happy with mobile phones statically analyzing scripts for their applications before running, so that they can throw typeerrors that might never be reached
  1288. # [19:52] * Quits: jensnockert (~jensnocke@37-46-188-154.customers.ownit.se) (Ping timeout: 258 seconds)
  1289. # [19:53] <Ms2ger> Hixie, why do you want to set JS back to the stone age?
  1290. # [19:53] * Hixie feeds Ms2ger
  1291. # [19:53] <caitp> > implying it ever left the stone age
  1292. # [19:54] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  1293. # [19:55] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  1294. # [19:57] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Client Quit)
  1295. # [20:02] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  1296. # [20:03] * Joins: mven (~textual@169.241.49.196)
  1297. # [20:03] * Quits: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net) (Quit: tantek)
  1298. # [20:04] * Joins: BigBangUDR (~Thunderbi@101.57.10.135)
  1299. # [20:04] * Quits: BigBangUDR (~Thunderbi@101.57.10.135) (Client Quit)
  1300. # [20:04] * Quits: mven (~textual@169.241.49.196) (Max SendQ exceeded)
  1301. # [20:05] * Joins: mven (~textual@169.241.49.196)
  1302. # [20:05] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
  1303. # [20:06] * Joins: tj_vantoll (~Adium@c-98-250-130-237.hsd1.mi.comcast.net)
  1304. # [20:06] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Client Quit)
  1305. # [20:10] * Quits: KevinMarks2 (~yaaic@50-0-120-82.dedicated.static.sonic.net) (Ping timeout: 240 seconds)
  1306. # [20:11] <jtcranmer> Domenic: ping
  1307. # [20:11] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  1308. # [20:12] * Joins: KevinMarks (~yaaic@2607:fb90:40d:e3e1:4896:1887:aad1:4657)
  1309. # [20:13] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Client Quit)
  1310. # [20:13] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  1311. # [20:14] * Joins: KevinMarks2 (~yaaic@50-0-120-82.dedicated.static.sonic.net)
  1312. # [20:14] * Quits: mven (~textual@169.241.49.196) (Ping timeout: 265 seconds)
  1313. # [20:16] * Quits: weinig (~weinig@17.202.50.223) (Ping timeout: 240 seconds)
  1314. # [20:16] * Joins: weinig_ (~weinig@17.114.217.5)
  1315. # [20:16] * Quits: KevinMarks (~yaaic@2607:fb90:40d:e3e1:4896:1887:aad1:4657) (Ping timeout: 240 seconds)
  1316. # [20:16] * Quits: annevk_ (~annevk@77-57-114-66.dclient.hispeed.ch) (Ping timeout: 258 seconds)
  1317. # [20:16] * Joins: KevinMarks (~KevinMark@50-0-120-82.dedicated.static.sonic.net)
  1318. # [20:18] <smaug____> Hixie: want to interpret what http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#inappropriate-for-the-control means
  1319. # [20:21] <Domenic> jtcranmer: pong
  1320. # [20:21] * Quits: deane (~Thunderbi@124-197-19-37.callplus.net.nz) (Read error: Connection reset by peer)
  1321. # [20:22] * Joins: annevk (~annevk@77-57-127-188.dclient.hispeed.ch)
  1322. # [20:23] <jtcranmer> Domenic: when are you planning on working on the streams spec again?
  1323. # [20:23] * Joins: annevk_ (~annevk@77-57-127-188.dclient.hispeed.ch)
  1324. # [20:24] <Domenic> jtcranmer: as soon as possible; i had a conversation with an implementer the other day that brought up a number of things to get my head back in the game
  1325. # [20:25] <jtcranmer> that's good to hear
  1326. # [20:25] * Quits: annevk_ (~annevk@77-57-127-188.dclient.hispeed.ch) (Read error: Connection reset by peer)
  1327. # [20:25] * Joins: annevk_ (~annevk@77-57-127-188.dclient.hispeed.ch)
  1328. # [20:25] <jtcranmer> I hadn't seen any progress since the CSP... firestorm a month ago
  1329. # [20:25] * Joins: deane (~Thunderbi@124-197-19-37.callplus.net.nz)
  1330. # [20:26] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  1331. # [20:26] <smaug____> Hixie: especially " the first row describing that autofill field in the table below." part
  1332. # [20:26] * Joins: rniwa (~rniwa@17.202.43.222)
  1333. # [20:27] <smaug____> also, is anyone shipping this API
  1334. # [20:27] <smaug____> or could we like... rewrite it
  1335. # [20:27] * Quits: annevk (~annevk@77-57-127-188.dclient.hispeed.ch) (Ping timeout: 276 seconds)
  1336. # [20:28] * Joins: sankha93 (~sankha93@dslb-188-096-088-194.pools.arcor-ip.net)
  1337. # [20:28] * Quits: sankha93 (~sankha93@dslb-188-096-088-194.pools.arcor-ip.net) (Changing host)
  1338. # [20:28] * Joins: sankha93 (~sankha93@fsf/emeritus/sankha93)
  1339. # [20:29] * Joins: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net)
  1340. # [20:29] * Joins: annevk (~annevk@77-57-114-66.dclient.hispeed.ch)
  1341. # [20:30] * Quits: annevk_ (~annevk@77-57-127-188.dclient.hispeed.ch) (Ping timeout: 252 seconds)
  1342. # [20:33] * Quits: annevk (~annevk@77-57-114-66.dclient.hispeed.ch) (Read error: Connection reset by peer)
  1343. # [20:33] * Joins: annevk (~annevk@77-57-114-66.dclient.hispeed.ch)
  1344. # [20:33] * Quits: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net) (Quit: othermaciej)
  1345. # [20:35] * Joins: annevk_ (~annevk@77-57-114-66.dclient.hispeed.ch)
  1346. # [20:36] * Joins: bholley (~bholley@98.210.101.88)
  1347. # [20:37] * Quits: annevk (~annevk@77-57-114-66.dclient.hispeed.ch) (Ping timeout: 240 seconds)
  1348. # [20:41] * Joins: satazor (~satazor@bl17-218-25.dsl.telepac.pt)
  1349. # [20:44] * Quits: TuRnaD0 (~Thunderbi@x1-6-e0-46-9a-1e-fe-ca.cpe.webspeed.dk) (Remote host closed the connection)
  1350. # [20:52] * Joins: richt (~richt@c83-248-137-176.bredband.comhem.se)
  1351. # [20:58] * Quits: KevinMarks (~KevinMark@50-0-120-82.dedicated.static.sonic.net) (Ping timeout: 240 seconds)
  1352. # [21:00] * Quits: KevinMarks2 (~yaaic@50-0-120-82.dedicated.static.sonic.net) (Ping timeout: 240 seconds)
  1353. # [21:02] * Joins: KevinMarks (~yaaic@2607:fb90:40d:e3e1:b170:e1d:7f75:ff78)
  1354. # [21:03] <Hixie> smaug____: here now, what's up?
  1355. # [21:05] <smaug____> trying to interpret what the spec says
  1356. # [21:05] <smaug____> first, should the tokens be in order
  1357. # [21:06] <smaug____> "set of space-separated tokens" hints no ordering
  1358. # [21:06] <smaug____> (since a set isn't normally ordered)
  1359. # [21:06] <Hixie> are you asking for implementations, or authors?
  1360. # [21:06] <smaug____> implementations
  1361. # [21:06] <Hixie> k let me see...
  1362. # [21:06] <smaug____> but then there is "in the order given below"
  1363. # [21:07] <Hixie> you want the next section
  1364. # [21:07] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#processing-model-2
  1365. # [21:07] <smaug____> then in http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#inappropriate-for-the-control I have no idea what it means the there is "name" and under that some other values which are indented a bit
  1366. # [21:08] <smaug____> are those other values somehow special
  1367. # [21:08] <smaug____> the text above talks about "first row", but of what
  1368. # [21:08] * Joins: mven (~textual@169.241.49.196)
  1369. # [21:08] <Hixie> are we switching to talking about author conformance criteria?
  1370. # [21:09] <smaug____> I don't know what in the spec says it isn't implementation thing
  1371. # [21:10] <Hixie> there aren't any requirements that apply to UAs in that first section
  1372. # [21:11] <Hixie> it doesn't say that anywhere, it's just a description of what is in that section
  1373. # [21:11] <Hixie> the only "must"s are things that would apply to authors (and validators)
  1374. # [21:12] <smaug____> "The attribute, if present, must have a value that is a set of space-separated tokens consisting of either a single token that is an ASCII case-insensitive match for the string "off", or a single token that is an ASCII case-insensitive match for the string "on", or the following, in the order given below:"
  1375. # [21:12] <smaug____> why is that not for implementations ?
  1376. # [21:12] <Hixie> it's saying what the value must be
  1377. # [21:12] <Hixie> how could that be an implementation requirement?
  1378. # [21:12] <Hixie> i don't understand what the requirement would be if it was an implementation requirement
  1379. # [21:13] <Hixie> the spec talks a bit about this here: http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-to-read-this-specification
  1380. # [21:13] <Hixie> does that help?
  1381. # [21:13] <Hixie> (second paragraph)
  1382. # [21:13] * Quits: mven (~textual@169.241.49.196) (Ping timeout: 252 seconds)
  1383. # [21:13] <smaug____> ok, I see
  1384. # [21:13] <smaug____> this is just unusually hard to interpret
  1385. # [21:13] <smaug____> also, does anyone implement this stuff yet?
  1386. # [21:14] <smaug____> (since if not, I might r- patches trying to implement it)
  1387. # [21:14] <Hixie> yeah, chrome has shipped this for some time. i tried to get impl feedback on it before they shipped but mozilla was being unusually confusing in its responses and didn't give feedback, and apple and microsoft didn't say anything at all iirc.
  1388. # [21:15] <Hixie> (they waited many months before shipping, and it only got specced a year or so later when mozilla started implementing)
  1389. # [21:15] <Hixie> (actually, the rAc() is what didn't get specced. I guess the attribute was specced earlier.)
  1390. # [21:15] <Hixie> i can try to make it clearer
  1391. # [21:15] <Hixie> not sure what is hard to interpret though
  1392. # [21:17] * Joins: IZh (~IZh@0897578511.static.corbina.ru)
  1393. # [21:17] <smaug____> well, the whole API is odd
  1394. # [21:17] * Joins: victorbjelkholm (~victorbje@41.Red-83-60-204.dynamicIP.rima-tde.net)
  1395. # [21:18] <Hixie> how so?
  1396. # [21:18] <smaug____> trying to do so much using just one attribute
  1397. # [21:19] <Hixie> it's not doing that much, it's just saying what the field represents
  1398. # [21:19] <smaug____> in very different level
  1399. # [21:19] <smaug____> shipping|billing could be one attribute, name etc one
  1400. # [21:20] <smaug____> home|work|etc one
  1401. # [21:20] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
  1402. # [21:20] <Hixie> isn't that just syntactically equivalent?
  1403. # [21:20] <Hixie> i don't understand the difference
  1404. # [21:20] <Hixie> (except that having multiple attributes means more confusion about when things take effect)
  1405. # [21:21] <smaug____> easier to understand what the attribute is about
  1406. # [21:21] <Hixie> seems to me to be exactly equivalent, but ok
  1407. # [21:21] <Hixie> either way, i didn't design this, i just specced what had shipped
  1408. # [21:21] <smaug____> but if this is shipping in chrome, perhaps I'll need to live with this
  1409. # [21:22] <Hixie> so it's about 2 years too late for that kind of feedback :-)
  1410. # [21:22] <Hixie> next time, send feedback when it's requested :-)
  1411. # [21:22] <smaug____> I can't really follow all the spec stuff
  1412. # [21:22] <Hixie> i hear ya
  1413. # [21:22] <smaug____> I end up commenting when someone asks for a review
  1414. # [21:23] <smaug____> Hixie: but ok, thanks
  1415. # [21:23] * Joins: newtron_ (~newtron@199.71.174.204)
  1416. # [21:24] <Hixie> fwiw, https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&resolution=---&target_milestone=Needs%20Impl%20Interest is a list of bugs that represent features that are not yet implemented for which feedback is being requested
  1417. # [21:24] <Hixie> (especially feedback of the form "we want to implement this" or "we think this is dumb and should not exist", but also api design)
  1418. # [21:25] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  1419. # [21:25] <Hixie> so looking at that list every few weeks would be a good way to keep on top of this kind of thing in the future
  1420. # [21:25] * Quits: tobie (sid5692@gateway/web/irccloud.com/x-yhzxcjhagxmyjyun) (Ping timeout: 245 seconds)
  1421. # [21:25] * Quits: bholley (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  1422. # [21:25] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  1423. # [21:25] * Quits: jamesr_ (sid10481@gateway/web/irccloud.com/x-bzmmsicnhegukigf) (Ping timeout: 258 seconds)
  1424. # [21:26] * Quits: krit (sid15081@gateway/web/irccloud.com/x-tfcxmqkxceiukdam) (Read error: Connection reset by peer)
  1425. # [21:26] * Joins: jamesr_ (sid10481@gateway/web/irccloud.com/x-enxypchdphrlsczj)
  1426. # [21:26] * Joins: krit (sid15081@gateway/web/irccloud.com/x-bkigebdudrkybudl)
  1427. # [21:27] * Quits: newtron (~newtron@199.71.174.203) (Ping timeout: 240 seconds)
  1428. # [21:27] * Joins: bholley (~bholley@98.210.101.88)
  1429. # [21:28] * Quits: newtron_ (~newtron@199.71.174.204) (Ping timeout: 240 seconds)
  1430. # [21:28] * Joins: tobie (sid5692@gateway/web/irccloud.com/x-rmlqqgzmdzwgmbkw)
  1431. # [21:29] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
  1432. # [21:29] * smaug____ bookmarks
  1433. # [21:29] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Quit: Reconnecting…)
  1434. # [21:30] * Joins: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi)
  1435. # [21:30] <caitp> if only there were some way to undumb the dumb of old
  1436. # [21:32] <Hixie> you can have a pretty API, or you can have a successful API. your call. :-)
  1437. # [21:33] <caitp> lots of pretty people are successful, no reason pretty APIs can't be
  1438. # [21:35] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  1439. # [21:35] * Joins: othermaciej (~mjs@17.114.217.202)
  1440. # [21:37] * Quits: llkats (~llkats@h-64-236-138-1.aoltw.net) (Remote host closed the connection)
  1441. # [21:39] * Quits: weinig_ (~weinig@17.114.217.5) (Quit: weinig_)
  1442. # [21:41] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
  1443. # [21:43] * Quits: satazor (~satazor@bl17-218-25.dsl.telepac.pt) (Ping timeout: 252 seconds)
  1444. # [21:44] <Hixie> caitp: i think there is a reason, actually
  1445. # [21:45] <Hixie> caitp: the problem is that once an API is deployed, you can't change it. But you can't work out how to make it perfect before it's deployed.
  1446. # [21:45] * Quits: othermaciej (~mjs@17.114.217.202) (Quit: othermaciej)
  1447. # [21:49] * Quits: npcomp (~eldon@c-24-126-240-124.hsd1.ga.comcast.net) (Quit: leaving)
  1448. # [21:49] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
  1449. # [21:49] * Joins: othermaciej (~mjs@17.114.217.202)
  1450. # [21:49] <Philip`> I think caitp is suggesting that you should design seven billion variations of an API, and then let people work out which ones are pretty, and those ones will become successful
  1451. # [21:50] <caitp> or you could break peoples applications periodically, preferably early on
  1452. # [21:50] <caitp> or any number of other ways
  1453. # [21:50] <caitp> peoples lives don't depend on this stuff, and people aren't going to stop using the web just because they have to change a few letters in some application
  1454. # [21:51] <caitp> just my opinion, nobody gotta take it, but nobody's life depends on this stuff never changing
  1455. # [21:51] <Domenic> that's precisely what they'll do
  1456. # [21:51] <Domenic> or worse, they'll stop using your browser
  1457. # [21:51] <caitp> what alternative are they going to turn to?
  1458. # [21:52] * Quits: othermaciej (~mjs@17.114.217.202) (Client Quit)
  1459. # [21:52] <Domenic> iOS/Android
  1460. # [21:52] <Domenic> and/or a browser that didn't break their sites
  1461. # [21:52] <caitp> they might go outside or read a book or get back to working on curing cancer
  1462. # [21:52] <Hixie> breaking people's applications is how you get "pretty and not successful"
  1463. # [21:53] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  1464. # [21:53] <caitp> there are plenty of examples of apis with breaking changes which don't really hurt their use
  1465. # [21:53] <caitp> openGL and openglES for one
  1466. # [21:53] <caitp> for two, rather
  1467. # [21:53] <Hixie> (at least, not successful on the scale of the Web or Windows)
  1468. # [21:53] <caitp> gtk2 vs gtk3
  1469. # [21:53] * Joins: tav (~tav`@host31-52-138-103.range31-52.btcentralplus.com)
  1470. # [21:53] <Hixie> get back to me when gtk has a billion users.
  1471. # [21:54] <caitp> well hopefully it never gets there, if we're lucky it will die off and be replaced by something pretty and successful
  1472. # [21:55] <caitp> breaking changes are valuable. you don't want them every day, but at least a few times a decade
  1473. # [21:55] <Philip`> caitp: Assuming you mean the breaking transition from GL to GLES, that worked because GLES existed on a new platform that no existing GL application could possibly run on anyway, so application developers had to start from scratch and could use whatever API was there
  1474. # [21:56] <caitp> OpenGL2 vs OpenGL3 is massively different, and there have been breaking changes from early gles to more recent gles as well, but it's just an example
  1475. # [21:56] <Hixie> caitp: https://plus.google.com/+IanHickson/posts/SiLdNL9MsFw
  1476. # [21:56] <caitp> I've read it, it's a nice post
  1477. # [21:59] <caitp> but I think people greatly exaggerate the importance of users changing browsers for a while, or of users not browsing the web for a while. It's never going to make any real difference to anybody
  1478. # [21:59] * Quits: barnabywalters (~barnabywa@89.17.128.127) (Quit: barnabywalters)
  1479. # [22:00] <Hixie> let's suppose that you're right. it actually still doesn't matter. what matters is that the people developing browsers think it's true.
  1480. # [22:02] <caitp> imagine if people started using IE again to browse tumblr because of some rendering glitch in a particular theme that affected gecko or blink, due to a breaking change
  1481. # [22:02] <caitp> maybe you'd see less irrational complaints about "IE is awful/slow/etc", and more reality
  1482. # [22:02] <caitp> you'd bring honesty back!
  1483. # [22:02] <caitp> man, that would be great
  1484. # [22:02] * Joins: scor (~scor@drupal.org/user/52142/view)
  1485. # [22:02] * Joins: othermaciej (~mjs@17.114.217.202)
  1486. # [22:04] <Domenic> and people would get fired from mozilla and google (or get very poor performance reviews)
  1487. # [22:04] <Domenic> you have to remember that there are real consequences to effin up the software you ship
  1488. # [22:04] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
  1489. # [22:05] <Hixie> what would happen is that just one browser (the one that implemented the breaking change) would not work
  1490. # [22:05] <Hixie> and users would blame the browser and move to another one
  1491. # [22:05] <Hixie> some very small number of users if it was just one breaking change
  1492. # [22:05] <Hixie> and the other browser vendors would see this and say "well we're not doing _that_"
  1493. # [22:06] <Hixie> just look at the level of difficulty that browsers are facing trying to drop showModalDialog()
  1494. # [22:06] <Hixie> an API that every browser vendor desperately wants to drop
  1495. # [22:06] <Hixie> an API that has virtually no use on the Web itself
  1496. # [22:06] <Hixie> an API that causes security problems
  1497. # [22:06] <Hixie> an API that massively complicates the specs and implementations
  1498. # [22:07] <Hixie> an API that was originally non-standard
  1499. # [22:07] <caitp> I know it's hard, Hixie
  1500. # [22:08] * Joins: mven (~textual@169.241.49.196)
  1501. # [22:08] <caitp> but it's hard because of an attitude problem, and that is a bug worth fixing
  1502. # [22:09] * Joins: llkats (~llkats@h-64-236-138-1.aoltw.net)
  1503. # [22:09] <Hixie> i have no idea whatsoever how to fix humans. good luck. in the meantime...
  1504. # [22:09] <zewt> if you're working for a browser vendor trying to get politics and practicalities changed, great; if you're not, that's a lovely statement but not an actionable one
  1505. # [22:10] <Hixie> (this is the same argument i have against RDF&co. Embedding structured data in the web page is essentially a human problem, and it's harder to fix that problem than it is for us to develop NLP.)
  1506. # [22:10] <Hixie> (not that NLP is easy at all. It's just that social problems are even harder.)
  1507. # [22:10] <Domenic> an attitude problem O_O
  1508. # [22:11] <caitp> I think it can be done
  1509. # [22:11] <zewt> Domenic: that's what business realities look like, when it's not your job :P
  1510. # [22:11] <caitp> for most of the browser vendors out there, browser use isn't their main business
  1511. # [22:12] <caitp> well, okay, maybe not most
  1512. # [22:12] <caitp> lets say 2 out of 5
  1513. # [22:12] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  1514. # [22:12] <caitp> maybe you could even throw apple in there too, since they push objc
  1515. # [22:12] <Domenic> Yes, and for Goldman Sachs, structured investments isn't their main business. Doesn't mean the structured investments group wants to give all their business to Citigroup.
  1516. # [22:12] <caitp> that's comparing an apple to an orchard, don't you think?
  1517. # [22:12] * Quits: mven (~textual@169.241.49.196) (Ping timeout: 255 seconds)
  1518. # [22:13] <Domenic> not at all
  1519. # [22:13] <caitp> there's a lot more money in one arena than the other
  1520. # [22:13] <Domenic> business units and companies and responsibility and performance reviews work the same way in both environments
  1521. # [22:13] <caitp> thus the attitude problem
  1522. # [22:13] <Domenic> if you say so...
  1523. # [22:14] <caitp> when something doesn't have a real impact, either financially or culturally, it must not be held to such a high standard
  1524. # [22:14] <Hixie> as you said before, it's an attitude problem. Specifically, the attitude of the engineers on the browser teams, and the people who evaluate their performance.
  1525. # [22:14] <Hixie> for those people, browser use is their main business.
  1526. # [22:15] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  1527. # [22:16] <Hixie> btw, even if all the browser vendors were to agree to break things together, even that wouldn't solve your problem. You'd just make the Web platform less attractive and cause Web developers to consider becoming developers for other platforms.
  1528. # [22:16] <caitp> and that would be just fine
  1529. # [22:16] <caitp> it really doesn't matter in the grand scheme of things :)
  1530. # [22:16] <caitp> it really doesn't
  1531. # [22:17] <caitp> but, I know I don't have to convince you of that
  1532. # [22:17] <Hixie> well, it greatly matters to me that the open multi-vendor platforms be more successful than the proprietary ones.
  1533. # [22:18] <Hixie> Also, do you really want to be breaking these web apps? Consider if one of them is the ticketing app for an airline. Suddenly over the course of a week all the browsers stop working on that site. Can you imagine the chaos that that company would face? Now multiply that across the whole of our economy.
  1534. # [22:18] * Joins: KevinMarks_ (~KevinMark@50-0-120-82.dedicated.static.sonic.net)
  1535. # [22:19] <IZh> It's hot here today. ;-)
  1536. # [22:19] <caitp> fortunately, it's possible to have relationships with businesses who use your product, and inform them of coming breaking changes
  1537. # [22:19] <Hixie> in practice, those relationships don't exist.
  1538. # [22:19] <Hixie> i mean, i would love to live in the world you describe, don't get me wrong.
  1539. # [22:19] <caitp> sure they do, I have participated in them
  1540. # [22:19] <Hixie> but it's not the world i live in.
  1541. # [22:19] <caitp> you can have more of them
  1542. # [22:20] <caitp> you can encourage effective communication
  1543. # [22:20] <caitp> there is no shortage of ways to make things suck less than they do, and just no real effort to take on those endeavors
  1544. # [22:21] <Hixie> well that's just offensive.
  1545. # [22:21] <caitp> but I don't want to have a fight about this
  1546. # [22:21] <Hixie> you basically just said that the last 15 years of my life have been "no real effort"
  1547. # [22:21] <caitp> oh come now Hixie, I'm not saying that
  1548. # [22:21] <Hixie> you really did.
  1549. # [22:21] <caitp> maybe "no real effort" was the wrong choice of words
  1550. # [22:22] <Hixie> (not just my life, either.)
  1551. # [22:22] <IZh> Evolution vs revolution.
  1552. # [22:24] <caitp> various organizations are certainly making an effort to open the process and get more input from different interested parties, so yes, that effort is being made
  1553. # [22:24] <Hixie> we've also spent years trying to improve the web concretely, by providing better APIs, defining the platform better to improve interop, etc.
  1554. # [22:24] <Hixie> not to mention all the work on test suites
  1555. # [22:25] <Hixie> and all the work on developer advocacy
  1556. # [22:25] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  1557. # [22:25] <Hixie> and all the work on campaigning to browser vendors that they better support standards
  1558. # [22:25] <Hixie> and all the work trying to convince each other that particular design patterns are better than others
  1559. # [22:26] <caitp> and that's all awesome, no doubt
  1560. # [22:26] <Hixie> what have _you_ done to improve the web?
  1561. # [22:27] <caitp> I've worked on improving compliance with various proposed standards, improving application frameworks, and am not quiet at all about my opinions on the problems with it and how they can be addressed
  1562. # [22:27] <Domenic> it's interesting that you flipped the offensive bit at "no real effort"; I flipped it at "attitude problem"
  1563. # [22:27] <caitp> and have even campaigned to some degree to address some of those problems
  1564. # [22:28] <Hixie> urls?
  1565. # [22:28] <caitp> but I'm just one person, and I am very snarky, not necessarily diplomatic
  1566. # [22:28] <caitp> so campaigning is not my strongpoint
  1567. # [22:28] <IZh> 8
  1568. # [22:28] <IZh> Oops
  1569. # [22:31] * Quits: Ms2ger (~Ms2ger@134.199-242-81.adsl-dyn.isp.belgacom.be) (Quit: nn)
  1570. # [22:36] <caitp> sorry Hixie I didn't mean to come across as saying that there have been __no__ efforts to improve things, but I don't think there has been much of a real effort to give people a reality check about the importance of number-of-downloads/users/etc
  1571. # [22:37] <caitp> so I apologize for that =)
  1572. # [22:38] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
  1573. # [22:39] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Client Quit)
  1574. # [22:40] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
  1575. # [22:41] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Client Quit)
  1576. # [22:41] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
  1577. # [22:41] * Quits: ahf (ahf@irssi/staff/ahf) (Ping timeout: 240 seconds)
  1578. # [22:42] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
  1579. # [22:43] * Quits: othermaciej (~mjs@17.114.217.202) (Quit: othermaciej)
  1580. # [22:44] <Hixie> caitp: i think if you tried to tell a browser vendor that users were less important, they'd respond with a precise dollar figure per user and ask you how many dollars you think they should give up in order to make some API slightly prettier
  1581. # [22:45] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Client Quit)
  1582. # [22:45] <caitp> sure, and then you say "whatever it takes", because the reality is that the revenue models for most of these vendors don't really come from people using their particular browser all the time
  1583. # [22:45] <Hixie> i also think the reaction would probably depend on whether they were currently increasing in market share or losing it. It's worth noting that Chrome is more willing to break APIs these days than other browsers; I don't think their relative market numbers are unrelated to this.
  1584. # [22:46] <Hixie> uh
  1585. # [22:46] <Domenic> what i am hearing is that caitp hates capitalism ;)
  1586. # [22:46] <Hixie> the revenue model of all browsers is pretty much entirely based on how much they use their browsers.
  1587. # [22:46] <Hixie> caitp: what do you think the revenue model of browsers is?
  1588. # [22:46] <caitp> you've got a number of revenue models
  1589. # [22:46] <Hixie> you do?
  1590. # [22:47] <Domenic> hmm, i was pretty sure the argument from a few minutes ago was that revenue wasn't important, and people should go outside and read books or something.
  1591. # [22:47] <caitp> in Mozilla's case, you have donations to the foundation, ad revenue for the corporation. In the case of Google, you have piles of ad revenue. in the case of Mozilla, you have cloud services, OEM licensing, and other models
  1592. # [22:47] <caitp> in the case of Apple, you have iPhone sales, etc etc
  1593. # [22:48] <caitp> it's not that revenue isn't important, it's that the impact on revenue breaking changes would have is exaggerated
  1594. # [22:48] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
  1595. # [22:48] <Hixie> um... you might want to look at mozilla's financials more closely.
  1596. # [22:48] <Domenic> JakeA: curious what https://twitter.com/trygve_lie/status/468839273010323456 is about?
  1597. # [22:49] <Hixie> and in the case of iPhone, sales of the device are going to drop if people find that browsers on their device don't work (there's only one rendering engine for all browsers on iPhones)
  1598. # [22:49] <caitp> and that's only significant if it breaks a huge amount of the web
  1599. # [22:50] <caitp> you can break a lot with minimal impact
  1600. # [22:50] <Hixie> what is a huge amount? a million pages?
  1601. # [22:50] <Hixie> a hundred thousand?
  1602. # [22:50] <caitp> lets put it this way, hamstersmut.com rendering a paragraph wrong is probably not going to severely impact sales
  1603. # [22:51] <Hixie> so 2 million?
  1604. # [22:51] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Client Quit)
  1605. # [22:51] <caitp> a number of pages that have real audiences
  1606. # [22:51] <Hixie> the tail on the web is very long
  1607. # [22:51] <caitp> and the number of those pages breaking could be mitigated by discussing with them
  1608. # [22:51] <Hixie> veeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeery long
  1609. # [22:52] <JakeA> Domenic: https://twitter.com/leftieFriele/status/468836645362757633, although I was genuinely unaware of the meaning of "webbles", I just found " web rebels " difficult to say
  1610. # [22:52] <Hixie> google knows of ~100 trillion pages
  1611. # [22:52] <Hixie> how do you plan to contact them? phone calls?
  1612. # [22:52] <caitp> mass email to DNS providers >:D
  1613. # [22:53] <Domenic> JakeA: haha wow
  1614. # [22:53] <Hixie> yeah, because spamming the world is definitely going to improve sales
  1615. # [22:53] * Joins: jeremyj (~jeremyj@17.202.44.231)
  1616. # [22:53] <caitp> for applications with real audiences, which have a real impact on sales, you could even go with face to face conversation to discuss breaking changes
  1617. # [22:53] <caitp> does it scale? no, but it doesn't have to
  1618. # [22:54] * Joins: othermaciej (~mjs@17.114.217.202)
  1619. # [22:55] <Hixie> 100 trillion pages.
  1620. # [22:55] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  1621. # [22:55] <Hixie> 0.001% of them is a billion pages.
  1622. # [22:56] <Hixie> i think it might have to scale.
  1623. # [22:56] <caitp> pages is not necessarily "domains"
  1624. # [22:56] <Hixie> there's more than a quarter of a billion domains
  1625. # [22:56] <caitp> and a given organization may have many domains
  1626. # [22:57] <Domenic> 100 trillion, really? that's awesome.
  1627. # [22:57] <Hixie> 0.001% is 2500 domains that have to be contacted
  1628. # [22:57] <caitp> which is totally doable
  1629. # [22:57] <caitp> and then you could even bundle them by industry
  1630. # [22:57] <caitp> government, utilities/transportation, entertainment, etc
  1631. # [22:57] <Hixie> at five hours per domain, that's a year and a half non-stop per breaking change
  1632. # [22:57] <Hixie> are you paying for that?
  1633. # [22:58] <Hixie> also, have you seen the response you get from developers when you tell them there's going to be a breaking change? look in blink-dev at the reaction around showModalDialog().
  1634. # [22:58] <caitp> out of my own pocket? hey, I'm a genius, not an oil executive
  1635. # [22:58] <Hixie> so who's going to be paying for it?
  1636. # [22:59] <caitp> who indeed
  1637. # [23:00] <Hixie> hello browser vendor executive, please make a choice: we could do nothing, and it would cost nothing, or we could make this breaking change, and it would cost us x% of users or a year and a half of intensive conversations with developers who will be angry at us for breaking their site.
  1638. # [23:00] <caitp> hey, what is money if it doesn't flow down the river
  1639. # [23:01] <wilhelm> Hey, opportunity cost. (c:
  1640. # [23:02] <Hixie> that's true, i forgot about hte opportunity cost. All the effort spent making that breaking change could instead have been spent making the browser a bit faster or more stable or whatever.
  1641. # [23:02] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  1642. # [23:02] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  1643. # [23:02] <caitp> if you remove brokenness, you might see a performance and stability improvement, too :D
  1644. # [23:03] <Hixie> do you have an example of how that could happen?
  1645. # [23:03] <Hixie> generally, changing APIs just introduces bugs, it doesn't remove them
  1646. # [23:03] * Quits: TabAtkins (sid11559@gateway/web/irccloud.com/x-gevdqifacmmsaftp) (Ping timeout: 265 seconds)
  1647. # [23:03] <caitp> sure, suppose we removed 12 million lines of code, which no longer has to be linked into a binary
  1648. # [23:03] <Domenic> Hixie: where in the spec would I go to find out what DOM should result from the strings "" vs. " "
  1649. # [23:03] * Quits: jkomoros__ (uid7860@gateway/web/irccloud.com/x-lqntiyfvhnovplek) (Ping timeout: 240 seconds)
  1650. # [23:04] <caitp> no longer ends up getting called and no longer takes up cache lines
  1651. # [23:04] * Quits: cwilso (sid10206@gateway/web/irccloud.com/x-oxaiubbbpkkfhidy) (Ping timeout: 240 seconds)
  1652. # [23:04] * Quits: bterlson (sid23757@gateway/web/irccloud.com/x-ahjrnjuprxkhvphy) (Ping timeout: 252 seconds)
  1653. # [23:04] <caitp> beautiful
  1654. # [23:04] <Domenic> Hixie: as in, I saved an empty .html file and opened it in my browser, vs. a one-byte one containing a space.
  1655. # [23:04] <Hixie> Domenic: you mean in parsing?
  1656. # [23:04] <Domenic> Hixie: yeah I'd imagine so.
  1657. # [23:04] <Hixie> Domenic: http://www.whatwg.org/specs/web-apps/current-work/#parsing
  1658. # [23:04] <Domenic> Noooo trolled by the single-page spec again :P
  1659. # [23:05] <Hixie> caitp: you were talking about changing APIs, not removing APIs
  1660. # [23:05] <caitp> it's an example hixie, you could definitely do a lot of both
  1661. # [23:05] * Joins: bterlson (sid23757@gateway/web/irccloud.com/x-lbrwhrjhsaxnmdda)
  1662. # [23:05] <Domenic> if i were a browser engine implementer i would spend all my time improving browser speed when viewing the html standard, just as a matter of improving my own productivity :P
  1663. # [23:05] <Hixie> caitp: you say "definitely", but i don't see on what you're basing this
  1664. # [23:05] * Joins: cwilso (sid10206@gateway/web/irccloud.com/x-vbeddiyoakrnscik)
  1665. # [23:05] * Joins: TabAtkins (sid11559@gateway/web/irccloud.com/x-wwpveoohsvklapjf)
  1666. # [23:06] <Domenic> Hixie: I really like the new "Note", "Example", etc.
  1667. # [23:06] <caitp> I base things on hypothetical scenarios
  1668. # [23:06] <Hixie> Domenic: chrome is pretty fast at loading it. I don't really understand why the other browsers aren't improving to match it.
  1669. # [23:06] * Quits: Rubennn (~Rubennn@apher.gewooniets.nl) (Ping timeout: 245 seconds)
  1670. # [23:06] <caitp> it's the best source of evidence
  1671. # [23:06] <Domenic> (stunned silence)
  1672. # [23:06] <caitp> such empirical, much scientific, wow
  1673. # [23:07] <Hixie> i'll take that as a concession speech...
  1674. # [23:07] <caitp> hardly
  1675. # [23:07] * Quits: tj_vantoll (~Adium@c-98-250-130-237.hsd1.mi.comcast.net) (Quit: Leaving.)
  1676. # [23:07] * Joins: Rubennn (~Rubennn@apher.gewooniets.nl)
  1677. # [23:07] <caitp> just a little good humour
  1678. # [23:07] * Joins: jkomoros__ (uid7860@gateway/web/irccloud.com/x-grdfzhelwdquglqe)
  1679. # [23:07] * Quits: llkats (~llkats@h-64-236-138-1.aoltw.net)
  1680. # [23:07] * Joins: mven (~textual@169.241.49.196)
  1681. # [23:08] <Hixie> caitp: so what are you basing it on then?
  1682. # [23:08] <caitp> let me scroll up to see what I said "definitely" baout
  1683. # [23:08] <caitp> about*
  1684. # [23:08] <Domenic> Hixie: well it turns out today is not the day I'm going to spend understanding the HTML parsing algorithm :P. Do you happen to know off the top of your head what behavior should be for "" vs " "? I can always test browsers I suppose.
  1685. # [23:08] <caitp> oh, definitely remove and change apis
  1686. # [23:09] <caitp> sure, there's a lot of complete crap that you could remove, like most of the parsing algorithm
  1687. # [23:09] <caitp> (just for example)
  1688. # [23:09] <caitp> most of the DOM api
  1689. # [23:09] <caitp> most of CSS
  1690. # [23:09] <Hixie> Domenic: i can look...
  1691. # [23:10] <caitp> although removing a lot of that wouldn't make anyone very happy, it would be a marked improvement
  1692. # [23:10] * Joins: llkats (~llkats@h-64-236-138-1.aoltw.net)
  1693. # [23:10] * Quits: IZh (~IZh@0897578511.static.corbina.ru) (Remote host closed the connection)
  1694. # [23:10] <Hixie> Domenic: looks like no difference. a space at the very start gets dropped on the floor.
  1695. # [23:11] * Quits: Maurice (copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
  1696. # [23:11] <Hixie> caitp: ok so removing "most of the parsing algorithm" would in fact affect trillions of pages on hundreds of millions of domains.
  1697. # [23:11] * Quits: abarth (sid5294@gateway/web/irccloud.com/x-drqxasbbrukseuos) (Ping timeout: 265 seconds)
  1698. # [23:11] <caitp> yeah, but think of how much code smell you could get rid of 8)
  1699. # [23:11] * Quits: JakeA (uid3836@gateway/web/irccloud.com/x-mqazovfmjccinyhw) (Ping timeout: 252 seconds)
  1700. # [23:11] <Hixie> caitp: so that's a non-starter even if i concede everything you said earlier about how easy it is to make breaking changes
  1701. # [23:12] * Quits: parshap_ (sid18846@gateway/web/irccloud.com/x-rntuzhtkxhptvobc) (Ping timeout: 265 seconds)
  1702. # [23:12] <Hixie> caitp: i'm going to assume that "msot of the DOM api" and "most of CSS" are just more "little good humour"
  1703. # [23:12] <Domenic> Hixie: appreciated, thanks.
  1704. # [23:12] * Joins: abarth (sid5294@gateway/web/irccloud.com/x-yvzwzwcxorkbvlwt)
  1705. # [23:13] * Joins: JakeA (uid3836@gateway/web/irccloud.com/x-amwuauijhiovzsxc)
  1706. # [23:13] <caitp> nah, if you could do it all over again, you could learn from past mistakes and improve it, and minimize special casing and bizarre behaviour
  1707. # [23:13] <caitp> it would be beautiful
  1708. # [23:14] * Joins: parshap_ (sid18846@gateway/web/irccloud.com/x-bndjlyrzgtthwqud)
  1709. # [23:14] <caitp> but obviously that's a wild leap beyond removal of simple things
  1710. # [23:14] * Quits: mven (~textual@169.241.49.196) (Ping timeout: 276 seconds)
  1711. # [23:14] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  1712. # [23:14] <caitp> but oh man, it would be glorious
  1713. # [23:14] <Hixie> it would be glorious for about a month
  1714. # [23:15] <Hixie> until the next new feature developed by someone who didn't have anything to do with the initial glorious design was added
  1715. # [23:15] <Hixie> or until the next browser shipped with a minor bug that the web then started depending on
  1716. # [23:15] <Hixie> and within a year we'd be back where we started
  1717. # [23:15] <caitp> yeah but in another 2 decades you could do it all over again
  1718. # [23:15] <caitp> totally worth it
  1719. # [23:16] <Hixie> (or, more likely, it wouldn't take off in the first place, since it would have to compete with the existing web, and 100 trillion existing documents in ugly code would trump the 0 documents of beautiful code in users' eyes, since they don't see the code)
  1720. # [23:16] <wilhelm> caitp: Aw, you're 12 years late. Here you go: http://www.w3.org/TR/xhtml2/
  1721. # [23:16] <caitp> I have good friends on that WG
  1722. # [23:16] <caitp> well, the xmlwg
  1723. # [23:16] <Domenic> hehehehe
  1724. # [23:17] <Domenic> wilhelm++
  1725. # [23:17] <Hixie> well that explains a lot
  1726. # [23:17] <wilhelm> :D
  1727. # [23:17] * Quits: llkats (~llkats@h-64-236-138-1.aoltw.net)
  1728. # [23:18] <caitp> good people is good people, and sometimes they have sensible ideas
  1729. # [23:18] <jgraham> caitp: So the real-world example with the closest properties to what you describe was Opera+Presto. It didn't intentionally break APIs, but due to low marketshare sites didn't go out of their way to support it. As a result Opera did a huge amount of outreach to sites, and a huge amount of work on implementation quality. But often sites wouldn't apply fixes even if you literally sent them a patch file to apply to their code. Not small site either; hug
  1730. # [23:19] <wilhelm> jgraham: /load splitlong.pl
  1731. # [23:19] <jgraham> wilhelm: Oh, I thought I already had
  1732. # [23:19] <jgraham> caitp: So the real-world example with the closest properties to what you describe was Opera+Presto. It didn't intentionally break APIs, but due to low marketshare sites didn't go out of their way to support it. As a result Opera did a huge amount of outreach to sites, and a huge amount of work on implementation quality. But often sites wouldn't apply fixes even if you literally sent them a patch file to apply to their code. Not small site either; hug
  1733. # [23:19] <jgraham> ... got hundreds of thousands of Opera users.
  1734. # [23:19] <caitp> yeah but if all of our mighty browser vendor overlords joined in for the breaking changes, people wouldn't really have a choice. but I do know that it's not something that's going to happen any time soon, it's a pipedream
  1735. # [23:20] <jgraham> Yes, but getting everyone to act like that isn't a Nash equilibrium
  1736. # [23:22] <Hixie> jgraham: your text cut off at "Not small site either; hug" then contined with "... got hundreds"
  1737. # [23:22] <Hixie> continued
  1738. # [23:23] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 264 seconds)
  1739. # [23:24] <Hixie> caitp: i don't think anyone is arguing that "people" aren't "good people". Just that said "people", apparently including you, have an unrealistic idea of what is achievable when it involves changing how people think or act.
  1740. # [23:24] * Joins: Lachy (~Lachy@cm-84.215.104.248.getinternet.no)
  1741. # [23:24] <caitp> or you know what might happen instead, maybe the WWW will simply stop existing as nationstates put up huge national firewalls, and architect strong protections against those firewalls being undermined, and that greatly reduces the pool of applications that would be affected
  1742. # [23:25] <caitp> it's not that I have an unrealistic sense of what is achievable
  1743. # [23:25] <Hixie> that is debatable.
  1744. # [23:25] <caitp> it's that I have a lot of confidence
  1745. # [23:25] <jgraham> "huge ones that probably"
  1746. # [23:25] <Hixie> ok, you have an unrealistic level of confidence in what is achievable.
  1747. # [23:25] <Hixie> imho
  1748. # [23:25] <wilhelm> Not unrealistic. Positively harmful. What a waste of good engineers. (c:
  1749. # [23:26] <caitp> hey, at least I'm not trying to start the next snapchat
  1750. # [23:27] <Hixie> as jgraham says, getting all the browser vendors to work in this way is not a nash equilibrium. In practice, humans do act to find a nash equilibrium.
  1751. # [23:28] * Joins: `nik` (~nik@li490-134.members.linode.com)
  1752. # [23:28] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
  1753. # [23:30] * Quits: KevinMarks_ (~KevinMark@50-0-120-82.dedicated.static.sonic.net) (Ping timeout: 265 seconds)
  1754. # [23:32] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Client Quit)
  1755. # [23:36] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  1756. # [23:36] * Quits: cheron (~cheron@unaffiliated/cheron) (Ping timeout: 240 seconds)
  1757. # [23:37] * Joins: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net)
  1758. # [23:38] * Quits: richt (~richt@c83-248-137-176.bredband.comhem.se) (Remote host closed the connection)
  1759. # [23:38] * Joins: a-ja (~Instantbi@70.230.147.189)
  1760. # [23:38] * Joins: richt (~richt@c83-248-137-176.bredband.comhem.se)
  1761. # [23:39] * Quits: KevinMarks (~yaaic@2607:fb90:40d:e3e1:b170:e1d:7f75:ff78) (Ping timeout: 240 seconds)
  1762. # [23:42] * Quits: richt (~richt@c83-248-137-176.bredband.comhem.se) (Ping timeout: 240 seconds)
  1763. # [23:45] * Joins: sankha_ (~sankha93@dslb-084-057-207-063.pools.arcor-ip.net)
  1764. # [23:45] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  1765. # [23:46] * Quits: NDoc (~NDoc@c-68-80-107-173.hsd1.pa.comcast.net) (Quit: leaving)
  1766. # [23:46] * Joins: KevinMarks (~yaaic@2607:fb90:212a:1795:dc53:91fa:58e0:4449)
  1767. # [23:46] <Hixie> Domenic: how does the promise pattern fit into models where we use onreadystatechange today, where the object can be in multiple states and transitions through them one by one?
  1768. # [23:47] * Quits: sankha93 (~sankha93@fsf/emeritus/sankha93) (Ping timeout: 252 seconds)
  1769. # [23:48] <Domenic> Hixie: three answers to that...
  1770. # [23:48] <Domenic> 1) it doesn't; promises are for simple one and done async ops
  1771. # [23:48] <Domenic> 2) it might be useful for users to have a promise for the 80% case, e.g. completely-loaded
  1772. # [23:49] * Joins: satazor (~satazor@80.78.37.188.rev.vodafone.pt)
  1773. # [23:49] * Joins: sankha__ (~sankha93@dslb-084-057-203-058.pools.arcor-ip.net)
  1774. # [23:49] <Domenic> 3) in certain cases it can be natural to model individual state transitions as promises. E.g. you could have both ".headersReceived" and ".loaded" promises. (I don't remember the other ready states besides loaded... picked headersReceived because it seemed plausible.)
  1775. # [23:49] <Domenic> 3) is pretty rare though
  1776. # [23:50] <Domenic> you could consider document.ready vs. document.loaded as an instance of 3), I guess.
  1777. # [23:51] * Quits: sankha_ (~sankha93@dslb-084-057-207-063.pools.arcor-ip.net) (Ping timeout: 264 seconds)
  1778. # [23:51] * Joins: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon)
  1779. # [23:55] <Hixie> Domenic: i'm looking at script and resource loading, and there's all kinds of edge cases, different states, etc.
  1780. # [23:55] * Joins: sankha_ (~sankha93@dslb-188-104-195-160.pools.arcor-ip.net)
  1781. # [23:55] <Hixie> Domenic: e.g. you want to know when some things are downloaded but not yet executed, so you can execute something when everything is ready
  1782. # [23:55] <Hixie> Domenic: or you want to know when everything has executed, so you can use the api
  1783. # [23:55] <Hixie> Domenic: or you want to know when things have started downloading, to show progress UI
  1784. # [23:56] <Domenic> some of the questions to ask are: is it useful for a "late" subscriber to know that these things occurred?
  1785. # [23:56] <Domenic> e.g. if the script has already executed, do you usually want to run the same code in response to that, as you would run if you had queued up a handler before the execution happened?
  1786. # [23:57] <Domenic> with events, if you miss your chance for registration, then you have to switch programming patterns
  1787. # [23:57] <Domenic> if (alreadyExecuted) { doStuff1(); } else { addEventListener("executed", doStuff2); }
  1788. # [23:57] <Domenic> if doStuff1 and doStuff2 are always the same code, then promises are better
  1789. # [23:57] <Domenic> if they are always different, events are better
  1790. # [23:58] <Domenic> (a common case being doStuff1 is a noop, whereas doStuff2 takes action)
  1791. # [23:58] * Quits: sankha__ (~sankha93@dslb-084-057-203-058.pools.arcor-ip.net) (Ping timeout: 252 seconds)
  1792. # [23:59] <Domenic> progress is pretty explicitly out of scope for promises
  1793. # [23:59] <Domenic> events work well for that
  1794. # [23:59] <Domenic> although the use case of knowing when progress *starts* is an interesting one... my gut says it's not a common use case?
  1795. # [23:59] <Domenic> i could potentially see .executed and .loaded as two separate state-transition-signalling promises
  1796. # [23:59] <Domenic> but i am not sure it is worth the use case
  1797. # Session Close: Wed May 21 00:00:00 2014

The end :)