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

Options:

  1. # Session Start: Wed May 28 00:00:01 2014
  2. # Session Ident: #whatwg
  3. # [00:00] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
  4. # [00:00] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
  5. # [00:02] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: :tiuQ tiuq sah woclrak)
  6. # [00:03] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
  7. # [00:09] * Quits: danjesus (~danjesus@187.37.68.156) (Remote host closed the connection)
  8. # [00:09] * Joins: jeremyj (~jeremyj@17.202.44.231)
  9. # [00:11] * Quits: weinig (~weinig@17.114.5.151) (Quit: weinig)
  10. # [00:11] * Quits: barnabywalters (~barnabywa@fire-out.ru.is) (Quit: barnabywalters)
  11. # [00:12] * Quits: ehynds (~ehynds@146-115-145-170.c3-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com)
  12. # [00:12] * Joins: weinig (~weinig@17.114.5.151)
  13. # [00:12] * Joins: danjesus (~danjesus@187.37.68.156)
  14. # [00:12] * Joins: barnabywalters (~barnabywa@fire-out.ru.is)
  15. # [00:15] * Quits: barnabywalters (~barnabywa@fire-out.ru.is) (Client Quit)
  16. # [00:16] * Joins: newtron_ (~newtron@199.71.174.204)
  17. # [00:16] * Quits: weinig (~weinig@17.114.5.151) (Ping timeout: 245 seconds)
  18. # [00:16] * Joins: barnabywalters (~barnabywa@fire-out.ru.is)
  19. # [00:16] * Quits: ehsan (~ehsan@66.207.208.102) (Remote host closed the connection)
  20. # [00:17] * Quits: sankha93 (~sankha93@fsf/emeritus/sankha93) (Remote host closed the connection)
  21. # [00:17] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
  22. # [00:19] * Quits: newtron (~newtron@199.71.174.203) (Ping timeout: 240 seconds)
  23. # [00:19] * Joins: shannonmoeller (~shannonmo@pool-108-17-8-225.bflony.fios.verizon.net)
  24. # [00:20] * Quits: newtron_ (~newtron@199.71.174.204) (Ping timeout: 240 seconds)
  25. # [00:21] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Ping timeout: 240 seconds)
  26. # [00:21] * Joins: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi)
  27. # [00:22] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 258 seconds)
  28. # [00:23] * Quits: mven_ (~mven@169.241.49.57) (Read error: Connection reset by peer)
  29. # [00:25] * Joins: mven_ (~mven@169.241.49.57)
  30. # [00:27] * Joins: ehynds (~ehynds@146-115-145-170.c3-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com)
  31. # [00:31] * Joins: ap_ (~ap@17.114.219.248)
  32. # [00:33] * Quits: ehynds (~ehynds@146-115-145-170.c3-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com)
  33. # [00:34] * Quits: ap (~ap@2620:149:4:304:94aa:396b:f1a3:3bbb) (Ping timeout: 240 seconds)
  34. # [00:34] * ap_ is now known as ap
  35. # [00:34] * Joins: othermaciej (~mjs@17.244.162.161)
  36. # [00:37] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Ping timeout: 245 seconds)
  37. # [00:38] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  38. # [00:39] * Quits: shannonmoeller (~shannonmo@pool-108-17-8-225.bflony.fios.verizon.net) (Quit: Leaving...)
  39. # [00:40] * Joins: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi)
  40. # [00:41] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  41. # [00:43] * Joins: jeremyj (~jeremyj@17.202.44.231)
  42. # [00:44] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  43. # [00:46] * Quits: plutoniix (~plutoniix@node-1ccb.pool-101-108.dynamic.totbb.net) (Quit: จรลี จรลา)
  44. # [00:46] * Joins: weinig (~weinig@17.202.50.223)
  45. # [00:50] * Joins: llkats (~llkats@h-64-236-138-1.aoltw.net)
  46. # [00:51] * Joins: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl)
  47. # [00:55] * Quits: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl) (Ping timeout: 252 seconds)
  48. # [00:56] * Quits: weinig (~weinig@17.202.50.223) (Ping timeout: 276 seconds)
  49. # [00:56] * Joins: bholley (~bholley@98.210.101.88)
  50. # [00:58] * Joins: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com)
  51. # [00:58] * Joins: dbaron (~dbaron@corp.mtv2.mozilla.com)
  52. # [01:00] * Quits: mven (~textual@169.241.49.233) (Ping timeout: 258 seconds)
  53. # [01:02] * Quits: bholley (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  54. # [01:05] * Quits: barnabywalters (~barnabywa@fire-out.ru.is) (Quit: barnabywalters)
  55. # [01:06] * Joins: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl)
  56. # [01:07] * Joins: bholley (~bholley@98.210.101.88)
  57. # [01:10] * Quits: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl) (Ping timeout: 240 seconds)
  58. # [01:13] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  59. # [01:15] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
  60. # [01:18] * Joins: jeremyj (~jeremyj@17.202.44.231)
  61. # [01:21] * Joins: rniwa (~rniwa@17.202.43.222)
  62. # [01:22] * Quits: dbaron (~dbaron@corp.mtv2.mozilla.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  63. # [01:23] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
  64. # [01:23] * Quits: tantek (~tantek@172.56.38.55) (Quit: tantek)
  65. # [01:27] * Joins: jernoble|laptop (~jernoble@17.202.45.163)
  66. # [01:30] * Joins: jdaggett (~jdaggett@61-121-216-2.bitcat.net)
  67. # [01:30] * Quits: Garbee (uid21171@gateway/web/irccloud.com/x-axbibaguauclgwkt) (Quit: Connection closed for inactivity)
  68. # [01:32] * Quits: ap (~ap@17.114.219.248) (Remote host closed the connection)
  69. # [01:32] * Joins: ap (~ap@2620:149:4:304:9d2f:11e8:518d:3d51)
  70. # [01:34] <JonathanNeal> What’s the status of Element.prototype.findAll / find? Is that still happening?
  71. # [01:35] * Joins: gavinc (~gavin@barad-dur.carothers.name)
  72. # [01:35] <Hixie> anyone here a JS module expert who can answer me some questions? I'm trying to work out if I can walk the dependency tree using the ES6 module API
  73. # [01:36] <zewt> still dubious about adding an api entry point that's basically just an alias for something else
  74. # [01:39] * Hixie starts a sentence "HTML Imports import other Imports" and then realises he's gonna have to start over
  75. # [01:39] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  76. # [01:42] * Joins: jeremyj (~jeremyj@17.202.44.231)
  77. # [01:42] * Joins: mven (~textual@ip68-104-38-84.lv.lv.cox.net)
  78. # [01:46] * Quits: jeremyj (~jeremyj@17.202.44.231) (Client Quit)
  79. # [01:46] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  80. # [01:46] <astearns> HTML imports importing other imports is an important feature
  81. # [01:47] * Quits: othermaciej (~mjs@17.244.162.161) (Quit: othermaciej)
  82. # [01:47] * Joins: jeremyj (~jeremyj@17.202.44.231)
  83. # [01:50] * Quits: lmclister (~lmclister@sjfw1.adobe.com)
  84. # [01:50] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 265 seconds)
  85. # [01:59] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Ping timeout: 252 seconds)
  86. # [02:01] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 255 seconds)
  87. # [02:03] * Quits: jernoble|laptop (~jernoble@17.202.45.163) (Ping timeout: 265 seconds)
  88. # [02:04] * Joins: KevinMarks2 (~yaaic@2607:fb90:2805:a49f:f331:5bee:3484:b950)
  89. # [02:06] * Joins: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl)
  90. # [02:10] * Quits: bholley (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  91. # [02:11] * Quits: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl) (Ping timeout: 252 seconds)
  92. # [02:11] * Quits: llkats (~llkats@h-64-236-138-1.aoltw.net) (Remote host closed the connection)
  93. # [02:12] * Joins: bholley (~bholley@98.210.101.88)
  94. # [02:12] * Joins: llkats (~llkats@h-64-236-138-4.aoltw.net)
  95. # [02:13] * Joins: othermaciej (~mjs@76.74.153.41)
  96. # [02:15] * Quits: aiglesias (~aiglesias@host29.190-139-157.telecom.net.ar) (Remote host closed the connection)
  97. # [02:16] * Quits: llkats (~llkats@h-64-236-138-4.aoltw.net) (Ping timeout: 255 seconds)
  98. # [02:17] * Quits: danjesus (~danjesus@187.37.68.156) (Remote host closed the connection)
  99. # [02:18] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
  100. # [02:23] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 240 seconds)
  101. # [02:24] * Joins: aiglesias (~aiglesias@host29.190-139-157.telecom.net.ar)
  102. # [02:30] * Quits: KevinMarks2 (~yaaic@2607:fb90:2805:a49f:f331:5bee:3484:b950) (Ping timeout: 240 seconds)
  103. # [02:31] <TabAtkins> JonathanNeal: http://dom.spec.whatwg.org/#dom-parentnode-query Got renamed to query/queryAll, but otherwise still there in DOM and planning to stick around.
  104. # [02:31] <TabAtkins> zewt: What are you referring to?
  105. # [02:32] * Quits: jeffreyatw (~jeffreyat@173.247.197.10) (Quit: jeffreyatw)
  106. # [02:33] * Joins: dbaron (~dbaron@corp.mtv2.mozilla.com)
  107. # [02:33] * Quits: aiglesias (~aiglesias@host29.190-139-157.telecom.net.ar)
  108. # [02:35] <zewt> find vs. querySelector
  109. # [02:36] <TabAtkins> Those arent' aliases.
  110. # [02:36] <TabAtkins> They are similar, but in the sense that querySelector was a mistake we have to support, and query() is the way we should have designed it in the first place.
  111. # [02:37] <zewt> the last time I saw it, it was "we want to add new features to querySelector, so let's make a new function with a shorter name while we're at it"
  112. # [02:37] * Joins: KevinMarks2 (~yaaic@2607:fb90:2805:a49f:f331:5bee:3484:b950)
  113. # [02:37] <zewt> don't know anything wrong with querySelector that needs a new entry point
  114. # [02:37] <TabAtkins> It's "let's redo querySelector, but with the correct scoping behavior, and allow relative selectors while we're at it, since everyone expects that and it's an obvious feature".
  115. # [02:38] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
  116. # [02:39] * Quits: estellevw (~estellevw@209.49.66.106) (Quit: Snuggling with the puppies)
  117. # [02:42] * Quits: dbaron (~dbaron@corp.mtv2.mozilla.com) (Ping timeout: 240 seconds)
  118. # [02:48] * Joins: plutoniix (~plutoniix@210.213.57.70)
  119. # [02:50] * Joins: jernoble|laptop (~jernoble@76.74.153.41)
  120. # [02:55] * Joins: jungkees (uid24208@gateway/web/irccloud.com/x-nwxtqoblwrvljzsa)
  121. # [02:57] * rektide_ is now known as rektide
  122. # [02:58] * Quits: jernoble|laptop (~jernoble@76.74.153.41) (Quit: Textual IRC Client: www.textualapp.com)
  123. # [02:59] <Hixie> TabAtkins: i think you misread my last comment on the promises thing
  124. # [02:59] <TabAtkins> I miight have.
  125. # [03:03] * Joins: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net)
  126. # [03:04] * Joins: Goplat (~goplat@reactos/developer/Goplat)
  127. # [03:04] * Quits: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net) (Remote host closed the connection)
  128. # [03:05] * Joins: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net)
  129. # [03:06] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  130. # [03:08] * Quits: jory (~jory@supercu.be) (Ping timeout: 240 seconds)
  131. # [03:09] * Quits: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
  132. # [03:10] * Joins: Guest7163 (~jory@supercu.be)
  133. # [03:17] * Joins: karlcow (~karl@nerval.la-grange.net)
  134. # [03:17] * Quits: bholley (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  135. # [03:18] <TabAtkins> annevk: I'm writing some basic advice for writing async algos in specs at http://wiki.csswg.org/spec/async-algos . I'd appreciate guidance on the right spec language to use for queueing tasks when you need to mutate some observable document state.
  136. # [03:21] <TabAtkins> Hixie: Looking over it again, I'm not sure how I misread your comment. Mind elaborating?
  137. # [03:25] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: This computer has gone to sleep)
  138. # [03:27] * Joins: tantek (~tantek@216.9.110.5)
  139. # [03:28] * Joins: jeffreyatw (~jeffreyat@199-241-200-45.PUBLIC.monkeybrains.net)
  140. # [03:34] * Quits: othermaciej (~mjs@76.74.153.41) (Quit: othermaciej)
  141. # [03:35] * Joins: izhak (~izhak@92.248.142.152)
  142. # [03:36] * Joins: bholley (~bholley@98.210.101.88)
  143. # [03:37] <Hixie> TabAtkins: maybe i misread yours? i was saying that it was not ok that argument-checking turns into a rejected promise.
  144. # [03:37] <TabAtkins> Oh jeez, I missed a "not". Okay, then you're not inconsistent, you're just still wrong and lots of people disagree with you. ^_^
  145. # [03:37] <Hixie> lots of people agree, too, it looks like
  146. # [03:38] <TabAtkins> Several people who have been closely involved with the work on promises all agree.
  147. # [03:38] <TabAtkins> That is, people who have a strong working and theoretical background on useful coding patterns for this kind of thing.
  148. # [03:39] <Hixie> yeah. so. just so we're clear, i give argument from authority zero weight. :-)
  149. # [03:42] * Joins: estellevw (~estellevw@173-228-112-232.dsl.dynamic.sonic.net)
  150. # [03:45] * Quits: tantek (~tantek@216.9.110.5) (Quit: tantek)
  151. # [03:46] * Quits: bholley (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  152. # [03:47] * Quits: ehsan (~ehsan@24-212-207-29.cable.teksavvy.com) (Quit: Leaving...)
  153. # [03:50] <TabAtkins> Obviously. What I'm saying is that it looks like you're treating this like a personal preference API design issue, and it's not. Those people have good experience in why async APIs are more usable in the wild/in the large when they're designed this way.
  154. # [03:52] * Joins: danjesus (~danjesus@177.68.90.206)
  155. # [03:53] * Quits: jeffreyatw (~jeffreyat@199-241-200-45.PUBLIC.monkeybrains.net) (Quit: jeffreyatw)
  156. # [03:53] <TabAtkins> And they've written down the reasons why, and it doesn't look like you've addressed their arguments.
  157. # [03:55] <TabAtkins> Heck, even I've written down arguments for the "always reject" pattern <http://www.xanthir.com/b4P_0>, and I didn't even realize it! It wasn't until after Domenic schooled me that I realized my earlier explanations were completely in line with that pattern.
  158. # [03:55] * Joins: jeffreyatw (~jeffreyat@199-241-200-45.PUBLIC.monkeybrains.net)
  159. # [03:56] <TabAtkins> Throwing+rejecting is akin to having to wrap both the source and the call site of a function in try/catch in Mauvascript, because some errors get thrown at the source location and some get thrown at the call site.
  160. # [03:56] * Joins: tantek (~tantek@172.56.38.55)
  161. # [03:57] <Hixie> TabAtkins: you realise i also have good experience in designing APIs, right
  162. # [03:58] <TabAtkins> I thought you just said argument from authority have zero weight!
  163. # [03:58] <Hixie> it doesn't
  164. # [03:58] <Hixie> but your saying "these people have experience" sounds like you're implying "and you don't"
  165. # [03:59] <TabAtkins> Don't read it like that, then, because that's not what I'm saying.
  166. # [03:59] * Joins: scor (~scor@drupal.org/user/52142/view)
  167. # [03:59] <TabAtkins> It's "this people have experience, but you're treating them like they just have an opinion".
  168. # [03:59] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
  169. # [03:59] <Hixie> i've made counter-arguments to every argument presented, as far as i can tell
  170. # [04:00] <Hixie> it's either opinion, or they're wrong. :-) i think it's probably opinion.
  171. # [04:00] <TabAtkins> Which continue to be of the form "I believe I can draw a firm line between contract violations and data errors", which is wrong.
  172. # [04:01] <TabAtkins> Alternately, "I believe that the arguments people have made about how difficult and annoying it is to handle both sync and async errors are spurious".
  173. # [04:01] <Hixie> the web api has drawn that firm line for years
  174. # [04:01] <Hixie> decades even
  175. # [04:02] <Hixie> exceptions on one side, 'error' events on the other
  176. # [04:02] * Quits: tantek (~tantek@172.56.38.55) (Quit: tantek)
  177. # [04:02] <TabAtkins> Oh come now, error events are rare.
  178. # [04:02] <Hixie> yup
  179. # [04:02] <Hixie> exceptions too, actually
  180. # [04:03] <TabAtkins> And it's very easy to argue that the line they draw is arbitrary and bad, and they shouldn't be doing so.
  181. # [04:03] <Hixie> what would that argument look like?
  182. # [04:03] <TabAtkins> (Events also never composed in any meaningful manner, which is the exact scenario being held up as being difficult to handle when you're mixing sync and async errors.)
  183. # [04:04] <TabAtkins> (Unlike promises, where composition is commonplace and expected.)
  184. # [04:04] <Hixie> we're not mixing sync and async errors
  185. # [04:04] <Hixie> the sync errors never happen unless there's a bug
  186. # [04:04] <Hixie> they're a completely different beast than the async errors.
  187. # [04:04] <TabAtkins> Many async errors don't happen unless there's a bug, too.
  188. # [04:05] <TabAtkins> And regardless, having one error-handling path is usually much easier to handle correctly.
  189. # [04:05] <TabAtkins> This is the exact argument made by several people, and by the blog posts you've been referred to.
  190. # [04:05] <TabAtkins> You seem to be claiming that the difficulties those people outline and explain aren't real, or aren't actually difficult to handle.
  191. # [04:06] <Hixie> that argument is totally bogus. it implies that you're (a) going to do anything useful when "handling" an error that's caused by a bug, and (b) that even if you did, it could in any meaningful sense be the same thing as if you were handling a non-logic bug, like a network error.
  192. # [04:06] <Hixie> s/non-logic bug/non-bu error/
  193. # [04:06] <Hixie> non-bug
  194. # [04:06] <TabAtkins> So you don't understand the argument, then.
  195. # [04:06] <TabAtkins> I suggest looking into it further and trying harder to understand it.
  196. # [04:06] <Hixie> maybe. or maybe you don't understand why it's wrong. :-)
  197. # [04:08] <Hixie> why do i have the burden of trying to convince myself that you're right as opposed to you having the burden to convince yourself that i'm right?
  198. # [04:08] * Joins: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl)
  199. # [04:12] * Quits: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl) (Ping timeout: 264 seconds)
  200. # [04:16] * Joins: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net)
  201. # [04:16] * Quits: jeffreyatw (~jeffreyat@199-241-200-45.PUBLIC.monkeybrains.net) (Read error: Connection reset by peer)
  202. # [04:18] * Joins: jeffreyatw (~jeffreyat@199-241-200-45.PUBLIC.monkeybrains.net)
  203. # [04:19] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
  204. # [04:20] * Quits: llkats (~llkats@c-69-181-45-245.hsd1.ca.comcast.net) (Ping timeout: 264 seconds)
  205. # [04:23] * Quits: silky__ (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
  206. # [04:23] * Joins: Streusel (~Anonymous@unaffiliated/streusel)
  207. # [04:24] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 264 seconds)
  208. # [04:24] <SamB> TabAtkins: so what useful thing are you going to do in response to one of these bugs?
  209. # [04:28] * SamB wonders if TabAtkins has ever seen an async API that he liked
  210. # [04:28] <TabAtkins> SamB: I already did - I adjusted the Font Loading APIs to accord with this.
  211. # [04:30] <TabAtkins> Hixie: Because only one of us is right, and it's me, so it would be counterproductive for new to convince myself that you're right. ^_^
  212. # [04:31] <Hixie> that seems like an unproductive attitude, if you're serious
  213. # [04:31] <Hixie> i find that convincing myself that other people are right is one of the best uses of my time
  214. # [04:31] * Joins: KevinMarks_ (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net)
  215. # [04:32] * Quits: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr) (Excess Flood)
  216. # [04:33] <SamB> I meant outside JS stuff
  217. # [04:33] * Quits: KevinMarks (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
  218. # [04:33] * Quits: nephyrin (~neph@corp.mtv2.mozilla.com) (Remote host closed the connection)
  219. # [04:33] * Joins: nephyrin (~neph@corp.mtv2.mozilla.com)
  220. # [04:34] <TabAtkins> Hixie: Less cheekily, I was already on your side, and I was convinced otherwise by reasonable arguments from Domenic.
  221. # [04:34] <TabAtkins> SamB: I have no idea what you're talking about, in that case.
  222. # [04:34] <Hixie> TabAtkins: i've read those same arguments, and i don't see why they are compelling.
  223. # [04:34] * Joins: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr)
  224. # [04:34] <SamB> TabAtkins: you don't know what a non-JS API is?
  225. # [04:34] <TabAtkins> SamB: No, I have no clue what you're asking.
  226. # [04:35] <TabAtkins> I mean, come on, at least *try* for the reasonable explanation for my confusion. ^_^
  227. # [04:35] <SamB> I was trying to provoke you into revealing more details ;-P
  228. # [04:35] <TabAtkins> Oh! you were referring to bugs in my JS code, not bugs as in GitHub issues.
  229. # [04:35] <SamB> not necessarily your code
  230. # [04:36] <TabAtkins> Right, just JS code in general.
  231. # [04:36] <TabAtkins> I thought you were asking about what I was going to do in response to the github issue.
  232. # [04:36] <TabAtkins> Anyway, same thing you'd do with any try/catch.
  233. # [04:36] <caitp> is this still the promise thing?
  234. # [04:36] <TabAtkins> Yeah.
  235. # [04:36] * TabAtkins is home and trying to play Civ now, though.
  236. # [04:37] <SamB> TabAtkins: what's that thing you'd do with any try/catch?
  237. # [04:37] <TabAtkins> Depends entirely on what the code is?
  238. # [04:37] <SamB> and how does it help when someone just screwed up their calls
  239. # [04:38] <Hixie> TabAtkins: specifically, it looks like https://github.com/domenic/promises-unwrapping/issues/24#issuecomment-23979547 canvinced you, but i disagree with the premise of that argument. There is a fundamental difference between the types of errors he's talking about. If you've got a promise for a network-obtained resource, it makes sense that you could deal with "the network is flaky" by e.g. trying again or using a cached resource. But there's no logical thing y
  240. # [04:38] * Joins: silky__ (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net)
  241. # [04:38] <Hixie> ...you could do in response to a SyntaxError, ReferenceError, TypeError, or InvalidStateError. They're just qualitatively different. You don't want all your rejection handlers to deal with this. That's what window.onerror is for.
  242. # [04:38] <SamB> but, like, what are you gonna do with the equivalent of "bad FD"
  243. # [04:40] <caitp> hixie, there is a problem with treating them differently --- those errors which in other languages might be caught at compiletime, can't really be caught at compiletime in js (unless it's a legitimate syntax error that breaks the parser) --- you can only run into them at runtime
  244. # [04:40] <TabAtkins> Hixie: Actually, you often do. It's a common trope in Python, frex, to forgo argument checking and instead just try calling other APIs with whatever you've got, wrapping the call in a try/catch and doing something alternate regardless of what the error is.
  245. # [04:40] <TabAtkins> The same trope applies to JS just as much.
  246. # [04:41] <caitp> and then, if you are going to treat them differently at runtime by making "special" errors uncatchable, then
  247. # [04:41] <caitp> that pretty much throws away the ecma draft
  248. # [04:41] <TabAtkins> If *anything* happens to your network request, you might want to fail over to a cache.
  249. # [04:41] <SamB> TabAtkins: hmm, I think usually you only do that on specific exceptions
  250. # [04:41] <TabAtkins> You might also want to be more sophisticated, and do retries in some circumstances, etc.
  251. # [04:41] <SamB> otherwise you risk really confusing yourself when things go wrong
  252. # [04:41] <TabAtkins> But that's totally already possible.
  253. # [04:41] <SamB> because you'll never see the exception
  254. # [04:41] <caitp> or at least, adds things to it which don't currently exist
  255. # [04:42] <Hixie> TabAtkins: calling an api at random is absurd. if that's the kind of "experience" that is leading to this design, then i can just rest my case here.
  256. # [04:42] <TabAtkins> "at random" is a terrible characterization of what I just described.
  257. # [04:42] <SamB> TabAtkins: what if you never get a request made because you totally flubbed the parameters?
  258. # [04:43] <TabAtkins> SamB: Testing will reveal that, then.
  259. # [04:43] <TabAtkins> Or examining your error logs.
  260. # [04:43] <SamB> how do these logs happen if no exception is thrown?
  261. # [04:43] <Hixie> "hey i don't know if what i've got here is valid for this api, but i'll call it anyway" is not good practice.
  262. # [04:43] <TabAtkins> "Why do I keep making requests to "{keepalive:true}"? Oh, because I swapped the arg order in fetch(). Duh."
  263. # [04:43] <caitp> dude it's the web, it's the land of "not a good practice"
  264. # [04:43] * Quits: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95) (Quit: coolbot95)
  265. # [04:43] <SamB> no need to make it super easy
  266. # [04:43] * Hixie fires up some DA:O instead of trying to explain why we shouldn't be optimising APIs for bad practice
  267. # [04:44] <SamB> I'd rather exclaim that
  268. # [04:44] <zewt> i've never seen duck typing in JS, I think the only time I've called something expecting to catch a low-level exception is for feature detection
  269. # [04:44] <zewt> i rarely even use it in Python
  270. # [04:45] <zewt> that said, any good language should let you catch any runtime error
  271. # [04:45] <caitp> feature detection is a pretty good use case for a world where you have dozens of browsers with different capabilities and configurations
  272. # [04:45] <SamB> the main thing I see that at all resembles what TabAtkins said in Python is that pattern where you catch ImportError and fall back to some other way of doing whatever it is the thing you tried to import was for
  273. # [04:45] <caitp> and in different versions
  274. # [04:45] <TabAtkins> Hixie: Extremely common example: I've got a file handle, which may or may not exist. Checking ahead of time whether it exists is futile, because it might disappear between now and th enext line of code.
  275. # [04:45] * Quits: gungan_fuq (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com) (Ping timeout: 258 seconds)
  276. # [04:45] <SamB> caitp: you don't usually want to do feature detection asynchronously ...
  277. # [04:46] <TabAtkins> Hixie: Thus the Python idiom is to just call the function assuming the file is there, and handle "file never existed" and "file did exist, but just now disappeared" the same way, in the catch block, unless you have a good reason to differentiate them.
  278. # [04:46] <caitp> no, but i'm not really taking sides in that argument, what I'm saying is that catching things like that can be useful
  279. # [04:46] <SamB> TabAtkins: filehandles don't suddenly stop existing in sane environments
  280. # [04:46] <caitp> and if it's going to work synchronously, why not asynchronously
  281. # [04:46] <TabAtkins> SamB: The file underneath them does.
  282. # [04:46] <caitp> you know, for consistency
  283. # [04:46] <SamB> just saying
  284. # [04:46] <TabAtkins> What are you just saying? Files can get deleted.
  285. # [04:46] <zewt> TabAtkins: "a nonexistant FD" and "a valid FD pointing to a file that doesn't exist any more" are pretty different things
  286. # [04:46] <caitp> this is the web, it's the land of "not a sane environment" :p
  287. # [04:46] <SamB> you people have strange file handles here, is all
  288. # [04:47] <TabAtkins> zewt: In many cases they're identical for your purposes.
  289. # [04:47] <SamB> zewt: I don't think web file handles are much like FDs
  290. # [04:47] <TabAtkins> See: every use of a file handle in Bikeshed.
  291. # [04:47] <SamB> I Think they're more like struct stat
  292. # [04:47] <zewt> can we call your file handle a "filename" for this example?
  293. # [04:47] <TabAtkins> zewt: Yeah, whatever.
  294. # [04:48] <TabAtkins> Same diff for these purposes.
  295. # [04:48] <zewt> it seems like you're describing "open(filename) and catch IOError to see if it fails", which is fine
  296. # [04:48] <SamB> in unix a file doesn't go away just because it's deleted, if you already have a handle to it
  297. # [04:48] <SamB> I never really understood how it works on Windows for sure, since usually you aren't allowed to delete such files in the first place
  298. # [04:48] <zewt> but i'm not sure it's the same case as "open(filename) where filename might be None, and catch TypeError" (eg. duck typing)
  299. # [04:49] <zewt> SamB: ... that's why I established "filename", because that seemed irrelevant
  300. # [04:49] <SamB> yeah sorry
  301. # [04:49] <SamB> just, I can't help ranting about the stupid terminology ...
  302. # [04:52] <TabAtkins> zewt: Yes.
  303. # [04:52] <zewt> anyway, i don't know the particular case well enough to have an opinion, though I can see a distinction between synchronous and async here (can't think of any reason, off-hand anyway, why I'd want to receive a TypeError async; that just means the async task fell over)
  304. # [04:52] <SamB> (back to Python, I only just learned that file() was deprecated, and you're better off if you never switched from open())
  305. # [04:52] <TabAtkins> You should be using io.open anyway.
  306. # [04:52] <TabAtkins> Returns unicodes automatically, rather than strs.
  307. # [04:52] <TabAtkins> Or use Python3, I guess. ^_^
  308. # [04:52] <SamB> huh? a file isn't unicode!
  309. # [04:52] <zewt> i want to, but I don't see it happening on the horizon, heh
  310. # [04:52] * Quits: danjesus (~danjesus@177.68.90.206) (Remote host closed the connection)
  311. # [04:52] <TabAtkins> SamB: It is if you're reading text!
  312. # [04:52] <TabAtkins> If your text isnt' in utf-8, what are you doing with your life.
  313. # [04:53] <SamB> I guess a lot of APIs insist on you picking an encoding (possibly raw binary) and sticking with it though
  314. # [04:53] <zewt> (at work, at least)
  315. # [04:53] <SamB> so in that case you'd have to pick at open() time
  316. # [04:53] <SamB> anyway, I found out when working on porting the libstdc++ pretty printers to 2+3
  317. # [04:53] * Joins: danjesus (~danjesus@177.68.90.206)
  318. # [04:54] <zewt> one stupid thing that also impedes my desire to use python 3: print not being a keyword
  319. # [04:54] <SamB> I know, right?
  320. # [04:54] <zewt> like, that's nice and all, but I have years of muscle memory for "print foo"
  321. # [04:54] <SamB> I just wish the REPL had an option to turn it back
  322. # [04:54] <SamB> I don't really care so much in code
  323. # [04:55] * Quits: izhak (~izhak@92.248.142.152) (Ping timeout: 255 seconds)
  324. # [04:55] <SamB> maybe also for -c ...
  325. # [04:55] <SamB> or was that -e
  326. # [04:56] * Quits: estellevw (~estellevw@173-228-112-232.dsl.dynamic.sonic.net) (Quit: Snuggling with the puppies)
  327. # [04:56] <SamB> (also when are they going to support proper SIGINT handling?)
  328. # [04:57] <caitp> file a bug on your favourite implementation with an issue tracker
  329. # [04:57] <zewt> if you want a real, serious gripe for Python (and there really are only a few), look at its HTTPS server certificate handling
  330. # [04:58] <zewt> (there isn't any)
  331. # [04:58] <SamB> caitp: I think exarkun already filed it
  332. # [04:59] <caitp> then you know what you have to do
  333. # [04:59] <caitp> get 600 of your closest friends to spam it with "+1"
  334. # [05:00] <SamB> google is silly
  335. # [05:00] <KevinMarks2> I've been reading the anti python 3 rants and they all seem very command line oriented
  336. # [05:00] <SamB> it wants to google for "exar kun python" or "exar kun twisted"
  337. # [05:01] <KevinMarks2> Whereas the python 3 changes seem more Internet oriented
  338. # [05:01] <caitp> autonomously?
  339. # [05:01] <SamB> even though the nick connected with those topics is almost invariably spelled "exarkun"
  340. # [05:01] <zewt> i think there are too many changes in 3 to categorize them
  341. # [05:01] <SamB> caitp: I typed exarkun and that's what came up in the suggestions
  342. # [05:02] <SamB> well, along with some star wars stuff
  343. # [05:02] <SamB> where the one with the space makes sense
  344. # [05:05] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  345. # [05:06] * Joins: jeremyj (~jeremyj@17.202.44.231)
  346. # [05:12] <SamB> hmm, guess I misremembered who filed <http://bugs.python.org/issue1054041> ...
  347. # [05:15] <caitp> looks like thats been open for basically since the dawn of time
  348. # [05:15] * Guest7163 is now known as jory
  349. # [05:25] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  350. # [05:32] * Joins: karlcow (~karl@nerval.la-grange.net)
  351. # [05:33] * Joins: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  352. # [05:43] * Quits: jwalden (~waldo@corp.mtv2.mozilla.com) (Quit: brb)
  353. # [05:47] * Joins: gungan_fuq (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com)
  354. # [05:58] * Joins: estellevw (~estellevw@173-228-112-232.dsl.dynamic.sonic.net)
  355. # [06:00] * Joins: jwalden (~waldo@c-50-168-55-219.hsd1.ca.comcast.net)
  356. # [06:09] * Joins: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl)
  357. # [06:12] * Krinkle is now known as Krinkle|detached
  358. # [06:14] * Quits: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl) (Ping timeout: 245 seconds)
  359. # [06:17] * Quits: KevinMarks2 (~yaaic@2607:fb90:2805:a49f:f331:5bee:3484:b950) (Ping timeout: 240 seconds)
  360. # [06:18] * Quits: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  361. # [06:19] * Joins: dbaron (~dbaron@172.56.39.88)
  362. # [06:20] * Joins: KevinMarks (~yaaic@2607:fb90:2203:b714:2a69:a41:533f:c1d2)
  363. # [06:20] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
  364. # [06:21] * Quits: jeffreyatw (~jeffreyat@199-241-200-45.PUBLIC.monkeybrains.net) (Quit: jeffreyatw)
  365. # [06:24] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 252 seconds)
  366. # [06:26] * Quits: KevinMarks (~yaaic@2607:fb90:2203:b714:2a69:a41:533f:c1d2) (Ping timeout: 240 seconds)
  367. # [06:27] * Joins: KevinMarks (~yaaic@2607:fb90:2203:b714:2a69:a41:533f:c1d2)
  368. # [06:30] * Joins: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  369. # [06:36] * Quits: dbaron (~dbaron@172.56.39.88) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  370. # [06:36] * Quits: danjesus (~danjesus@177.68.90.206)
  371. # [06:37] * hayato_gardening is now known as hayato
  372. # [06:51] * Joins: jeffreyatw (~jeffreyat@199-188-192-248.PUBLIC.monkeybrains.net)
  373. # [06:56] * Quits: Rastus_Vernon (uid15187@wikimedia/Rastus-Vernon) (Quit: Connection closed for inactivity)
  374. # [07:01] * Joins: BigBangUDR (~Thunderbi@220.225.242.27)
  375. # [07:09] * Joins: rxgx (uid22483@gateway/web/irccloud.com/x-uzupcemvrzghhdjt)
  376. # [07:13] <Hixie> TabAtkins: if the contract is "pass me what might be a valid file handle or might not, and i'll act accordingly", then an async response might make sense in that scenario
  377. # [07:13] <Hixie> TabAtkins: if the contract is "pass me a guaranteed valid file handle", then an async response wouldn't make sense
  378. # [07:15] <Hixie> TabAtkins: but if the contract is "pass me what might be a valid file handle" and you pass it a banana, i wouldn't want an async response, because wtf is my async handler supposed to do with that?
  379. # [07:18] <caitp> for Hixie's point, if you can prevent the async operation from ever taking place if it should result in an error, then great, there might be a tiny performance benefit and a better guarantee of correctness. to TabAtkin's point, it means you end up with a lot messier, less reasonable code
  380. # [07:18] <Hixie> it doesn't make the code more messy
  381. # [07:18] <Hixie> nobody is going to be handling these exceptions one way or the other
  382. # [07:19] <caitp> sure they are
  383. # [07:19] <Hixie> in fact it's less messy if the exceptions are sync
  384. # [07:19] <Hixie> since there's no code there
  385. # [07:19] <Hixie> but if they're async you have to at least have an "else, do nothing" clause
  386. # [07:20] <caitp> you're writing a toolkit which people will use which makes some async call --- they want you to set some readonly parameter of an xhr object to some value which isn't supported in that browser yet (such as "json" for responseType in safari)
  387. # [07:20] <caitp> well, not "readOnly"
  388. # [07:20] <caitp> you know what I mean, limited set of allowed values :>
  389. # [07:21] <caitp> anyways, so the library won't want to break your code, because it works perfectly well on other browsers
  390. # [07:21] <Hixie> setting an attribute is a beautiful case of where bad values should be handled by throwing an exception
  391. # [07:21] <caitp> so they will add a bunch of gross error checking
  392. # [07:21] * Quits: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  393. # [07:21] <caitp> and it gets messy and hurts performance
  394. # [07:21] <Hixie> because where the heck would the promise even be given
  395. # [07:21] * Joins: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  396. # [07:21] <caitp> well, this isn't a DOM api example, but I think the same sort of thing applies
  397. # [07:22] <caitp> you're setting a value which browser X doesn't support, but browser Y does
  398. # [07:22] <caitp> it throws --- you have to handle this because you support browser Y
  399. # [07:22] <Hixie> in non-DOM APIs, I can already do what i want, and i don't care how other people write their code
  400. # [07:22] <Hixie> it's the DOM APIs I care about here
  401. # [07:23] <caitp> which is great and all, except that people can and do wrap DOM apis to get more consistent or easier ways to interact with them
  402. # [07:23] <caitp> and have been doing this for a pretty long time now
  403. # [07:23] <Hixie> lots of people wrap DOM APIs in lots of different ways, sure
  404. # [07:24] <caitp> all I'm sayin is, if you need try/catch blocks to get consistent behaviour across implementations, that sucks
  405. # [07:25] <Hixie> can you show me what you think it would look like the way i'm asking for and the way you're asking for?
  406. # [07:25] <Hixie> i'm not sure i understand
  407. # [07:31] * Joins: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net)
  408. # [07:34] <caitp> https://gist.github.com/caitp/c63788b2a308b4b2c56c
  409. # [07:34] <caitp> that's a pretty simple example --- oh, and it doesn't actually accomplish consistent behaviour across browsers
  410. # [07:34] * Quits: ambv (~ambv@206.108.217.134) (Remote host closed the connection)
  411. # [07:34] <caitp> i mean, it does get api consistency
  412. # [07:35] <caitp> but for consistent behaviour across browsers you'd need a separate try/catch for each problematic property
  413. # [07:35] <caitp> and a fallback behaviour in the case of an error
  414. # [07:35] <Hixie> this is which case? the case as you want it or the case as i want it?
  415. # [07:35] <Hixie> i'm not sure I really understand this example.
  416. # [07:35] <caitp> i don't really have a strong opinion one way or the other on the promise thing
  417. # [07:35] <Hixie> oh ok
  418. # [07:36] <caitp> but I think in real applications, throwing synchronously for async operations can mean that you have to handle both synchronous and asynchronous errors
  419. # [07:36] <caitp> in many cases
  420. # [07:36] <caitp> and this is messy
  421. # [07:36] <Hixie> i don't understand why you ever have to handle the synchronous errors i'm talking about
  422. # [07:36] <Hixie> if the code is written right, you'll never get them
  423. # [07:37] <caitp> because safari doesn't support a feature that you want to use in your app which works perfectly well on FFos
  424. # [07:37] <Hixie> (i guess except if you're feature-testing, but in that specific case a sync exception is a hell of an easier way to deal with it than an async one)
  425. # [07:37] <caitp> or IE doesn't, or Opera doesn't, or... etc
  426. # [07:37] <Hixie> (sync exception from the browser, i mean)
  427. # [07:37] <caitp> sure, but then you still need to tiptoe around the synchronous errors
  428. # [07:38] <Hixie> there's no tip-toeing dude. you just wrap the call you're unsure about in a try/catch and use the alternative api if it throws.
  429. # [07:38] <Hixie> it's as blunt as it comes.
  430. # [07:38] <caitp> that's tiptoeing
  431. # [07:38] <Hixie> it's as subtle as an axe.
  432. # [07:39] <caitp> okay, let's put it another way, it's going an extra length to evade an error that realistically you shouldn't even have to care about
  433. # [07:39] <caitp> because you're writing tests to verify that your code works as you expect it to
  434. # [07:39] <caitp> you're paying some kid 200k/year to manage your selenium testing infrastructure
  435. # [07:39] <Hixie> what? no, i'm just talking about feature-testing here
  436. # [07:40] <Hixie> try { someHostObject.someAttribute = 'someValueThatMightNotBeSupported' } catch { someHostObject.someAttribute = 'theSadderAlternative' }
  437. # [07:40] <Hixie> that's it
  438. # [07:40] <caitp> yeah i think there are a couple points being made about this and they're getting mixed up a bit
  439. # [07:41] <Hixie> that would certainly explain why i am regularly feeling in this discussion (not just with you) that people are arguing against points i haven't made
  440. # [07:42] * Quits: jeffreyatw (~jeffreyat@199-188-192-248.PUBLIC.monkeybrains.net) (Quit: jeffreyatw)
  441. # [07:42] <caitp> so, I don't have a strong opinion on it, I could live with synchronous exceptions -- they do win for feature detection
  442. # [07:42] <caitp> but, I think they can still lead to the writing of very messy code, too
  443. # [07:43] <Hixie> (have you seen the kind of code that promises can lead to? they're hardly a panacea either.)
  444. # [07:43] <Hixie> except for feature testing, the code for what i'm proposing is exactly zero lines of code.
  445. # [07:43] * Quits: nicolasbadia (~nicolasba@78.209.78.103) (Quit: nicolasbadia)
  446. # [07:44] <Hixie> and for feature testing, it's simpler with exceptions.
  447. # [07:44] <caitp> definitely--but I think if you mix and match handling errors in rejection handlers as well as synchronous catch blocks, that's kinda sucky
  448. # [07:44] <Hixie> there's no mixing and matching.
  449. # [07:44] <Hixie> you only handle exceptions in the rejection handlers.
  450. # [07:44] <caitp> ideally, asynchronous apis should __always__ be asynchronous
  451. # [07:44] <Hixie> yes, the _APIs_ should always be asynchronous. no objection there.
  452. # [07:44] <Hixie> i'm only talking about how the UA reacts when you do something outside of the API
  453. # [07:45] <Hixie> like typo the method call, get the wrong arguments, pass in an object that's of the wrong type or in the wrong state, etc.
  454. # [07:45] <caitp> don't you think for a dynamic language it's easier to deal with this stuff with tests that don't happen during the runtime of the actual application?
  455. # [07:46] <Hixie> can you elaborate on "this stuff"?
  456. # [07:46] <caitp> checking for things like syntax errors or type errors
  457. # [07:46] <Hixie> yes.
  458. # [07:46] <Hixie> that's my point.
  459. # [07:47] <caitp> but then you're also saying you want to have the same behaviour during runtime, and I'm less sure about that, because the audience of a live application doesn't get much benefit from hearing about how you mistyped something
  460. # [07:48] <Hixie> pretty sure the audience of a live application doesn't care if they hear about it via exceptions or rejected promises
  461. # [07:48] <caitp> they might care because it won't crash their app ;p
  462. # [07:49] <Hixie> but if they hear about it via exceptions, the code will just stop, whereas if they get a rejected promise, the code will continue, likely doing unexpected things (since the code isn't ready to accept this) and corrupting their data.
  463. # [07:49] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
  464. # [07:50] <caitp> yeah but you just know people are just going to use sweetjs to wrap everything in try/catch blocks so that their precious puppy catalog app doesn't break
  465. # [07:50] <Hixie> we're already past the point where their app breaks
  466. # [07:50] <Hixie> we're just debating how it breaks
  467. # [07:51] <Hixie> notice that nothing that the "all promises all the time" team is proposing will stop ReferenceErrors (where you typo the method name) from being sync
  468. # [07:51] <Hixie> i'm just saying we should have a few more sync exceptions than they are
  469. # [07:52] <caitp> so, this takes us back to the feature-detection thing, because I agree that you shouldn't need to handle exceptions like that (although I know that people will go out of their way to solve the problem the "wrong way" with catch blocks)
  470. # [07:53] <caitp> and this is the case where browser A behaves correctly, and browser B doesn't, and browser C also doesn't, but behaves incorrectly in a different way
  471. # [07:53] <caitp> this would vary from api to api, but if things are going to throw when they really shouldn't, that really sucks
  472. # [07:55] <caitp> and yeah, rejection handlers don't really solve that
  473. # [07:55] <caitp> that's true
  474. # [07:59] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  475. # [07:59] * Joins: tav (~tav`@host217-42-231-34.range217-42.btcentralplus.com)
  476. # [08:03] * Joins: Smylers (~smylers@host86-156-211-5.range86-156.btcentralplus.com)
  477. # [08:06] * Quits: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net) (Ping timeout: 276 seconds)
  478. # [08:06] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
  479. # [08:07] * Quits: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr) (Excess Flood)
  480. # [08:10] * Joins: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr)
  481. # [08:11] * Joins: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl)
  482. # [08:15] * Quits: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl) (Ping timeout: 264 seconds)
  483. # [08:16] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
  484. # [08:17] * Quits: Smylers (~smylers@host86-156-211-5.range86-156.btcentralplus.com) (Quit: Leaving.)
  485. # [08:39] * Joins: lerc_ (~quassel@121-74-2-8.telstraclear.net)
  486. # [08:40] * Quits: lerc (~quassel@121-74-255-121.telstraclear.net) (Ping timeout: 245 seconds)
  487. # [08:42] * Joins: mpt (mpt@conference/canonical/x-jnzoodgurfwxywva)
  488. # [08:42] * Quits: mpt (mpt@conference/canonical/x-jnzoodgurfwxywva) (Changing host)
  489. # [08:42] * Joins: mpt (mpt@canonical/mpt)
  490. # [08:42] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
  491. # [08:45] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 255 seconds)
  492. # [08:51] * Joins: markkes (~markkes@62.207.90.201)
  493. # [09:00] * Quits: mpt (mpt@canonical/mpt) (Ping timeout: 240 seconds)
  494. # [09:00] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  495. # [09:05] * Quits: ivan\ (~ivan@unaffiliated/ivan/x-000001) (Quit: ERC Version 5.3 (IRC client for Emacs))
  496. # [09:05] * Joins: Ms2ger (~Ms2ger@25.208-64-87.adsl-dyn.isp.belgacom.be)
  497. # [09:06] * Joins: ivan\ (~ivan@unaffiliated/ivan/x-000001)
  498. # [09:07] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
  499. # [09:10] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  500. # [09:10] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Client Quit)
  501. # [09:11] * Quits: rniwa (~rniwa@17.202.43.222) (Quit: rniwa)
  502. # [09:15] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
  503. # [09:16] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  504. # [09:20] * Quits: rxgx (uid22483@gateway/web/irccloud.com/x-uzupcemvrzghhdjt) (Quit: Connection closed for inactivity)
  505. # [09:22] * Joins: Lachy (~Lachy@213.166.174.2)
  506. # [09:22] <krit> zcorpan: Is there anything that is not addressed on DOMPoint, DOMRect, DOMQuad in http://dev.w3.org/fxtf/geometry/ ?
  507. # [09:26] <zcorpan> krit: don't think so
  508. # [09:28] * Joins: richt (~richt@83.218.67.123)
  509. # [09:28] <Ms2ger> On Ringmark: "we were instructed to take whatever steps were necessary to make Firefox and Opera look as good as possible in those tests so that some kind of partnership might blossom"
  510. # [09:31] <krit> zcorpan: ok, I will ask for a detailed review tomorrow and give a 2 weeks time frame. If there are no bigger concerns, we can move to LC.
  511. # [09:32] <zcorpan> krit: ok
  512. # [09:32] <krit> zcorpan: because we are at it, why does DOMQuad have no CTOR for DOMPoint? http://dev.w3.org/fxtf/geometry/#DOMQuad
  513. # [09:32] <krit> sorry, DOMPointReadOnly as argument I mean
  514. # [09:33] <krit> just has DOMPointInit
  515. # [09:33] * Quits: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net) (Quit: tantek)
  516. # [09:34] <zcorpan> krit: you can pass in such objects and webidl rules convert them to DOMPointInit
  517. # [09:34] <krit> zcorpan: oh cool, didn't know that
  518. # [09:35] <zcorpan> i guess we could put in a few notes about webidl tricks the spec uses
  519. # [09:36] <krit> zcorpan: yes, some examples. Was about to add some today. Would be great if you could add some for DOMQuad or DOMRect where appropriate
  520. # [09:37] <zcorpan> krit: can you file bugs where you want me to add examples?
  521. # [09:37] <krit> zcorpan: hm, I try to :)
  522. # [09:37] <zcorpan> thx :-)
  523. # [09:45] <krit> zcorpan: added 3 bug reports. Think the spec would benefit of examples here. https://www.w3.org/Bugs/Public/buglist.cgi?component=Geometry&list_id=37973&product=FXTF&;resolution=--- I can create the graphics for 25904 if you create the example.
  524. # [09:45] <krit> zcorpan: DOMMatrix needs some examples as well of course. Add them today.
  525. # [09:45] <zcorpan> krit: ok
  526. # [09:46] * Quits: KevinMarks (~yaaic@2607:fb90:2203:b714:2a69:a41:533f:c1d2) (Ping timeout: 240 seconds)
  527. # [09:46] <zcorpan> krit: i can try to look at it next week i think
  528. # [09:47] <krit> zcorpan: maybe I can try to create some examples and give it to you for review
  529. # [09:49] <zcorpan> bbiab
  530. # [09:49] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
  531. # [09:49] <annevk> Domenic: they do, but you don't really have to queue a task in this case; you want to change state on an object and resolve the promise, and only expose the object's changed state the moment the promise's callbacks are invoked in the microtask queued for that
  532. # [09:59] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
  533. # [10:04] * Quits: espadrine_ (~ttyl@AMontsouris-158-1-16-154.w92-128.abo.wanadoo.fr) (Read error: Connection timed out)
  534. # [10:04] * Joins: espadrine_ (~ttyl@AMontsouris-158-1-16-154.w92-128.abo.wanadoo.fr)
  535. # [10:06] <annevk> Domenic: TabAtkins: hmm yeah I guess you have to queue a task, seems somewhat sad it cannot be done in that microtask that's already happening anyway
  536. # [10:12] * Joins: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl)
  537. # [10:14] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  538. # [10:15] * Quits: Streusel (~Anonymous@unaffiliated/streusel) (Quit: Computer has gone to sleep.)
  539. # [10:17] * Quits: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl) (Ping timeout: 252 seconds)
  540. # [10:18] <foolip> annevk: the path to icons is wrong now in e.g. http://html5.org/r/6551
  541. # [10:19] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 255 seconds)
  542. # [10:23] * Quits: jdaggett (~jdaggett@61-121-216-2.bitcat.net) (Quit: jdaggett)
  543. # [10:23] <annevk> foolip: fixed
  544. # [10:26] * Joins: Garbee (uid21171@gateway/web/irccloud.com/x-nwoksmxreoyfbrny)
  545. # [10:29] <annevk> After a little over three years https://github.com/whatwg/dom/commit/9c2833fe3833d709dd9d66c985131528ff1bd966 it seems we are finally getting to the point where the "Core" part of DOM Level 3 Events is finally made obsolete https://www.w3.org/Bugs/Public/show_bug.cgi?id=25485#c5
  546. # [10:38] <MikeSmith> hayato: two of the shadow-dom testing PRs at https://github.com/w3c/web-platform-tests/pulls/iseki-masaya have been awaiting review for a couple of months now
  547. # [10:41] <hayato> MikeSmith: Let me review those. Thanks for letting me know that.
  548. # [10:41] <MikeSmith> hayato: thanks much
  549. # [10:43] <MikeSmith> hayato: btw the submitter of those two PRs didn't respond at all to the previous review comment you made on the third one, so I'm not sure it's super likely he'll respond on these. So don't sink a huge amount of time into it.
  550. # [10:45] <hayato> MikeSmith: I got it. Ill see to it. Thank you for your help.
  551. # [10:45] * Joins: darobin (~darobin@78.109.80.74)
  552. # [10:54] <foolip> annevk: thanks!
  553. # [11:00] <annevk> jungkees: thanks for working on the hooks, will review in a bit
  554. # [11:01] <jungkees> annevk: thanks!
  555. # [11:02] <annevk> jungkees: btw, started working on this: http://fetch.spec.whatwg.org/#fetch-api
  556. # [11:03] <jungkees> annevk: I've seen that and will follow on it
  557. # [11:04] <annevk> jungkees: btw, please make it clear somehow that the Cache API will be generic and needs to work in a document environment as well eventually
  558. # [11:04] <annevk> jungkees: was not clear to the person working on it in Gecko
  559. # [11:05] * Quits: jwalden (~waldo@c-50-168-55-219.hsd1.ca.comcast.net) (Quit: zzz)
  560. # [11:05] <jungkees> annevk: JakeA has better idea I think. AFAIK, we intended to enable that in document context during the dicussion
  561. # [11:06] <jungkees> annevk: not for V1 I guess
  562. # [11:07] <annevk> jungkees: JakeA: yeah, but there should at least be a note to that effect
  563. # [11:07] <JakeA> annevk: same for fetch()?
  564. # [11:12] * Quits: Ms2ger (~Ms2ger@25.208-64-87.adsl-dyn.isp.belgacom.be) (Quit: bbl)
  565. # [11:12] <annevk> JakeA: in Fetch I defined fetch() as being exposed as window.fetch()
  566. # [11:13] <JakeA> ahh cool
  567. # [11:13] <annevk> JakeA: we'll see what implementations say
  568. # [11:13] * Joins: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl)
  569. # [11:15] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  570. # [11:18] * Quits: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl) (Ping timeout: 258 seconds)
  571. # [11:19] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 255 seconds)
  572. # [11:40] * Quits: BigBangUDR (~Thunderbi@220.225.242.27) (Quit: BigBangUDR)
  573. # [11:43] * Joins: mpt (mpt@canonical/mpt)
  574. # [12:03] <annevk> TabAtkins: your guide looks good, might want to coordinate or link to Domenic's version here https://github.com/w3ctag/promises-guide
  575. # [12:05] * Quits: Kolombiken (~Adium@gateway.creuna.se) (Ping timeout: 276 seconds)
  576. # [12:08] * Joins: BigBangUDR (~Thunderbi@220.225.242.27)
  577. # [12:16] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  578. # [12:21] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 255 seconds)
  579. # [12:28] * Joins: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi)
  580. # [12:31] * Quits: mpt (mpt@canonical/mpt) (Ping timeout: 265 seconds)
  581. # [12:39] * Quits: cbiesinger (sid8099@gateway/web/irccloud.com/x-kqkdolpnpfciqzkc) (Ping timeout: 245 seconds)
  582. # [12:39] * Quits: jungkees (uid24208@gateway/web/irccloud.com/x-nwxtqoblwrvljzsa) (Ping timeout: 252 seconds)
  583. # [12:39] * Quits: hdv (sid2376@gateway/web/irccloud.com/x-ajzjsypoiyrjjfls) (Ping timeout: 252 seconds)
  584. # [12:39] * Quits: Garbee (uid21171@gateway/web/irccloud.com/x-nwoksmxreoyfbrny) (Ping timeout: 245 seconds)
  585. # [12:40] * Joins: cbiesinger (sid8099@gateway/web/irccloud.com/x-idzrsfiqjljkkonp)
  586. # [12:40] * Joins: jungkees (uid24208@gateway/web/irccloud.com/x-viwwbsnaxupvxiiq)
  587. # [12:41] * Quits: systematik (~nick@thunder.nickmerrill.co) (Ping timeout: 252 seconds)
  588. # [12:41] * Joins: systematik (~nick@thunder.nickmerrill.co)
  589. # [12:41] * Joins: Garbee (uid21171@gateway/web/irccloud.com/x-pkqnyulmuayqvfer)
  590. # [12:41] * Joins: hdv (sid2376@gateway/web/irccloud.com/x-xfidrxzsqmrifmge)
  591. # [12:45] * Joins: adactio (~adactio@212.42.170.121)
  592. # [12:55] * Joins: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95)
  593. # [13:05] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  594. # [13:06] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
  595. # [13:06] <jgraham> zcorpan, foolip: Thanks for the help with the WebVTT issues
  596. # [13:06] <foolip> jgraham: np!
  597. # [13:13] * Quits: plutoniix (~plutoniix@210.213.57.70) (Quit: จรลี จรลา)
  598. # [13:14] <krit> zcorpan: added examples and notes http://dev.w3.org/fxtf/geometry/#DOMQuad
  599. # [13:14] <zcorpan> krit: ok cool. i don't have time to review today, though :-(
  600. # [13:15] * Joins: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl)
  601. # [13:20] * Quits: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl) (Ping timeout: 264 seconds)
  602. # [13:21] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
  603. # [13:25] * Joins: Kolombiken (~Adium@gateway.creuna.se)
  604. # [13:27] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Ping timeout: 255 seconds)
  605. # [13:35] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
  606. # [13:44] * Joins: felipedefarias (~felipedef@189-19-85-225.dsl.telesp.net.br)
  607. # [13:46] * Joins: barnabywalters (~barnabywa@89.17.128.127)
  608. # [13:46] * Quits: jungkees (uid24208@gateway/web/irccloud.com/x-viwwbsnaxupvxiiq) (Quit: Connection closed for inactivity)
  609. # [13:50] * Quits: rcombs (~rcombs@rcombs.me) (Read error: Connection reset by peer)
  610. # [13:51] * Joins: Lachy_ (~Lachy@213.166.174.2)
  611. # [13:51] * Quits: Lachy (~Lachy@213.166.174.2) (Read error: Connection reset by peer)
  612. # [13:53] * Joins: rcombs (~rcombs@rcombs.me)
  613. # [13:59] * Joins: newtron (~newtron@199.71.174.203)
  614. # [14:11] * Quits: dshwang (~dshwang@134.134.139.70) (Remote host closed the connection)
  615. # [14:12] * Joins: tj_vantoll (~Adium@2601:4:5380:eba:897d:7ae:7419:bed1)
  616. # [14:13] * Joins: dshwang (~dshwang@134.134.139.70)
  617. # [14:13] * Krinkle|detached is now known as Krinkle
  618. # [14:15] * Joins: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl)
  619. # [14:16] * Quits: BigBangUDR (~Thunderbi@220.225.242.27) (Quit: BigBangUDR)
  620. # [14:18] * Joins: mpt (mpt@conference/canonical/x-iiobwrhkhyeoufjf)
  621. # [14:18] * Quits: mpt (mpt@conference/canonical/x-iiobwrhkhyeoufjf) (Changing host)
  622. # [14:18] * Joins: mpt (mpt@canonical/mpt)
  623. # [14:20] * Quits: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl) (Ping timeout: 240 seconds)
  624. # [14:23] * Joins: jdaggett (~jdaggett@q023013.dynamic.ppp.asahi-net.or.jp)
  625. # [14:40] * Quits: mpt (mpt@canonical/mpt) (Ping timeout: 240 seconds)
  626. # [14:42] * Quits: felipedefarias (~felipedef@189-19-85-225.dsl.telesp.net.br) (Remote host closed the connection)
  627. # [14:46] * Joins: lerc (~quassel@121-74-2-8.telstraclear.net)
  628. # [14:46] * Quits: lerc_ (~quassel@121-74-2-8.telstraclear.net) (Ping timeout: 252 seconds)
  629. # [14:48] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  630. # [15:00] * Joins: BigBangUDR (~Thunderbi@101.56.14.114)
  631. # [15:00] * Quits: BigBangUDR (~Thunderbi@101.56.14.114) (Client Quit)
  632. # [15:04] * Quits: eric_carlson (~eric@17.202.43.125) (Remote host closed the connection)
  633. # [15:08] * Quits: barnabywalters (~barnabywa@89.17.128.127) (Quit: barnabywalters)
  634. # [15:11] * Joins: eric_carlson (~eric@17.202.43.125)
  635. # [15:16] * Joins: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl)
  636. # [15:16] * Joins: barnabywalters (~barnabywa@89.17.128.127)
  637. # [15:17] * Quits: barnabywalters (~barnabywa@89.17.128.127) (Client Quit)
  638. # [15:21] * Quits: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl) (Ping timeout: 255 seconds)
  639. # [15:21] * Joins: mpt (mpt@conference/canonical/x-uzvqyeyzwudyibru)
  640. # [15:21] * Quits: mpt (mpt@conference/canonical/x-uzvqyeyzwudyibru) (Changing host)
  641. # [15:21] * Joins: mpt (mpt@canonical/mpt)
  642. # [15:25] <zcorpan> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25894 ... so .... people expecting their feedback to go to /dev/null might explain some of the junk bugs we get
  643. # [15:27] * Parts: juliangruber (~juliangru@37.153.99.230) ("Textual IRC Client: www.textualapp.com")
  644. # [15:27] <zcorpan> Hixie: maybe s/Submit Review Comment/Submit Bugzilla Issue/ ?
  645. # [15:28] <zcorpan> or just "Report bug" maybe
  646. # [15:28] <annevk> If that guy had a million discussions about charset, he didn't learn much from it :/
  647. # [15:28] <annevk> Or gal, I guess
  648. # [15:29] * Joins: izhak (~izhak@92.248.142.152)
  649. # [15:32] * Joins: TallTed (~Thud@63.119.36.36)
  650. # [15:33] * Quits: inimino (~inimino@oftn/board/inimino) (Ping timeout: 252 seconds)
  651. # [15:46] * Joins: inimino (~inimino@oftn/board/inimino)
  652. # [15:48] * Joins: plutoniix (~plutoniix@node-4fd.pool-125-25.dynamic.totbb.net)
  653. # [15:55] * Joins: ehynds (~ehynds@64.206.121.41)
  654. # [15:58] * Joins: barnabywalters (~barnabywa@89.17.128.127)
  655. # [16:01] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Remote host closed the connection)
  656. # [16:02] * Quits: mpt (mpt@canonical/mpt) (Ping timeout: 252 seconds)
  657. # [16:13] * Quits: markkes (~markkes@62.207.90.201) (Quit: Nettalk6 - www.ntalk.de)
  658. # [16:15] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
  659. # [16:16] * Joins: BigBangUDR (~Thunderbi@101.56.163.33)
  660. # [16:24] * Joins: mpt (mpt@conference/canonical/x-myunfwqtosqskgmx)
  661. # [16:24] <caitp> they seem upset
  662. # [16:25] * Quits: mpt (mpt@conference/canonical/x-myunfwqtosqskgmx) (Changing host)
  663. # [16:25] * Joins: mpt (mpt@canonical/mpt)
  664. # [16:26] * Quits: BigBangUDR (~Thunderbi@101.56.163.33) (Quit: BigBangUDR)
  665. # [16:29] <annevk> caitp: so is plural the preferred form? seems so weird
  666. # [16:30] <caitp> ¯\_(ツ)_/
  667. # [16:32] * Quits: lmclister (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  668. # [16:37] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
  669. # [16:39] * Quits: mven (~textual@ip68-104-38-84.lv.lv.cox.net) (Ping timeout: 265 seconds)
  670. # [16:53] <TabAtkins> annevk: Except for the part where I said "dunno lol, ask Anne", of course.
  671. # [16:54] <annevk> TabAtkins: yeah so it seems like you might have to queue a task, except that seems somewhat sad since a microtask would happen for the promise already (if there's listeners)
  672. # [16:55] <annevk> TabAtkins: maybe Hixie or Domenic has some thoughts on that
  673. # [16:55] <TabAtkins> Right, if you could align with the promise's microtask it would be nice.
  674. # [16:55] <annevk> Queuing a task would do that btw, it's just not as "quick"
  675. # [16:56] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: :tiuQ tiuq sah woclrak)
  676. # [16:56] * Joins: karlcow (~karl@nerval.la-grange.net)
  677. # [16:58] <TabAtkins> Because it's technically two tasks?
  678. # [17:02] <annevk> TabAtkins: because it happens later (e.g. if there's a bunch of other stuff queued)
  679. # [17:02] <annevk> TabAtkins: but that might be okay, the other stuff might be more important
  680. # [17:03] <TabAtkins> Eh, doesn't matter all that much. It's async already, so the exact point in time when the info change becomes visible isn't that important, as long as it happens before promise resolution.
  681. # [17:03] <TabAtkins> So the language is just "queue a (micro?)task to XXX" in the middle of an algo step?
  682. # [17:07] * Joins: marcosc (~marcosc@66.207.208.102)
  683. # [17:08] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  684. # [17:10] <annevk> TabAtkins: queue a task to set status and resolve promise to y I suppose
  685. # [17:10] * Joins: BigBangUDR (~Thunderbi@101.56.163.33)
  686. # [17:10] * Quits: BigBangUDR (~Thunderbi@101.56.163.33) (Client Quit)
  687. # [17:11] <annevk> TabAtkins: note that I still think changing status without having a way to get notified about that is bad, better to leave it unchanged in that case
  688. # [17:12] <TabAtkins> Hm, ok. So just resolving promise normally (no task language) is fine when nothing else accompanies it, but for clarity you should resolve it in the same task that you're setting observable state in, if you're doing so.
  689. # [17:14] <annevk> TabAtkins: otherwise promise observers would get called before the state was changed
  690. # [17:14] <TabAtkins> Oh, because of the task/microtask distinction?
  691. # [17:14] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Ping timeout: 240 seconds)
  692. # [17:15] <annevk> Yes, promise thing would happen end-of-current task, whatever that is, and state thing would at best happen next-task
  693. # [17:15] * Joins: tantek (~tantek@70-36-139-254.dsl.dynamic.sonic.net)
  694. # [17:16] <TabAtkins> Okay. And it's a no-no to explicitly invoke microtasks in async algos, because those are reserved for only a handful of things?
  695. # [17:16] * Quits: mven_ (~mven@169.241.49.57) (Quit: Leaving)
  696. # [17:18] * Joins: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl)
  697. # [17:18] <annevk> TabAtkins: it seems like these days you could queue a microtask
  698. # [17:18] <annevk> TabAtkins: I'd like to know what Hixie thinks about using that
  699. # [17:20] * Quits: jdaggett (~jdaggett@q023013.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
  700. # [17:22] * Joins: mven (~mven@169.241.49.57)
  701. # [17:22] * Quits: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl) (Ping timeout: 240 seconds)
  702. # [17:22] <TabAtkins> That would let me make the state change without delaying promise resolution until the next task
  703. # [17:23] <TabAtkins> Either way maintains the necessary ordering, but resolving the promise on a task is obviously slower.
  704. # [17:24] <JonathanNeal> Is there a polyfill for Element.prototype.queryAll?
  705. # [17:26] <annevk> TabAtkins: it's later, might not be slower overall
  706. # [17:26] * Quits: TallTed (~Thud@63.119.36.36) (Remote host closed the connection)
  707. # [17:28] * Quits: Lachy_ (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  708. # [17:29] * Joins: Lachy (~Lachy@213.166.174.2)
  709. # [17:29] <TabAtkins> annevk: Yeah, but chaining "later" multiple times is slower.
  710. # [17:29] <TabAtkins> JonathanNeal: jQuery
  711. # [17:30] <JonathanNeal> TabAtkins: one of those days, huh. :-)
  712. # [17:30] <annevk> TabAtkins: example?
  713. # [17:31] <TabAtkins> JonathanNeal: Being serious. Jq's .find is our .query all.
  714. # [17:31] * Quits: Lachy (~Lachy@213.166.174.2) (Client Quit)
  715. # [17:32] <TabAtkins> annevk: If you're gonna kick off more async requests, you want those as soon as possible
  716. # [17:32] <TabAtkins> On the other hand, you might be kicking off async requests from event handlers too
  717. # [17:32] * Quits: ImBcmDth (~Jon@oftn/member/ImBcmDth) (Ping timeout: 252 seconds)
  718. # [17:32] <TabAtkins> So I guess it doesn't actually matter.
  719. # [17:35] * Quits: richt (~richt@83.218.67.123) (Remote host closed the connection)
  720. # [17:39] * Joins: lmclister (~lmclister@sjfw1.adobe.com)
  721. # [17:41] * Joins: TheGallery (~TheGaller@athedsl-212130.home.otenet.gr)
  722. # [17:43] <Hixie> TabAtkins, annevk: i'm here, not sure i understand the discussion above though (missing some context?)
  723. # [17:44] <TabAtkins> Hixie: I have an algo with an async section...
  724. # [17:44] <TabAtkins> Hixie: In it, I need to make some author-visible state change (set a FontFace's status attribute to "loaded"), and then resolve a promise.
  725. # [17:44] * Joins: Lachy (~Lachy@213.166.174.2)
  726. # [17:44] <TabAtkins> Hixie: I think I need to queue a task to do the attribute setting, so it happens at a well-defined time.
  727. # [17:45] <TabAtkins> Hixie: And I should probably also resolve the promise in the task, so there's a well-defined ordering between attribute-set and promise-resolve.
  728. # [17:45] <Hixie> ideally you'd make it happen in the same microtask as the promise is resolved in
  729. # [17:45] <TabAtkins> Hixie: But should I do those operations in a task or a microtask?
  730. # [17:45] <Hixie> er
  731. # [17:45] <Hixie> as the promise callback is called in
  732. # [17:45] <TabAtkins> Yeah, kk. (I was about to correct your terminology. ^_^)
  733. # [17:46] <Hixie> but failing that, this seems like the kind of thing i would use "await a stable state" for
  734. # [17:46] <TabAtkins> So it ideally happens in the same microtask as promise callbacks, before the callbacks are called. I don't think we have prose hooks for that.
  735. # [17:46] <TabAtkins> Hm, interesting.
  736. # [17:46] <Hixie> that lets you build the algorithm pretty neatly, but in the background it's just built with microtasks
  737. # [17:47] <Hixie> basically it lets you designate a set of steps that execute as a microtask while the rest of the algorithm is async
  738. # [17:47] <Hixie> a bit like a synchronised section
  739. # [17:47] <TabAtkins> Example in a spec?
  740. # [17:48] <Hixie> one sec
  741. # [17:48] <Hixie> search for "Failed with elements: Queue a task to fire a simple"
  742. # [17:49] <Hixie> and look at steps 10-20 below that
  743. # [17:50] <TabAtkins> Urg, I gotta load single-page for that. kk.
  744. # [17:50] <Hixie> one sec
  745. # [17:50] <Hixie> i can give you the multipage link
  746. # [17:50] <TabAtkins> Would be nice, since I'm tethering my internet right now.
  747. # [17:50] <Hixie> it's in http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#concept-media-load-algorithm
  748. # [17:51] * Quits: Lachy (~Lachy@213.166.174.2) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  749. # [17:51] <Hixie> but ignore the first occurance of stable-state in that algorithm and look for the one i mentioned earlier
  750. # [17:51] <Hixie> because the first one does a confusing fork in the middle of the stable state
  751. # [17:51] <Hixie> and that obscures the point i'm trying to make :-)
  752. # [17:52] <TabAtkins> Okay, cool. I'll recommend using a nested list for that, rather than unicode characters, but this works. ^_^
  753. # [17:53] <Hixie> well the unicode characters are non-normative
  754. # [17:53] <Hixie> they just make it more obvious where the synchronisation starts and ends
  755. # [17:53] <Hixie> (i recommend being typographically consistent for the readers' benefit)
  756. # [17:54] <Hixie> but sure, it could also be described as a set of steps in a sublist
  757. # [17:54] <TabAtkins> So I think I'd go "Asynchronously await a stable state, then execute the following steps synchronously: <nested-list>".
  758. # [17:55] <TabAtkins> Where <nested-list> is "1. Set font face's status attribute to "loading". 2. Accept the promise with font face.".
  759. # [17:56] * Joins: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net)
  760. # [17:59] <Hixie> make sure if this isn't the end of the algorithm that you also have the "3. Resume the rest of the algorithm asynchronously."
  761. # [18:00] * Joins: ehsan (~ehsan@66.207.208.102)
  762. # [18:00] <TabAtkins> Isn't that implied by the end of the list?
  763. # [18:00] <Hixie> someone filed a bug asked for me to spec focusin/focusout, so I filed a bug on a browser asking if we could maybe remove them instead, and the end result is that now I might have to also spec DOMFocusIn/DOMFocusOut. wtf.
  764. # [18:01] <Hixie> TabAtkins: as currently written, no
  765. # [18:01] <Hixie> TabAtkins: (because don't forget, in my case i don't have a nested list)
  766. # [18:01] <TabAtkins> I know that in your case you don't.
  767. # [18:01] <TabAtkins> I suppose being clear about things is fine. Just trying to reduce boilerplate to a minimum.
  768. # [18:02] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
  769. # [18:02] * Quits: mpt (mpt@canonical/mpt) (Ping timeout: 252 seconds)
  770. # [18:05] <Hixie> understood
  771. # [18:05] <Hixie> i think synchronous sections are confusing enough that being overtly explicit each time is probably reasonable
  772. # [18:05] * Joins: jsbell (jsbell@nat/google/x-tfbdksikvsshkdmf)
  773. # [18:05] * Joins: bholley (~bholley@c-67-161-57-5.hsd1.ca.comcast.net)
  774. # [18:06] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 258 seconds)
  775. # [18:08] * Parts: adactio (~adactio@212.42.170.121)
  776. # [18:10] <annevk> Hixie: focus :-(
  777. # [18:13] * Joins: jeffreyatw (~jeffreyat@66-194-1-26.STATIC.twtelecom.net)
  778. # [18:14] <annevk> Also, recent emails on UI events :-(
  779. # [18:14] <annevk> "We'll just augment that other spec"
  780. # [18:20] * Joins: Maurice` (copyman@5ED5617C.cm-7-6b.dynamic.ziggo.nl)
  781. # [18:21] * Quits: darobin (~darobin@78.109.80.74) (Remote host closed the connection)
  782. # [18:22] <annevk> Hixie: you still around? Should we talk about cleanup now?
  783. # [18:24] * Joins: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi)
  784. # [18:25] * Quits: TheGallery (~TheGaller@athedsl-212130.home.otenet.gr) (Quit: Leaving)
  785. # [18:28] * Joins: BigBangUDR (~Thunderbi@101.56.24.137)
  786. # [18:29] * Joins: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net)
  787. # [18:29] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Quit: Reconnecting…)
  788. # [18:30] * Joins: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi)
  789. # [18:30] * Quits: barnabywalters (~barnabywa@89.17.128.127) (Quit: barnabywalters)
  790. # [18:30] * Quits: zaal (~zaal@cpc65346-nrwh11-2-0-cust48.4-4.cable.virginm.net) (Ping timeout: 258 seconds)
  791. # [18:32] * Joins: felipedefarias (~felipedef@189-19-85-225.dsl.telesp.net.br)
  792. # [18:33] * Joins: zaal (~zaal@cpc65346-nrwh11-2-0-cust48.4-4.cable.virginm.net)
  793. # [18:37] * Joins: TallTed (~Thud@63.119.36.36)
  794. # [18:38] * Quits: bholley (~bholley@c-67-161-57-5.hsd1.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  795. # [18:38] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  796. # [18:39] * Joins: Ms2ger (~Ms2ger@25.208-64-87.adsl-dyn.isp.belgacom.be)
  797. # [18:39] * Quits: BigBangUDR (~Thunderbi@101.56.24.137) (Quit: BigBangUDR)
  798. # [18:40] * Joins: llkats (~llkats@50.141.87.3)
  799. # [18:40] * Quits: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi) (Ping timeout: 265 seconds)
  800. # [18:41] * Joins: r2 (~r2@66.94.71.3)
  801. # [18:50] * Quits: llkats (~llkats@50.141.87.3) (Read error: Connection reset by peer)
  802. # [18:50] * Quits: estellevw (~estellevw@173-228-112-232.dsl.dynamic.sonic.net) (Quit: Snuggling with the puppies)
  803. # [18:52] * Joins: llkats (~llkats@50.141.87.3)
  804. # [18:53] * Joins: jeremyj (~jeremyj@17.202.44.231)
  805. # [19:02] * Krinkle is now known as Krinkle|detached
  806. # [19:18] * Quits: othermaciej (~mjs@c-50-136-134-16.hsd1.ca.comcast.net) (Quit: othermaciej)
  807. # [19:19] * Joins: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl)
  808. # [19:20] * Joins: llkats_ (~llkats@50.141.87.3)
  809. # [19:21] * Joins: ambv (~ambv@206.108.217.134)
  810. # [19:22] * Quits: llkats (~llkats@50.141.87.3) (Ping timeout: 240 seconds)
  811. # [19:24] * Quits: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl) (Ping timeout: 265 seconds)
  812. # [19:24] * Krinkle|detached is now known as Krinkle
  813. # [19:29] * Quits: gungan_fuq (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com) (Ping timeout: 252 seconds)
  814. # [19:29] * Joins: estellevw (~estellevw@209.49.73.82)
  815. # [19:30] * Quits: bnicholson2 (~bnicholso@24.130.57.109) (Ping timeout: 245 seconds)
  816. # [19:34] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  817. # [19:35] * Quits: llkats_ (~llkats@50.141.87.3) (Read error: Connection reset by peer)
  818. # [19:36] * Joins: othermaciej (~mjs@76.74.153.49)
  819. # [19:36] * Joins: llkats (~llkats@50.141.87.3)
  820. # [19:48] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  821. # [19:51] <Hixie> annevk: i've got some time this afternoon, but right now is poor
  822. # [19:53] * Joins: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl)
  823. # [19:53] * Quits: tj_vantoll (~Adium@2601:4:5380:eba:897d:7ae:7419:bed1) (Quit: Leaving.)
  824. # [19:54] * Joins: bholley (~bholley@98.210.101.88)
  825. # [19:55] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  826. # [19:55] * Quits: llkats (~llkats@50.141.87.3) (Read error: Connection reset by peer)
  827. # [19:56] * Joins: llkats (~llkats@50.141.87.3)
  828. # [19:56] * Joins: bnicholson2 (~bnicholso@corp.mtv2.mozilla.com)
  829. # [19:57] * Quits: espadrine_ (~ttyl@AMontsouris-158-1-16-154.w92-128.abo.wanadoo.fr) (Ping timeout: 240 seconds)
  830. # [19:58] * Joins: tj_vantoll (~Adium@c-98-250-130-237.hsd1.mi.comcast.net)
  831. # [20:02] * Quits: dbaron (~dbaron@50-0-248-164.dsl.dynamic.sonic.net) (Ping timeout: 252 seconds)
  832. # [20:03] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
  833. # [20:05] * Joins: jwalden (~waldo@corp.mtv2.mozilla.com)
  834. # [20:07] * Joins: ^esc (~esc-ape@77.119.129.217.wireless.dyn.drei.com)
  835. # [20:07] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 245 seconds)
  836. # [20:09] * Quits: ^esc_ (~esc-ape@178.115.131.222.wireless.dyn.drei.com) (Ping timeout: 252 seconds)
  837. # [20:10] * Joins: espadrine_ (~ttyl@AMontsouris-158-1-15-152.w92-128.abo.wanadoo.fr)
  838. # [20:11] * Joins: Smylers (~smylers@host86-156-211-5.range86-156.btcentralplus.com)
  839. # [20:11] * Joins: jeremyj (~jeremyj@17.202.44.231)
  840. # [20:14] * Joins: jernoble|laptop (~jernoble@17.202.45.163)
  841. # [20:23] <estellevw> Is Emotion Markup Language (http://www.w3.org/TR/2014/REC-emotionml-20140522/) something that might be brought into html?
  842. # [20:23] * Quits: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com) (Ping timeout: 240 seconds)
  843. # [20:25] * Quits: jeffreyatw (~jeffreyat@66-194-1-26.STATIC.twtelecom.net) (Quit: jeffreyatw)
  844. # [20:25] <Hixie> estellevw: what's the use case?
  845. # [20:25] <Hixie> estellevw: are any browsers interested in implementing it?
  846. # [20:25] * Quits: llkats (~llkats@50.141.87.3) (Read error: Connection reset by peer)
  847. # [20:25] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
  848. # [20:26] <estellevw> i don't have one. I was basically wondering if it's something anyone cares about and if I should spend brain cells on it
  849. # [20:26] <estellevw> but if no one has even heard about it, the answer would be no
  850. # [20:26] <estellevw> at least at this time
  851. # [20:26] * Joins: llkats (~llkats@50.141.87.3)
  852. # [20:27] <Hixie> i've only heard of it in the context of jokes...
  853. # [20:29] * Quits: lmclister (~lmclister@sjfw1.adobe.com)
  854. # [20:30] <estellevw> ok, thanks. I thought it might be a joke, but too much effort seemed to have been put in it for it to be one, and the date wasn't April 1
  855. # [20:34] <Hixie> oh i'm sure it was not intended as a joke
  856. # [20:34] * Joins: caitp (~caitp@CPE48f8b385c01c-CM602ad06daeed.cpe.net.cable.rogers.com)
  857. # [20:34] <Hixie> not clear what it's relationship to the web is though, even though it happened at the w3c
  858. # [20:39] * Quits: othermaciej (~mjs@76.74.153.49) (Quit: othermaciej)
  859. # [20:47] * Joins: barnabywalters (~barnabywa@89.17.128.127)
  860. # [20:51] * Krinkle is now known as Krinkle|detached
  861. # [20:53] * Joins: zdobersek (~zan@109.201.154.190)
  862. # [20:53] * Quits: abinader (sid21713@gateway/web/irccloud.com/x-unythathyxpzznve)
  863. # [20:54] * Joins: jacobolus (~jacobolus@199-241-200-88.PUBLIC.monkeybrains.net)
  864. # [20:54] * Joins: lmclister (~lmclister@sjfw1.adobe.com)
  865. # [20:55] * Joins: dcherman2 (~dcherman@164.55.254.106)
  866. # [20:55] * Quits: zdobersek (~zan@109.201.154.190) (Client Quit)
  867. # [20:56] * Joins: dbaron (~dbaron@corp-nat.p2p.sfo1.mozilla.com)
  868. # [20:59] * Joins: othermaciej (~mjs@17.245.31.110)
  869. # [20:59] * Quits: llkats (~llkats@50.141.87.3) (Ping timeout: 240 seconds)
  870. # [20:59] * Joins: llkats (~llkats@50.141.87.3)
  871. # [20:59] * Joins: darobin (~darobin@2a01:e34:ed05:d180:78b0:98d1:66af:cfa6)
  872. # [21:00] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  873. # [21:19] * Quits: llkats (~llkats@50.141.87.3) (Read error: Connection reset by peer)
  874. # [21:19] * Joins: llkats (~llkats@50.141.87.3)
  875. # [21:21] * Joins: richt (~richt@c83-248-137-176.bredband.comhem.se)
  876. # [21:23] * Krinkle|detached is now known as Krinkle
  877. # [21:26] * Quits: bholley (~bholley@98.210.101.88) (Read error: Connection reset by peer)
  878. # [21:26] * Joins: bholley_ (~bholley@98.210.101.88)
  879. # [21:29] <annevk> *-Star
  880. # [21:29] <annevk> Oh wrong, WS-*
  881. # [21:31] * Joins: richt_ (~richt@c83-248-137-176.bredband.comhem.se)
  882. # [21:31] * Quits: richt (~richt@c83-248-137-176.bredband.comhem.se) (Read error: Connection reset by peer)
  883. # [21:32] * Quits: othermaciej (~mjs@17.245.31.110) (Quit: othermaciej)
  884. # [21:33] * Quits: jernoble|laptop (~jernoble@17.202.45.163) (Quit: Textual IRC Client: www.textualapp.com)
  885. # [21:35] * Quits: richt_ (~richt@c83-248-137-176.bredband.comhem.se) (Client Quit)
  886. # [21:36] * Joins: othermaciej (~mjs@17.245.31.110)
  887. # [21:37] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
  888. # [21:38] * Quits: darobin (~darobin@2a01:e34:ed05:d180:78b0:98d1:66af:cfa6) (Quit: Leaving...)
  889. # [21:42] * Quits: llkats (~llkats@50.141.87.3) (Read error: Connection reset by peer)
  890. # [21:44] * Joins: llkats (~llkats@50.141.87.3)
  891. # [21:44] * Quits: izhak (~izhak@92.248.142.152) (Ping timeout: 255 seconds)
  892. # [21:44] * Joins: rniwa (~rniwa@17.202.43.222)
  893. # [21:44] * Joins: weinig (~weinig@17.114.218.140)
  894. # [21:45] * Quits: othermaciej (~mjs@17.245.31.110) (Remote host closed the connection)
  895. # [21:45] * Joins: cheron (~cheron@unaffiliated/cheron)
  896. # [21:45] * Joins: othermaciej (~mjs@17.245.31.110)
  897. # [21:47] * Joins: jeffreyatw (~jeffreyat@173.247.197.10)
  898. # [21:49] * Joins: annevk_ (~annevk@77-57-114-66.dclient.hispeed.ch)
  899. # [21:49] * Quits: annevk (~annevk@77-57-114-66.dclient.hispeed.ch) (Read error: Connection reset by peer)
  900. # [21:49] * Quits: cheron (~cheron@unaffiliated/cheron) (Ping timeout: 252 seconds)
  901. # [21:52] * Joins: smaug____ (~chatzilla@a91-154-44-207.elisa-laajakaista.fi)
  902. # [21:56] * Quits: barnabywalters (~barnabywa@89.17.128.127) (Quit: barnabywalters)
  903. # [21:59] <SamB> emotionml sounds like a *very* strange idea
  904. # [21:59] * Joins: othermaciej_ (~mjs@17.114.217.119)
  905. # [21:59] <caitp> well you need a way to convey <sarcasm />
  906. # [21:59] * Quits: Ms2ger (~Ms2ger@25.208-64-87.adsl-dyn.isp.belgacom.be) (Quit: nn)
  907. # [22:00] * Quits: othermaciej (~mjs@17.245.31.110) (Ping timeout: 252 seconds)
  908. # [22:00] * othermaciej_ is now known as othermaciej
  909. # [22:02] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
  910. # [22:05] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
  911. # [22:05] * Joins: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com)
  912. # [22:05] * Joins: japhet (sid20626@gateway/web/irccloud.com/x-imqpezjillcnlpta)
  913. # [22:06] * Joins: morewry_ (~morewry@c-76-103-214-98.hsd1.ca.comcast.net)
  914. # [22:07] * Quits: llkats (~llkats@50.141.87.3) (Ping timeout: 276 seconds)
  915. # [22:08] * Joins: llkats (~llkats@50.141.87.3)
  916. # [22:08] * Quits: jensnockert (~jensnocke@dynamic.1.7.34dbfd722180.e0f8471ae7fa.afb.bredband2.com) (Ping timeout: 252 seconds)
  917. # [22:09] <japhet> i looked for this in the spec, but maybe i missed it.....if a document is loaded via POST, then navigates to a fragment identifier, then a reloaded is triggered, should the resulting request be a GET or a POST?
  918. # [22:09] * Quits: bholley_ (~bholley@98.210.101.88) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  919. # [22:10] <japhet> the behavior is explicitly state to be GET for pushState and replaceState, but i didn't see anything for fragment identifiers
  920. # [22:11] * Quits: morewry (~morewry@c-76-103-214-98.hsd1.ca.comcast.net) (Ping timeout: 258 seconds)
  921. # [22:13] * Quits: KevinMarks_ (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net) (Remote host closed the connection)
  922. # [22:14] * Joins: emerson (~emerson@emersonveenstra.com)
  923. # [22:14] * Joins: KevinMarks (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net)
  924. # [22:14] * Joins: jeremyj (~jeremyj@17.202.44.231)
  925. # [22:14] * Joins: gungan_fuq (~encryptd_@68-112-125-21.dhcp.stcd.mn.charter.com)
  926. # [22:16] * Quits: weinig (~weinig@17.114.218.140) (Quit: weinig)
  927. # [22:27] * Krinkle is now known as Krinkle|detached
  928. # [22:27] * Joins: weinig (~weinig@17.114.218.140)
  929. # [22:27] * Quits: llkats (~llkats@50.141.87.3) (Read error: Connection reset by peer)
  930. # [22:28] * Krinkle|detached is now known as Krinkle
  931. # [22:30] <TabAtkins> japhet: You're not changing the resource, so I think it's still POST.
  932. # [22:30] <TabAtkins> annevk_:
  933. # [22:31] * Quits: tj_vantoll (~Adium@c-98-250-130-237.hsd1.mi.comcast.net) (Quit: Leaving.)
  934. # [22:31] <japhet> TabAtkins: that was my best guess, but I figured I should ask before arbitrarily changing blink
  935. # [22:31] <TabAtkins> Updated Font Loading to use the right async language, using language culled from Hixie. Review would be appreciated.
  936. # [22:31] <TabAtkins> japhet: Just guessing here, though. Dunno what the specs might say for it.
  937. # [22:31] * Quits: felipedefarias (~felipedef@189-19-85-225.dsl.telesp.net.br) (Remote host closed the connection)
  938. # [22:31] <TabAtkins> annevk_: Updated Font Loading to use the right async language, using language culled from Hixie. Review would be appreciated.
  939. # [22:33] * annevk_ is now known as annevk
  940. # [22:33] <annevk> TabAtkins: tomorrow ok?
  941. # [22:33] <TabAtkins> Yeah, no rush.
  942. # [22:34] <annevk> cool
  943. # [22:36] * Joins: newtron_ (~newtron@199.71.174.204)
  944. # [22:36] * Quits: othermaciej (~mjs@17.114.217.119) (Quit: othermaciej)
  945. # [22:36] <annevk> TabAtkins: oh, and just to be clear, tweet about standards is not aimed at you either :-)
  946. # [22:38] * Joins: othermaciej (~mjs@17.245.31.110)
  947. # [22:39] * Quits: newtron (~newtron@199.71.174.203) (Ping timeout: 240 seconds)
  948. # [22:40] * Quits: newtron_ (~newtron@199.71.174.204) (Ping timeout: 240 seconds)
  949. # [22:41] <TabAtkins> annevk: Hahaha, I knew that.
  950. # [22:53] <sgalineau> TabAkints: in bikeshed README, 'textual shortcuts for autolinks' link 404s for some reason
  951. # [22:53] <sgalineau> TabAtkins, even
  952. # [22:53] <TabAtkins> Weird, I'll check it out.
  953. # [22:54] <sgalineau> it is; the file is definitely there
  954. # [22:55] <TabAtkins> Man, that's been broken *forever*.
  955. # [22:55] <TabAtkins> Fixed now.
  956. # [22:55] <TabAtkins> Typo in the url.
  957. # [22:55] <TabAtkins> (Missing an "s" at the end of "definitions".)
  958. # [22:57] * Joins: othermaciej_ (~mjs@17.114.217.119)
  959. # [22:57] * Quits: othermaciej (~mjs@17.245.31.110) (Ping timeout: 258 seconds)
  960. # [22:57] * othermaciej_ is now known as othermaciej
  961. # [22:59] * Quits: weinig (~weinig@17.114.218.140) (Quit: weinig)
  962. # [22:59] * Quits: othermaciej (~mjs@17.114.217.119) (Client Quit)
  963. # [23:03] * Joins: weinig (~weinig@17.114.218.140)
  964. # [23:03] * Joins: othermaciej (~mjs@17.114.217.119)
  965. # [23:06] * Quits: weinig (~weinig@17.114.218.140) (Client Quit)
  966. # [23:11] * Quits: jeremyj (~jeremyj@17.202.44.231) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  967. # [23:12] * Joins: llkats (~llkats@50.141.87.3)
  968. # [23:18] <TabAtkins> annevk: Any objections to me working on Bikeshedding DOM for you?
  969. # [23:19] <annevk> TabAtkins: no sounds great
  970. # [23:19] * Quits: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95) (Quit: coolbot95)
  971. # [23:19] <annevk> TabAtkins: not sure about putting promise stuff in DOM though ;-)
  972. # [23:19] <annevk> TabAtkins: but that's also for tomorrow
  973. # [23:19] <TabAtkins> kk
  974. # [23:22] * Joins: abinader (sid21713@gateway/web/irccloud.com/x-fthlpjddihnvnqco)
  975. # [23:23] * Joins: coolbot95 (~coolbot95@gateway/tor-sasl/coolbot95)
  976. # [23:23] <Domenic> How did HTMLSpanElement come about? /cc Hixie
  977. # [23:23] <Domenic> annevk: I think if DOM defines #concept-throw, it can also define #concept-reject. Although I imagine you prefer to move both of those to WebIDL.
  978. # [23:24] <annevk> Domenic: I do
  979. # [23:25] <TabAtkins> Domenic: You mean like, the historical reasoning for adding the <span> element? Or actually the interface?
  980. # [23:26] <TabAtkins> annevk: I'm fine with both of them being in WebIDL too; all I care is that they both exist *somewhere*, and if putting reject in DOM is the fastest way to get it written down somewhere I can refer to, that's better.
  981. # [23:26] * Quits: TallTed (~Thud@63.119.36.36)
  982. # [23:27] * Quits: wiljanslofstra (~wiljanslo@cable-081-024-108-110.solcon.nl) (Remote host closed the connection)
  983. # [23:37] * Joins: jeremyj (~jeremyj@17.202.44.231)
  984. # [23:37] * Quits: jeremyj (~jeremyj@17.202.44.231) (Client Quit)
  985. # [23:39] * Quits: ehynds (~ehynds@64.206.121.41)
  986. # [23:42] * Joins: jeremyj (~jeremyj@17.202.44.231)
  987. # [23:43] * Quits: llkats (~llkats@50.141.87.3) (Read error: Connection reset by peer)
  988. # [23:44] * Joins: llkats (~llkats@50.141.87.3)
  989. # [23:46] * Joins: bholley (~bholley@corp-nat.p2p.sfo1.mozilla.com)
  990. # [23:48] <Hixie> MikeSmith: btw, i see 408s all the time with w3c bugzilla, but never anywhere else. so i do think it's something to do with w3c bugzilla.
  991. # [23:49] * silky__ is now known as malcolmva
  992. # [23:49] * Quits: bholley (~bholley@corp-nat.p2p.sfo1.mozilla.com) (Client Quit)
  993. # [23:51] * Joins: bholley (~bholley@corp-nat.p2p.sfo1.mozilla.com)
  994. # [23:54] * Joins: llkats_ (~llkats@50.141.87.3)
  995. # [23:56] * Quits: karlcow (~karl@nerval.la-grange.net) (Remote host closed the connection)
  996. # [23:56] * Joins: r2_ (~r2@181.16.14.134)
  997. # [23:57] * Joins: bentruyman_ (~bentruyma@23.252.119.254)
  998. # [23:59] * Quits: llkats_ (~llkats@50.141.87.3) (Read error: Connection reset by peer)
  999. # Session Close: Thu May 29 00:00:00 2014

The end :)