/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 :)