/irc-logs / freenode / #whatwg / 2013-10-10 / end

Options:

  1. # Session Start: Thu Oct 10 00:00:00 2013
  2. # Session Ident: #whatwg
  3. # [00:07] * Quits: alecf_ (~alecf@216.239.45.79) (Quit: alecf_)
  4. # [00:09] * Quits: TuRnaD0 (~Thunderbi@x1-6-e0-46-9a-1e-fe-ca.k368.webspeed.dk) (Quit: TuRnaD0)
  5. # [00:09] * Joins: tantek (~tantek@m9d2d36d0.tmodns.net)
  6. # [00:10] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Read error: Connection reset by peer)
  7. # [00:10] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  8. # [00:17] * Quits: encryptd_fractal (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Remote host closed the connection)
  9. # [00:27] <Domenic_> WeakMap => truly private state
  10. # [00:27] <Domenic_> Object.freeze throws in strict mode (which everyone should be using)
  11. # [00:28] * Joins: alecf_ (~alecf@216.239.45.79)
  12. # [00:28] <Domenic_> Without WeakMap it is impossible to have high-integrity objects in JS, like e.g. platform objects
  13. # [00:28] * Quits: bholley (~bholley@195-132-112-181.rev.numericable.fr) (Quit: bholley)
  14. # [00:31] * Joins: jreading (~Adium@ip98-169-193-48.dc.dc.cox.net)
  15. # [00:31] <Hixie_> what's the use case for high-integrity objects in JS?
  16. # [00:31] * Quits: rcombs (~rcombs@rcombs.me) (Ping timeout: 260 seconds)
  17. # [00:31] <Hixie_> i mean it sounds good and all, but it's not clear what the point is
  18. # [00:31] * Joins: rc0mbs (~rcombs@rcombs.me)
  19. # [00:31] <Hixie_> to me at least
  20. # [00:31] <TabAtkins> Explaining the platform, and introducing new things similar to the current platform.
  21. # [00:32] * rc0mbs is now known as rcombs
  22. # [00:32] <Hixie_> you can explain the platform without it, and you can introduce new things similar to the platform with it it too
  23. # [00:32] <Hixie_> we've been doing both for decades
  24. # [00:33] <TabAtkins> Different definition of "explaining", and no you can't, at least with sufficient fidelity.
  25. # [00:34] <Domenic_> saying "you must use C++ if you want private state" is kind of O_o
  26. # [00:36] <Hixie_> TabAtkins: ok, let me put it another way then: i disagree that those use cases are valuable :-)
  27. # [00:36] <Hixie_> TabAtkins: what's an end-user use case?
  28. # [00:36] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Read error: Connection reset by peer)
  29. # [00:36] <TabAtkins> We know you do. You've said that over and over again in the past.
  30. # [00:36] <TabAtkins> And we've just ignored you and worked around it. ^_^
  31. # [00:36] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  32. # [00:37] <Hixie_> yeah... not helpful
  33. # [00:37] <Hixie_> why not just explain why it's useful?
  34. # [00:37] <TabAtkins> Sorry, but you've repeatedly stated your disdain for "make APIs that look and act the same as native ones" as a use-case.
  35. # [00:37] <Hixie_> that's because it's not a use case...
  36. # [00:37] <TabAtkins> And that's why it's not worth explaining to you, because your suggestion of "just make the API not look like the platform" isn't useful.
  37. # [00:37] <Hixie_> it is often brought up as a use case as if it is obvious on its face why it's valid, but it's not obvious at all, and no attempt seems to have been made to explain it
  38. # [00:38] <Hixie_> it's like something you have on faith or something
  39. # [00:38] <Hixie_> faith-based API design considered harmful :-P
  40. # [00:38] <TabAtkins> I'm sorry you don't understand why it's useful for users of a library to have the library act like the rest of the platform.
  41. # [00:39] <Hixie_> that isn't helpful or constructive
  42. # [00:39] <Hixie_> seriously, if you can't articulate why something is helpful, maybe it's not. that's all i'm saying.
  43. # [00:39] * Joins: jpn (~jpn@a79-168-252-125.cpe.netcabo.pt)
  44. # [00:39] <Domenic_> i think it's been articulated, but not to your satisfaction, just to many other peoples'...
  45. # [00:39] <Hixie_> where?
  46. # [00:40] <TabAtkins> I did articulate it. I, and others, have done so many times. You just don't accept it. Shrug.
  47. # [00:42] <Hixie_> it just seems crazy to me that ES is getting a ton of APIs that i see as essentially pointless, and the only argument in favour is "we said it's important, but you won't believe us"
  48. # [00:42] <TabAtkins> "Because a consistent platform is good" is the basic reason for lots of things, including stuff you've found very valuable, like specifying the parser.
  49. # [00:42] <Hixie_> the parser spec is useful to get interop and that's good to avoid concrete security bugs.
  50. # [00:42] <Hixie_> consistency is not, and has never been, a compelling use case. there's tons of stuff we haven't added to HTML because consistency was the only argument.
  51. # [00:42] <TabAtkins> It's also helpful for authors, because it means a lower cognitive overhead.
  52. # [00:42] <Hixie_> more APIs doesn't mean a lower cognitive overhead.
  53. # [00:42] * Quits: [[zz]] (~q@node-11lq.pool-180-180.dynamic.totbb.net) (Ping timeout: 264 seconds)
  54. # [00:43] <Hixie_> i mean, it really doesn't. it's easier to understand classical mechanics (which isn't internally consistent) than quantum mechanics (which is), as a simple example of that.
  55. # [00:44] * Quits: arunranga (~otherarun@cpe-74-73-238-8.nyc.res.rr.com) (Quit: arunranga)
  56. # [00:44] <TabAtkins> Le sigh. No, but having libraries do things in a way similar to the platform *does* mean a lower cognitive overhead, as opposed to library users having to learn to do things in 2+ different ways because some things are "native" and some are "JS".
  57. # [00:45] <Hixie_> but again, authors don't have to do that. it's quite possible to write libraries that work close enough to the platform that authors have no troubles, without any of this stuff.
  58. # [00:45] <TabAtkins> And some patterns, like private state, which are extremely useful, currently require either giving up on real privacy (using naming conventions, for example), or costing a bunch of memory (using closures for private state on objects). WeakMaps address the problem easily and properly.
  59. # [00:45] <Hixie_> unless you have a concrete counter-example?
  60. # [00:45] <TabAtkins> Not off the top of my head, because I just stumbled into this argument.
  61. # [00:45] <TabAtkins> And I'm trying to code some Python right now. ^_^
  62. # [00:46] <smaug____> poor you :)
  63. # [00:46] <Hixie_> it's not "real" privacy. all this code is running in the same security context.
  64. # [00:46] <Hixie_> user privacy isn't in the slightest bit affected.
  65. # [00:46] <TabAtkins> "Privacy" clearly has different definitions, and I'm not using that one.
  66. # [00:47] <Hixie_> what definition are you using?
  67. # [00:48] <Hixie_> i'm just baffled by this. It seems like a clear case of user>author>spec>theory being turned on its head.
  68. # [00:48] <TabAtkins> ...the one that means private state on an object?
  69. # [00:48] <Hixie_> what's the use case for that on the web?
  70. # [00:49] <TabAtkins> The same as its use-case in any other programming language, ever.
  71. # [00:49] <zewt> the idea of putting state on an object in a different object seems pretty seriously nasty, at least from a code style standpoint (granted that it may be the same under the hood)
  72. # [00:49] <TabAtkins> I refuse to explain the concept of private state to you.
  73. # [00:49] <TabAtkins> zewt: It's a little funky at first, but not bad once you've seen it once or twice.
  74. # [00:50] <Hixie_> TabAtkins: ok, but then don't complain that it's "not worth explaining to you" when you won't explain it
  75. # [00:50] <Hixie_> just admit you don't want to and move on
  76. # [00:50] * Quits: tantek (~tantek@m9d2d36d0.tmodns.net) (Quit: tantek)
  77. # [00:50] * Hixie_ continues to be baffled
  78. # [00:50] <TabAtkins> It's... not worth explaining a basic computer science concept to you. You can use Wikipedia for that.
  79. # [00:51] <Hixie_> (note that i can't think of any other language that has a way to add private state to an object the way that WeakMap does.)
  80. # [00:51] <Hixie_> are we talking about local private state?
  81. # [00:51] <Hixie_> because that doesn't seem to be what WeakMap gives you
  82. # [00:51] <Hixie_> or freeze
  83. # [00:52] <zewt> i think WeakMap does give that, if we mean the same thing by "local private state"
  84. # [00:52] <Hixie_> i mean, i am an object, and i have state i don't want public.
  85. # [00:52] <TabAtkins> Yes, the actual code you write to assign private state via WeakMap is slightly different. Rather than obj[key] = val, you write map[obj] = val. That's not a material difference.
  86. # [00:52] <Hixie_> WeakMap seems to be a way to secretely annotate other objects.
  87. # [00:52] <zewt> hixie: right
  88. # [00:53] <zewt> if you want private state in the object itself you still need to stash it in a closure
  89. # [00:53] <Domenic_> that's... not in the object itself, that's in an external data structure called "scope"
  90. # [00:53] * Joins: tobie (~tobielang@col74-1-88-183-112-72.fbx.proxad.net)
  91. # [00:53] <Hixie_> i'm all for JS having classes with private blocks and all
  92. # [00:53] <Hixie_> but that seems completely orthogonal to this
  93. # [00:53] <zewt> Domenic_: no difference as far as API structure is concerned
  94. # [00:53] <Hixie_> this being WeakMap and the frozen object thing
  95. # [00:54] <Domenic_> zewt: big difference... but maybe i'm not understanding...?
  96. # [00:54] <zewt> fwiw I don't have a strong opinion on whether it's worth it or not, but I agree with hixie that this is not analogous to private state inside an object, this is external to the object
  97. # [00:55] <Domenic_> right, it is strictly more powerful than other languages' private state abstraction, which is tied to e.g. classical models
  98. # [00:55] <Domenic_> but it is in the end a private state abstraction
  99. # [00:55] <Hixie_> my opinion is not "strong", it just the default opinion of "there's no use case -> no need to have it"
  100. # [00:56] <zewt> it doesn't seem to support the private data model of other languages at all, so I'm not sure that it's more powerful
  101. # [00:56] <Hixie_> it doesn't seem more powerful at all... it seems entirely orthogonal
  102. # [00:56] <Domenic_> es7 will probably have syntax so that e.g. obj@key = val <-> map[obj].key = val
  103. # [00:56] <Domenic_> zewt: it definitely does support that model, let me dig up some example code...
  104. # [00:56] <TabAtkins> A better term for what WeakMaps give you is "uncollidable" state.
  105. # [00:56] <Domenic_> zewt: here you go https://gist.github.com/domenic/6736258
  106. # [00:56] <TabAtkins> Which you can use to implement cheaper private state than just using closures.
  107. # [00:57] <zewt> Domenic: to do that you'd need to stash your WeakMap in some place that itself can't be accessed--which means you're back to closures
  108. # [00:57] <Domenic_> sure, of course, or modules.
  109. # [00:57] <zewt> so it's a class that essentially exists so you don't have to use closures, which you have to put in a closure :)
  110. # [00:57] <zewt> (yeah, I know there's a difference in performance, depending on how you do it)
  111. # [00:57] <TabAtkins> zewt: Yup, closing over just a WeakMap around the constructor function is better than having to close over every bit of state.
  112. # [00:58] <Domenic_> the big difference is you can control who has access. they don't have to share a scope. so e.g. prototype methods can access the private state.
  113. # [00:59] <TabAtkins> And the even smaller WeakSet object is *solely* for branding - no chance of collision, secret if the set is secret, and doesn't accidentally leak.
  114. # [01:00] * Quits: jreading (~Adium@ip98-169-193-48.dc.dc.cox.net) (Ping timeout: 240 seconds)
  115. # [01:02] <zcorpan> man, i didn't realize css stack wasn't supported in background-image in blink
  116. # [01:03] <zcorpan> er, svg stack
  117. # [01:03] <TabAtkins> zewt: If you're familiar with Crockford's method of doing instance-private state, it requires defining fresh copies of the prototype methods directly onto each instance, so they'll be defined in the correct context. That's a big memory hit.
  118. # [01:03] * Joins: jreading (~Adium@ip98-169-193-48.dc.dc.cox.net)
  119. # [01:03] * Quits: alecf_ (~alecf@216.239.45.79) (Quit: alecf_)
  120. # [01:03] <zewt> seems clumsy, if the main use case is basically in-object private state, compared to traditional private member mechanisms
  121. # [01:04] <zewt> (not to claim I know how any of those could be applied to JS in a web-compatible way)
  122. # [01:04] <TabAtkins> With WeakMap, you can just define things as normal, with a closure wrapping the class definition to contain the weakmap definitions. Then each prototype function can just use the weakmaps to attach and access private state on instances.
  123. # [01:04] <TabAtkins> Yeah, exposing privacy in the same way as other type systems is really difficult, because JS's type system is so light.
  124. # [01:04] <Domenic_> i think it fits pretty well with JS, given JS is all about object literals and prototypes and not classes. but yes, slightly clumsy for the classical case, just like classes in JS generally are.
  125. # [01:05] <Domenic_> but, just like ES6 gives us class sugar to make it less clumsy, ES7 will probably give private state sugar
  126. # [01:05] * Quits: brion (~brion@wikipedia/pdpc.professional.brion) (Quit: brion)
  127. # [01:08] <zewt> not sure that "it's clumsy, but that's normal for JS and we'll pave over it later" is a very good sales point :)
  128. # [01:09] <TabAtkins> Heh. The issue is that the non-clumsy way doesn't decompose to real JS.
  129. # [01:09] <TabAtkins> It requires more structure than actually exists.
  130. # [01:09] <TabAtkins> So you have to start with the low-level one and add sugar for it after.
  131. # [01:09] * Joins: sicking (~sicking@v-1045.fw1.sfo1.mozilla.net)
  132. # [01:09] <zewt> python's __name mechanism could probably work conceptually, but wouldn't be web-compatible (also it's painfully ugly)
  133. # [01:10] <zewt> (makes me feel like I'm reading a C++ STL header, and that's ... bad)
  134. # [01:10] <TabAtkins> Right, nobody wants that.
  135. # [01:10] <TabAtkins> (Had a near-miss with people trying to make Symbols work that way.)
  136. # [01:12] * Joins: weinig (~weinig@17.114.107.123)
  137. # [01:14] * Joins: alecf_ (~alecf@216.239.45.79)
  138. # [01:17] * Quits: alecf_ (~alecf@216.239.45.79) (Client Quit)
  139. # [01:17] * heycam is now known as heycam|away
  140. # [01:17] * Quits: decotii (~decotii@hq.croscon.com) (Quit: Leaving)
  141. # [01:18] * heycam|away is now known as heycam
  142. # [01:23] * Joins: alecf_ (~alecf@216.239.45.79)
  143. # [01:25] * Quits: lmcliste_ (~lmclister@192.150.10.209)
  144. # [01:26] * Quits: jreading (~Adium@ip98-169-193-48.dc.dc.cox.net) (Quit: Leaving.)
  145. # [01:31] * Quits: jpn (~jpn@a79-168-252-125.cpe.netcabo.pt) (Quit: jpn)
  146. # [01:32] * Joins: jpn (~jpn@a79-168-252-125.cpe.netcabo.pt)
  147. # [01:34] * Quits: weinig (~weinig@17.114.107.123) (Quit: weinig)
  148. # [01:35] * Joins: weinig (~weinig@17.114.107.123)
  149. # [01:35] * Quits: weinig (~weinig@17.114.107.123) (Client Quit)
  150. # [01:37] * Joins: richt (~richt@operas.lnk.telstra.net)
  151. # [01:37] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
  152. # [01:41] * Joins: annevk (~annevk@92.66.135.187)
  153. # [01:42] * Joins: encryptd_fractal (~encryptd_@71-89-74-12.dhcp.bycy.mi.charter.com)
  154. # [01:43] * Quits: ehsan (~ehsan@66.207.208.102) (Remote host closed the connection)
  155. # [01:45] <Hixie_> TabAtkins: i think it's worth noting that the use case that the discussion ended up describing has nothing to do with simulating host objects
  156. # [01:45] <Hixie_> TabAtkins: (and if the use case is instance-private data, i really don't think it's a particularly good mechanism compared to other languages')
  157. # [01:45] <TabAtkins> No, it most certainly did. It was all about private state, which host objects can have.
  158. # [01:47] <Hixie_> it lets you get private state (in a weird way) with a slightly better memory story than you could do with closures. it doesn't give you private state that you couldn't get before, and it doesn't get you anything like the memory story that C++ native code has.
  159. # [01:48] <Hixie_> i don't understand how it can be described as something needed to simulate host objects.
  160. # [01:48] <Hixie_> or "explain the platform"
  161. # [01:48] <Hixie_> you can "explain the platform" with closures too
  162. # [01:48] <TabAtkins> "slightly better" is a misnomer. It goes from "too much memory wasted to consider for production systems" to "perfectly fine".
  163. # [01:48] <Hixie_> both of those are exaggerations.
  164. # [01:49] <Hixie_> but "lower memory usage" is a fine use case in and of its self
  165. # [01:49] <TabAtkins> Per-instance methods are completely unacceptable when you'll be creating thousands of instances.
  166. # [01:49] <Hixie_> why would you do per-instance methods?
  167. # [01:50] <TabAtkins> Because that's what you need to do if you want the methods to be able to *access* the per-instance private state.
  168. # [01:50] <TabAtkins> You can't just attach the methods to the prototype like normal, because then they're not in the instance's closure that captured the private variables.
  169. # [01:51] <Hixie_> isn't that going to be solved by a real class system?
  170. # [01:52] <TabAtkins> No, JS is not introduce "a real class system". Producing two completely different ways of having a class would be ridiculous and bad. JS is producing a class *syntax*, which desugars into the existing prototype-based stuff.
  171. # [01:52] * Joins: jernoble|laptop (~jernoble@199-188-193-107.PUBLIC.monkeybrains.net)
  172. # [01:53] <TabAtkins> (Or to put it another way, JS already has a real class system. It's different from some other class systems, but has its own benefits. It's not going to introduce a second one.)
  173. # [01:54] <Hixie_> ugh
  174. # [01:54] <Hixie_> see, this is what drives me crazy. we're introducing crazy things like WeakMap and freezing objects and so on, and not fixing the real pain points with JS, with are amongst others that authors just hate prototypes.
  175. # [01:55] <TabAtkins> Coming from the dude who's maintaining one of the largest piles of legacy hacks in existence. ^_^
  176. # [01:55] <Hixie_> and you can't "explain the platform" when you're desugaring into an entirely different model than the platform is built on, either
  177. # [01:55] <Domenic_> who hates prototypes?
  178. # [01:55] <TabAtkins> And no, prototypes work just fine. Most people don't give a shit about the specifics of the class system, because almost no one does anything complicated with classes, ever.
  179. # [01:55] <Hixie_> Domenic_: who doesn't
  180. # [01:55] <TabAtkins> What they hate is the syntax, for good reason, and we're fixing.
  181. # [01:56] <Domenic_> Hixie_: web developers?
  182. # [01:56] <Hixie_> yeah, web developers
  183. # [01:56] <TabAtkins> And if you do care about the class system, prototype-based systems have some nice qualities.
  184. # [01:56] <Domenic_> vm writers hate prototypes (so they go off and build dart)
  185. # [01:56] <Domenic_> but web devs like them
  186. # [01:56] <Hixie_> it's by far the #1 issue i hear about when it comes to web devs complaining to me about JS-related topics
  187. # [01:56] <Domenic_> O_o
  188. # [01:57] <zewt> (as a web developer, i've never found a single thing to like about JS's class model compared to, say, Python)
  189. # [01:57] <Hixie_> ^ that's what it looks like when phrased politely
  190. # [01:57] <Hixie_> usually i don't hear it phrased so politely
  191. # [01:57] <TabAtkins> Every prototype-related complaint I've heard has been about the way you do classes in the current syntax.
  192. # [01:58] <TabAtkins> I've never heard anyone complain about the actual mechanics, except for people who geek over class systems and are just discussing relative merits.
  193. # [01:58] * Joins: reyre (~reyre@CPE7cb21b1e2cf4-CM7cb21b1e2cf1.cpe.net.cable.rogers.com)
  194. # [01:58] <TabAtkins> "class Foo extends Bar { ... }" is in ES6, and it fixes the syntax complaints entirely.
  195. # [01:58] * Joins: marcosc (~marcosc@bl7-54-120.dsl.telepac.pt)
  196. # [01:59] <Hixie_> TabAtkins: what i find is that the people who are complaining about the syntax often don't understand the mechanics, and when you try to explain the mechanics to have them understand the syntax, they switch to complaining about the mechanics, usually with looks of contempt and disbelief.
  197. # [01:59] <TabAtkins> Hixie_: Most people don't have any clue how class systems work at all in the first place, and have only a surface understanding of what OO even means, particularly that it's just a loosely-connected set of primitives that are all separable.
  198. # [01:59] * Quits: tobie (~tobielang@col74-1-88-183-112-72.fbx.proxad.net) (Quit: tobie)
  199. # [01:59] * Quits: reyre_ (~reyre@CPE7cb21b1e2cf4-CM7cb21b1e2cf1.cpe.net.cable.rogers.com) (Ping timeout: 248 seconds)
  200. # [02:00] <TabAtkins> Alternately: Most people were taught OO in Java or C++, so of *course* they dislike anything with a different system.
  201. # [02:00] <zewt> (that isn't how I've ever thought of OO)
  202. # [02:00] <Hixie_> that's true of some people, but other people i've talked to are people with a decade+ of experience with C++ and Java and other languages
  203. # [02:00] <Hixie_> just because you learnt one model doesn't mean you don't prefer others.
  204. # [02:00] <Hixie_> i originally learnt without OO and i prefer OO, for instance. :-)
  205. # [02:01] <Hixie_> (for many purposes; obviously, not all.)
  206. # [02:01] <TabAtkins> Sure, it's cool to prefer whatever. I like CLOS best out of every one I've found, for example.
  207. # [02:01] * Joins: mven_ (~mven@ip68-224-15-53.lv.lv.cox.net)
  208. # [02:01] <TabAtkins> Which is definitely not prototype-based. It's "generic function-based", if anything.
  209. # [02:01] <Hixie_> and what i'm saying is that it's an active _dislike_ for js' model that i see
  210. # [02:01] * Quits: annevk (~annevk@92.66.135.187) (Remote host closed the connection)
  211. # [02:01] <zewt> i learned in basic on an apple II, but i try not to let that hold me back
  212. # [02:01] <TabAtkins> I've never seen that. Shrug.
  213. # [02:01] <Hixie_> you just saw it from zewt :-)
  214. # [02:02] <Hixie_> anyway. all this is skipping past the point that i thought was particularly interesting, which is that the JS model isn't the model browsers use, so so long as we have it, you can't "explain the platform" with it
  215. # [02:02] <jsbell> zewt: Do you also read $ as "string" ?
  216. # [02:02] <Hixie_> so "explain the model" is both not a good argument, and not one that actually applies
  217. # [02:02] <Domenic_> it's definitely the model browsers use
  218. # [02:02] <Domenic_> they just have access to one extra primitive, namely actual private state
  219. # [02:02] <Domenic_> there are direct APIs for this in V8 and SpiderMonkey
  220. # [02:03] <Domenic_> SetHiddenValue/GetHiddenValue in V8
  221. # [02:03] <zewt> not really, it's probably been 20 years since I've touched "classic" basic, heh
  222. # [02:03] <TabAtkins> Hixie_: Huh? Browsers use JS+magic. We're just trying to explain the magic so we can do things that look the same in pure JS.
  223. # [02:03] <zewt> much more time learning to hate $ thanks to perl and php
  224. # [02:04] <Hixie_> ...browsers use C++...
  225. # [02:04] * Joins: weinig (~weinig@17.114.217.25)
  226. # [02:05] <TabAtkins> Hixie_: I'm talking about what authors see.
  227. # [02:05] <TabAtkins> Browsers talk to the author with JS+magic.
  228. # [02:05] <Domenic_> some use rust. some use self-hosted stuff (i.e. JS). that's all unobservable to authors. authors see JS APIs.
  229. # [02:05] <Hixie_> so clearly i don't even know what you mean by "Explain the platform" then
  230. # [02:06] <TabAtkins> It means reducing the size of that "magic" bit.
  231. # [02:06] <TabAtkins> So that it's all just "JS".
  232. # [02:07] <Hixie_> i don't understand. what kind of magic are we talking about?
  233. # [02:07] <Hixie_> i mean, we're not talking about implementing Event or Node or Document or Window in JS, right?
  234. # [02:07] <Hixie_> or WebSocket, or XMLHttpRequest, or Location, or History
  235. # [02:07] <TabAtkins> Everything that can't be reproduced in pure JS (or can't be reproduced in a remotely similar way; for example, if it requires substantially more memory or processing time to do in JS over what native gets).
  236. # [02:08] <zewt> (incidentally, i've completely lost the discussion, heh)
  237. # [02:08] <Hixie_> surely anything that can be reproduced in JS should just be a library
  238. # [02:08] <TabAtkins> Or at least minimizing that "magic" to the small set of things that really are impossible to provide securely, or just far too difficult.
  239. # [02:08] <Hixie_> the whole point of having a platform is to provide things you can't do in a library
  240. # [02:08] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  241. # [02:08] <Domenic_> That should be about access to capabilities, not about basic expressive semantics
  242. # [02:08] <TabAtkins> No, it's also to provide common idioms so we're all talking the same language for common things.
  243. # [02:08] <Hixie_> i think that hits my problem with this
  244. # [02:08] <zewt> err, what?
  245. # [02:09] <Domenic_> (the former being access to a web socket, the latter being 'having private state'
  246. # [02:09] <TabAtkins> I am *super* not getting into the "never provide anything in the platform that can be done in JS" argument.
  247. # [02:09] <Hixie_> i guess that argument is the crux of the matter
  248. # [02:09] <TabAtkins> That argument is decided. The people who say "never" are wrong, and nobody listens to them.
  249. # [02:09] <Hixie_> ...
  250. # [02:09] * Quits: alecf_ (~alecf@216.239.45.79) (Quit: alecf_)
  251. # [02:10] <Hixie_> i think the opposite is clearly true
  252. # [02:10] <Hixie_> we almost never add features that can just be done in libraries
  253. # [02:10] <TabAtkins> Writing some code a few times in browsers is better than having it written by millions of authors and sent down over millions of page connections.
  254. # [02:10] <Hixie_> there's no point
  255. # [02:10] <TabAtkins> You can reproduce basically the entire platform with a socket library and WebGL.
  256. # [02:10] <TabAtkins> Your argument is invalid. ^_^
  257. # [02:10] <Hixie_> that is true for things that browsers can do better, but by definition, if browsers can do it better, then it's not something that can be done in JS
  258. # [02:11] * Joins: ehsan (~ehsan@24-212-206-174.cable.teksavvy.com)
  259. # [02:11] <Hixie_> if your argument was what we applied to the platform, there'd be almost no JS out there
  260. # [02:11] <Hixie_> and browsers would be terabytes in size
  261. # [02:11] <zewt> (i'm confused and surprised; I thought it was, at least among most people here, universally agreed that things should go in the platform even if they can be done in libraries if they're common enough, since developers shouldn't need to load a bunch of libraries to do basic stuff)
  262. # [02:12] <zewt> (with the meaning of "common enough" being more debated)
  263. # [02:14] <Hixie_> i don't think we've ever added anything that can be done in JS as well as natively. What did you have in mind?
  264. # [02:14] <Hixie_> we add things that people do as well as they can, but that native could do far better, to the platform, for sure
  265. # [02:14] * Joins: alecf_ (~alecf@207.198.105.22)
  266. # [02:14] <zewt> for example, the whole URL API that anne's been working on--i'm definitely tired of having to copy around query parameter parsing code everywhere I go, as well as that everyone reading my code has to learn the particular API I'm using, instead of seeing a common, standard API and knowing it already
  267. # [02:15] <TabAtkins> zewt: Yes, exactly.
  268. # [02:16] <Hixie_> the bulk of that API is Location and HTMLAnchorElement, which can't be done with JS
  269. # [02:16] <zewt> i'm talking about the API to parse out a URL into components
  270. # [02:17] <Hixie_> that's just the Location/HTMLAnchorElement API split out into a separate independent component
  271. # [02:17] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 264 seconds)
  272. # [02:17] <zewt> which people do all the time in JS, and there's no performance issue there, it's just a pain in the ass, and ridiculously commonly needed
  273. # [02:18] <TabAtkins> Hixie's argument would, for example, kill Set, since it's just a library over Map. (Map is needed, since you can't do Map in Map-less JS without severe performance penalties - lookup is O(n).)
  274. # [02:18] <Hixie_> yeah i really don't understand why we have many of the new JS features, Set included.
  275. # [02:18] <TabAtkins> And I don't understand why you don't understand, thus the difficulty in explaining more advanced things.
  276. # [02:19] <zewt> exaggeration aside i don't think browsers would be "terabytes in size" even if this was taken too far; Python has a very broad standard library (much more than I'd ever argue for browsers), and it's maybe 60 megs
  277. # [02:19] <Hixie_> (but it's clear that JS isn't being build with the same principles in mind as we're using e.g. for HTML)
  278. # [02:19] <TabAtkins> It seems very self-evident to me, as someone who does web programming regularly.
  279. # [02:19] <Hixie_> TabAtkins: ditto, but the opposite is what seems self-evident. :-)
  280. # [02:19] <TabAtkins> zewt: Yeah, but loading an extra 60megs into each tab is somewhat less good.
  281. # [02:20] <Hixie_> zewt: if it was taken to its logical extension, no web authors would write any code.
  282. # [02:20] <Hixie_> zewt: so browsers would have the code of every app in the world :-)
  283. # [02:20] <TabAtkins> Hixie_: That's not the logical extensions, that's ad absurdum.
  284. # [02:20] <zewt> well, that can be alleviated (you don't load things until they're used, shared memory for precompiled bytecode, etc)
  285. # [02:20] <zewt> Hixie_: like I said before, "common enough"
  286. # [02:21] <zewt> a tetris API is clearly not common enough, so people will still have to implement tetris themselves :)
  287. # [02:21] <TabAtkins> zewt: Yeah, maybe. I suspect we'll end up moving into the "broad standard library" world eventually, anyway.
  288. # [02:21] <Hixie_> i guess the logical extension would be anything that's implemented at least 5 times, so not everything.
  289. # [02:21] <TabAtkins> A realistic cutoff is quite a bit higher, but something like that.
  290. # [02:21] <zewt> TabAtkins: a similar trick in Python for server-based worker pools is to load everything you need before you fork workers, for example
  291. # [02:22] <zewt> Hixie_: my guess is tetris has been implemented more than 5 times, but I'd still say it's not common enough :)
  292. # [02:22] <zewt> ("been implemented" = in javascript)
  293. # [02:23] <TabAtkins> Right now the criteria seems to be "implemented at least thousands of times, or implemented in a few popular libraries used by millions", roughly.
  294. # [02:23] <Hixie_> anyway, i don't think that's the right criteria
  295. # [02:24] <Hixie_> i think we should add things to the platform when doing so provides something that you can't do from the authoring side.
  296. # [02:24] <zewt> it seems like you're arguing that there are only two possibilities, implementing only what can't be done in libraries at all, or implementing everything ever; there are a lot of places in-between
  297. # [02:24] <TabAtkins> Shrug, it's a reasonable calculus, when you consider author time vs browser dev time, and user page-load time.
  298. # [02:24] <Hixie_> now, that might be just consistency across a lot of authors, the way URL is (it can be cheaply added since it's just the existing API made independent)
  299. # [02:24] * Quits: marcosc (~marcosc@bl7-54-120.dsl.telepac.pt) (Remote host closed the connection)
  300. # [02:24] <Hixie_> but my point is that if that's your criteria, then it doesn't make any sense to talk about making the platform into something you can do in JS
  301. # [02:25] <Hixie_> since the whole _point_, under this design philosophy, is to provide things that can't be done
  302. # [02:25] <Hixie_> and so it's a futile goal
  303. # [02:25] <TabAtkins> Most of us don't operate under your particularly strict criteria, so that's irrelevant.
  304. # [02:25] * Joins: marcosc (~marcosc@bl7-54-120.dsl.telepac.pt)
  305. # [02:25] <Hixie_> TabAtkins: you know, it's incredibly frustrating and insulting when you just dismiss other people's concerns repeatedly.
  306. # [02:25] <TabAtkins> Hixie_: You know that I can say the exact same thing back, right?
  307. # [02:25] <Hixie_> "i disagree with you, so i'll ignore you"
  308. # [02:26] <Hixie_> i'm not ignoring you
  309. # [02:26] <Hixie_> i've been trying to understand your point of view for a few hours now
  310. # [02:26] <TabAtkins> "I disagree with you, so I'll just repeatedly ask for use-cases and not accept anything you say."
  311. # [02:26] <Hixie_> while you keep saying you're giving up
  312. # [02:26] <TabAtkins> ^_^
  313. # [02:26] * Joins: scor (~scor@c-98-216-39-127.hsd1.ma.comcast.net)
  314. # [02:26] * Quits: scor (~scor@c-98-216-39-127.hsd1.ma.comcast.net) (Changing host)
  315. # [02:26] * Joins: scor (~scor@drupal.org/user/52142/view)
  316. # [02:26] <Hixie_> there's a qualitiative difference here
  317. # [02:26] <Hixie_> qualitative even
  318. # [02:27] <TabAtkins> If your definition of use-case explicitly excludes the kinds of things we're trying to do, there's not really a difference.
  319. # [02:27] <TabAtkins> (Which in many of these cases is "make author's lives easier by having better consistency in the platform and across independent libraries".)
  320. # [02:27] <TabAtkins> I mean, I've explained it. You didn't accept the explanation. I can't do a lot about that.
  321. # [02:28] * Quits: sicking (~sicking@v-1045.fw1.sfo1.mozilla.net) (Quit: sicking)
  322. # [02:28] <TabAtkins> I've already learned from talking to you for years that you have certain opinions about programming languages that are very different from mine, and different from those of many involved in JS and DOM standards.
  323. # [02:28] <TabAtkins> And they aren't the kind of differences that can generally be bridged just by explaining. You've learned things differently, and prefer different patterns. Shrug.
  324. # [02:29] * Quits: cabanier (~cabanier@192.150.22.55) (Quit: Leaving.)
  325. # [02:29] <zewt> Hixie_: ... he's not dismissing anything, I typed the exact same thing he did (and ^U'd it since he said it first)
  326. # [02:29] * Quits: marcosc (~marcosc@bl7-54-120.dsl.telepac.pt) (Ping timeout: 252 seconds)
  327. # [02:29] * Quits: smaug____ (~chatzilla@cs164155.pp.htv.fi) (Remote host closed the connection)
  328. # [02:30] * Joins: smaug____ (~chatzilla@cs164155.pp.htv.fi)
  329. # [02:30] <zewt> you're saying "if this is your criteria, then this doesn't make sense"; that's *not* his criteria, so that's irrelevant
  330. # [02:36] <Hixie_> zewt: i'm specifically referring to e.g. "we've just ignored you and worked around it", "it's not worth explaining to you", "I'm sorry you don't understand", "You just don't accept it. Shrug.", "I refuse to explain the concept of private state to you", "It's... not worth explaining a basic computer science concept to you", "That argument is decided. The people who say "never" are wrong, and nobody listens to them", "Your argument is invalid", etc
  331. # [02:37] * Joins: krawchyk (~krawchyk@pool-108-18-25-78.washdc.fios.verizon.net)
  332. # [02:37] * Quits: smaug____ (~chatzilla@cs164155.pp.htv.fi) (Ping timeout: 240 seconds)
  333. # [02:37] <Hixie_> on another note, i'm still curious about the use case for "frozen". nothing in the platform acts like that, does it? what is it for?
  334. # [02:38] * Quits: Kolombiken (~Adium@gateway.creuna.se) (Ping timeout: 248 seconds)
  335. # [02:38] <TabAtkins> Hixie_: Several of those are seriously basic concepts which I shouldn't have to explain. Wikipedia is an easier reference than asking me.
  336. # [02:38] * Joins: cabanier (~cabanier@c-98-237-137-173.hsd1.wa.comcast.net)
  337. # [02:39] <TabAtkins> I am indeed sometimes sorry you don't understand. Like I just said, you prefer different patterns, and sometimes seem to have a hard time accepting that patterns you personally dislike are still liked by others, and so things using those patterns are okay to develop.
  338. # [02:39] <TabAtkins> The "Your argument is invalid." was a joke, referencing the meme.
  339. # [02:40] * Joins: Kolombiken (~Adium@gateway.creuna.se)
  340. # [02:41] <zewt> i've thought about using "frozen" in the past; if I remember correctly, it would only throw in strict mode? or was that something else similar to it
  341. # [02:41] <TabAtkins> zewt: Yeah.
  342. # [02:41] <TabAtkins> It no-ops in sloppy mode.
  343. # [02:42] <zewt> (having properties just silently not change seems horribly confusing, so I didn't use it, and strict is useless until every browser supports it)
  344. # [02:42] <TabAtkins> zewt: Every modern browser does, no?
  345. # [02:42] <zewt> don't know--they didn't when I looked at that feature
  346. # [02:43] <TabAtkins> Pretty sure they do now, but I can't name when each got it.
  347. # [02:44] <zewt> (i also don't recall why I wanted it, or if I was just looking at it randomly)
  348. # [02:46] * Joins: danjesus (~danjesus@187.101.85.19)
  349. # [02:47] * Quits: jernoble|laptop (~jernoble@199-188-193-107.PUBLIC.monkeybrains.net) (Quit: Computer has gone to sleep.)
  350. # [02:50] * Quits: ehsan (~ehsan@24-212-206-174.cable.teksavvy.com) (Remote host closed the connection)
  351. # [02:50] * Quits: dbaron (~dbaron@50-0-248-3.dsl.dynamic.sonic.net) (Ping timeout: 252 seconds)
  352. # [02:52] * Quits: jorgepedret (~jorgepedr@64-46-23-103.dyn.novuscom.net) (Quit: Computer has gone to sleep.)
  353. # [02:52] <zewt> i know I've wanted things like that in Python even recently, eg. where I return an array or a dictionary by reference and I want to make sure the caller doesn't accidentally modify it
  354. # [02:53] * Quits: WeirdAl (~chatzilla@g2spf.ask.info) (Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258])
  355. # [02:53] <zewt> (usually I end up making a deep copy instead, which is usually okay)
  356. # [02:54] <TabAtkins> Yeah, but it's silly to have to defensively eat the cost of a copy, when most of the time the caller won't even modify anything. Forcing the cost on the rare modifying cases is better.
  357. # [02:54] * Joins: garciawebdev (~garciaweb@11-223-235-201.fibertel.com.ar)
  358. # [02:55] * Quits: krawchyk (~krawchyk@pool-108-18-25-78.washdc.fios.verizon.net) (Remote host closed the connection)
  359. # [02:56] <zewt> well, as long as the cost is only when you try to modify something frozen, not on everything
  360. # [02:57] * Joins: marcosc_ (~marcosc@bl7-54-120.dsl.telepac.pt)
  361. # [02:58] <TabAtkins> Yeah.
  362. # [02:59] <TabAtkins> Otherwise, you're looking at a functional data structure. Those are pretty interesting, but definitely harder to use. ^_^
  363. # [02:59] <zewt> okay, this "es6 template string" thing that somebody randomly linked on the list definitely looks like pointless language bloat
  364. # [02:59] * Quits: encryptd_fractal (~encryptd_@71-89-74-12.dhcp.bycy.mi.charter.com) (Remote host closed the connection)
  365. # [03:00] * Joins: krawchyk (~krawchyk@pool-108-18-25-78.washdc.fios.verizon.net)
  366. # [03:00] * Joins: encryptd_fractal (~encryptd_@71-89-74-12.dhcp.bycy.mi.charter.com)
  367. # [03:00] * Quits: krawchyk (~krawchyk@pool-108-18-25-78.washdc.fios.verizon.net) (Remote host closed the connection)
  368. # [03:00] <TabAtkins> It's "how do I embed DSLs in JS".
  369. # [03:01] <TabAtkins> The answer is "it's complicated", apparently.
  370. # [03:01] <zewt> python's formatting model seems simpler and better
  371. # [03:01] <TabAtkins> You can process things more powerfully than Python's simply str.format
  372. # [03:02] <zewt> don't know about str.format, i mean the '%(x)s' % {'x': foo} thing
  373. # [03:02] * Joins: krawchyk (~krawchyk@pool-108-18-25-78.washdc.fios.verizon.net)
  374. # [03:02] <zewt> maybe format is the same thing
  375. # [03:03] <zewt> that avoids putting code in the string itself
  376. # [03:03] <TabAtkins> Yeah, .format is the same thing.
  377. # [03:03] <TabAtkins> Preferred now.
  378. # [03:03] <zewt> not by me, heh
  379. # [03:04] <TabAtkins> Has the nice benefit that you can pass it to map()!
  380. # [03:04] <zewt> i've never seen map() used in python except by people who haven't learned comprehensions
  381. # [03:04] <TabAtkins> Hah, I've used both.
  382. # [03:04] <zewt> in my experience map is 100% always harder to read
  383. # [03:05] * Quits: encryptd_fractal (~encryptd_@71-89-74-12.dhcp.bycy.mi.charter.com) (Ping timeout: 265 seconds)
  384. # [03:07] <zewt> (and I use traditional format strings wherever I can, unless the format string is from an external source or too complex; they're just much more concise and easier to author)
  385. # [03:08] <zewt> no comparison between '%ix%i' % (x, y) and '%(x)ix%(y)i' % { 'x': x, 'y': y }
  386. # [03:08] <zewt> which is about the level of most inline formatting
  387. # [03:09] * Joins: ehsan (~ehsan@24-212-206-174.cable.teksavvy.com)
  388. # [03:12] * Quits: ehsan (~ehsan@24-212-206-174.cable.teksavvy.com) (Remote host closed the connection)
  389. # [03:13] * Quits: weinig (~weinig@17.114.217.25) (Quit: weinig)
  390. # [03:13] <Hixie_> so what _is_ the point of freezing?
  391. # [03:14] * Quits: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net) (Remote host closed the connection)
  392. # [03:14] <zewt> well, the Python case I had applies to any language (making sure that people don't modify things accidentally, without having to make a deep copy all the time)
  393. # [03:15] <zewt> whether that's a practical issue in JS code I couldn't say, but I've wanted it in other places
  394. # [03:16] <Hixie_> can't you just do that with getters and setters?
  395. # [03:16] <TabAtkins> zewt: Using .format, it's just "{0}x{1}".format(x,y). You can use named placeholders instead, passing them as named arguments. You can also do formatting, but I haven't needed to, so whatever.
  396. # [03:16] <TabAtkins> Hixie_: No, because those can be overridden.
  397. # [03:16] <zewt> TabAtkins: i don't want to learn a completely different placeholder system; I've been using C-style ones for two decades and I don't have to think about it
  398. # [03:17] <zewt> TabAtkins: well, in the "making sure people don't write to this by accident" case, it doesn't matter if there's a back door, it's just to prevent accidents
  399. # [03:17] <TabAtkins> zewt: Sure. I haven't ever had to, so I don't care, and I appreciate the visual separation that the {} provides.
  400. # [03:17] <TabAtkins> zewt: Sure, but there are some use-cases where you really dont' want a back door, like running untrusted code (what Caja does).
  401. # [03:18] <zewt> (most of the cases of trying to protect code from other code in the same context seems unconvincing to me, but I won't claim I've looked at it thoroughly)
  402. # [03:18] <Hixie_> TabAtkins: well sure but if people want to screw around...
  403. # [03:18] <TabAtkins> zewt: Many are ill-founded, granted, but there are reasonable cases for sandboxing code.
  404. # [03:19] <zewt> i know we're not nearly there yet (and may never be, but who knows), but kicking untrusted code into a worker (a completely different context) seems like such a better direction
  405. # [03:22] <TabAtkins> Yeah, I'm not familiar enough with the stuff that Caja is used for to know how well that would work.
  406. # [03:23] <Hixie_> the caja stuff seems like such a case of wack-a-mole
  407. # [03:23] <Hixie_> it's basically retrofitting a security model into something that was never designed with it in mind
  408. # [03:24] * Quits: marcosc_ (~marcosc@bl7-54-120.dsl.telepac.pt) (Remote host closed the connection)
  409. # [03:24] * Joins: marcosc (~marcosc@bl7-54-120.dsl.telepac.pt)
  410. # [03:25] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
  411. # [03:25] * Joins: Goplat (~goplat@reactos/developer/Goplat)
  412. # [03:26] * Joins: sayanee (~sayanee@210.23.18.249)
  413. # [03:26] <TabAtkins> Welcome to the web.
  414. # [03:27] <Jasper> I am not reading that scrollback.
  415. # [03:27] <Hixie_> which part?
  416. # [03:27] <Hixie_> TabAtkins: which part?
  417. # [03:27] <TabAtkins> Hixie_: Which part of what?
  418. # [03:28] <Hixie_> TabAtkins: if you mean, the web is like that too, then yeah, that's why i don't think doing caja in it is a good idea :-)
  419. # [03:28] <TabAtkins> Yeah, I just meant that *everything* on the web is retrofitting onto a system that wasn't designed for whatever it is you're doing. ^_^
  420. # [03:29] * Quits: marcosc (~marcosc@bl7-54-120.dsl.telepac.pt) (Ping timeout: 264 seconds)
  421. # [03:29] <Hixie_> well yeah, but security is a case where if you get it slightly wrong, you've lost
  422. # [03:29] * Joins: weinig (~weinig@24.130.60.35)
  423. # [03:29] <Hixie_> unlike most things, where if you get it slightly wrong, you've still mostly won
  424. # [03:34] * Quits: reyre (~reyre@CPE7cb21b1e2cf4-CM7cb21b1e2cf1.cpe.net.cable.rogers.com) (Remote host closed the connection)
  425. # [03:35] * Quits: stalled (~stalled@unaffiliated/stalled) (Ping timeout: 245 seconds)
  426. # [03:37] * Joins: malaclyps (~Danny@gateway/tor-sasl/malaclyps)
  427. # [03:38] * Joins: encryptd_fractal (~encryptd_@71-89-74-12.dhcp.bycy.mi.charter.com)
  428. # [03:43] * Quits: encryptd_fractal (~encryptd_@71-89-74-12.dhcp.bycy.mi.charter.com) (Remote host closed the connection)
  429. # [03:43] * Joins: encryptd_fractal (~encryptd_@71-89-74-12.dhcp.bycy.mi.charter.com)
  430. # [03:47] * Quits: encryptd_fractal (~encryptd_@71-89-74-12.dhcp.bycy.mi.charter.com) (Ping timeout: 240 seconds)
  431. # [03:48] * Quits: alecf_ (~alecf@207.198.105.22) (Quit: alecf_)
  432. # [03:49] * Joins: encryptd_fractal (~encryptd_@71-89-74-12.dhcp.bycy.mi.charter.com)
  433. # [03:49] * heycam is now known as heycam|away
  434. # [03:49] * Quits: encryptd_fractal (~encryptd_@71-89-74-12.dhcp.bycy.mi.charter.com) (Client Quit)
  435. # [03:55] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net) (Remote host closed the connection)
  436. # [03:58] * Joins: marcosc_ (~marcosc@bl7-54-120.dsl.telepac.pt)
  437. # [04:00] * Joins: scor (~scor@c-98-216-39-127.hsd1.ma.comcast.net)
  438. # [04:00] * Quits: scor (~scor@c-98-216-39-127.hsd1.ma.comcast.net) (Changing host)
  439. # [04:00] * Joins: scor (~scor@drupal.org/user/52142/view)
  440. # [04:02] * Quits: Kolombiken (~Adium@gateway.creuna.se) (Read error: Connection reset by peer)
  441. # [04:02] * Joins: Kolombiken (~Adium@gateway.creuna.se)
  442. # [04:03] * Joins: stalled (~stalled@unaffiliated/stalled)
  443. # [04:05] * Joins: nod__ (~nod_@lib59-8-78-248-165-78.fbx.proxad.net)
  444. # [04:06] * Quits: jpn (~jpn@a79-168-252-125.cpe.netcabo.pt) (Quit: jpn)
  445. # [04:08] * Quits: malaclyps (~Danny@gateway/tor-sasl/malaclyps) (Ping timeout: 240 seconds)
  446. # [04:11] * Joins: malaclyps (~Danny@gateway/tor-sasl/malaclyps)
  447. # [04:13] * Quits: danjesus (~danjesus@187.101.85.19) (Remote host closed the connection)
  448. # [04:13] * Joins: danjesus (~danjesus@187.101.85.19)
  449. # [04:17] * Joins: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net)
  450. # [04:18] * Quits: danjesus (~danjesus@187.101.85.19) (Ping timeout: 245 seconds)
  451. # [04:24] * Quits: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net) (Remote host closed the connection)
  452. # [04:27] * ojan_gardening is now known as ojan_away
  453. # [04:29] * Joins: danjesus (~danjesus@187.101.85.19)
  454. # [04:29] * Quits: marcosc_ (~marcosc@bl7-54-120.dsl.telepac.pt) (Remote host closed the connection)
  455. # [04:30] * Joins: marcosc (~marcosc@bl7-54-120.dsl.telepac.pt)
  456. # [04:34] * Quits: marcosc (~marcosc@bl7-54-120.dsl.telepac.pt) (Ping timeout: 253 seconds)
  457. # [04:35] * heycam|away is now known as heycam
  458. # [04:38] <TabAtkins> Another theoretical benefit of freezing is that it allows harder optimizations - you're guaranteed that the shape of the object won't change after the freeze.
  459. # [04:39] <TabAtkins> That's "theoretical" because, afaik, V8 still actually uses the slow path for frozen objects, so freezing gives you *worse* performance. That's just because of them not going to the effort to fix it yet, not anything intrinsic; there's a bug against them to actually optimize frozen objects.
  460. # [04:42] * Quits: nod__ (~nod_@lib59-8-78-248-165-78.fbx.proxad.net) (Ping timeout: 248 seconds)
  461. # [04:45] * Quits: malaclyps (~Danny@gateway/tor-sasl/malaclyps) (Ping timeout: 240 seconds)
  462. # [04:46] <Hixie_> TabAtkins: are host objects "frozen" in any sense?
  463. # [04:47] <TabAtkins> That depends on the object, I guess.
  464. # [04:47] <TabAtkins> You can usually put expandos on them, so no.
  465. # [04:47] <Hixie_> so freezing isn't for "explaining the platform"?
  466. # [04:55] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
  467. # [04:55] * Quits: krawchyk (~krawchyk@pool-108-18-25-78.washdc.fios.verizon.net) (Remote host closed the connection)
  468. # [04:56] * Joins: Goplat (~goplat@reactos/developer/Goplat)
  469. # [05:10] <TabAtkins> I dunno. I forget exactly what freezing disallows, so it might be needed to explain some things.
  470. # [05:10] * Quits: garciawebdev (~garciaweb@11-223-235-201.fibertel.com.ar) (Remote host closed the connection)
  471. # [05:13] <cabanier> TabAtkins: it seems that freezing just makes things harder and slower for the v8 compiler
  472. # [05:18] <TabAtkins> cabanier: That's for now. It *should* make several optimizations easier and more certain, with no need to reserve the ability to de-optimize.
  473. # [05:21] * Joins: lmcliste_ (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  474. # [05:22] <cabanier> TabAtkins: not sure why that would be. It might make it easier to write code that can be optimized well
  475. # [05:22] <cabanier> TabAtkins: from what I understand from v8, it generates code as if the classes are frozen
  476. # [05:26] * Joins: nonge (~nonge@p5082B922.dip0.t-ipconnect.de)
  477. # [05:30] * Quits: nonge_ (~nonge@p5082BE39.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
  478. # [05:31] <TabAtkins> Yeah, but it has to de-optimize when you do change things.
  479. # [05:32] <cabanier> TabAtkins: it depends, right? In general, it just assumes a new frozen class and generates assembly for that
  480. # [05:32] <cabanier> Hixie_: I have to agree with Tab about "dismissing other people's concerns"
  481. # [05:33] <cabanier> Hixie_: we've going round and round about how the current path syntax and the stroking algorithm don't work
  482. # [05:33] <cabanier> Hixie_: but it seems our concerns are constantly dismissed (with no proof)
  483. # [05:43] <Hixie_> cabanier: i thought you'd sent mail that was still in the queue, is it not?
  484. # [05:43] <cabanier> Hixie_: queue?
  485. # [05:43] <Hixie_> have you sent a mail i haven't replied to yet?
  486. # [05:44] <cabanier> Hixie_: yes although it seems like we're stuck in a loop
  487. # [05:45] <Hixie_> i am not aware of any loop
  488. # [05:45] <cabanier> Hixie_: for instance, I never got a reply on dashing
  489. # [05:45] <Hixie_> there's e-mail that i still have to reply to, sure
  490. # [05:45] <Hixie_> there's currently 492 e-mails in my queue and 184 e-mails
  491. # [05:45] <Hixie_> er, 184 bugs
  492. # [05:45] <cabanier> :-)
  493. # [05:45] <Hixie_> that's not a loop and it's definitely not dismissing concerns, it's just being slow
  494. # [05:45] <Hixie_> i'll happily cop to that
  495. # [05:46] <Hixie_> well, not happily
  496. # [05:46] <Hixie_> but without reservation
  497. # [05:46] * Quits: lmcliste_ (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  498. # [05:47] <Hixie_> i'm about 2 months lagged right now
  499. # [05:47] <Hixie_> on e-mail i haven't intentionally delayed
  500. # [05:47] <Hixie_> and about 30 months lagged on e-mail that's blocked on other things
  501. # [05:47] <cabanier> Hixie_: yeah, I can believe that you're overloaded :-)
  502. # [05:47] <Hixie_> anyway, gotta ga, tv :-)
  503. # [05:48] <cabanier> Hixie_: for me, it's hard to make progress
  504. # [05:48] <cabanier> Hixie_: since implementors think the issues aren't resolved
  505. # [05:48] <cabanier> Hixie_: enjoy!
  506. # [06:01] * Quits: weinig (~weinig@24.130.60.35) (Quit: weinig)
  507. # [06:01] * Joins: jernoble|laptop (~jernoble@199-188-193-107.PUBLIC.monkeybrains.net)
  508. # [06:06] * Joins: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net)
  509. # [06:07] * Joins: primal1 (~primal1@pool-173-58-233-214.lsanca.fios.verizon.net)
  510. # [06:08] * heycam is now known as heycam|away
  511. # [06:08] * Quits: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net) (Remote host closed the connection)
  512. # [06:11] * Joins: jorgepedret (~jorgepedr@70-36-56-110.dyn.novuscom.net)
  513. # [06:11] * Quits: primal1 (~primal1@pool-173-58-233-214.lsanca.fios.verizon.net) (Client Quit)
  514. # [06:12] * Quits: jernoble|laptop (~jernoble@199-188-193-107.PUBLIC.monkeybrains.net) (Quit: Computer has gone to sleep.)
  515. # [06:15] * Quits: danjesus (~danjesus@187.101.85.19) (Remote host closed the connection)
  516. # [06:16] * Joins: danjesus (~danjesus@187.101.85.19)
  517. # [06:20] * Quits: richt (~richt@operas.lnk.telstra.net) (Remote host closed the connection)
  518. # [06:20] * Quits: danjesus (~danjesus@187.101.85.19) (Ping timeout: 248 seconds)
  519. # [06:21] * Joins: richt (~richt@operas.lnk.telstra.net)
  520. # [06:23] * Joins: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net)
  521. # [06:24] * Joins: jernoble|laptop (~jernoble@199-188-193-107.PUBLIC.monkeybrains.net)
  522. # [06:25] * Quits: richt (~richt@operas.lnk.telstra.net) (Ping timeout: 252 seconds)
  523. # [06:26] * heycam|away is now known as heycam
  524. # [06:44] * Joins: TuRnaD0 (~Thunderbi@x1-6-e0-46-9a-1e-fe-ca.k368.webspeed.dk)
  525. # [06:44] * Quits: TuRnaD0 (~Thunderbi@x1-6-e0-46-9a-1e-fe-ca.k368.webspeed.dk) (Client Quit)
  526. # [06:45] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
  527. # [06:46] * Quits: jernoble|laptop (~jernoble@199-188-193-107.PUBLIC.monkeybrains.net) (Quit: Textual IRC Client: www.textualapp.com)
  528. # [06:47] * Joins: krawchyk (~krawchyk@pool-108-18-25-78.washdc.fios.verizon.net)
  529. # [06:53] <Hixie_> cabanier: i replied to those e-mails for you
  530. # [06:53] * Quits: rniwa (~rniwa@17.212.154.114) (Quit: rniwa)
  531. # [06:54] <cabanier> Hixie_: thanks!
  532. # [06:55] * Quits: Lachy (~Lachy@cm-84.215.104.248.getinternet.no) (Ping timeout: 264 seconds)
  533. # [07:00] * Quits: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net) (Remote host closed the connection)
  534. # [07:06] * Quits: krawchyk (~krawchyk@pool-108-18-25-78.washdc.fios.verizon.net) (Remote host closed the connection)
  535. # [07:07] * Joins: sicking (~sicking@c-67-180-9-161.hsd1.ca.comcast.net)
  536. # [07:07] * Quits: sicking (~sicking@c-67-180-9-161.hsd1.ca.comcast.net) (Client Quit)
  537. # [07:16] <Hixie_> cabanier: also replied to https://www.w3.org/Bugs/Public/show_bug.cgi?id=23386
  538. # [07:17] * Quits: jorgepedret (~jorgepedr@70-36-56-110.dyn.novuscom.net) (Quit: Computer has gone to sleep.)
  539. # [07:23] <cabanier> Hixie_: thanks! replied
  540. # [07:24] * Joins: dbaron (~dbaron@172.56.6.218)
  541. # [07:24] * Quits: dbaron (~dbaron@172.56.6.218) (Read error: Connection reset by peer)
  542. # [07:30] * Joins: richt (~richt@91.216.105.37)
  543. # [07:37] * Joins: zdobersek (~zdobersek@cpe-77.38.31.63.cable.t-1.si)
  544. # [07:40] * Quits: Kolombiken (~Adium@gateway.creuna.se) (Ping timeout: 265 seconds)
  545. # [07:51] * Joins: Smylers (~smylers@host86-180-214-205.range86-180.btcentralplus.com)
  546. # [07:55] * Joins: birtles (~chatzilla@61-121-216-2.bitcat.net)
  547. # [07:59] * Krinkle is now known as Krinkle|detached
  548. # [08:13] * Joins: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net)
  549. # [08:13] * Joins: rniwa (~rniwa@c-98-207-134-149.hsd1.ca.comcast.net)
  550. # [08:18] * Quits: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net) (Remote host closed the connection)
  551. # [08:22] * Joins: lmcliste_ (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net)
  552. # [08:23] * Quits: Smylers (~smylers@host86-180-214-205.range86-180.btcentralplus.com) (Quit: Leaving.)
  553. # [08:23] * Quits: lmcliste_ (~lmclister@c-98-210-38-110.hsd1.ca.comcast.net) (Client Quit)
  554. # [08:36] * Quits: zdobersek (~zdobersek@cpe-77.38.31.63.cable.t-1.si) (Ping timeout: 252 seconds)
  555. # [08:52] * Quits: richt (~richt@91.216.105.37) (Remote host closed the connection)
  556. # [08:52] * Joins: zdobersek (~zdobersek@cpe-77.38.31.63.cable.t-1.si)
  557. # [08:53] * Joins: richt (~richt@180.94.118.5)
  558. # [08:58] * Quits: richt (~richt@180.94.118.5) (Ping timeout: 265 seconds)
  559. # [09:03] * Joins: Ms2ger (~Ms2ger@193.190.253.150)
  560. # [09:04] * Joins: richt (~richt@91.216.105.27)
  561. # [09:08] * Quits: richt (~richt@91.216.105.27) (Remote host closed the connection)
  562. # [09:09] * Joins: richt (~richt@180.94.118.5)
  563. # [09:09] * Joins: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt)
  564. # [09:13] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
  565. # [09:13] * Quits: richt (~richt@180.94.118.5) (Ping timeout: 264 seconds)
  566. # [09:16] * Quits: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt) (Ping timeout: 264 seconds)
  567. # [09:17] <Ms2ger> Hixie_, usually when people start with "This is a suggestion to fix major problems relating to developing a more modern application as related to browser history issues.", I give up :)
  568. # [09:26] * Joins: Kolombiken (~Adium@94.137.124.2)
  569. # [09:31] * Joins: mitemitreski (~mitemitre@212.120.17.179)
  570. # [09:32] * Joins: karlcow (~karl@nerval.la-grange.net)
  571. # [09:33] * Joins: bholley (~bholley@195-132-112-181.rev.numericable.fr)
  572. # [09:43] * Joins: Smylers (~smylers@94.117.150.85)
  573. # [09:44] * Joins: annevk (hidden-use@31-151-229-189.dynamic.upc.nl)
  574. # [09:47] * Quits: Smylers (~smylers@94.117.150.85) (Ping timeout: 240 seconds)
  575. # [09:50] * Joins: Smylers (~smylers@94.117.150.85)
  576. # [09:52] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  577. # [09:52] * Joins: hasather (~hasather@80.91.33.141)
  578. # [09:52] <annevk> Hixie_: FWIW, I don't think everyone in TC39 is convinced Object.freeze() at all should exist. Mark Miller got them through in some compromise decision... Same goes for "use strict" as far as I can tell.
  579. # [09:52] <annevk> Hixie_: it's not quite as like-minded as TabAtkins makes it out to be
  580. # [09:53] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Read error: Connection reset by peer)
  581. # [09:53] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  582. # [09:54] <annevk> Object.freeze() in particular is quite badly designed as it doesn't actually "freeze" objects. It just freezes some of its properties, but not e.g. internal state.
  583. # [10:06] * Quits: Smylers (~smylers@94.117.150.85) (Ping timeout: 265 seconds)
  584. # [10:07] * Joins: jwalden (~waldo@89.202.203.51)
  585. # [10:18] * Quits: birtles (~chatzilla@61-121-216-2.bitcat.net) (Quit: ChatZilla 0.9.90-rdmsoft [XULRunner 1.9.0.17/2009122204])
  586. # [10:20] * Joins: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net)
  587. # [10:20] <annevk> jsbell: not throwing for non-new makes subclassing harder to support
  588. # [10:21] <annevk> jsbell: once IDL is updated to support ES6-style classes that'll be clearer
  589. # [10:23] * Joins: Smylers (~smylers@81.143.60.194)
  590. # [10:23] * Quits: Smylers (~smylers@81.143.60.194) (Remote host closed the connection)
  591. # [10:24] * Joins: Smylers (~smylers@81.143.60.194)
  592. # [10:28] <zcorpan> "Having moved into open standards, DRM is easy to turn off later" http://www.w3.org/2013/04/drm/debate_outline.html
  593. # [10:29] * Joins: jpn (~jpn@a79-168-252-125.cpe.netcabo.pt)
  594. # [10:30] * Ms2ger blinks
  595. # [10:30] * Joins: gavin___ (~gavin@76.14.87.162)
  596. # [10:31] * Quits: gavin_ (~gavin@76.14.87.162) (Read error: Connection reset by peer)
  597. # [10:34] * Quits: jpn (~jpn@a79-168-252-125.cpe.netcabo.pt) (Quit: jpn)
  598. # [10:37] * Quits: heycam (~cam@nextlevelau.spd.co.il) (Ping timeout: 260 seconds)
  599. # [10:38] * Joins: heycam (~cam@nextlevelau.spd.co.il)
  600. # [10:39] * heycam is now known as heycam|away
  601. # [10:39] * Joins: darobin (~darobin@46.218.78.54)
  602. # [10:42] <annevk> o_O
  603. # [10:43] * Joins: smaug____ (~chatzilla@cs164155.pp.htv.fi)
  604. # [10:44] * Quits: annevk (hidden-use@31-151-229-189.dynamic.upc.nl) (Remote host closed the connection)
  605. # [10:44] * Joins: annevk (hidden-use@31-151-229-189.dynamic.upc.nl)
  606. # [10:49] * Quits: annevk (hidden-use@31-151-229-189.dynamic.upc.nl) (Ping timeout: 264 seconds)
  607. # [10:50] * Quits: espadrine (~ttyl@acces1046.res.insa-lyon.fr) (Ping timeout: 260 seconds)
  608. # [10:52] * kinetik_ is now known as kinetik
  609. # [10:52] * Joins: tobie (~tobielang@25-176.199-178.cust.bluewin.ch)
  610. # [10:55] * Joins: espadrine (~ttyl@acces1046.res.insa-lyon.fr)
  611. # [10:56] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: This computer has gone to sleep)
  612. # [11:01] * Joins: karlcow (~karl@nerval.la-grange.net)
  613. # [11:01] * Quits: sayanee (~sayanee@210.23.18.249) (Remote host closed the connection)
  614. # [11:12] * Joins: annevk (hidden-use@31-151-229-189.dynamic.upc.nl)
  615. # [11:12] <nicoo> Bullshit overflow.
  616. # [11:16] <MikeSmith> in Gecko IDLs what does [Throws] mean?
  617. # [11:16] <annevk> MikeSmith: it means it can throw an exception
  618. # [11:16] <annevk> Still need to talk about bz about that. Might be good for IDL too...
  619. # [11:16] <MikeSmith> ok
  620. # [11:16] * Quits: karlcow (~karl@nerval.la-grange.net) (Remote host closed the connection)
  621. # [11:17] * Ms2ger is skeptical about specs getting it right
  622. # [11:17] <MikeSmith> and [GetterThrows] means it can throw on getting?
  623. # [11:19] * Quits: darobin (~darobin@46.218.78.54) (Ping timeout: 248 seconds)
  624. # [11:22] <Ms2ger> Yep
  625. # [11:23] * Joins: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt)
  626. # [11:23] * Quits: rniwa (~rniwa@c-98-207-134-149.hsd1.ca.comcast.net) (Quit: rniwa)
  627. # [11:24] <MikeSmith> I see [Constant] in there too, which seems useful
  628. # [11:24] <MikeSmith> sorta
  629. # [11:24] <annevk> Ms2ger: pretty much everything can throw in theory I guess
  630. # [11:24] <annevk> Ms2ger: maybe Gecko could be smarter about it...
  631. # [11:25] <annevk> Ms2ger: e.g. if something has DOMString as argument, it can throw...
  632. # [11:25] <Ms2ger> Well, the Throws bit doesn't include webidl exceptions
  633. # [11:38] <annevk> Ms2ger: ah, see, this is why I should talk to bz
  634. # [11:45] * Joins: nod__ (~nod_@46.29.126.206)
  635. # [11:51] * Joins: darobin (~darobin@46.218.78.54)
  636. # [11:54] * Quits: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt) (Remote host closed the connection)
  637. # [11:55] * Joins: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt)
  638. # [11:57] * Quits: annevk (hidden-use@31-151-229-189.dynamic.upc.nl) (Remote host closed the connection)
  639. # [11:58] * Joins: annevk (hidden-use@31-151-229-189.dynamic.upc.nl)
  640. # [11:58] * Joins: annevk_ (hidden-use@31-151-229-189.dynamic.upc.nl)
  641. # [11:58] * Quits: annevk (hidden-use@31-151-229-189.dynamic.upc.nl) (Read error: Connection reset by peer)
  642. # [11:59] * Quits: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt) (Ping timeout: 248 seconds)
  643. # [12:00] * Joins: WesleyMcClane_ (~quassel@host171-108-dynamic.7-87-r.retail.telecomitalia.it)
  644. # [12:01] <smaug____> MikeSmith: yeah, [Constant] is useful, though often it should be [SameObject] I guess
  645. # [12:01] * Joins: barnabywalters (~barnabywa@46-239-239-203.tal.is)
  646. # [12:01] <smaug____> [Pure] is more implementation detail, probably not anything for specs
  647. # [12:03] <MikeSmith> what is [Pure]?
  648. # [12:04] * Quits: WesleyMcClane (~quassel@host195-146-dynamic.11-87-r.retail.telecomitalia.it) (Ping timeout: 265 seconds)
  649. # [12:04] <smaug____> the getter returns the same value as long as any setters or methods (which might change the underlying data) haven't been called
  650. # [12:05] <MikeSmith> ah
  651. # [12:07] <smaug____> I wonder if document.images should be [SameObject]
  652. # [12:07] <smaug____> and other similar .foos on document
  653. # [12:09] * Quits: annevk_ (hidden-use@31-151-229-189.dynamic.upc.nl) (Remote host closed the connection)
  654. # [12:10] * Joins: annevk (hidden-use@31-151-229-189.dynamic.upc.nl)
  655. # [12:14] * Quits: annevk (hidden-use@31-151-229-189.dynamic.upc.nl) (Ping timeout: 248 seconds)
  656. # [12:17] * Quits: Ms2ger (~Ms2ger@193.190.253.150) (Quit: bbl)
  657. # [12:18] * Quits: smaug____ (~chatzilla@cs164155.pp.htv.fi) (Ping timeout: 240 seconds)
  658. # [12:19] * Joins: jpn (~jpn@88.214.180.25)
  659. # [12:31] <jgraham> zcorpan: You don't happen to remember what features of range-request.php are actually required by the preload tests, so you?
  660. # [12:31] <jgraham> *do
  661. # [12:32] <jgraham> I am wondering if it is possible to just bake-in support for range requests and then use the pipe features of wptserve to recreate the whole required featureset
  662. # [12:32] <jgraham> (the pipe features would give you support for trickling the requests)
  663. # [12:33] * Quits: darobin (~darobin@46.218.78.54) (Remote host closed the connection)
  664. # [12:33] <jgraham> (the thing that seems most problematic is support for caching)
  665. # [12:54] <zcorpan> jgraham: i remember that there are tests that check that e.g. off is fetched by first making a 0-inf range request, then a request at the end, then a request at the beginning again
  666. # [12:56] <zcorpan> jgraham: but i don't remember what the whole required feature set is.
  667. # [12:58] <zcorpan> jgraham: but i guess stuff was implemented in range-request on a it's-necessary basis rather than it's-possible basis
  668. # [12:59] * Quits: nod__ (~nod_@46.29.126.206) (Ping timeout: 264 seconds)
  669. # [13:01] * Quits: tobie (~tobielang@25-176.199-178.cust.bluewin.ch) (Quit: tobie)
  670. # [13:03] <jgraham> Yeah, I could just do a straight port of course
  671. # [13:03] <MikeSmith> dumb question: in WebIDL is there a way to define a property as a direct property of an object rather than a property of its prototype?
  672. # [13:04] <jgraham> MikeSmith: I don't remember such a feature (but might be wrong). What's the use case?
  673. # [13:08] <MikeSmith> jgraham: No use case. What I'm wondering about very specifically is, in implementations of the Notification API, the "permission" property and "requestPermission" property/function are direct properties of the Notification object, not properties of its prototype.
  674. # [13:08] <MikeSmith> so first I wonder why that is
  675. # [13:08] <MikeSmith> and second I wonder if there's some reason why the implementations do that, how it could even be expressed in WebIDL
  676. # [13:09] <jgraham> Does "implementations" in this case mean blink?
  677. # [13:09] <MikeSmith> no gecko as well
  678. # [13:09] <jgraham> Hmm
  679. # [13:09] <jgraham> I thought Gecko did the prototype thing for IDL properties
  680. # [13:09] * MikeSmith doublechecks
  681. # [13:10] <MikeSmith> Notification.hasOwnProperty("permission") returns true in gecko too
  682. # [13:12] <MikeSmith> while, e.g., Notification.hasOwnProperty("icon") returns false
  683. # [13:12] * Joins: Gue______ (~textual@212.161.9.162)
  684. # [13:13] <MikeSmith> so some members of the IDL in the spec become properties of the prototype and others ("permission" and "requestPermission") become direct properties of the object
  685. # [13:16] <jgraham> They are properties of the interface object afaict
  686. # [13:16] <jgraham> Because they are declared as "static"
  687. # [13:16] <jgraham> http://dev.w3.org/2006/webapi/WebIDL/#es-operations
  688. # [13:16] <jgraham> "If the operation is static, then the property exists on the interface object."
  689. # [13:18] <MikeSmith> ah
  690. # [13:19] <MikeSmith> So then I think maybe idlharness.js might not yet have support for recognizing them as such
  691. # [13:20] <MikeSmith> it seems to be expecting them in the prototype
  692. # [13:20] <jgraham> Since idlharness.js hasn't been updated in several years, that seems quite likely
  693. # [13:20] <jgraham> But you didn't have anything else to do today, right? ;)
  694. # [13:21] <MikeSmith> haha
  695. # [13:21] <MikeSmith> the other thing this makes me wonder about then is, why is the Notification spec defining them as static
  696. # [13:22] <MikeSmith> no other specs seem to have IDLs with similar static attributes
  697. # [13:22] <MikeSmith> and until recently I think V8 didn't even support them
  698. # [13:24] <MikeSmith> hmm actually I guess I can understand why in this specific case
  699. # [13:24] <MikeSmith> given the way that the perms mechanism works in Notifications
  700. # [13:24] <MikeSmith> I guess the difference is that no other specs are using that kind of mechanism
  701. # [13:26] * jgraham wonders how multiple byte ranges are actually supposed to work e.g. what does bytes=1-10,20-30 return? Why does bytes=1-15,10-20 return the same as bytes=1-20?
  702. # [13:33] <jgraham> Oh, maybe you just use a funky response type
  703. # [13:33] <jgraham> the spec could make that clearer
  704. # [13:37] * Joins: josemanuel (~josemanue@88.Red-83-33-68.dynamicIP.rima-tde.net)
  705. # [13:39] * Joins: reyre (~reyre@CPE7cb21b1e2cf4-CM7cb21b1e2cf1.cpe.net.cable.rogers.com)
  706. # [13:41] * Joins: richt (~richt@91.216.105.52)
  707. # [13:43] * Quits: reyre (~reyre@CPE7cb21b1e2cf4-CM7cb21b1e2cf1.cpe.net.cable.rogers.com) (Remote host closed the connection)
  708. # [13:45] * Quits: Gue______ (~textual@212.161.9.162) (Quit: Computer has gone to sleep.)
  709. # [13:49] * Quits: josemanuel (~josemanue@88.Red-83-33-68.dynamicIP.rima-tde.net) (Quit: Saliendo)
  710. # [13:50] * Joins: annevk (hidden-use@31-151-229-189.dynamic.upc.nl)
  711. # [13:56] * Joins: nod__ (~nod_@46.29.126.206)
  712. # [14:02] * Quits: annevk (hidden-use@31-151-229-189.dynamic.upc.nl) (Remote host closed the connection)
  713. # [14:02] * Joins: annevk (hidden-use@31-151-229-189.dynamic.upc.nl)
  714. # [14:07] * Quits: annevk (hidden-use@31-151-229-189.dynamic.upc.nl) (Ping timeout: 252 seconds)
  715. # [14:07] * Quits: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net) (Remote host closed the connection)
  716. # [14:10] * Joins: darobin (~darobin@46.218.78.54)
  717. # [14:11] * Joins: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net)
  718. # [14:11] * Joins: annevk (hidden-use@31-151-229-189.dynamic.upc.nl)
  719. # [14:13] * Joins: Ms2ger (~Ms2ger@vpnf083.ugent.be)
  720. # [14:22] * Quits: annevk (hidden-use@31-151-229-189.dynamic.upc.nl) (Remote host closed the connection)
  721. # [14:22] * Joins: annevk (hidden-use@31-151-229-189.dynamic.upc.nl)
  722. # [14:26] * Quits: annevk (hidden-use@31-151-229-189.dynamic.upc.nl) (Ping timeout: 245 seconds)
  723. # [14:28] * Joins: annevk (hidden-use@31-151-229-189.dynamic.upc.nl)
  724. # [14:35] <annevk> MikeSmith: URL.createObjectURL(...) works the same way
  725. # [14:35] <MikeSmith> annevk: ah OK
  726. # [14:36] <MikeSmith> so fwiw I'm hacking static attribute/operation support into idlharness.js now
  727. # [14:36] * MikeSmith looks at URL IDL
  728. # [14:36] <annevk> MikeSmith: it's defined in the File API, somewhat confusingly
  729. # [14:37] <MikeSmith> ok
  730. # [14:37] * MikeSmith looks there
  731. # [14:37] <zcorpan> the "don't nest dfn elements" rule helped me find a mistake (i used dfn when i meant var)
  732. # [14:37] <MikeSmith> yay
  733. # [14:39] * Joins: jdaggett (~jdaggett@y230006.dynamic.ppp.asahi-net.or.jp)
  734. # [14:41] * Quits: annevk (hidden-use@31-151-229-189.dynamic.upc.nl) (Remote host closed the connection)
  735. # [14:41] * Joins: annevk (hidden-use@31-151-229-189.dynamic.upc.nl)
  736. # [14:44] * Joins: jreading (Adium@nat/novell/x-egnpkzhfpjcqvqiw)
  737. # [14:46] * Quits: annevk (hidden-use@31-151-229-189.dynamic.upc.nl) (Ping timeout: 245 seconds)
  738. # [14:52] * Joins: jarek (~jarek@unaffiliated/jarek)
  739. # [14:53] * Quits: jarek (~jarek@unaffiliated/jarek) (Client Quit)
  740. # [14:54] * Joins: jarek (~jarek@unaffiliated/jarek)
  741. # [14:56] * Joins: arunranga (~otherarun@cpe-74-73-238-8.nyc.res.rr.com)
  742. # [14:59] * Joins: SteveF (~chatzilla@93.158.51.47)
  743. # [14:59] * Joins: umgrosscol (~umgrossco@grosscol.umdl.umich.edu)
  744. # [14:59] * Joins: krawchyk (~krawchyk@65.220.49.251)
  745. # [15:03] * Joins: scor (~scor@drupal.org/user/52142/view)
  746. # [15:08] * Quits: mpt (~mpt@canonical/mpt) (Read error: Connection reset by peer)
  747. # [15:10] * Joins: annevk (hidden-use@31-151-229-189.dynamic.upc.nl)
  748. # [15:11] * Joins: decotii (~decotii@hq.croscon.com)
  749. # [15:11] * Joins: mpt (~mpt@nat/canonical/x-tyvjhmhsriweoiwl)
  750. # [15:11] * Quits: mpt (~mpt@nat/canonical/x-tyvjhmhsriweoiwl) (Changing host)
  751. # [15:11] * Joins: mpt (~mpt@canonical/mpt)
  752. # [15:15] * Quits: annevk (hidden-use@31-151-229-189.dynamic.upc.nl) (Remote host closed the connection)
  753. # [15:15] * Joins: annevk (hidden-use@31-151-229-189.dynamic.upc.nl)
  754. # [15:19] * Joins: tobie (~tobielang@col74-1-88-183-112-72.fbx.proxad.net)
  755. # [15:20] * Quits: annevk (hidden-use@31-151-229-189.dynamic.upc.nl) (Ping timeout: 245 seconds)
  756. # [15:26] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
  757. # [15:33] * Joins: reyre (~reyre@142.204.133.18)
  758. # [15:58] * Joins: scor (scor@drupal.org/user/52142/view)
  759. # [15:59] * Joins: TallTed (~Thud@63.119.36.36)
  760. # [16:00] * Quits: richt (~richt@91.216.105.52) (Remote host closed the connection)
  761. # [16:00] * Quits: darobin (~darobin@46.218.78.54) (Remote host closed the connection)
  762. # [16:01] * Joins: richt (~richt@180.94.118.5)
  763. # [16:05] * Quits: richt (~richt@180.94.118.5) (Ping timeout: 245 seconds)
  764. # [16:07] <zcorpan> Domenic_: nice presentation
  765. # [16:07] * Joins: encryptd_fractal (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  766. # [16:08] <zcorpan> MikeSmith: i added another static method today
  767. # [16:08] <MikeSmith> zcorpan: CSSOM?
  768. # [16:08] <zcorpan> yeah
  769. # [16:09] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 264 seconds)
  770. # [16:10] <MikeSmith> well I got the idlharness support working locally
  771. # [16:11] <MikeSmith> so I'll submit a patch for it
  772. # [16:21] * Joins: ehsan_ (~ehsan@66.207.208.102)
  773. # [16:25] * Joins: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt)
  774. # [16:30] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: jarek)
  775. # [16:32] * Joins: mpt (~mpt@canonical/mpt)
  776. # [16:38] * Joins: brion (~brion@wikipedia/pdpc.professional.brion)
  777. # [16:42] * Krinkle|detached is now known as Krinkle
  778. # [16:43] * Quits: mven_ (~mven@ip68-224-15-53.lv.lv.cox.net) (Remote host closed the connection)
  779. # [16:43] * Joins: mven (~mven@ip68-224-15-53.lv.lv.cox.net)
  780. # [16:48] * Quits: mven (~mven@ip68-224-15-53.lv.lv.cox.net) (Ping timeout: 248 seconds)
  781. # [16:51] * Quits: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt) (Remote host closed the connection)
  782. # [16:51] * Quits: mitemitreski (~mitemitre@212.120.17.179) (Read error: Connection reset by peer)
  783. # [16:51] * Joins: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt)
  784. # [16:52] * Joins: hasather_ (~hasather@guest.schibsted.no)
  785. # [16:55] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 248 seconds)
  786. # [16:56] * Quits: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt) (Ping timeout: 252 seconds)
  787. # [16:56] * Quits: hasather_ (~hasather@guest.schibsted.no) (Ping timeout: 264 seconds)
  788. # [16:57] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
  789. # [17:00] * Quits: tobie (~tobielang@col74-1-88-183-112-72.fbx.proxad.net) (Quit: tobie)
  790. # [17:01] * Joins: darobin (~darobin@46.218.78.54)
  791. # [17:05] * Joins: Cromulent (~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com)
  792. # [17:06] * Joins: josemanuel (~josemanue@88.Red-83-33-68.dynamicIP.rima-tde.net)
  793. # [17:08] * Quits: nod__ (~nod_@46.29.126.206) (Ping timeout: 248 seconds)
  794. # [17:08] * Quits: Ms2ger (~Ms2ger@vpnf083.ugent.be) (Quit: bbl)
  795. # [17:09] * Joins: nod__ (~nod_@46.29.126.206)
  796. # [17:09] * Quits: nod__ (~nod_@46.29.126.206) (Read error: Connection reset by peer)
  797. # [17:10] * Joins: nod__ (~nod_@46.29.126.206)
  798. # [17:10] * Quits: Cromulent (~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com) (Ping timeout: 248 seconds)
  799. # [17:12] * Joins: tobie (~tobielang@col74-1-88-183-112-72.fbx.proxad.net)
  800. # [17:14] * Quits: Kolombiken (~Adium@94.137.124.2) (Ping timeout: 245 seconds)
  801. # [17:16] * Quits: tobie (~tobielang@col74-1-88-183-112-72.fbx.proxad.net) (Quit: tobie)
  802. # [17:22] * Quits: darobin (~darobin@46.218.78.54) (Remote host closed the connection)
  803. # [17:24] * Quits: twisted` (uid6794@gateway/web/irccloud.com/x-ytkvaklvansiwszf) (Ping timeout: 246 seconds)
  804. # [17:27] * Quits: nod__ (~nod_@46.29.126.206) (Ping timeout: 245 seconds)
  805. # [17:29] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
  806. # [17:29] * Joins: lmcliste_ (~lmclister@192.150.10.209)
  807. # [17:32] * Quits: matijs (uid2278@gateway/web/irccloud.com/x-wjvdgxydoudpbuot) (Ping timeout: 246 seconds)
  808. # [17:33] * Joins: darobin (~darobin@46.218.78.54)
  809. # [17:33] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 264 seconds)
  810. # [17:34] * Joins: darobin_ (~darobin@46.218.78.54)
  811. # [17:34] * Quits: darobin (~darobin@46.218.78.54) (Read error: Connection reset by peer)
  812. # [17:37] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 265 seconds)
  813. # [17:41] * Joins: Cromulent (~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com)
  814. # [17:44] * Quits: darobin_ (~darobin@46.218.78.54) (Remote host closed the connection)
  815. # [17:47] * Joins: darobin (~darobin@46.218.78.54)
  816. # [17:48] * Joins: mpt (~mpt@nat/canonical/x-nqwsititbdcwsyei)
  817. # [17:48] * Quits: mpt (~mpt@nat/canonical/x-nqwsititbdcwsyei) (Changing host)
  818. # [17:48] * Joins: mpt (~mpt@canonical/mpt)
  819. # [17:50] * Quits: darobin (~darobin@46.218.78.54) (Remote host closed the connection)
  820. # [17:55] * Joins: frozenice (~frozenice@unaffiliated/fr0zenice)
  821. # [17:56] * Quits: SteveF (~chatzilla@93.158.51.47) (Ping timeout: 264 seconds)
  822. # [17:56] * Joins: trustme (46b74e9a@gateway/web/freenode/ip.70.183.78.154)
  823. # [17:57] * Joins: smaug____ (~chatzilla@a91-154-42-225.elisa-laajakaista.fi)
  824. # [17:58] * Quits: cabanier (~cabanier@c-98-237-137-173.hsd1.wa.comcast.net) (Quit: Leaving.)
  825. # [18:02] * Joins: hasather (~hasather@guest.schibsted.no)
  826. # [18:06] * Joins: nimbu (~nimbu@sjfw1-a.adobe.com)
  827. # [18:06] * Joins: Maurice (copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
  828. # [18:09] * Quits: hasather (~hasather@guest.schibsted.no) (Ping timeout: 264 seconds)
  829. # [18:12] * Quits: trustme (46b74e9a@gateway/web/freenode/ip.70.183.78.154) (Quit: Page closed)
  830. # [18:13] * Quits: jpn (~jpn@88.214.180.25) (Quit: jpn)
  831. # [18:17] * Joins: ap (~ap@2620:149:4:304:ad81:9d9f:6055:972b)
  832. # [18:18] * Joins: baku (~baku@2-236-39-253.ip231.fastwebnet.it)
  833. # [18:18] * Joins: jorgepedret (~jorgepedr@64-46-23-103.dyn.novuscom.net)
  834. # [18:18] * Joins: gavin_ (~gavin@76.14.87.162)
  835. # [18:18] * Quits: gavin___ (~gavin@76.14.87.162) (Read error: Connection reset by peer)
  836. # [18:20] * Joins: SteveF (~chatzilla@93.158.51.47)
  837. # [18:24] * Joins: nod__ (nod_@2a01:e35:2f07:61e0:9dee:49da:c38c:8022)
  838. # [18:30] * Quits: Smylers (~smylers@81.143.60.194) (Ping timeout: 252 seconds)
  839. # [18:33] * Joins: matijs (uid2278@gateway/web/irccloud.com/x-ggtsedqoxrkqnhtj)
  840. # [18:35] * Joins: jernoble|laptop (~jernoble@76.74.153.41)
  841. # [18:39] * Joins: cabanier (~cabanier@192.150.22.55)
  842. # [18:39] <Hixie_> annevk-cloud: huh, ok. thanks for the update.
  843. # [18:39] * Quits: jernoble|laptop (~jernoble@76.74.153.41) (Client Quit)
  844. # [18:49] <bholley> Hixie_: hey
  845. # [18:49] <bholley> Hixie_: now a good time?
  846. # [18:53] * Joins: jernoble|laptop (~jernoble@17.212.154.195)
  847. # [18:53] * Quits: jwalden (~waldo@89.202.203.51) (Quit: back tomorrow)
  848. # [18:53] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 248 seconds)
  849. # [18:56] * Quits: nod__ (nod_@2a01:e35:2f07:61e0:9dee:49da:c38c:8022) (Ping timeout: 252 seconds)
  850. # [18:56] * Quits: smaug____ (~chatzilla@a91-154-42-225.elisa-laajakaista.fi) (Remote host closed the connection)
  851. # [18:56] * Joins: smaug____ (~chatzilla@a91-154-42-225.elisa-laajakaista.fi)
  852. # [18:58] * Joins: dbaron (~dbaron@50-0-248-3.dsl.dynamic.sonic.net)
  853. # [19:00] * Joins: nod__ (nod_@2a01:e35:2f07:61e0:51e2:590e:19a5:d97d)
  854. # [19:03] * Quits: ehsan_ (~ehsan@66.207.208.102) (Read error: Connection reset by peer)
  855. # [19:04] * Joins: ehsan_ (~ehsan@66.207.208.102)
  856. # [19:04] * Joins: twisted` (uid6794@gateway/web/irccloud.com/x-mdeelmcucooyqvyj)
  857. # [19:04] * Quits: nod__ (nod_@2a01:e35:2f07:61e0:51e2:590e:19a5:d97d) (Ping timeout: 252 seconds)
  858. # [19:05] * Krinkle is now known as Krinkle|detached
  859. # [19:06] * Joins: nod__ (~nod_@46.29.126.206)
  860. # [19:07] * Joins: mpt (~mpt@canonical/mpt)
  861. # [19:10] * Joins: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt)
  862. # [19:15] * Joins: WesleyMcClane (~quassel@host146-150-dynamic.11-87-r.retail.telecomitalia.it)
  863. # [19:17] <dglazkov> good morning, Whatwg!
  864. # [19:17] * Joins: felipeduardo_ (~felipedua@177.41.244.27)
  865. # [19:17] * Quits: WesleyMcClane_ (~quassel@host171-108-dynamic.7-87-r.retail.telecomitalia.it) (Ping timeout: 240 seconds)
  866. # [19:18] * Joins: WeirdAl (~chatzilla@g2spf.ask.info)
  867. # [19:20] * Quits: nimbu (~nimbu@sjfw1-a.adobe.com) (Quit: Leaving.)
  868. # [19:21] * Quits: felipeduardo (~felipedua@189.115.44.34) (Ping timeout: 248 seconds)
  869. # [19:22] * Quits: encryptd_fractal (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Remote host closed the connection)
  870. # [19:23] * Joins: encryptd_fractal (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  871. # [19:24] * Joins: nimbu (~nimbu@192.150.10.205)
  872. # [19:26] * Quits: ehsan_ (~ehsan@66.207.208.102) (Remote host closed the connection)
  873. # [19:26] * Quits: felipeduardo_ (~felipedua@177.41.244.27) (Ping timeout: 248 seconds)
  874. # [19:26] * Quits: Cromulent (~Cromulent@cpc1-reig5-2-0-cust251.6-3.cable.virginmedia.com) (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
  875. # [19:27] * Quits: Benvie (~bbenvie@v-1045.fw1.sfo1.mozilla.net) (Ping timeout: 248 seconds)
  876. # [19:29] <Hixie_> bholley: hey
  877. # [19:29] <Hixie_> bholley: sure!
  878. # [19:30] * Joins: Benvie (~bbenvie@v-1045.fw1.sfo1.mozilla.net)
  879. # [19:35] * Quits: alecf (alecf@nat/google/x-weejggyufgmqblnw) (Quit: alecf)
  880. # [19:35] * Joins: alecf (alecf@nat/google/x-afercvoxmzjciymn)
  881. # [19:37] * Quits: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt) (Remote host closed the connection)
  882. # [19:37] * Joins: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt)
  883. # [19:38] * Joins: marcosc_ (~marcosc@bl11-8-39.dsl.telepac.pt)
  884. # [19:38] * Quits: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt) (Read error: Connection reset by peer)
  885. # [19:39] * Joins: felipeduardo_ (~felipedua@189.115.44.34)
  886. # [19:41] * Joins: Ms2ger (~Ms2ger@91.182.63.25)
  887. # [19:50] * Joins: rniwa (~rniwa@17.212.154.114)
  888. # [19:50] * ojan_away is now known as ojan
  889. # [19:53] * Quits: nod__ (~nod_@46.29.126.206) (Ping timeout: 245 seconds)
  890. # [19:57] <barnabywalters> where is the best place to ask about potential implications of HTML DRM?
  891. # [19:57] <TabAtkins> Depends on what you want. HTMLWG is good if you want frustrating non-answers to any concerns. Here is okay if you want people venting their spleen.
  892. # [19:57] <jgraham> It depends what you mean "implications"
  893. # [19:59] <barnabywalters> okay, so the question is: will DRM-protected HTML mean browser extensions can no longer make changes to web UIs, i.e. access+modify the DOM?
  894. # [19:59] <TabAtkins> The current DRM efforts are purely about <video>.
  895. # [20:00] <TabAtkins> But if we ever do have DRM for HTML itself, then yes, that's almost certainly what it means, or at least it will be severely restricted.
  896. # [20:00] <barnabywalters> okay, so all the “DRM will kill view-source” stuff is inaccurate?
  897. # [20:00] <TabAtkins> No, eventual DRM will. The only spec so far (EME) won't, though it's still horrible.
  898. # [20:02] <barnabywalters> boooo :(
  899. # [20:02] <barnabywalters> okay, thanks
  900. # [20:03] * Joins: sicking (~sicking@v-1045.fw1.sfo1.mozilla.net)
  901. # [20:03] <barnabywalters> Can I cite these logs as a source for “DRM will prevent users from being able to take control of their web UIs”, or is there a better source?
  902. # [20:04] * Quits: marcosc_ (~marcosc@bl11-8-39.dsl.telepac.pt) (Remote host closed the connection)
  903. # [20:05] <jgraham> You could, but that isn't what anyone said, really
  904. # [20:05] <jgraham> DRM *for HTML* would do that
  905. # [20:05] <jgraham> So far there is no concrete proposal for that
  906. # [20:05] <barnabywalters> ah, sorry — noted
  907. # [20:05] * Joins: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt)
  908. # [20:05] <jgraham> Although Jeffe Jaffe at W3C has hinted it is something he would like
  909. # [20:06] <jgraham> *Jeff
  910. # [20:06] * Quits: nimbu (~nimbu@192.150.10.205) (Quit: Leaving.)
  911. # [20:09] <jgraham> (I think. Although I can't find the source for thinking that right now)
  912. # [20:10] * Quits: barnabywalters (~barnabywa@46-239-239-203.tal.is) (Quit: barnabywalters)
  913. # [20:10] * Quits: marcosc (~marcosc@bl11-8-39.dsl.telepac.pt) (Ping timeout: 265 seconds)
  914. # [20:11] <jgraham> (hm, it is possible that I was thinking of someone else's characterisation of his position. So probably best ignore me)
  915. # [20:14] * Joins: nimbu (~nimbu@192.150.10.205)
  916. # [20:15] * Ms2ger submits a /. article about jgraham's claim
  917. # [20:17] <jgraham> Ms2ger: It's OK, no one has read /. for about 10 years
  918. # [20:17] * ojan is now known as ojan_gardener
  919. # [20:18] <jgraham> Ms2ger: More usefully, do Mozilla have anything like .headers files that can match more than one file?
  920. # [20:19] <Ms2ger> Not that I know of
  921. # [20:19] <jgraham> e.g. if I want to add some header to all html files in a directory
  922. # [20:19] <jgraham> Hmm
  923. # [20:19] <jgraham> That would seriously improve some of these ported-from-apache cases
  924. # [20:22] <Ms2ger> Seems like something useful to add
  925. # [20:22] <Ms2ger> Maybe
  926. # [20:23] <Ms2ger> I dunno if everything-in-this-dir would be the right granularity
  927. # [20:23] <jgraham> No, well apache has a whole load of ad-hoc microsyntaxes for this stuff
  928. # [20:23] <jgraham> <FilesMatch "\.(vtt|json)$"> for example
  929. # [20:24] * Quits: SteveF (~chatzilla@93.158.51.47) (Ping timeout: 248 seconds)
  930. # [20:27] * Quits: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net) (Remote host closed the connection)
  931. # [20:27] * Quits: smaug____ (~chatzilla@a91-154-42-225.elisa-laajakaista.fi) (Read error: Operation timed out)
  932. # [20:29] * Joins: smaug____ (~chatzilla@a91-154-42-225.elisa-laajakaista.fi)
  933. # [20:30] * Quits: smaug____ (~chatzilla@a91-154-42-225.elisa-laajakaista.fi) (Read error: Operation timed out)
  934. # [20:33] * Joins: niloy (~niloy@124.40.244.213)
  935. # [20:33] * Joins: smaug____ (~chatzilla@a91-154-42-225.elisa-laajakaista.fi)
  936. # [20:34] <niloy> can someone tell me if transition events are suppose to bubble up?
  937. # [20:35] * Quits: sicking (~sicking@v-1045.fw1.sfo1.mozilla.net) (Quit: sicking)
  938. # [20:36] <TabAtkins> niloy: http://dev.w3.org/csswg/css-transitions/#transitionend
  939. # [20:37] <niloy> so the problem is, I have 'transitionend' on a parent element which I am interesed in, but a third party component is also using transition inside it
  940. # [20:37] <niloy> its bubbling up and messing up my code
  941. # [20:38] <niloy> the third party component is simply having transition effects
  942. # [20:38] * Joins: ehsan (~ehsan@66.207.208.102)
  943. # [20:38] <niloy> how should I handle this case?
  944. # [20:39] <TabAtkins> You've gotta figure out some way to distinguish the component's events from the ones you're interested in.
  945. # [20:41] <niloy> TabAtkins, okay... thanks, I would assume there are valid use cases for having the event bubble up
  946. # [20:41] <TabAtkins> Yeah, it's so you can put a listener on a parent element and listen to events from a bunch of children, rather than having to register individual listeners on everything.
  947. # [20:42] <niloy> but that can be said about 'load' & 'focus' too
  948. # [20:43] <TabAtkins> Sure. A lot of events bubble. Some don't. The reasoning is often historical.
  949. # [20:44] <niloy> okay!
  950. # [20:46] * Quits: encryptd_fractal (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Ping timeout: 240 seconds)
  951. # [20:47] * Quits: nimbu (~nimbu@192.150.10.205) (Ping timeout: 252 seconds)
  952. # [20:48] <bholley> Hixie_: back again
  953. # [20:48] <Hixie_> hey!
  954. # [20:49] <bholley> Hixie_: \o/
  955. # [20:49] <bholley> oh happy evening
  956. # [20:49] <bholley> Hixie_: so, shall we jump in?
  957. # [20:49] <bholley> Hixie_: do you prefer PM or here?
  958. # [20:50] * Quits: smaug____ (~chatzilla@a91-154-42-225.elisa-laajakaista.fi) (Read error: Operation timed out)
  959. # [20:50] * Joins: Smylers (~smylers@host86-180-214-205.range86-180.btcentralplus.com)
  960. # [20:50] * Quits: webben (~benjamin@198.61.227.102) (Quit: WeeChat 0.4.3-dev)
  961. # [20:52] * Joins: svl (~me@d154162.upc-d.chello.nl)
  962. # [20:54] * Joins: othermaciej (~mjs@17.114.218.23)
  963. # [20:55] * Quits: dbaron (~dbaron@50-0-248-3.dsl.dynamic.sonic.net) (Ping timeout: 264 seconds)
  964. # [20:55] * Joins: jonathanmarvens (~jonathanm@c-50-157-151-94.hsd1.ma.comcast.net)
  965. # [20:56] * Quits: rcombs (~rcombs@rcombs.me) (Ping timeout: 245 seconds)
  966. # [20:57] * Joins: sicking (~sicking@v-1045.fw1.sfo1.mozilla.net)
  967. # [20:57] * Joins: encryptd_fractal (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  968. # [20:59] * Joins: rcombs (~rcombs@rcombs.me)
  969. # [21:02] * bholley pokes Hixie_
  970. # [21:02] * Quits: baku (~baku@2-236-39-253.ip231.fastwebnet.it) (Ping timeout: 264 seconds)
  971. # [21:07] * Joins: baku (~baku@2-236-39-253.ip231.fastwebnet.it)
  972. # [21:07] * Joins: weinig (~weinig@17.114.217.25)
  973. # [21:11] <Hixie_> bholley: here's good
  974. # [21:11] <Hixie_> bholley: sorry, got distracted by some bug
  975. # [21:11] <bholley> Hixie_: cool
  976. # [21:11] <bholley> Hixie_: so
  977. # [21:11] <Hixie_> and for some reason had my volume low so didn't hear the beeps
  978. # [21:11] <bholley> Hixie_: per my last email, I think we should just do null prototypes for cross-origin objects
  979. # [21:11] <Hixie_> that makes things simpler, certainly
  980. # [21:11] <Hixie_> though doesn't that mean we need to move everything to the obejcts?
  981. # [21:11] <bholley> Hixie_: as in, making things |own|?
  982. # [21:12] <bholley> Hixie_: that's a good question. We wouldn't need to in Gecko, but I don't know how to spec that magic
  983. # [21:12] <Hixie_> as in, if the prototypes aren't there, then the methods better be somewhere that exists
  984. # [21:12] <bholley> Hixie_: I wonder how Blink deals with this
  985. # [21:12] * bholley tries to remember if Blink returns null or throws
  986. # [21:12] * Joins: nimbu (~nimbu@sjfw1-a.adobe.com)
  987. # [21:12] * bholley looks up the bug
  988. # [21:12] * Quits: nimbu (~nimbu@sjfw1-a.adobe.com) (Client Quit)
  989. # [21:13] <bholley> ok, yeah. Webkit/Blink throw
  990. # [21:13] <Hixie_> well either way, if you can't look up the prototype...
  991. # [21:13] <Hixie_> i guess the automatic lookup could be exempt
  992. # [21:13] <bholley> Hixie_: but yeah, anyway. Making them all |own| should be fine, I'd think
  993. # [21:13] * felipeduardo_ is now known as felipeduardo
  994. # [21:13] <Hixie_> (but then we'd still need to talk about the prototype being unique per origin)
  995. # [21:14] <bholley> Hixie_: I'm happy to experiment with this in Gecko if you like
  996. # [21:14] <Hixie_> making them |own| means putting them on the object directly?
  997. # [21:14] <bholley> Hixie_: (making them own)
  998. # [21:14] * Joins: krawchyk_ (~krawchyk@65.220.49.251)
  999. # [21:14] <bholley> Hixie_: right
  1000. # [21:14] <Hixie_> lgtm
  1001. # [21:14] <bholley> Hixie_: which isn't visible, given that enumeration is forbidden
  1002. # [21:14] <Hixie_> instanceof Location would stop working too, i guess
  1003. # [21:14] <bholley> Hixie_: except for Object.getOwnPropertyDescriptor
  1004. # [21:14] <Hixie_> if that even works now
  1005. # [21:14] <bholley> Hixie_: no, it would work
  1006. # [21:14] <bholley> Hixie_: per heycam's webIDL trick
  1007. # [21:14] <Hixie_> oh right, webidl does magic for instanceof
  1008. # [21:14] <Hixie_> forgot about that
  1009. # [21:14] <Hixie_> k
  1010. # [21:14] <bholley> Hixie_: it's not about the prototype, it's the branding
  1011. # [21:14] <bholley> Hixie_: ok, cool. Sorted
  1012. # [21:14] * bholley adds that to his list
  1013. # [21:15] <Hixie_> and that affects Location and Window, right?
  1014. # [21:15] <bholley> Hixie_: correct
  1015. # [21:15] <Hixie_> ok
  1016. # [21:15] <bholley> Hixie_: assuming we've since removed Document from the list of XO-available properties
  1017. # [21:15] <Hixie_> yeah, that's on my list
  1018. # [21:15] <Hixie_> making contentDocument and other ways of getting Documents throw
  1019. # [21:15] <bholley> Hixie_: I think the Gecko patch I landed has made it to release
  1020. # [21:15] * bholley checks
  1021. # [21:16] <bholley> Hixie_: yes. So proven to be web-compatible
  1022. # [21:16] <bholley> Mozilla23
  1023. # [21:16] <bholley> Hixie_: so, moving onto Location
  1024. # [21:17] * Quits: krawchyk (~krawchyk@65.220.49.251) (Ping timeout: 252 seconds)
  1025. # [21:18] <bholley> Hixie_: My proposal has been for both (a) security checks against the BC-principal at the time of invoke/get/set, and (b) security checks against the Document principal at the time of property lookup
  1026. # [21:18] <Hixie_> let's be very explicit when we talk about origins, rather than using terms like "BC-principal", because that got us into trouble last time we discussed this
  1027. # [21:19] <bholley> Hixie_: well, my beef is that the expansion of "BC-principal" is super long
  1028. # [21:19] <Hixie_> well sure
  1029. # [21:19] <Hixie_> just copy-and-paste :-)
  1030. # [21:20] <Hixie_> alternatively, we can define them once
  1031. # [21:20] <Hixie_> and then refer to them by letter or whatever
  1032. # [21:20] <bholley> Hixie_: "The principal of the document whose Window is the target of the WindowProxy of the same browsing context containing the Window whose Document is associated with the Location object we're discussing"
  1033. # [21:20] <Hixie_> by "principal" you mean "origin"?
  1034. # [21:20] <bholley> Hixie_: yes, sorry
  1035. # [21:21] <bholley> Hixie_: that is my definition of BC origin
  1036. # [21:21] <bholley> Hixie_: which is a mutable value
  1037. # [21:21] <Hixie_> so the origin of the active document of the browsing context of the Window of the Document of the Location object being accessed?
  1038. # [21:22] <Hixie_> what teh spec calls the "relevant Document"? http://www.whatwg.org/specs/web-apps/current-work/#location
  1039. # [21:22] <bholley> Hixie_: correct
  1040. # [21:22] <bholley> Hixie_: great
  1041. # [21:22] <Hixie_> ok
  1042. # [21:22] <bholley> Hixie_: "relevant document's origin"
  1043. # [21:23] * Quits: sicking (~sicking@v-1045.fw1.sfo1.mozilla.net) (Quit: sicking)
  1044. # [21:23] <bholley> Hixie_: that's a fine term to use
  1045. # [21:23] <bholley> Hixie_: contrasted with the "owner document's origin"
  1046. # [21:23] <Hixie_> owner document here being the one Location is associated with
  1047. # [21:23] * bholley isn't sure if something else should be used in lieu of the word "owner"
  1048. # [21:23] <bholley> Hixie_: ok
  1049. # [21:23] <Hixie_> ("Each Document object in a browsing context's session history is associated with a unique instance of a Location object")
  1050. # [21:23] <bholley> "associated document's origin" and "relevant document's origin"
  1051. # [21:23] <Hixie_> ok
  1052. # [21:23] <bholley> those terms good?
  1053. # [21:24] <Hixie_> "good" is relative, but they'll do :-)
  1054. # [21:24] <bholley> \o/
  1055. # [21:24] <bholley> so
  1056. # [21:24] <bholley> reframing
  1057. # [21:24] <bholley> My proposal has been for both (a) security checks against the relevant document origin at the time of invoke/get/set, and (b) security checks against the associated document origin at the time of property lookup
  1058. # [21:24] * Quits: weinig (~weinig@17.114.217.25) (Quit: weinig)
  1059. # [21:24] <bholley> Hixie_: IIRC, we at some point agreed on (a), but then the fog may have reappeared
  1060. # [21:25] * Quits: niloy (~niloy@124.40.244.213) (Quit: Leaving)
  1061. # [21:25] * Joins: nimbu (~nimbu@sjfw1-a.adobe.com)
  1062. # [21:26] <Hixie_> and we're comparing this origin to what, the script's incumbent origin?
  1063. # [21:26] <Hixie_> incumbent script's origin, rather
  1064. # [21:26] * bholley pauses to make sure he gets this right
  1065. # [21:27] <bholley> yes
  1066. # [21:27] <Hixie_> please hold, verifing...
  1067. # [21:28] * Joins: annevk (~annevk@92.66.135.189)
  1068. # [21:28] * bholley stirs his split-pea soup
  1069. # [21:28] * Joins: encrypt__ (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  1070. # [21:29] <Hixie_> hmm
  1071. # [21:29] <Hixie_> i disagree with (b), i think
  1072. # [21:29] <bholley> Hixie_: do you agree with (a)?
  1073. # [21:29] <Hixie_> i think so
  1074. # [21:29] * encrypt__ is now known as madPleasure
  1075. # [21:30] * madPleasure is now known as madPleasur3
  1076. # [21:30] <bholley> Hixie_: ok
  1077. # [21:30] <bholley> so
  1078. # [21:30] <bholley> b
  1079. # [21:30] * madPleasur3 is now known as madPleasure
  1080. # [21:30] <Hixie_> i think (a) is what i wrote at https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c32 in the four items in the dashed bulleted list
  1081. # [21:30] <Hixie_> (b) i disagree with because parent.siblingIframeInDifferentOrigin.location.replace(newurl) should work
  1082. # [21:31] <Hixie_> iirc
  1083. # [21:31] <Hixie_> but i think this gets to the first paragraph prefixed with # in that same comment
  1084. # [21:31] * Joins: weinig (~weinig@17.114.217.25)
  1085. # [21:31] <bholley> Hixie_: right - my beef with c32, which is what started this whole discussion, is that you switched _all_ security checks to use the "relevant document origin", when I believe we should only move half of them
  1086. # [21:31] <Hixie_> if we have that paragraph, we don't need (b) because you can't see any changes the owner document's origin does
  1087. # [21:32] <Hixie_> the #-paragraphs don't use the relevant origin
  1088. # [21:32] <Hixie_> they use the owner origin
  1089. # [21:32] * Quits: encryptd_fractal (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Ping timeout: 265 seconds)
  1090. # [21:32] <bholley> Hixie_: in c32?
  1091. # [21:32] * Joins: dbaron (~dbaron@v-1045.fw1.sfo1.mozilla.net)
  1092. # [21:32] <Hixie_> yeah
  1093. # [21:32] <bholley> "that's not the same as Location object's associated Document's
  1094. # [21:32] <bholley> browsing context's active document's effective script origin."
  1095. # [21:33] <bholley> Hixie_: that sounds like "relevant document origin" to me
  1096. # [21:33] <bholley> Hixie_: oh, I misunderstood "#'
  1097. # [21:34] <Hixie_> basically your (a) is trying to deal with the same attack vector as my 4 "-" paragraphs, and your (b) is trying to deal with the same attack vector s my 2 "#" paragraphs
  1098. # [21:34] <Hixie_> i think we agree on (a) entirely at this point
  1099. # [21:34] <bholley> Hixie_: I believe so, yes
  1100. # [21:34] <Hixie_> and (b) is where we disagree
  1101. # [21:34] <bholley> roger
  1102. # [21:34] <bholley> let me mull this for a second
  1103. # [21:34] <Hixie_> and when i say disagree, i mean you have a proposal, and i don't know shit
  1104. # [21:34] * Quits: othermaciej (~mjs@17.114.218.23) (Quit: othermaciej)
  1105. # [21:34] <Hixie_> because this stuff confuses me a lot :-)
  1106. # [21:38] <bholley> well, Hixie has a proposal too
  1107. # [21:39] <bholley> which I believe does indeed solve the same attack vector
  1108. # [21:39] <bholley> since they're "different objects"
  1109. # [21:39] <bholley> though
  1110. # [21:39] <Hixie_> i'm happy, eager even, to consider other ways to solve it
  1111. # [21:40] <Hixie_> i don't think your (b) really works though, because it prevents parent.siblingIframeInDifferentOrigin.location.replace(newurl) which i'm pretty sure (off the top of my head) should work
  1112. # [21:40] <Hixie_> i really should develop some console that makes cross-origin testing easier
  1113. # [21:40] <bholley> Hixie_: why would it prevent replace? replace is allowed cross-origin
  1114. # [21:41] <bholley> Hixie_: oh, sorry. I guess I'm baking in some assumptions here
  1115. # [21:41] <Hixie_> heh
  1116. # [21:41] <bholley> Hixie_: for the security checks I propose in (b), I'm proposing that the cross-origin-accessible properties remain accessible even if the security check fails
  1117. # [21:42] * Joins: madPleas_ (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  1118. # [21:42] <Hixie_> the attack i'm worried about is something like origin A does "self.location.replace.secret = document" and origin B tries to get to "thatOtherWindow.location.replace.secret"
  1119. # [21:42] <bholley> Hixie_: well, per spec, each has a different version of |replace|, right?
  1120. # [21:43] <Hixie_> well, i'm assuming that's not an assumption i should be making :-)
  1121. # [21:43] <Hixie_> if we're good with the #-paragraphs (which are what the spec says now), then i think we don't have any need for anything extra to handle (b)
  1122. # [21:43] <Hixie_> but do we want those paragraphs?
  1123. # [21:43] <Hixie_> i do not know
  1124. # [21:44] <bholley> Hixie_: well, those paragraphs aptly describe the Blink/WebKit architecture
  1125. # [21:44] <bholley> Hixie_: and less-so Gecko's Xray architecture
  1126. # [21:45] * Quits: madPleasure (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Ping timeout: 248 seconds)
  1127. # [21:45] <bholley> Hixie_: I'm happy to keep the spec mostly the way it is, but I'd like to keep the door open spec-wise for Xrays
  1128. # [21:45] * Quits: baku (~baku@2-236-39-253.ip231.fastwebnet.it) (Ping timeout: 248 seconds)
  1129. # [21:45] <bholley> since we may do that in Servo too (remains to be seen)
  1130. # [21:46] <Hixie_> well so long as there's no user-detectable difference, i am happy to open it as wide as a barn door can open
  1131. # [21:46] <Hixie_> author-detectable, i should say
  1132. # [21:46] <Hixie_> what would it mean to leave it open for Xrays?
  1133. # [21:47] <bholley> Hixie_: basically, I'm fine with continuing to orient the security bits of the spec as they are, so long as we're willing to occasionally tweak things one way or another so that they're implementable for us without pulling an Opera ;-)
  1134. # [21:47] <Hixie_> i certainly wish to do anything possible to ensure the continued existence of gecko
  1135. # [21:47] <Ms2ger> Heh
  1136. # [21:47] <Ms2ger> How about Servo?
  1137. # [21:47] <bholley> Hixie_: and, ideally, implementable for someone else who wants to do the Xray thing with less complexity than Mozilla's baggage requires
  1138. # [21:47] <bholley> (cough Servo)
  1139. # [21:48] <Hixie_> Ms2ger: i just want multiple entirely independent browser implementations. the more the better.
  1140. # [21:48] <bholley> amen
  1141. # [21:48] <Hixie_> bholley: what would that mean in concrete spec terms?
  1142. # [21:49] <bholley> Hixie_: so, in a nutshell - the spec describes a world in which we create a separate JS reflection of a given cross-origin object for each origin that observes it
  1143. # [21:49] <Hixie_> sounds right
  1144. # [21:49] <bholley> Hixie_: in this world, it doesn't really matter if each origin defines orthogonal sets of properties on the object, because they never interfere with each other
  1145. # [21:50] <Hixie_> right, though to make it easier to implement, you don't want to allow that, right?
  1146. # [21:51] <bholley> Hixie_: correct. With Xrays, all the origins look at the same object, but with a special set of glasses that filter out all the crap
  1147. # [21:51] <bholley> Hixie_: which works well until we start allowing those origins to put their own junk on the object as well
  1148. # [21:51] * Quits: madPleas_ (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Read error: Connection reset by peer)
  1149. # [21:51] * Joins: smaug____ (~chatzilla@a91-154-42-225.elisa-laajakaista.fi)
  1150. # [21:51] <bholley> Hixie_: we do, in fact, have the machinery to do that in Gecko, but I'd like to avoid exposing that to the web
  1151. # [21:52] <Hixie_> yeah
  1152. # [21:52] <Hixie_> sounds like what the spec says, right?
  1153. # [21:52] * Joins: krawchyk (~krawchyk@65.220.49.251)
  1154. # [21:52] <Hixie_> or does it need to be even tighter
  1155. # [21:52] <Hixie_> these glasses apply to everything including function objects like location.replace, right
  1156. # [21:52] <bholley> Hixie_: correct
  1157. # [21:53] <bholley> Hixie_: so currently, I don't see what in the spec would prevent each origin from defining funny properties on a cross-origin Location object
  1158. # [21:53] <Hixie_> and "These objects must have the prototype chain appropriate..." should be changed to say they're null prototypes?
  1159. # [21:53] <bholley> Hixie_: right
  1160. # [21:53] <Hixie_> yeah, i was coming to that conclusion too
  1161. # [21:55] <Hixie_> ok let me try to write some text, one sec
  1162. # [21:55] * Quits: krawchyk_ (~krawchyk@65.220.49.251) (Ping timeout: 252 seconds)
  1163. # [21:55] * Joins: madPleas_ (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  1164. # [21:58] <cabanier> Hixie_: "dismissing other people's concerns"
  1165. # [21:58] <Hixie_> bholley: ok what do you think of https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c50 ?
  1166. # [22:00] * Joins: sicking (~sicking@v-1045.fw1.sfo1.mozilla.net)
  1167. # [22:00] * Quits: madPleas_ (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Ping timeout: 265 seconds)
  1168. # [22:00] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.sonic.net)
  1169. # [22:01] * Joins: madPleas_ (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  1170. # [22:02] * Joins: davve (~user@83.218.67.122)
  1171. # [22:02] <annevk> bholley: so I was thinking... If ECMAScript were to define the multiple global story, it'd have to tackle some kind of abstract origin concept too, as realms could suddenly become connected or disconnected due to document.domain
  1172. # [22:02] <bholley> Hixie_: reading
  1173. # [22:03] * Quits: svl (~me@d154162.upc-d.chello.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  1174. # [22:03] <annevk> bholley: and if it does that, it'd have to define how objects referenced across globals were to behave once disconnected, which means we could argue for Gecko's arguably better design to be standardized
  1175. # [22:03] * Joins: SteveF (~chatzilla@93.158.51.47)
  1176. # [22:03] * Quits: weinig (~weinig@17.114.217.25) (Quit: weinig)
  1177. # [22:04] <bholley> annevk: yeah. I think it's the right approach, but it's a royal PITA for Webkit/Blink to implement
  1178. # [22:04] * Joins: weinig (~weinig@17.114.217.25)
  1179. # [22:04] <annevk> prolly also Trident
  1180. # [22:04] <annevk> I wonder what Allen's plan with respect to this is at the moment
  1181. # [22:05] <annevk> Multiple globals is definitely on the table, but maybe it's not ES6 material
  1182. # [22:05] * Quits: reyre (~reyre@142.204.133.18) (Remote host closed the connection)
  1183. # [22:05] <Hixie_> annevk: btw while you're here... what's the story with application/x-www-form-urlencoded? seems URL has some version of it, but not quite the same as HTML?
  1184. # [22:05] <annevk> Hixie_: my idea was for it to move to URL
  1185. # [22:05] <annevk> Hixie_: differences might be bugs
  1186. # [22:06] <annevk> Hixie_: sorry :/
  1187. # [22:06] <Hixie_> wouldn't that lead to dependencies from URL to HTML?
  1188. # [22:07] <Hixie_> e.g. for <isindex>?
  1189. # [22:07] <Hixie_> and accept-charset and so on?
  1190. # [22:08] <annevk> Hixie_: I figured those would just be parameters to the algorithm
  1191. # [22:08] <Hixie_> oh so we'd split the algorithm in half?
  1192. # [22:08] <annevk> Hixie_: e.g. part of the application/x-www-form-urlencoded format
  1193. # [22:09] <annevk> s/e.g./as in/
  1194. # [22:11] <bholley> Hixie_: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c51
  1195. # [22:12] <bholley> Hixie_: the only big question there is whether we're willing to disallow property modifications on alien objects
  1196. # [22:12] <bholley> Hixie_: if we are, I think the rest will work
  1197. # [22:12] <Hixie_> i am. dunno if others are. :-)
  1198. # [22:12] <Hixie_> abarth: ping
  1199. # [22:12] <bholley> Hixie_: it'll involve some hackery on the Gecko end, but stuff I'm totally willing to do to settle the spec stuff on this
  1200. # [22:13] <Hixie_> bholley: what do you mean by "not be able to define or modify", btw? Throw? No-op? Do whatever freezing does?
  1201. # [22:14] <Hixie_> annevk: i dunno, it seems like it'd make the algorithms much harder to follow and i don't see the real gain to be had
  1202. # [22:14] <abarth> Hixie_: hi
  1203. # [22:14] <bholley> Hixie_: it's up for debate. We currently throw for the cross-origin objects themselves, and don't do any checks on the functions pulled off of them. If we made the functions alien objects, it's probably simplest to do it by Freezing them
  1204. # [22:14] <Hixie_> abarth: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c50 and 51 and 52
  1205. # [22:15] <bholley> Hixie_: at which point it probably makes the most sense to cause Location and Window to implement frozen semantics
  1206. # [22:15] <bholley> Hixie_: which we can probably do
  1207. # [22:15] <Hixie_> bholley: on the alien versions? makes sense to me.
  1208. # [22:15] <Hixie_> bholley: what exactly are freezing semantics?
  1209. # [22:15] <bholley> Hixie_: I don't know - presumably they're defined in ES?
  1210. # [22:15] <annevk> Hixie_: URL needs the serialization algorithm for URLQuery
  1211. # [22:16] <annevk> Hixie_: XMLHttpRequest needs it for sending URLQuery to a server
  1212. # [22:16] <Hixie_> annevk: hm, interesting
  1213. # [22:16] <Hixie_> annevk: ok, will look more later. might just end up having two versions one for forms and one for the cleaner stuff.
  1214. # [22:16] <abarth> Hixie_: I don't think we're going to implement that
  1215. # [22:16] <annevk> Hixie_: for similar reasons I'm afraid I might end up defining multipart/form-data
  1216. # [22:17] <Hixie_> annevk: larry said he's respeccing that; see the bug
  1217. # [22:17] <Hixie_> annevk: send him feedback
  1218. # [22:17] <abarth> Hixie_: that requires JS engine magic
  1219. # [22:17] <annevk> Hixie_: yeah, I have some private email I need to go through
  1220. # [22:17] <Hixie_> i have to go to lunch, any change abarth and bholley you can discuss this amongst yourselves while i forage? :-)
  1221. # [22:17] <annevk> Hixie_: lets avoid multiple algorithms that are essentially the same though
  1222. # [22:17] <abarth> bholley: hi
  1223. # [22:17] * Ms2ger finds it pretty funny that Servo has new Comment(), but not document.createComment()
  1224. # [22:18] * Quits: krawchyk (~krawchyk@65.220.49.251) (Remote host closed the connection)
  1225. # [22:18] <abarth> bholley: I don't really understand the problem you're trying to solve
  1226. # [22:18] <abarth> bholley: can you help me understand?
  1227. # [22:18] <bholley> abarth, Hixie_: I actually have to eat dinner
  1228. # [22:18] <abarth> ok
  1229. # [22:18] <bholley> abarth: can I ping you back in a little bit?
  1230. # [22:18] <abarth> sure
  1231. # [22:18] <bholley> abarth: cool
  1232. # [22:20] * Quits: weinig (~weinig@17.114.217.25) (Quit: weinig)
  1233. # [22:20] * Joins: madPleasure (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  1234. # [22:22] * Quits: annevk (~annevk@92.66.135.189) (Remote host closed the connection)
  1235. # [22:23] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
  1236. # [22:23] * Joins: annevk (~annevk@92.66.135.189)
  1237. # [22:23] * Quits: madPleas_ (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Ping timeout: 248 seconds)
  1238. # [22:24] * Quits: davve (~user@83.218.67.122) (Remote host closed the connection)
  1239. # [22:25] * Joins: barnabywalters (~barnabywa@89.17.128.127)
  1240. # [22:26] * Quits: barnabywalters (~barnabywa@89.17.128.127) (Client Quit)
  1241. # [22:27] * Quits: annevk (~annevk@92.66.135.189) (Ping timeout: 240 seconds)
  1242. # [22:28] * Quits: madPleasure (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Ping timeout: 248 seconds)
  1243. # [22:28] * Joins: madPleasure (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  1244. # [22:33] * Joins: madPleas_ (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  1245. # [22:34] * Quits: madPleasure (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Ping timeout: 252 seconds)
  1246. # [22:36] * Quits: Ms2ger (~Ms2ger@91.182.63.25) (Ping timeout: 248 seconds)
  1247. # [22:40] * Quits: nimbu (~nimbu@sjfw1-a.adobe.com) (Quit: Leaving.)
  1248. # [22:46] * Joins: nimbu (~nimbu@sjfw1-a.adobe.com)
  1249. # [22:51] * Joins: Ms2ger (~Ms2ger@91.182.63.25)
  1250. # [22:53] * Quits: TallTed (~Thud@63.119.36.36)
  1251. # [22:55] * Joins: weinig (~weinig@17.114.217.25)
  1252. # [22:59] * Quits: weinig (~weinig@17.114.217.25) (Ping timeout: 240 seconds)
  1253. # [23:00] <Hixie_> bholley: (back)
  1254. # [23:00] * Quits: umgrosscol (~umgrossco@grosscol.umdl.umich.edu) (Quit: Nettalk6 - www.ntalk.de)
  1255. # [23:02] * Joins: weinig (~weinig@17.114.217.25)
  1256. # [23:12] * Quits: smaug____ (~chatzilla@a91-154-42-225.elisa-laajakaista.fi) (Remote host closed the connection)
  1257. # [23:13] * Quits: Maurice (copyman@5ED57922.cm-7-6b.dynamic.ziggo.nl)
  1258. # [23:15] * Joins: sgalineau (~sylvaing@192.150.10.208)
  1259. # [23:17] * Joins: smaug____ (~chatzilla@a91-154-42-225.elisa-laajakaista.fi)
  1260. # [23:26] * Quits: rcombs (~rcombs@rcombs.me) (Ping timeout: 245 seconds)
  1261. # [23:26] * Joins: rcombs (~rcombs@rcombs.me)
  1262. # [23:31] * Quits: Ms2ger (~Ms2ger@91.182.63.25) (Quit: nn)
  1263. # [23:32] * Quits: madPleas_ (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Ping timeout: 248 seconds)
  1264. # [23:32] * Joins: madPleasure (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  1265. # [23:32] * Quits: ehsan (~ehsan@66.207.208.102) (Read error: Connection reset by peer)
  1266. # [23:33] * Joins: ehsan (~ehsan@66.207.208.102)
  1267. # [23:36] * Quits: Smylers (~smylers@host86-180-214-205.range86-180.btcentralplus.com) (Ping timeout: 248 seconds)
  1268. # [23:36] * Joins: rxgx (~rxgx@64.38.203.218)
  1269. # [23:36] * Quits: SteveF (~chatzilla@93.158.51.47) (Ping timeout: 264 seconds)
  1270. # [23:38] * Quits: ap (~ap@2620:149:4:304:ad81:9d9f:6055:972b) (Quit: ap)
  1271. # [23:38] * Joins: ap (~ap@17.245.27.252)
  1272. # [23:38] * Quits: smaug____ (~chatzilla@a91-154-42-225.elisa-laajakaista.fi) (Remote host closed the connection)
  1273. # [23:39] * Joins: smaug____ (~chatzilla@a91-154-42-225.elisa-laajakaista.fi)
  1274. # [23:41] * Joins: madPleas_ (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  1275. # [23:42] * Quits: ap (~ap@17.245.27.252) (Ping timeout: 245 seconds)
  1276. # [23:44] * Quits: madPleasure (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Ping timeout: 248 seconds)
  1277. # [23:45] * Joins: madPleasure (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  1278. # [23:46] * Joins: reyre (~reyre@CPE7cb21b1e2cf4-CM7cb21b1e2cf1.cpe.net.cable.rogers.com)
  1279. # [23:48] * Quits: madPleas_ (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Ping timeout: 252 seconds)
  1280. # [23:49] <Hixie_> cabanier: you say you're not proposing anything, but aren't you in fact proposing that the spec change?
  1281. # [23:49] <Hixie_> or did i misunderstand the conversation?
  1282. # [23:50] <cabanier> Hixie_: I want the spec to reflect reality
  1283. # [23:50] <Hixie_> reality is there's one browser whose feature that nobody yet uses, no?
  1284. # [23:50] <Hixie_> s/that//
  1285. # [23:51] <Hixie_> i mean, i want the spec to reflect reality too, but generally there's two ways to do that.
  1286. # [23:51] * Joins: madPleas_ (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com)
  1287. # [23:51] <Hixie_> and if we're not constrained by legacy content, we should pick the better solution.
  1288. # [23:51] <cabanier> I think we're already constrained
  1289. # [23:52] <cabanier> ie http://paperjs.org/reference/style/
  1290. # [23:52] <Hixie_> i don't see what about that page constrains us
  1291. # [23:52] <cabanier> not sure how paper.js works under the hood but they must already rely
  1292. # [23:53] * Quits: jreading (Adium@nat/novell/x-egnpkzhfpjcqvqiw) (Ping timeout: 252 seconds)
  1293. # [23:53] <cabanier> on existing dashing behavior
  1294. # [23:53] <cabanier> pdf.js is shipping too in firefox
  1295. # [23:53] * Quits: nimbu (~nimbu@sjfw1-a.adobe.com) (Quit: Leaving.)
  1296. # [23:53] <Hixie_> paper.js alone wouldn't constrain us, it'd have to be some software built on paper.js that relies on a particular dashing behaviour
  1297. # [23:53] <cabanier> well, yes :-)
  1298. # [23:53] <Hixie_> firefox doesn't yet implement the spec's API, so it doesn't constrain us either as far as I can tell
  1299. # [23:54] * Quits: madPleasure (~encryptd_@66-188-99-174.static.ftbg.wi.charter.com) (Ping timeout: 248 seconds)
  1300. # [23:54] <cabanier> they use a prefixed API that's basically the same
  1301. # [23:54] <Hixie_> the example on http://paperjs.org/reference/style/ really supports justin's proposal, i have to say
  1302. # [23:54] <cabanier> yeah. it does look nicer
  1303. # [23:55] * Quits: zdobersek (~zdobersek@cpe-77.38.31.63.cable.t-1.si) (Quit: ZNC - http://znc.in)
  1304. # [23:55] <cabanier> but again, if we want to help authors that have existing content, we should follow what the graphics libraries do
  1305. # [23:55] <Hixie_> if there's existing content, but is there?
  1306. # [23:56] <cabanier> svg?
  1307. # [23:56] <cabanier> flash?
  1308. # [23:56] <cabanier> pdf?
  1309. # [23:56] <cabanier> gdi?
  1310. # [23:56] <Hixie_> neither of those are canvas.
  1311. # [23:56] <cabanier> but people are porting their assets to canvas
  1312. # [23:56] <Hixie_> and all of those could work with justin's proposal trivially
  1313. # [23:56] <cabanier> nono, Justin's proposal is actually quite hard
  1314. # [23:57] <cabanier> and wouldn't match existing SVG assets
  1315. # [23:57] <Hixie_> because...?
  1316. # [23:57] <cabanier> ?
  1317. # [23:58] * Joins: nimbu (~nimbu@sjfw1-a.adobe.com)
  1318. # [23:58] <cabanier> because it would render dashes differently
  1319. # [23:58] <Hixie_> (i feel our conversations would go much quicker if when you made an assertion, you immediately explained it, rather than waiting for me to prompt you to tell me why you made it)
  1320. # [23:58] <Hixie_> justin's proposal is to not stop the dashes, unless there's an annotation that says to reset the dash offset, yes?
  1321. # [23:58] <cabanier> Justin's proposal rearranges dashes so they don't fall on joins or endcaps
  1322. # [23:58] <Hixie_> so it would be trivial to port any path from svg to canvas, you'd just have to reset the dash offset when you do a moveTo or whichever
  1323. # [23:59] <Hixie_> oh i just meant his simpler proposal
  1324. # [23:59] <Hixie_> sure, his more elaborate one would need more in-depth changes.
  1325. # [23:59] <cabanier> let me look that one up.
  1326. # [23:59] * Joins: ap (~ap@17.245.106.45)
  1327. # Session Close: Fri Oct 11 00:00:01 2013

The end :)