/irc-logs / freenode / #whatwg / 2011-10-13 / end

Options:

1. # Session Start: Thu Oct 13 00:00:01 2011
2. # Session Ident: #whatwg
3. # [00:00] <jgraham> TabAtkins: In what way? The discussion is precisely about the DOM replacement in Dart
4. # [00:00] <jgraham> If you're not talking about it, you are the only one
5. # [00:00] <TabAtkins> jgraham: Not at all. Dart happens to be provoking the discussion, but I don't give a crap about Dart. I care about better DOM.
6. # [00:00] <TabAtkins> jgraham: Um, Anne's not talking about Dart either. By his own direct admission.
7. # [00:01] <smaug____> TabAtkins: isn't the DOM4 work exactly about fixing the problems of old DOM API
8. # [00:01] <jgraham> TabAtkins: So propose the better DOM APIs
9. # [00:01] <TabAtkins> smaug____: In general, yes. I think annevk is too conservative, though. ^_^
10. # [00:01] <jgraham> I haven't really seen people do that
11. # [00:01] <jgraham> Apart from all the hand-wringing about what new HTMLFooElement should do
12. # [00:01] <TabAtkins> jgraham: The Dart APIs are, roughly, what several of us Google engineers working on JS would like to see in DOM.
13. # [00:01] <bga_> TabAtkins sometimes any even very good software is needed to be completely rewritten
14. # [00:02] <smaug____> TabAtkins: propose better DOM APIS ;)
15. # [00:02] <TabAtkins> Me, Alex Russell, Erik Arvidsson, etc.
16. # [00:02] <jgraham> TabAtkins: So propose them then...
17. # [00:02] <smaug____> APIs
18. # [00:02] <krijn> Don't fight kids!
19. # [00:02] <annevk> TabAtkins, conservative how? I just think mode switching is bad idea
20. # [00:02] <TabAtkins> annevk: You underestimate the aggregate pain that the sucky DOM causes to authors, and assert that nobody uses the DOM, so it's all right.
21. # [00:03] <jgraham> krijn: In England we fight kids: http://www.guardian.co.uk/uk/2011/sep/21/eight-year-old-children-cage-fight-preston
22. # [00:03] <annevk> I didn't say the DOM is all right
23. # [00:03] <krijn> o_O
24. # [00:04] <jgraham> TabAtkins: But there's no one trying to fix it. So far we have the Element.create suggestion (which I like) and the new HTMLElement suggestion (which doesn't work at all)
25. # [00:04] <jgraham> That's it
26. # [00:04] <jgraham> krijn: Indeed
27. # [00:04] <bga_> TabAtkins how many times you deprecate oк remove some ability during dom0-dom4?
28. # [00:05] <annevk> TabAtkins, anyway, what I think does not really matter, what matters so far is that there is a lot of noise, but not so much signal, about a better DOM
29. # [00:05] <TabAtkins> jgraham: No one trying to fix it? Alex and Arv have been pushing forever on making NodeList be an array, for example.
30. # [00:05] <bga_> i never heard that some feature was removes
31. # [00:05] * smaug____ is having hard time to find good things in the (dart) DOM API
32. # [00:05] <TabAtkins> smaug____: I... I don't understand how that is possible.
33. # [00:05] <jgraham> TabAtkins: iirc that doesn't work either
34. # [00:05] <annevk> I guess tied to Dart there is some signal now, but I am personally hoping for it to be on www-dom
35. # [00:06] <jgraham> It is easy to come up with unworkable ideas of course
36. # [00:06] <TabAtkins> smaug____: Or pehraps you're not looking at the negative space, the fact that the Element interface is, like, a dozen methods/attributes now.
37. # [00:06] <krijn> I want Element.nyanCatify()
38. # [00:07] <TabAtkins> annevk: Dart is useful as a "hey look at this!", since individual feature suggestions are often shot down with "the DOM isn't really that painful" by you and others. ^_^
39. # [00:07] <krijn> annevk: btw, did we meet on Wednesday?
40. # [00:08] <annevk> krijn, last week, briefly?
41. # [00:08] * Quits: othermaciej (~mjs@17.245.90.53) (Quit: othermaciej)
42. # [00:08] <krijn> Hm
43. # [00:08] <krijn> Don't know what was in the beer on that boat, but I'm missing some parts
44. # [00:09] * Joins: davidb_ (~davidb@bas1-toronto06-2925210074.dsl.bell.ca)
45. # [00:09] <smaug____> "(For mysterious reasons, these are named allinlowercase unlike the rest of the DOM.)" ?
46. # [00:09] * Quits: sylvaing (~sylvaing@c-98-232-9-174.hsd1.wa.comcast.net)
47. # [00:09] <TabAtkins> elem.onclick="..."
48. # [00:09] <smaug____> what is mysterious about onfoo handlers
49. # [00:09] <TabAtkins> As opposed to elem.onClick="..."
50. # [00:10] * Joins: tmzt_ (~tmzt@adsl-99-164-50-164.dsl.akrnoh.sbcglobal.net)
51. # [00:10] <smaug____> they are all lowercase because the content attributes in HTML are lowercase
52. # [00:10] <TabAtkins> We usually camelcase in JS.
53. # [00:10] <smaug____> nothing mysterious there
54. # [00:10] <TabAtkins> smaug____: That's not a general pattern.
55. # [00:10] <bga_> TabAtkins dom isnt painful because we can completely change it api via dom prototypes. s/length/size/ for example
56. # [00:10] * Joins: othermaciej (~mjs@17.245.90.53)
57. # [00:10] <TabAtkins> We camelcase some things that are uncased in the content attributes.
58. # [00:11] * Quits: mven (~mven__@169.241.49.57) (Quit: Leaving)
59. # [00:11] <TabAtkins> bga_: That's not a valid argument. Libraries *can* fix anything. They shouldn't be required, though.
60. # [00:11] <smaug____> the new event registration mechanism looks also broken
61. # [00:11] <smaug____> what if I want to add listener for event "foo"
62. # [00:12] <smaug____> would it be then elem.on.foo.add (...)
63. # [00:12] <smaug____> and that foo property would magically appear in the 'on' object
64. # [00:12] <bga_> smaug____ el.onFoo.add is better
65. # [00:13] * Quits: tmzt (~tmzt@adsl-99-164-48-159.dsl.akrnoh.sbcglobal.net) (Ping timeout: 240 seconds)
66. # [00:13] <smaug____> ah, it says "we also put a subscript operator on NodeEvents."
67. # [00:13] <TabAtkins> smaug____: Yes, though I think you have to use the subscript operator.
68. # [00:13] <TabAtkins> elem.on['foo'].add()
69. # [00:14] <smaug____> anyway, don't understand why to change onclick = value to on.click.add(value);
70. # [00:14] <bga_> because its not add
71. # [00:14] <bga_> its assign
72. # [00:15] <annevk> smaug____, the latter allows for multiple
73. # [00:16] <smaug____> I wonder where <element onclick="adlfkm"> handler appears
74. # [00:16] <smaug____> ah, it does allow multiple
75. # [00:16] <smaug____> but it breaks onfoo idl vs content attribute mapping
76. # [00:16] <smaug____> ah, well
77. # [00:16] <smaug____> I just don't care this
78. # [00:16] * Joins: dominicc|home (~dominicc@114.167.184.208)
79. # [00:16] <smaug____> won't implement any of this stuff anyway
80. # [00:16] <bga_> smaug____ my friend made small monkey patch which replace on* properties to setters which calls addEventLisneters
81. # [00:17] <smaug____> bga_: how does that work?
82. # [00:17] <smaug____> er
83. # [00:18] <smaug____> ah, yes, defineProperty or some such
84. # [00:18] <bga_> yes
85. # [00:18] <smaug____> replacing Element.property.onclick by assigning a new value wouldn't ofc work
86. # [00:18] <bga_> smaug____ but its points vector
87. # [00:18] <arv> One of the goals with the on property was to unify the onfoo and the addEventListener("foo") mess
88. # [00:18] * heycam|away is now known as heycam
89. # [00:19] <smaug____> what is the mess with onfoo and addEventListener?
90. # [00:20] <TabAtkins> onfoo is annoying because it can only accept a single listener. However, it's short, while addEventListener is super-verbose and painful.
91. # [00:20] <arv> I assume you think it is good to have 2 different ways? I know there are minor differences but who cares?
92. # [00:20] <TabAtkins> You want short and easy for such a common thing. You also want a single way to do it if possible.
93. # [00:20] <smaug____> how is addEventListener painful?
94. # [00:21] <smaug____> ok, it is a bit long method name, but that is all
95. # [00:21] <arv> and having strings as type sucks because it does not catch typos
96. # [00:21] * Joins: tmzt (~tmzt@adsl-76-253-134-36.dsl.akrnoh.sbcglobal.net)
97. # [00:21] <TabAtkins> "That is all"? That's the whole problem. The DOM is stuffed full of painfully long names for no reason.
98. # [00:21] <TabAtkins> That just makes your code huge and hard to both type and read.
99. # [00:21] <smaug____> you elem.on['foo'] doesn't catch typos either
100. # [00:21] <smaug____> yuor
101. # [00:21] <smaug____> your
102. # [00:22] <smaug____> :)
103. # [00:22] <dominicc|home> and boolean parameters make understanding call sites harder
104. # [00:22] <TabAtkins> It's impossible to catch typos in arbitrary user-creted events, obviously.
105. # [00:22] <arv> That is all? Seriously. You don't think it is flawed in any other way than the length?
106. # [00:22] <TabAtkins> Oh god, I completely forgot abotu the boolean parameter in aEL. >_<
107. # [00:22] <smaug____> dominicc|home: you don't need to use boolean parameters with add/removeEventListener
108. # [00:22] <bga_> 1st what you can do is make Element.prototype.on = Element.prototype.addEventListener
109. # [00:22] <TabAtkins> ...yes you do.
110. # [00:22] <TabAtkins> If you don't use it, it's a violation, and makes FF angry.
111. # [00:22] <smaug____> there is no need to use boolean parameter
112. # [00:22] <smaug____> no
113. # [00:23] * Joins: Rik` (~Rik`@2a01:e34:ec0f:1570:e549:b971:6ae9:9da7)
114. # [00:23] <arv> ff was fixed so, it is a step in the right direction
115. # [00:23] <arv> but
116. # [00:23] <arv> still
117. # [00:23] * Joins: mven (~mven__@169.241.49.57)
118. # [00:23] <TabAtkins> Ah, wasn't aware it was fixed.
119. # [00:23] <arv> reading a true or false at the end is still painful for the cases where it does matter
120. # [00:23] <annevk> wait are we looking at DOM4 or Firefox?
121. # [00:23] <smaug____> spec was fixed (and then gecko started to follow the spec)
122. # [00:23] <dominicc|home> They’re optional I think. But still there… MDN says Mozilla has a second optional bool now.
123. # [00:23] <TabAtkins> Still, seeing "someMethod(foo, bar, true)" kills me.
124. # [00:23] <annevk> because that's been optional since forever
125. # [00:24] <TabAtkins> dominicc|home: Oh jeezus.
126. # [00:24] <smaug____> they were may optional actually because it was a bug in webkit that it allowed to leave out the last parameter :)
127. # [00:24] * Quits: david_carlisle (~chatzilla@dcarlisle.demon.co.uk) (Ping timeout: 258 seconds)
128. # [00:24] <smaug____> s/may//
129. # [00:24] * Quits: tmzt_ (~tmzt@adsl-99-164-50-164.dsl.akrnoh.sbcglobal.net) (Ping timeout: 276 seconds)
130. # [00:25] <dominicc|home> So addEventListener has many infelicities.
131. # [00:25] <arv> WebKit just followed common js practice. Makes me smile every time when that happens
132. # [00:25] <arv> (but it does not happen often enough)
133. # [00:25] <smaug____> and not following the spec?
134. # [00:25] <smaug____> and not even filing spec bug
135. # [00:25] <arv> The specs should follow reality, not the other way around
136. # [00:26] <annevk> it's nice to tell the spec list if you think reality has shifted though
137. # [00:26] <smaug____> is webkit the reality ?
138. # [00:26] <annevk> also
139. # [00:26] <annevk> webkit is changing their practice
140. # [00:26] <annevk> and making arguments required
141. # [00:26] * Quits: davidb_ (~davidb@bas1-toronto06-2925210074.dsl.bell.ca) (Quit: davidb_)
142. # [00:27] <annevk> so it's not as simple as you say
143. # [00:27] <arv> nothing is as simple as I say
144. # [00:27] <annevk> that fourth addEventListener argument is something Mozilla did not propose anywhere btw smaug____
145. # [00:27] <TabAtkins> Not even the DOM.
146. # [00:28] * Joins: shans (~shanestep@202.171.174.250)
147. # [00:29] <smaug____> annevk: very true. But if I do something wrong doesn't make it ok for others to do wrong ;)
148. # [00:29] * Quits: shans (~shanestep@202.171.174.250) (Client Quit)
149. # [00:29] <smaug____> and unfortunately 4th parameter was added long ago
150. # [00:29] <arv> annevk: I'm well aware that it is hard work to spec these things and I appreciate all the good work you (and others) are doing
151. # [00:30] <arv> One of the reasons why we chose to experiment with this in the Dart DOM was because we could do this without the risk of not breaking anything since there is no Dart code out there
152. # [00:31] <dominicc|home> arv: And since Dart is "developer preview" you expect to be able to make breaking changes for a while, right?
153. # [00:32] <arv> and we were tired of doing another blind webidl to dart conversion which would fit dart as badly as webidl fits js today
154. # [00:32] <arv> do
155. # [00:32] <arv> m
156. # [00:32] <arv> 
157. # [00:32] <arv> dominicc|home: yes
158. # [00:32] * Quits: robman (~robman@eth4584.nsw.adsl.internode.on.net) (Ping timeout: 245 seconds)
159. # [00:32] <smaug____> what is wrong with webidl <-> js?
160. # [00:33] <TabAtkins> smaug____: WebIDL still encourages horrifyingly bad impedance mismatch with what good JS APIs should be.
161. # [00:33] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
162. # [00:33] * Quits: jarek__ (~jarek@aeat198.neoplus.adsl.tpnet.pl) (Ping timeout: 276 seconds)
163. # [00:34] <smaug____> really?
164. # [00:34] <annevk> I don't really mind Dart that much. What I mind is all the screaming that the DOM is broken and then either not proposing anything or coming up with proposals that are unworkable when you look at the details.
165. # [00:34] <annevk> And of course there are some more constructive proposals too, e.g. from Ojan, so it's not all bad.
166. # [00:34] * Joins: jarek__ (~jarek@79.186.10.184)
167. # [00:34] <arv> annevk: I totally agree with that point. There are too many haters out there
168. # [00:35] <arv> Also Ojan is awesome =D
169. # [00:35] <annevk> TabAtkins, yeah, I hear that all the time, "omgwtfbbq Web IDL is terrible"
170. # [00:36] <annevk> please do propose a workable alternative or just appreciate the fact it's so much vastly better than what we had before
171. # [00:36] <TabAtkins> annevk: I know it's vastly better than what we had before.
172. # [00:36] <TabAtkins> It's not perfect, though, dammit!
173. # [00:39] <smaug____> TabAtkins: but really, what is bad in WebIDL?
174. # [00:39] <TabAtkins> arv would be able to answer better than I, but in general it's still relatively hard to design properly idiomatic APIs in WebIDL.
175. # [00:39] <smaug____> (I apparently just don't know why people are complaining about WebIDL)
176. # [00:40] * Joins: shans (~shanestep@202.171.174.250)
177. # [00:41] <arv> One of the problem with WebIDL is that it is language neutral which leads to impedance mismatch. For example, webidl attributes almost always have side effects and as such needs to be done as getters and setters to follow JS semantics. Some of these things are hidden in prose in webidl
178. # [00:42] <arv> other things include interceptors which cannot be done in JS without ES6 proxies
179. # [00:43] <dominicc|home> arv: And your contention is that, because the attribute setters have side effects, it would be more idiomatic in JS if they were functions?
180. # [00:43] <arv> dominicc|home: JS has setters and getters (unlike java which uses getFoo and setFoo)
181. # [00:44] <dominicc|home> arv: Right. So… what is the problem with mapping attributes to getters and setters?
182. # [00:44] * jernoble is now known as jernoble|afk
183. # [00:44] <rniwa> Hixie: ping
184. # [00:44] <Hixie> pong
185. # [00:44] <arv> yes, and this is being taken care of in the latest webidl spec
186. # [00:45] <rniwa> Hixie: i'm confused about your comment on https://bugs.webkit.org/show_bug.cgi?id=68610
187. # [00:45] <rniwa> Hixie: are you saying that itemtype is a space-separated list of types?
188. # [00:45] <rniwa> Hixie: or are you saying it is not
189. # [00:45] <Hixie> it is now a space-separated list of types
190. # [00:45] <Hixie> as of about 24 hours ago
191. # [00:45] <rniwa> :(
192. # [00:47] <annevk> arv, do you mean in Web IDL the specification or in the language it defines?
193. # [00:47] <rniwa> Hixie: ok, but I'm more inclined to prefix all attributes now
194. # [00:47] <Hixie> heh
195. # [00:47] <rniwa> I thought the spec was relatively stable but apparently not
196. # [00:48] <Hixie> it should be a backwards-compatible change for any existing content
197. # [00:48] <arv> annevk: I'm not fully sure. Can you clarify that question?
198. # [00:48] <rniwa> that seems to indicate that there's a chance we'll have incompatible changes in the future
199. # [00:48] <rniwa> or that we might end up wanting to make incompat. changes but can't due to backward compat.
200. # [00:48] <Hixie> rniwa: we make changes to things that have been "stable" for 15 years sometimes
201. # [00:48] <Hixie> rniwa: doesn't mean it won't change
202. # [00:48] <rniwa> Hixie: does any other vendor besides WebKit implement this?
203. # [00:48] <Hixie> rniwa: what i try to ensure is that changes don't break shipped code
204. # [00:49] <Hixie> rniwa: opera may, not sure (foolip?)
205. # [00:49] <annevk> arv, is it a problem that specifications need to use "attribute DOMString x;" for what is essentially a getter/setter? Or is it a problem with how Web IDL defines "attribute"?
206. # [00:50] <arv> annevk: I would have been happier if the specification was done in ES5 code
207. # [00:50] <arv> annevk: I think the part that explains how to map Web IDL to ES5 already says that they should be implemented as getters and setters on the prototype.
208. # [00:50] <smaug____> rniwa: microdata?
209. # [00:51] <smaug____> rniwa: there is a patch for gecko, but it needs to be updated ...
210. # [00:51] <rniwa> smaug____: ok. are you prefixing attributes?
211. # [00:51] <rniwa> smaug____: or new methods on Document/Element?
212. # [00:51] <annevk> how would you enforce any kind of consistency if specifications need to define all the ES details themselves?
213. # [00:51] * smaug____ is looking at the patch
214. # [00:52] <Hixie> rniwa: prefixing attributes doesn't solve this, btw
215. # [00:52] <Hixie> rniwa: it just adds even more trouble, with authors having to use multiple apis
216. # [00:52] <annevk> Opera is unprefixed fwiw
217. # [00:52] <rniwa> Hixie: yeah but it'll at least discourage ppl from widely deploying it until we remove prefixing
218. # [00:52] <smaug____> optional_argc] nsIDOMNodeList getItems([optional] in DOMString types);
219. # [00:52] <Hixie> rniwa: we don't _want_ to discourage people
220. # [00:52] * bga_ is now known as bga_|away
221. # [00:53] <Hixie> smaug____: it's itemType that's changed, not getItems()
222. # [00:53] <rniwa> Hixie: well, I'd like to discourage until API is stable
223. # [00:53] <Hixie> rniwa: the API won't be stable for decades
224. # [00:53] <rniwa> smaug____: no prefixes then?
225. # [00:53] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 248 seconds)
226. # [00:53] <Hixie> rniwa: and then it'll be obsolete
227. # [00:53] <rniwa> Hixie: I disagree.
228. # [00:53] <Hixie> rniwa: what do you mean by "Stable"?
229. # [00:53] <rniwa> Hixie: by stable, I mean that it won't have radial changes like WebSocket did
230. # [00:53] <smaug____> rniwa: in the patch I don't see prefixes
231. # [00:54] <rniwa> smaug____: ok, I guess we can follow the same suite then
232. # [00:54] <rniwa> smaug____: btw, would you mind giving me the bugzilla url
233. # [00:54] <TabAtkins> rniwa: "radical" meaning what? The sensible definition is "not backwards-compatible".
234. # [00:54] <smaug____> rniwa: https://bugzilla.mozilla.org/show_bug.cgi?id=591467
235. # [00:54] <Hixie> rniwa: i will never make radical changes like websocket. that was a travesty.
236. # [00:54] <rniwa> smaug____: so that I can post it on WebKit's bugzilla
237. # [00:54] <Hixie> rniwa: and the ietf can be entirely blamed for that
238. # [00:54] <TabAtkins> By that definition, this change is not radical.
239. # [00:54] <rniwa> TabAtkins: this was not
240. # [00:54] <Hixie> we should never have moved websocket to ietf
241. # [00:55] <Hixie> it literally delayed us by a year
242. # [00:55] <rniwa> smaug____: wow! you're implementing all of it in one patch?
243. # [00:55] <Hixie> we'd have compression and multiplexing by now if we'd stayed at whatwg
244. # [00:55] <Hixie> but anyway
245. # [00:55] * Joins: MikeSmith_ (~MikeSmith@EM114-48-182-2.pool.e-mobile.ne.jp)
246. # [00:55] <smaug____> rniwa: I don't know much about it
247. # [00:55] <Hixie> water under the bridge
248. # [00:55] <smaug____> hsivonen would know
249. # [00:55] <smaug____> but I guess it is late for him
250. # [00:55] * jernoble|afk is now known as jernoble
251. # [00:56] <smaug____> (for some reason it is not that late for me although I live in the same city as hsivonen )
252. # [00:57] * Quits: annevk (~annevk@EM111-191-114-31.pool.e-mobile.ne.jp) (Ping timeout: 252 seconds)
253. # [00:57] <Hixie> heh
254. # [00:59] * Quits: MikeSmith (~MikeSmith@EM111-191-114-31.pool.e-mobile.ne.jp) (Ping timeout: 276 seconds)
255. # [00:59] * MikeSmith_ is now known as MikeSmith
256. # [00:59] * Quits: jarek__ (~jarek@79.186.10.184) (Ping timeout: 260 seconds)
257. # [01:02] * Quits: astearns (~anonymous@192.150.22.5) (Ping timeout: 245 seconds)
258. # [01:03] * Quits: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net) (Remote host closed the connection)
259. # [01:04] * Joins: annevk (~annevk@EM114-48-182-2.pool.e-mobile.ne.jp)
260. # [01:05] <annevk> arv, basically, IDL handles a whole bunch of details that specifications do not need to take care of now and because of IDL they are taken care of consistently; is your idea that we should replace all that by just having "raw" ECMAScript definitions for each method in specifications?
261. # [01:05] <annevk> arv, because to me such an idea sounds like it will lead to a hell of a lot more prose and less consistency across specifications
262. # [01:06] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 258 seconds)
263. # [01:06] * Joins: temp02 (~temp01@unaffiliated/temp01)
264. # [01:07] <arv> annevk: I can see that. Since Web IDL has type annotations and JS does not.
265. # [01:08] <arv> annevk: one of the benefits I see though is that it would prevent new APIs that cannot be expressed in JS without proxies
266. # [01:08] <annevk> yeah, that is the biggest win
267. # [01:08] * Joins: Amorphous (jan@unaffiliated/amorphous)
268. # [01:10] * Quits: KevinMarks (~KevinMark@71.204.145.244) (Quit: The computer fell asleep)
269. # [01:10] <TabAtkins> Clearly we should write idl in Dart.
270. # [01:10] <annevk> arv, I don't know what proxies are
271. # [01:11] <annevk> arv, what APIs cannot be expressed in JS? Last time this came up Brendan discussed things such as document.all
272. # [01:11] <arv> annevk: Proxies are interceptors
273. # [01:11] <Hixie> (what's wrong with APIs not being implementable in JS? We don't want JS to implement them, we want browsers to implement them. They only need to be _usable_ from JS.)
274. # [01:12] <arv> arv: Yah, things like HTMLCollection and all other collections in DOM
275. # [01:12] <arv> arv: Other things include dataSet (I don't remember the interface name)
276. # [01:12] * Joins: jkomoros (komoroske@nat/google/x-djumfbqkrjwzgkca)
277. # [01:13] <arv> I want JS to be able to host the DOM. I think the right thing to do is to fix JS in this case though
278. # [01:14] <Hixie> why on earth would you want JS to be able to host the DOM?
279. # [01:14] <Hixie> the requirements for doing that seem like a whole bunch of things that aren't useful for general purpose web authoring
280. # [01:14] <Hixie> so that seems like a very odd thing to prioritise
281. # [01:15] <smaug____> https://github.com/andreasgal/dom.js/
282. # [01:15] <arv> Consistency. No more alien behavior
283. # [01:15] <Hixie> consistency is not a goal
284. # [01:15] <arv> smaug____: Andreas uses proxies
285. # [01:15] <smaug____> indeed
286. # [01:15] <smaug____> for implementation
287. # [01:15] <arv> smaug____: Which we created for this purpose
288. # [01:15] <arv> smaug____: and other use cases of course
289. # [01:16] * Quits: KillerX (~anant@206.15.76.122) (Quit: KillerX)
290. # [01:16] <TabAtkins> Being unable to write a library with functionality similar to the native DOM is bad.
291. # [01:16] <zewt> (well, the interface of an API should always be implementable in JS; the underlying functionality not so much, of course)
292. # [01:17] * Quits: shans (~shanestep@202.171.174.250) (Quit: shans)
293. # [01:17] * Joins: erlehmann (~erlehmann@dslb-092-078-130-083.pools.arcor-ip.net)
294. # [01:17] * dglazkov is now known as dglazkov|away
295. # [01:17] <Hixie> TabAtkins: you can write a library with functionality similar to the native DOM, but I disagree with the premise that if you couldn't that would be bad. Why would it be bad?
296. # [01:18] <TabAtkins> Hixie: You couldn't do so, before we added proxies.
297. # [01:18] <Hixie> sure you could, for some value of "similar"
298. # [01:18] <TabAtkins> Hixie: It's bad because it means that libraries are forever different and possibly substandard to the native version.
299. # [01:18] <Hixie> why is that bad
300. # [01:18] <zewt> how is it not bad?
301. # [01:18] * Joins: ap_ (~ap@17.212.155.203)
302. # [01:18] <TabAtkins> Yes.
303. # [01:19] <annevk> I'm also having a hard time seeing why it's bad.
304. # [01:19] <zewt> for example, i should be able to implement standardized, drop-in-compatible APIs in JS, as far as is possible given their underlying functionality
305. # [01:19] <Hixie> zewt: why???
306. # [01:20] <Hixie> has anyone actually got an argument here that explains why we would ever want proxies or all this "self-hosting js dom" stuff other than a flat assertion that we should?
307. # [01:20] <zewt> (eg. implementing things like the hidden attribute on browsers that don't support it yet, as an obvious and simple example)
308. # [01:20] <annevk> We don't apply that principle anywhere else. E.g. as we discussed earlier with CSS exposing access for any kind of property is not going to fly.
309. # [01:21] <Hixie> we don't make it possible for authors to implement http in a web browser
310. # [01:21] <Hixie> or implement css
311. # [01:21] <TabAtkins> Hixie: I don't understand how you don't understand why having magical syntax capabilities that only the native platform can use is bad.
312. # [01:21] <zewt> ^
313. # [01:21] <TabAtkins> Um, neither of those are turing-complete languages.
314. # [01:21] <zewt> it seems to obvious to me that I don't know how to explain it further, heh
315. # [01:22] <TabAtkins> Also, it turns out there may actually be a performance win from hosting the DOM in pure JS, since you're not having to call across FFI boundaries.
316. # [01:22] <annevk> TabAtkins, what makes it being turing-complete relevant?
317. # [01:22] <zewt> APIs exposed to JS should be using the *same vocabulary as the language itself*
318. # [01:22] <TabAtkins> annevk: DSLs are not the same thing as full languages.
319. # [01:22] <Hixie> (imho proxies in js are a terrible idea, fwiw. they are massively complex and don't provide anything authors actually need. I'm all for providing things like getters and setters, and maybe syntax to make some members private or have "real" classes, but having an API that lets you fiddle with the low-level bits of objects is just asking for authors to shoot themselves in the feet.)
320. # [01:23] <TabAtkins> Hixie: Things like proxies are useful for reimplementing the DOM. They're also useful for other things. Almost any feature that could be a magical native feature could be useful somewhere else too.
321. # [01:23] <Hixie> TabAtkins: every platform has capabilities only the native platform has. e.g. only the kernel can allocate memory to a process. What's wrong with that?
322. # [01:23] <zewt> (don't know anything about proxies; I'm only talking at the JS language level)
323. # [01:23] <smaug____> from implementation point of view implementing DOM using a "safe" (!= C++) language would be good. JS is such a safe language, and browser devs happen to be familiar with it.
324. # [01:23] <smaug____> bu that is all just implementation detail
325. # [01:24] <TabAtkins> The kernel isn't a programming language. We're talking syntax.
326. # [01:24] <smaug____> but yes, performance can be also better when implemented in JS
327. # [01:24] <zewt> Hixie: anyone can implement a function with the same API as malloc/free or brk, though
328. # [01:24] <TabAtkins> Functionality can be special and magical; by definition, some it has to be. Syntax doesn't need to be, though.
329. # [01:24] * dglazkov|away is now known as dglazkov
330. # [01:24] <Hixie> syntax is basically irrelevant to anything, imho
331. # [01:24] <annevk> TabAtkins, still not an argument
332. # [01:24] <Hixie> who cares what the syntax is
333. # [01:25] <TabAtkins> And that's fundamentally why you're wrong, Hixie.
334. # [01:25] <annevk> TabAtkins, in reply to "not the same"
335. # [01:25] <Hixie> it's like people who say that they prefer python to perl or whatever because it has spaces indenting or doesn't or whatever
336. # [01:25] <Hixie> who cares
337. # [01:25] <zewt> what?
338. # [01:25] <Hixie> TabAtkins: so far your argument has consistent of no more than an assertion, so i'm pretty confident that i'm not wrong :-)
339. # [01:25] <Hixie> consisted
340. # [01:26] <Hixie> or at least, that you haven't in any way provided a reason why i should think that i'm wrong
341. # [01:26] <TabAtkins> annevk: A DSL has a special, limited purpose. It's not meant as a general-purpose computing language. It does one thing and does it well.
342. # [01:26] <Hixie> JavaScript is not meant as a general-purpose computing language.
343. # [01:26] <TabAtkins> A general purpose computing language is, well, general-purpose.
344. # [01:26] <Hixie> It's a language for writing Web apps.
345. # [01:26] <annevk> TabAtkins, you are just explaining what a DSL is, you are not giving an argument
346. # [01:26] * bga_|away is now known as bga_
347. # [01:26] <zewt> i should be able to implement a class with a drop-in-compatible interface to, say, IDB or Blob or any other API, and pass the object to something that expects that API, and make it work; if that's impossible because the API is something that can't be expressed in JS itself, that's a flaw
348. # [01:26] <Hixie> zewt: i strongly disagree with that
349. # [01:26] <zewt> why/
350. # [01:27] <zewt> also ?
351. # [01:27] <TabAtkins> I strongly agree with zewt, and think you're a bad person for disagreeing, Hixie.
352. # [01:27] <hober> Consider the desire to write a polyfill library
353. # [01:27] <zewt> heh
354. # [01:27] <TabAtkins> ^_^
355. # [01:27] <Hixie> zewt: you should absolutely _not_ be able to create an API that fakes a native, privileged object. That ways lies security nightmares.
356. # [01:27] <zewt> how so?
357. # [01:27] <hober> you write the library in js and want it to be a drop-in replacement for the equivalent dom feature
358. # [01:27] <zewt> if your security model depends on not being able to have the same interface as some native object, your security model is deeply broken
359. # [01:28] <zewt> that doesn't even make sense
360. # [01:28] <mkanat> zewt: The security model does depend on people not being able to replace certain objects themselves, though.
361. # [01:28] <TabAtkins> annevk: People do not expect to be able to self-host DSLs.
362. # [01:28] <zewt> this is simple duck typing (as it's called in Python, at least)
363. # [01:28] <zewt> caring about the interface and not the object type
364. # [01:28] <Hixie> i don't even know where to begin in explaining why it's a bad idea to be able to replace native objects
365. # [01:28] <Hixie> take Event for example
366. # [01:28] <TabAtkins> annevk: Largely because, since a DSL is designed for a specific domain by definition, self-hosting is virtually never that domain.
367. # [01:28] <Hixie> dispatching an Event has all kinds of special infrastructure
368. # [01:28] <Hixie> like whether the event is trusted
369. # [01:29] <Hixie> what phase the event is in
370. # [01:29] <Hixie> etc
371. # [01:29] <annevk> you are not making sense
372. # [01:29] <annevk> TabAtkins that is
373. # [01:29] <Hixie> a real (native) Event object implements all that machinery in a way that the UA knows it can trust
374. # [01:29] <zewt> obviously we're not talking about passing reimplementations to native methods
375. # [01:29] <Hixie> you can't just fake an Event and dispatch it
376. # [01:29] <TabAtkins> annevk: I don't know what else to say. ;_; You asked me why a DSL doesn't need to be able to self-host. I explained why.
377. # [01:29] <Hixie> zewt: "obviously" nothing
378. # [01:29] <Hixie> zewt: i have no idea what you're talking about!
379. # [01:29] <zewt> no, obviously, we're talking about *within javascript*, not to native non-JS methods
380. # [01:30] <TabAtkins> Hixie: Pay attention to zewt's example. Look at IDB, for example
381. # [01:30] <Hixie> zewt: ok let's reset this conversation. what is it you want to do?
382. # [01:30] <Hixie> zewt: that you can't do without JS being all kinds of more complicated?
383. # [01:30] <TabAtkins> Being able to fake idb via some other mechanism to polyfill older browsers is a Good Thing(tm).
384. # [01:30] <Hixie> i have no idea what "idp" and "polyfill" are
385. # [01:30] <Hixie> "idb"
386. # [01:30] <TabAtkins> IndexedDB.
387. # [01:30] <TabAtkins> Polyfilling. Shimming. Whatever.
388. # [01:30] <hober> use case: this browser doesn't support the new form validation dom api. i want to have a drop-in replacement "formvalidationapi.js"
389. # [01:30] <TabAtkins> The fact that you don't know this word is a strong indicator that you're out of touch with webdev needs. ^_^
390. # [01:31] <Hixie> o_O
391. # [01:31] <zewt> i didn't know that word D:
392. # [01:31] * dglazkov is now known as dglazkov|away
393. # [01:31] <TabAtkins> Polyfilling = using JS in an older browser to fake a feature that isn't implemented in the old browser yet.
394. # [01:32] <TabAtkins> Allowing you to pretend that the new feature exists everywhere.
395. # [01:32] <Hixie> if the use case we're talking about is "i want to reimplement the API that the UA doesn't provide because it's an old API" then the solution is IMHO not to reimplement the API but to provide an API of your own that abstracts away what background API exists
396. # [01:32] <Hixie> don't just reimplement whatever shit i came up with
397. # [01:32] <zewt> strongly disagree
398. # [01:32] <TabAtkins> No, that's wrong. That way means that we live with libraries forever, or someday make a painful migration back to native.
399. # [01:32] <Hixie> (or even better, just wait til it's implemented everywhere)
400. # [01:32] <TabAtkins> We want to work with the native stuff.
401. # [01:33] <zewt> i want to implement the standard API (or as close as I can get) in a self-contained way that I can drop in on browsers that need it, and forget about it, and then other code (that other people may have to read) don't have to learn my new special wrapper API, it just uses the standard one that everyone knows
402. # [01:33] <Hixie> adding a whole bunch of complexity to the platform purely so that in the future, new APIs can be shimmed by script, seems like an incredible waste of time
403. # [01:33] <Hixie> (frankly, if we're creating APIs that you _can_ shim, then we're clearly not adding APIs that matter)
404. # [01:33] <TabAtkins> ...
405. # [01:34] * Joins: aho (~nya@fuld-590c7543.pool.mediaWays.net)
406. # [01:34] <TabAtkins> I don't understand you at all, Hixie.
407. # [01:35] <Hixie> ditto :-)
408. # [01:35] <TabAtkins> That seems to argue that there's no reason to every make a convenience api, if it's at all possible for a library, no matter how complex, to implement the same functionality.
409. # [01:35] <zewt> lots of APIs can be implemented in JS that you really don't want to if you can help it (obvious examples being performance-critical stuff, like SHA-1 and crypto)
410. # [01:36] <Hixie> i'm strongly inclined to avoid adding convenience APIs and performance-critical stuff should just be implemented in JS and JS should be fast enough
411. # [01:36] <zewt> wow, we just diverged from reality by about a light year :)
412. # [01:36] <Hixie> hey, you're the one who wants JS to be able to fake native code!
413. # [01:36] <TabAtkins> Everything you have just said is wrong-headed, Hixie.
414. # [01:36] <Hixie> TabAtkins: i'm eager to hear your arguments showing how that is the case
415. # [01:37] <arv> Take dataSet for example, it adds no new semantic value. Only convenience. But since it requires interceptors/proxies it cannot be emulated in older browsers
416. # [01:37] <Hixie> TabAtkins: but so far all you've done is ad hominem and argument from assertion
417. # [01:37] <zewt> i'm the one who wants to be able to implement APIs as fallbacks when I have to, for compatibility; i certainly do want to be able to use ones with decent native performance when they're available
418. # [01:38] <Hixie> zewt: i don't see why the shims have to implement the native APIs perfectly down to the last "readonly" or whatnot. JS today is quite close enough for shim purposes.
419. # [01:38] <arv> ...and if you wrap it in another library all platforms, now and forever suffer the extra latency of downloading that library
420. # [01:38] <Hixie> not now and forever, only now and up to when the API is widely implemented
421. # [01:39] <arv> Hixie: es5 is not close enough
422. # [01:39] <Hixie> (it's not like that latency is that big a deal -- measure it)
423. # [01:39] <Hixie> arv: do you have any examples of how it is not close enough?
424. # [01:39] <zewt> Hixie: i'm not saying it needs to be an exact implementation (i did say "as close as I can get"); I'm saying implementing the APIs is a generally useful thing to be able to do
425. # [01:39] <Hixie> arv: (i think es3 was close enough)
426. # [01:39] <arv> Hixie: so you expect people to go back and update web pages?
427. # [01:39] <Hixie> arv: ones that are still used? yeah. the web moves on.
428. # [01:40] <arv> element.dataSet.newProperty = newValue; // try to emulate that
429. # [01:40] <Hixie> arv: (apps aren't like docs in that regard)
430. # [01:40] <arv> Hixie: fair enough
431. # [01:40] <zewt> (being able to implement them more closely is a good thing, and the bits where we can't I'd consider flaws, but whether they're enough of flaws to spend a lot of engineering fixing is a different question)
432. # [01:40] <Hixie> arv: just use setAttribute('data-new-property') until it's widely available. next?
433. # [01:40] <arv> Hixie: but more and more docs have jQuery in them
434. # [01:40] <TabAtkins> Hixie: No, I haven't, but you dont' seem to be understanding me well enough. So, let's try again.
435. # [01:40] <arv> Hixie: so why did we add dataSet then?
436. # [01:41] <Hixie> arv: i thought we were talking about cases where people _weren't_ useing libraries?
437. # [01:41] <Hixie> arv: for convenience in 10 years
438. # [01:41] <TabAtkins> !_!
439. # [01:41] <Hixie> same reason we add new CSS features
440. # [01:41] <TabAtkins> And with sufficient JS powers, we can achieve convenience *today*.
441. # [01:41] <arv> Hixie: my point re jquery was that most content today are more than just static pages
442. # [01:42] <Hixie> arv: that's _clearly_ not the case.
443. # [01:42] <Hixie> arv: the vast majority of content is docs
444. # [01:42] <Hixie> arv: without script at all
445. # [01:42] <Hixie> arv: other than ads and analytics
446. # [01:42] <Hixie> TabAtkins: why does it matter if we get the convenience at t=-5y, t=0, or t=5y?
447. # [01:43] <TabAtkins> t=5y is five years away!
448. # [01:43] <Hixie> so?
449. # [01:43] <Hixie> 5 years ago today was five years away
450. # [01:43] <zewt> not all of us are vampires
451. # [01:43] <TabAtkins> We don't have infinite time to wait for things! We often dont' even have moderate finite amounts of time!
452. # [01:43] <annevk> Got to love the IE blog " WebVTT originated from W3C discussions last year after a need for simple caption authoring was identified."
453. # [01:43] <zewt> wait do vampires age, i'm not a vampireologist
454. # [01:43] <Hixie> impatience is _certainly_ not the reason to add orders of magnitude of complexity to the platform
455. # [01:44] <TabAtkins> If you characterize it as "impatience", you'll never see the value in it of course.
456. # [01:44] <Hixie> if you're impatient, you'll never see the value in waiting? :-)
457. # [01:45] <Hixie> seriously, the web moves so fast these days compared to any point in the past, it's incredible that there are still people who want it to move faster
458. # [01:45] <TabAtkins> Now is always better than later. The faster you can innovate in one area, the faster innovation happens everywhere else.
459. # [01:45] <zewt> patience doesn't enter into it; a page that I have to write today I have to write today, I don't get to tell my boss "let's wait five years"
460. # [01:45] <Hixie> we're probably the fastest moving industry there is
461. # [01:45] <Hixie> there's such a thing as going _too_ fast, imho :-)
462. # [01:45] * Quits: theoros (~user@unaffiliated/theoros) (Ping timeout: 260 seconds)
463. # [01:45] <TabAtkins> I'm trying to force the Singularity here, dammit!
464. # [01:45] <Hixie> now is _not_ always better than later. Later you have more experience, and waiting means you can fix things.
465. # [01:45] <hober> Hixie: indeed
466. # [01:46] <zewt> you don't have nearly as much experience if you never use a feature because you have to wait 5 years for it to become widely available :)
467. # [01:46] <TabAtkins> Hixie: Plus, some parts of the platform do *not* move quickly. Mobile, for example.
468. # [01:46] * Quits: hasather_ (~hasather_@84.38.144.96) (Remote host closed the connection)
469. # [01:46] <Hixie> just look at the issue rniwa raised earlier, where itemtype changed and rniwa wanted to use prefixes because of it
470. # [01:46] <TabAtkins> Or, you know, the ~40% of the web still on IE7 or lower.
471. # [01:47] <TabAtkins> Plus zewt's point, that adoption in JS means more experimentation and more experience.
472. # [01:47] <TabAtkins> It would have taken much longer to get querySelector if jQuery hadn't existed.
473. # [01:48] * hober thinks mobile is moving pretty quickly actually
474. # [01:48] * Joins: micheil_mbp (~micheil@195.24.233.121)
475. # [01:48] <TabAtkins> Hixie: out of curiosity, since you said that you don't think convenience APIs should exist, do you think we shouldn't have done querySelector?
476. # [01:48] <zewt> mobile is sort of crippled because phone manufacturers rarely update browsers
477. # [01:48] <TabAtkins> hober: The edge is moving roughly as fast as the edge of the desktop. The tail is still pretty slow, though.
478. # [01:48] <TabAtkins> Because of what zewt just said.
479. # [01:48] * Joins: micheil_mbp_ (~micheil@195.24.233.121)
480. # [01:49] <zewt> (which is gross and embarrassing; all mobile platforms are *new* platforms, and there's no excuse that they don't all have well-built upgrade systems for browsers)
481. # [01:49] <hober> I can think of some phone manufacturers who are pretty good at updating their browsers :)
482. # [01:49] <TabAtkins> Still not the majority. ^_^
483. # [01:50] <smaug____> hober: tell me one. (I may actually change my phone reasonable soon)
484. # [01:50] <TabAtkins> smaug____: Presumably he was referring to iphone
485. # [01:50] <zewt> no android phone does, since it pretty much takes a full OS update to update the browser
486. # [01:50] <smaug____> ( though, I can just use Nightly and update the browser every day )
487. # [01:50] * Quits: micheil (~micheil@195.24.233.121) (Ping timeout: 252 seconds)
488. # [01:50] * micheil_mbp_ is now known as micheil
489. # [01:51] <smaug____> does iphone's Safari get updated often?
490. # [01:52] * Joins: theoros (~user@unaffiliated/theoros)
491. # [01:52] * Quits: micheil_mbp (~micheil@195.24.233.121) (Ping timeout: 252 seconds)
492. # [01:52] <miketaylr> zewt: of course there are browsers available on the android platform that update much faster than the OS
493. # [01:52] <hober> It doesn't come out every six weeks, but then again, like Hixie said, there's such a thing as moving too fast. :)
494. # [01:55] * Joins: shans (~shanestep@202.171.174.250)
495. # [01:58] <hober> un-derailing the conversation for a moment, I think both Hixie & TabAtkins are making reasonable points:
496. # [01:58] <hober> I agree with Tab that it would be nice for JS authors to be able to write polyfills for features, and at least in some cases JS should be augmented to facilitate that.
497. # [01:58] <hober> Hixie's right, though, that if a new API is easily polyfillable, that's a smell that the API probably doesn't belong in the platform
498. # [01:58] * Quits: ben_alman_ (~ben_alman@web126.webfaction.com) (Excess Flood)
499. # [01:59] * Joins: ben_alman (~ben_alman@web126.webfaction.com)
500. # [01:59] * Quits: rillian_ (~rillian@184.71.166.126) (Remote host closed the connection)
501. # [01:59] <TabAtkins> I still disagree with that. We can produce high-value convenience APIs that are easily polyfillable.
502. # [01:59] <TabAtkins> They are still worthwhile to add to the platform.
503. # [02:00] <TabAtkins> For example, getting the mouse location relative to a target element is pretty easy. I reinvent it every time I write anything using the mouse.
504. # [02:00] <TabAtkins> It's still a high-value thing to provide natively, precisely *because* I have to reinvent it every single time I write anything using the mouse.
505. # [02:01] <TabAtkins> (Plus, something can be easy to polyfill the primary use-case for, but still offer additional value in providing corner-cases that are harder to polyfill.)
506. # [02:01] * eric_carlson is now known as ericc|away
507. # [02:01] <hober> Yeah, I have "probably" in my line above to give myself enough rhetorical wiggle room to agree with you in some cases and not in others. :) it's a judgement call
508. # [02:01] <TabAtkins> Plus, it's still surprisingly easy to get the mouse thing wrong.
509. # [02:01] <zewt> miketaylr: but most people use the stock browser, and people should be able to do so
510. # [02:02] <miketaylr> (for sure)
511. # [02:02] <zewt> TabAtkins: there's also a lot of value in standardizing basic stuff like that that's used a lot, instead of every page reinventing it slightly differently
512. # [02:02] <TabAtkins> Yup.
513. # [02:03] <TabAtkins> So whether or not it can be polyfilled easily is, I think, a useless signal when deciding whether to add it.
514. # [02:03] <TabAtkins> Whether it's useful and commonly-needed is really what you need to account for.
515. # [02:03] * Quits: smaug____ (~chatzilla@GMYCXXIII.gprs.sl-laajakaista.fi) (Ping timeout: 255 seconds)
516. # [02:04] * heycam is now known as heycam|away
517. # [02:06] * Quits: dbaron (~dbaron@206-15-76-122.static.twtelecom.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
518. # [02:07] <TabAtkins> (I suppose if something is rarely needed, but really useful when it is needed, whether or not it's easy to duplicate in JS can be a useful factor to consider.)
519. # [02:07] <Hixie> TabAtkins: (sorry, was afk)
520. # [02:08] <TabAtkins> It's cool, I can talk enough for both of us.
521. # [02:08] * Joins: jdong_bot_ (~jdong_bot@117.79.233.178)
522. # [02:08] <Hixie> TabAtkins: i think querySelector() is fine, because the UA has all kinds of knowledge and ability to optimise that the script doesn't
523. # [02:08] <Hixie> TabAtkins: but equally, i think it doesn't make much sense to implement a JS version of it
524. # [02:09] <TabAtkins> Well, not *now* it doesn't. It made all kinds of sense when jQuery did it.
525. # [02:09] <Hixie> TabAtkins: having said that, i think ES3 is quite capable of providing enough of a shim for it that we don't need more magical syntax features.
526. # [02:09] <TabAtkins> Actually, though, it does still make sense to implement it in JS, because there are still significant browsers that don't have it.
527. # [02:10] * Quits: othermaciej (~mjs@17.245.90.53) (Quit: othermaciej)
528. # [02:10] <TabAtkins> Yes, querySelector requires nothing special on the syntax front to shim. That was just a question about your general point that convenience features shouldn't be added.
529. # [02:11] <Hixie> TabAtkins: what are examples of things that you think need shimming that can't be sufficiently shimmed with JS?
530. # [02:12] <TabAtkins> arv gave an example in the form of dataSet.
531. # [02:12] <TabAtkins> It can be shimmed now, with Proxies.
532. # [02:12] <Hixie> an example that isn't trivially dealt with by just using getAttribute
533. # [02:13] <Hixie> that is, an example where the convenience provided is great enough to justify adding a bunch of features to support providing the convenience
534. # [02:13] <TabAtkins> No. The syntax is the important part there. dataSet is exactly equivalent in *functionality* to setAttribute. It's more convenient to use because of syntax.
535. # [02:13] <Hixie> sure but it's not important enough to matter
536. # [02:13] <TabAtkins> The fact that it was an obvious enough syntax win for you to add it should be a sufficient answer as to why outside JS libs would want it.
537. # [02:13] <zewt> if it wasn't important enough to matter then why was it added in the first place?
538. # [02:13] <Hixie> given the choice between a bunch of syntax to allow authors to emulate dataSet and just using DOM Core, DOM Core is the obviously better choice.
539. # [02:14] * Joins: othermaciej (~mjs@17.245.90.53)
540. # [02:14] * heycam|away is now known as heycam
541. # [02:15] <Hixie> to add a feature to the platform you have to compare the cost of not having it to the cost of implementing it. The cost of not having dataSet is minimal, the cost of implementing dataSet is even less so. The cost of not having dataSet is minimal, the cost of implementing a bunch of additions to JS to enable authors to fake it is comparatively huge.
542. # [02:15] <arv> another one is classList
543. # [02:15] <TabAtkins> The cost of never having anything like dataSet is larger.
544. # [02:15] <arv> same issues as dataSet but more useful (IMO)
545. # [02:16] <Hixie> you can surely fake enough of classList today
546. # [02:17] <Hixie> it's just a bunch of methods
547. # [02:17] <Hixie> where's the problem?
548. # [02:17] <annevk> it's dataset not dataSet btw
549. # [02:18] <TabAtkins> annevk: I always forget. arv said dataSet early, so I copied him.
550. # [02:20] <zewt> ... by the way, what's so badly complex about proxies? google isn't finding much about them, but https://gist.github.com/1202328 looks fairly straightforward
551. # [02:21] <zewt> (not as nice as Python's __getattr__, but I assume performance is the problem with that interface)
552. # [02:21] <TabAtkins> zewt: Decent tutorial at http://soft.vub.ac.be/~tvcutsem/proxies/
553. # [02:22] <arv> classList[index] cannot be emulated
554. # [02:22] <zewt> looks fairly self-contained
555. # [02:22] * Joins: jacobolus (~jacobolus@74-95-207-206-SFBA.hfc.comcastbusiness.net)
556. # [02:22] * Quits: jdong_bot_ (~jdong_bot@117.79.233.178) (Remote host closed the connection)
557. # [02:24] <paul_irish> fwiw https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills lists basically every shim/polyfill for all newish features there is.
558. # [02:24] <paul_irish> elem.classList[methodname]('classname') is unsupported in the polyfill listed.
559. # [02:25] <Hixie> arv: so just use classList.item(index)
560. # [02:25] <zewt> heh Video Timed Track (subtitles)
561. # [02:25] <Hixie> arv: you don't have to duplicate the entire API, only enough of the API for it to be usable
562. # [02:25] <zewt> an assured way of making sure nobody can find VTT: call it Video Timed Track
563. # [02:26] <TabAtkins> Hixie: The fact that the platform has a nice convenient way of doing something, but libraries can't ever duplicate it, is a bug.
564. # [02:26] * Quits: ZombieLoffe (ZombieL@unaffiliated/zombieloffe)
565. # [02:26] <Hixie> TabAtkins: so you keep saying, but that doesn't follow from the use cases you describe
566. # [02:26] <TabAtkins> Again, if it was sufficiently obvious of a win to be included in the first place, it's clearly a useful thing for libraries to have as well.
567. # [02:26] <paul_irish> zewt: just updated so the abbv is present in the page
568. # [02:27] <Hixie> TabAtkins: you are assuming that something was added to the platform because it was a good idea and not just because i copied-and-pasted other parts of the platform that did it too
569. # [02:27] <Hixie> TabAtkins: there's plenty of stuff in the platform that isn't a win at all, let alone a "sufficiently obvious win"
570. # [02:27] <TabAtkins> Are you saying that relatively new APIs you've designed are mistakes?
571. # [02:27] <zewt> i'd suggest that one of the following must be true: 1: being able to write foo.bar and have bar looked up dynamically is a useful idiom in APIs, and it should be possible to do this in JS libraries; or 2: it's not very useful, and no new APIs should do that
572. # [02:28] * Joins: jarek (~jarek@bdb25.neoplus.adsl.tpnet.pl)
573. # [02:28] * Quits: jarek (~jarek@bdb25.neoplus.adsl.tpnet.pl) (Changing host)
574. # [02:28] * Joins: jarek (~jarek@unaffiliated/jarek)
575. # [02:28] <zewt> (speaking of getattr(foo, "bar"), not getters, of course)
576. # [02:28] <Hixie> TabAtkins: many have plenty of mistakes or bits that are consistent merely for the sake of consistency, or have features that are made available because they can be but where if i was designing the API for an environment where they could not be i wouldn't blink at omitting it
577. # [02:29] <Hixie> TabAtkins: .item(n) vs [n] being a classic example of the latter
578. # [02:29] <Hixie> TabAtkins: (having said that, i've no objection to JS adding a neat syntax to support index getters in classes)
579. # [02:29] <TabAtkins> Sigh. It seems like every feature that we point out, you say wasn't necessary in the first place and doesn't need to be done in library code.
580. # [02:30] <Hixie> TabAtkins: yes, it is my argument that everything you can't do in JS is stuff you needn't do in JS
581. # [02:30] <annevk> I think [n] is nice to have
582. # [02:30] <erlehmann> best browser ever http://vttynotes.blogspot.com/2011/10/cve-2011-3230-launch-any-file-path-from.html
583. # [02:30] <TabAtkins> Hixie: That's a stupid argument. ^_^
584. # [02:30] <annevk> emulating IDL [replaceable] and such however goes a bit far
585. # [02:30] <zewt> i'm still not understanding what's so objectionable about this proxy interface; it looks self-contained and already implemented in FF
586. # [02:30] <Hixie> TabAtkins: it's backed up by the fact that every concrete example you've given has in fact supported my argument
587. # [02:30] <Hixie> TabAtkins: if you have a counter-example i'm certainly open to it
588. # [02:31] <TabAtkins> Hixie: Only in your mind. ;_; Because you self-admitedly don't consider syntax important.
589. # [02:31] <Hixie> TabAtkins: also, note that i have no objection to specific features being added to JS, my objection is to the explicit goal of adding everything necessary to emulate DOM APIs in JS
590. # [02:31] * Quits: jwalden (~waldo@2620:101:8003:200:224:d7ff:fef0:8d90) (Quit: ChatZilla 0.9.87-2.1450hg.fc15 [XULRunner 7.0.1/20110930134335])
591. # [02:31] <Hixie> TabAtkins: because i think that goal is sufficiently met already
592. # [02:32] <TabAtkins> I consider self-hosting a valuable property for a language to have.
593. # [02:32] * Joins: othermaciej_ (~mjs@2620:149:4:1b01:80a8:7797:8c40:91dd)
594. # [02:32] <Hixie> a valuable feature for a turing-complete language and an API to have but not a language like CSS?
595. # [02:33] * Quits: shans (~shanestep@202.171.174.250) (Ping timeout: 258 seconds)
596. # [02:33] <TabAtkins> Yes?
597. # [02:34] <TabAtkins> Again, DSL is, by definition, domain-specific, not general-purpose.
598. # [02:35] <Hixie> the DOM API is not domain-specific?
599. # [02:35] <Hixie> _JS_ is not domain-specific?
600. # [02:35] <zewt> js certainly is not
601. # [02:36] <TabAtkins> Nobody's asking to be able to self-host the DOM API in the DOM API. We want to host the DOM in JS.
602. # [02:36] <TabAtkins> JS is most certainly not domain-specific! What possibly could possess you to think it is?
603. # [02:36] <erlehmann> DOMain-specific!
604. # [02:36] <TabAtkins> erlehmann: :headdesk:
605. # [02:36] * zewt eyes Unity editor open with a couple JS scripts that have nothing to do with the web
606. # [02:36] <Hixie> it's the web's programming language, i can't imagine any other context in which i'd actually want to use it
607. # [02:36] <erlehmann> careful, TabAtkins. or i shall make a new comic.
608. # [02:36] <zewt> TabAtkins: (the important question: whose head)
609. # [02:37] <TabAtkins> Hixie: You are operating under an incorrect definition of "domain-specific" and "general purpose".
610. # [02:37] <Hixie> TabAtkins: and you're mis-using "self-hosting" :-)
611. # [02:37] <TabAtkins> No I'm not. ^_^
612. # [02:37] <Hixie> JS implementing DOM is not self-hosting
613. # [02:37] <Hixie> that would be JS implementing JS
614. # [02:37] * Joins: shans (~shanestep@202.171.174.250)
615. # [02:38] <Hixie> if JS is "general purpose", why is CSS not "general purpose"?
616. # [02:38] <TabAtkins> Yes. DOM is a library built in JS. By definition, if JS is self-hosting, it can host the DOM too.
617. # [02:38] <Hixie> DOM is _not_ a library build in JS!
618. # [02:38] <Hixie> it's an API exposed to JS built typically in C++
619. # [02:38] <TabAtkins> Hixie: Um, because CSS is a DSL. It's nowhere near turing-complete, and not intended for generic computation.
620. # [02:38] <Hixie> ...
621. # [02:38] <zewt> "..." what?
622. # [02:39] <Hixie> we're going around in circles
623. # [02:39] <TabAtkins> I don't understand how!
624. # [02:39] <Hixie> whether something is turing complete or not doesn't have any bearing on whether it's general purpose or not
625. # [02:39] <TabAtkins> How can you possibly think CSS is a general-purpose computer language?!?
626. # [02:39] <zewt> i don't understand the question--of course you can't implement CSS features in CSS; CSS isn't even a programming language
627. # [02:39] <TabAtkins> zewt: Sure it is. It's just a very limited one.
628. # [02:39] <zewt> it's not, not by any definition of the term I've ever seen or used
629. # [02:40] <TabAtkins> It's a styling and layout programming language.
630. # [02:40] <TabAtkins> You're probably just not very familiar with declarative languages.
631. # [02:40] <zewt> it's a layout language; it's not a layout *programming* language
632. # [02:40] <TabAtkins> CSS is a program that accepts a DOM as input and produces a laid-out page.
633. # [02:40] * jernoble is now known as jernoble|afk
634. # [02:40] <Hixie> none of us seem to agree on terminology here
635. # [02:40] <zewt> heh
636. # [02:41] <Hixie> anyway
637. # [02:41] <Hixie> i have to go
638. # [02:41] <zewt> TabAtkins: i disagree, but let's skip this debate :)
639. # [02:41] <TabAtkins> Hixie: Pretty sure everyone extra-disagrees with your terms, though, if you consider CSS a general-purpose alnguage and JS not.
640. # [02:41] <zewt> (was: re: third-order tangent)
641. # [02:41] <Hixie> but i must first say that i continue to see no intrinsic reason why a library that implements a DOM shim would need to support every last subtlty of the DOM
642. # [02:41] <Hixie> it just has to be close enough
643. # [02:41] <Hixie> TabAtkins: i consider both to be domain-specific
644. # [02:42] <TabAtkins> Hixie: Is C domain-specific?
645. # [02:42] <annevk> extra-disagree lol
646. # [02:42] <Hixie> no, C is general-purpose
647. # [02:42] <TabAtkins> Then your definition is broken.
648. # [02:42] <Hixie> ko
649. # [02:42] <Hixie> ok
650. # [02:42] <zewt> in every other language I've used at any length, every API exposed to the language can be exposed by code written in the language itself; JS being the weird exception
651. # [02:42] <Hixie> the point is moot, since i don't think whether something is general purpose or not should control whether it needs to have the syntactic ability to emulate its APIs or not
652. # [02:43] <Hixie> zewt: you haven't used many languages
653. # [02:43] <annevk> Wikipedia sides with Hixie fwiw http://en.wikipedia.org/wiki/General-purpose_programming_language
654. # [02:43] <Hixie> zewt: there are tons of languages that can't describe all their APIs
655. # [02:43] <TabAtkins> annevk: How so?
656. # [02:44] <zewt> perhaps badly-designed languages, which I do try hard to avoid
657. # [02:44] <Hixie> zewt: e.g. Perl (some of its APIs are especially crazy), Pascal (normal Pascal can't implement its own Writeln function)
658. # [02:44] <zewt> nice timing bringing up Perl :)
659. # [02:44] <TabAtkins> JS is a perfectly fine general-purpose functional programming language. It happens that in its most common implementations there are a couple of additional libraries built-in that are designed for easier writing of webapps, is all.
660. # [02:44] <zewt> (pascal is a toy language, as far as I'm concerned)
661. # [02:44] <zewt> (havn't touched it in ... 15 years?)
662. # [02:45] <Hixie> i happen to be particularly familiar with those two so can comment authoratively off the top of my head
663. # [02:45] <Hixie> i'd be surprised if there weren't similar limitations in most languages
664. # [02:45] <Hixie> but i really have to go
665. # [02:45] <Hixie> bbl
666. # [02:46] <TabAtkins> annevk: Yup, reading further, I'm quite certain that Wikipedia disagrees with Hixie. There is no reasonable definition of "domain-specific" under which JS is one.
667. # [02:46] <zewt> (C, C++, Python)
668. # [02:50] * Joins: ezoe (~ezoe@203-140-90-183f1.kyt1.eonet.ne.jp)
669. # [02:51] * Joins: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp)
670. # [02:52] * Joins: dominicc (~dominicc@2401:fa00:4:1000:225:ff:fef2:ad7f)
671. # [02:55] <erlehmann> C is general purpose. I make music with a compiler. :3
672. # [02:55] * Quits: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 258 seconds)
673. # [02:56] * Joins: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp)
674. # [02:56] <annevk> TabAtkins, I meant for "C"
675. # [02:56] <erlehmann> #include <math.h>
676. # [02:56] <erlehmann> #include <stdio.h>
677. # [02:56] <erlehmann> main(){long int t;int sample;for(t=0;;t++){sample=(((t&512)>>(int)(3*sin(t*4&(int)(t/256))))>>(t>>18)|((t&512)>>(int)(4*sin(t*4&(int)(t/512))))>>(t>>27));fputc(sample, stdout);}}
678. # [02:57] <erlehmann> just pipe this to /dev/audio :3
679. # [02:57] <annevk> given that JavaScript is used on e.g. servers and elsewhere it does not really seem that domain specific to me
680. # [02:57] <TabAtkins> annevk: Did you think I was saying that C was domain-specific?
681. # [02:57] <annevk> but I don't really care
682. # [02:57] <erlehmann> javascript ist used on servers … and desktops. doesn't gnome have javascript?
683. # [02:57] * Quits: sicking (~chatzilla@206-15-76-122.static.twtelecom.net) (Ping timeout: 260 seconds)
684. # [02:58] * Joins: agektmr (~Adium@220.109.219.244)
685. # [02:58] <bga_> gnome3 - yes
686. # [02:58] <TabAtkins> Even if JS was only ever used in webpages in browsers, it's still not domain-specific. It is capable of (and designed for) arbitrary computation.
687. # [02:58] <erlehmann> i concur.
688. # [02:59] <TabAtkins> This isn't like, I dunno, using XSLT to compute mandelbrots.
689. # [02:59] <bga_> also qml
690. # [02:59] <erlehmann> hey, i wrote a CMS abomination in XSLT once. i think everyone has to live through that, coming-of-age-story.
691. # [03:01] <TabAtkins> bga_: From wikipedia's description, it looks like QML is a DSL.
692. # [03:01] <TabAtkins> It looks like you can run arbitrary JS, but it's designed for designing UI.
693. # [03:02] <TabAtkins> And the syntax is clearly slanted towards that end.
694. # [03:10] * Quits: bga_ (~bga@95-55-46-124.dynamic.avangarddsl.ru) (Read error: Connection reset by peer)
695. # [03:14] * Quits: jkomoros (komoroske@nat/google/x-djumfbqkrjwzgkca) (Quit: jkomoros)
696. # [03:19] * heycam is now known as heycam|away
697. # [03:19] <TabAtkins> erlehmann: By the way, it would be great if you could put in a Kate Beaton credit in your comic.
698. # [03:20] <erlehmann> TabAtkins, oh. i thought people knew that already.
699. # [03:20] <erlehmann> after all, it was for and about you, i spotted the fat pony in your sig!
700. # [03:20] <TabAtkins> Some of us do, sure. It's always good manners to credit, though, for the people who aren't already aware of an awesomic comic.
701. # [03:20] <erlehmann> s/sig/avatar/
702. # [03:20] <erlehmann> okay.jpg
703. # [03:21] <TabAtkins> It gives you an opportunity to evangelize a bad-ass comic. ^_^
704. # [03:21] * Joins: jkomoros (~komoroske@67.218.110.183)
705. # [03:21] <erlehmann> i am actually right now reading through “hark, a vagrant”
706. # [03:21] <erlehmann> and must admit i have no idea what the title says
707. # [03:22] <TabAtkins> The title?
708. # [03:22] <TabAtkins> Oh, the phrase "hark, a vagrant"?
709. # [03:22] <erlehmann> yesss
710. # [03:22] <TabAtkins> It's a phrase from an early bio comic. Kate is walking past a homeless dude, who shouts for her. She responds (to no one in particular), "Hark, a vagrant!".
711. # [03:22] <TabAtkins> Where "hark" is an archaic term meaning "Hey!"
712. # [03:23] * Quits: jkomoros (~komoroske@67.218.110.183) (Client Quit)
713. # [03:23] <erlehmann> what is a vagrant
714. # [03:23] <erlehmann> then
715. # [03:23] <TabAtkins> A homeless dude.
716. # [03:23] <erlehmann> intredasting.
717. # [03:24] <erlehmann> so i learned something
718. # [03:24] <erlehmann> thanks, tab atkins.
719. # [03:25] <erlehmann> i was just thinking that kate beaton could make erotic comics, but then i remembered the workings of jess fink.
720. # [03:25] <erlehmann> screw that.
721. # [03:26] <TabAtkins> Hey, I kinda like Chester 5000.
722. # [03:27] <erlehmann> i would like to draw that way. alas, i can only make icons and pixel graphics :/
723. # [03:28] <erlehmann> in before over 9000 years of mastering
724. # [03:28] <erlehmann> the skill of drawing
725. # [03:29] * Quits: jdong_ (~quassel@222.126.155.250) (Remote host closed the connection)
726. # [03:34] * Joins: davidb (~davidb@bas1-toronto06-2925210074.dsl.bell.ca)
727. # [03:37] <annevk> ooh, roc is at that conference today
728. # [03:37] <annevk> that's too bad
729. # [03:37] * Joins: myakura (~myakura@FL1-203-136-164-250.tky.mesh.ad.jp)
730. # [03:37] <annevk> can someone else answer my fullscreen questions?
731. # [03:37] <annevk> (if so, see the WHATWG list)
732. # [03:38] * Quits: necolas (~necolas@5e0c0fc8.bb.sky.com) (Remote host closed the connection)
733. # [03:44] * Quits: shans (~shanestep@202.171.174.250) (Quit: shans)
734. # [03:47] <zewt> personally I don't understand the "full screen without input" idea--that's crippling to essentially every usage, i can't imagine anyone ever using it
735. # [03:47] <zewt> even a trivial video player wants space to pause
736. # [03:48] <annevk> you get some keyboard always
737. # [03:48] <annevk> but even then I fail to see the concern given the various things that are in place
738. # [03:50] * Quits: ap_ (~ap@17.212.155.203) (Quit: ap_)
739. # [03:50] <zewt> the entire "go fullscreen first and ask if that was okay" model that it seems everyone is implementing is really worrisome
740. # [03:51] <zewt> i don't want sites taking my browser window fullscreen to show a gigantic interstitial ad (at which point the browser asking permission is basically going "wow, that was annoying, wasn't it?")
741. # [03:51] <zewt> i'm surprised i havn't seen sites do that with flash, though i guess i wouldn't since i flashblock by default
742. # [03:51] <annevk> it's going to use the "trusted click" model for sure
743. # [03:51] <zewt> that doesn't help, it just moves the annoyance to the first time you click anywhere
744. # [03:52] * Joins: dydx (~dydz@adsl-75-37-25-16.dsl.pltn13.sbcglobal.net)
745. # [03:52] <annevk> i guess some sites do that with popups these days
746. # [03:52] <zewt> lots of pages listen for clicks on document to open a popup yeah what you said
747. # [03:52] <zewt> the only benefit, IMO, to the only-on-click model is preventing infinite recursion
748. # [03:53] <zewt> not so much preventing the annoyance itself, just keeping it from exploding
749. # [03:53] <zewt> (and it's clearer than magic behind-the-scenes heuristics like "has this site opened a popup/tried to go fullscreen already in the last few seconds")
750. # [03:56] <annevk> so you prefer upfront confirmation?
751. # [03:57] <zewt> as long as there's an easy "always allow for this site" option, yeah
752. # [03:58] <annevk> ugh
753. # [03:58] <zewt> the API already allows it, but it seems like both FF and Chrome are going the ask-afterwards route
754. # [03:58] <annevk> seems better to just nuke it permanently for the few sites that abuse it
755. # [03:58] <zewt> it's the sort of thing that seems really tempting for low-grade advertisers to push sites to do
756. # [04:01] * Quits: myakura (~myakura@FL1-203-136-164-250.tky.mesh.ad.jp) (Remote host closed the connection)
757. # [04:06] * Quits: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi) (Read error: Operation timed out)
758. # [04:06] * Joins: david_carlisle (~chatzilla@dcarlisle.demon.co.uk)
759. # [04:10] * Joins: jdong_ (~quassel@222.126.155.250)
760. # [04:11] * Joins: astearns (~anonymous@c-50-132-63-33.hsd1.wa.comcast.net)
761. # [04:11] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: Leaving)
762. # [04:12] * Quits: nw` (eero@heaven.unlink.org) (Read error: Operation timed out)
763. # [04:14] * Joins: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi)
764. # [04:16] * Joins: nw` (eero@212.94.66.210)
765. # [04:16] * Quits: mkanat (mkanat@nat/google/x-juwkphzzevcqbumb) (Quit: Ex-Chat)
766. # [04:19] * heycam|away is now known as heycam
767. # [04:20] <erlehmann> annevk, with geolocation, upfront notification is working.
768. # [04:20] <erlehmann> also, what zewt said. madness.
769. # [04:23] <zewt> what happens with ask-after notifications if a page goes fullscreen, shows an ad for 2-3 seconds, then exits before the user has a chance to click "stop doing that"? browsers would also need to keep the "allow/block fullscreen" question open after exiting fullscreen to prevent that
770. # [04:23] * Quits: jdong_ (~quassel@222.126.155.250) (Ping timeout: 244 seconds)
771. # [04:25] * Quits: rniwa (rniwa@nat/google/x-ohprythrsayklyib) (Quit: rniwa)
772. # [04:26] * Quits: david_carlisle (~chatzilla@dcarlisle.demon.co.uk) (Ping timeout: 248 seconds)
773. # [04:44] * Quits: othermaciej (~mjs@17.245.90.53) (Quit: othermaciej)
774. # [04:44] * othermaciej_ is now known as othermaciej
775. # [04:45] * Joins: shans (~shanestep@202.171.174.250)
776. # [04:47] * Quits: micheil (~micheil@195.24.233.121) (Quit: http://brandedcode.com | http://github.com/miksago)
777. # [04:53] * Joins: Rik`_ (~Rik`@2a01:e34:ec0f:1570:78e7:d7f6:3230:e444)
778. # [04:55] * Joins: Rik`__ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
779. # [04:55] * Joins: jdong_ (~quassel@222.126.155.250)
780. # [04:57] * Quits: Rik` (~Rik`@2a01:e34:ec0f:1570:e549:b971:6ae9:9da7) (Ping timeout: 240 seconds)
781. # [04:57] * Quits: Rik`__ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
782. # [04:57] * Joins: Rik`___ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
783. # [04:57] * Joins: shans_ (~shanestep@202.171.174.250)
784. # [04:58] * Quits: Rik`_ (~Rik`@2a01:e34:ec0f:1570:78e7:d7f6:3230:e444) (Ping timeout: 244 seconds)
785. # [04:58] * Quits: Rik`___ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
786. # [04:58] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
787. # [04:59] * Quits: shans (~shanestep@202.171.174.250) (Read error: Connection reset by peer)
788. # [04:59] * shans_ is now known as shans
789. # [04:59] * Joins: Rik`_ (~Rik`@2a01:e34:ec0f:1570:4d3e:f53e:576e:9a5c)
790. # [04:59] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
791. # [05:02] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
792. # [05:03] * Joins: Rik`__ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
793. # [05:03] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
794. # [05:05] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
795. # [05:05] * Quits: Rik`__ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
796. # [05:05] * Quits: Rik`_ (~Rik`@2a01:e34:ec0f:1570:4d3e:f53e:576e:9a5c) (Ping timeout: 240 seconds)
797. # [05:05] * Quits: ojan (ojan@nat/google/x-izusvtpnjxksxuef) (Quit: ojan)
798. # [05:07] * Joins: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
799. # [05:07] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
800. # [05:08] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
801. # [05:08] * Quits: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
802. # [05:10] * Joins: Rik`_ (~Rik`@78.192.241.87)
803. # [05:10] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
804. # [05:12] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
805. # [05:12] * Quits: Rik`_ (~Rik`@78.192.241.87) (Read error: Connection reset by peer)
806. # [05:14] * Joins: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
807. # [05:14] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
808. # [05:15] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
809. # [05:15] * Quits: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
810. # [05:18] * Joins: tantek (~tantek@cpe-74-73-189-229.nyc.res.rr.com)
811. # [05:21] <annevk> zewt, sure
812. # [05:21] <annevk> erlehmann, you want to optimize for the positive case
813. # [05:21] <annevk> these DOM Level 3 Events emails sure are entertaining
814. # [05:26] <erlehmann> annevk, too many asshats out there. let me be the first to abuse SUDDEN FULLSCREEN MADNESS.
815. # [05:26] <erlehmann> just think: this, combined with shock sites.
816. # [05:27] * Joins: nattokirai (~nattokira@rtr.mozilla.or.jp)
817. # [05:28] * Quits: shans (~shanestep@202.171.174.250) (Read error: Connection reset by peer)
818. # [05:29] * Quits: nonge_ (~nonge@91.50.110.20) (Ping timeout: 260 seconds)
819. # [05:31] * Quits: miketaylr (~miketaylr@24.42.93.245) (Quit: miketaylr)
820. # [05:31] * Quits: jacobolus (~jacobolus@74-95-207-206-SFBA.hfc.comcastbusiness.net) (Remote host closed the connection)
821. # [05:33] * Joins: shans (~shanestep@202.171.174.250)
822. # [05:37] * Quits: dydx (~dydz@adsl-75-37-25-16.dsl.pltn13.sbcglobal.net) (Quit: dydx)
823. # [05:39] <annevk> erlehmann, yeah I totally see myself browsing shock sites all day
824. # [05:40] * Joins: nonge_ (~nonge@p5B326835.dip.t-dialin.net)
825. # [05:44] * Joins: jacobolus (~jacobolus@c-71-202-250-194.hsd1.ca.comcast.net)
826. # [05:50] * Quits: davidb (~davidb@bas1-toronto06-2925210074.dsl.bell.ca) (Quit: davidb)
827. # [05:51] * Joins: benjoffe_ (~benjoffe_@CPE-121-218-225-100.lnse4.cht.bigpond.net.au)
828. # [06:03] * heycam is now known as heycam|away
829. # [06:14] * Quits: aho (~nya@fuld-590c7543.pool.mediaWays.net) (Quit: EXEC_over.METHOD_SUBLIMATION)
830. # [06:14] * Joins: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net)
831. # [06:15] <annevk> heycam|away, hey
832. # [06:16] <annevk> heycam|away, I guess we could reuse Error, but is it worth it?
833. # [06:20] * Joins: zhaying (~zhaying@adsl-072-148-156-026.sip.mia.bellsouth.net)
834. # [06:29] <annevk> is cpearce on IRC?
835. # [06:29] * Quits: shans (~shanestep@202.171.174.250) (Quit: shans)
836. # [06:37] * Quits: tantek (~tantek@cpe-74-73-189-229.nyc.res.rr.com) (Read error: Connection reset by peer)
837. # [06:38] * Joins: tantek (~tantek@74.73.189.229)
838. # [06:40] * Quits: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net) (Remote host closed the connection)
839. # [06:40] * Joins: rniwa (~rniwa@216.239.45.130)
840. # [06:42] * Quits: erlehmann (~erlehmann@dslb-092-078-130-083.pools.arcor-ip.net) (Quit: Ex-Chat)
841. # [06:51] <zewt> synchronous calls waiting for an animation to complete? D:
842. # [06:57] * Quits: annevk (~annevk@EM114-48-182-2.pool.e-mobile.ne.jp) (Ping timeout: 248 seconds)
843. # [06:58] * Quits: MikeSmith (~MikeSmith@EM114-48-182-2.pool.e-mobile.ne.jp) (Ping timeout: 252 seconds)
844. # [07:00] * Joins: micheil (~micheil@92.40.253.92.threembb.co.uk)
845. # [07:02] * Quits: zewt (~x@c-24-62-196-44.hsd1.ma.comcast.net) (Ping timeout: 248 seconds)
846. # [07:04] * Joins: MikeSmith (~MikeSmith@EM114-48-71-193.pool.e-mobile.ne.jp)
847. # [07:04] * abarth is now known as abarth|wet
848. # [07:14] * Quits: micheil (~micheil@92.40.253.92.threembb.co.uk) (Quit: http://brandedcode.com | http://github.com/miksago)
849. # [07:14] * Joins: zcorpan (~zcorpan@c-699de355.410-6-64736c14.cust.bredbandsbolaget.se)
850. # [07:16] * Quits: jdong_ (~quassel@222.126.155.250) (Ping timeout: 252 seconds)
851. # [07:18] * Joins: annevk (~annevk@EM114-48-71-193.pool.e-mobile.ne.jp)
852. # [07:21] * Joins: robman (~robman@eth4584.nsw.adsl.internode.on.net)
853. # [07:31] * Joins: FlorianX (~Florian_S@p4FE2CA21.dip.t-dialin.net)
854. # [07:42] * Quits: benjoffe_ (~benjoffe_@CPE-121-218-225-100.lnse4.cht.bigpond.net.au) (Remote host closed the connection)
855. # [07:44] * abarth|wet is now known as abarth
856. # [07:47] * Joins: zewt (~x@24.62.196.44)
857. # [07:49] * Quits: ezoe (~ezoe@203-140-90-183f1.kyt1.eonet.ne.jp) (Ping timeout: 258 seconds)
858. # [07:50] <zcorpan> s/may only be called/must be called/ is a "worthy grammatical clarification"? ok
859. # [07:52] * Quits: zewt (~x@24.62.196.44) (Ping timeout: 260 seconds)
860. # [07:57] * Joins: lAeternusl (~kvirc@rs.gridnine.com)
861. # [08:06] * Joins: ezoe (~ezoe@112-68-245-242f1.kyt1.eonet.ne.jp)
862. # [08:06] * Quits: jacobolus (~jacobolus@c-71-202-250-194.hsd1.ca.comcast.net) (Remote host closed the connection)
863. # [08:07] <Hixie> zcorpan: if by "worthy grammatical clarification" you mean "correction for bogus use of RFC2119 terms" :-)
864. # [08:12] * Joins: maikmerten (~merten@ls5dhcp200.cs.uni-dortmund.de)
865. # [08:15] * Joins: jacobolus (~jacobolus@adsl-99-35-227-57.dsl.pltn13.sbcglobal.net)
866. # [08:16] <zcorpan> d3e is full of it it seems
867. # [08:20] <Hixie> d3e?
868. # [08:21] <Hixie> oh dom events?
869. # [08:21] <Hixie> hm
870. # [08:24] * Joins: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
871. # [08:24] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
872. # [08:24] * Quits: ezoe (~ezoe@112-68-245-242f1.kyt1.eonet.ne.jp) (Ping timeout: 252 seconds)
873. # [08:25] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
874. # [08:25] * Quits: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
875. # [08:26] <Hixie> what's the state of the art in terms of networking protocols to transfer responsibility for a token from one server on the Internet to another server?
876. # [08:26] <Hixie> that is, is there an established solution, or is it a known unsolveable problem, or something else?
877. # [08:27] * Joins: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
878. # [08:27] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
879. # [08:27] <Hixie> (that is, say there are two servers A and B, and A currently has ownership/responsibility of a token X, and wants to transfer it to B, but wants B to only take it if B knows that A knows that B has taken it)
880. # [08:27] * Joins: jdong_ (~quassel@222.126.155.250)
881. # [08:28] <Hixie> (abarth?)
882. # [08:28] <abarth> Hixie: sorry, playing bridge
883. # [08:28] <abarth> send email
884. # [08:28] <Hixie> nothing important, just my question above
885. # [08:29] <Hixie> not a web standard thing
886. # [08:29] <Hixie> enjoy your bridge :-)
887. # [08:29] * Quits: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
888. # [08:29] * Joins: Rik` (~Rik`@2a01:e34:ec0f:1570:9171:ee99:57a0:6a32)
889. # [08:31] * Joins: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
890. # [08:32] * Quits: othermaciej (~mjs@2620:149:4:1b01:80a8:7797:8c40:91dd) (Read error: Connection reset by peer)
891. # [08:32] * Joins: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net)
892. # [08:32] * Joins: othermaciej (~mjs@17.212.155.82)
893. # [08:33] * Joins: Rik`__ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
894. # [08:33] * Quits: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
895. # [08:34] * Joins: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
896. # [08:34] * Quits: Rik`__ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
897. # [08:34] * Quits: Rik` (~Rik`@2a01:e34:ec0f:1570:9171:ee99:57a0:6a32) (Ping timeout: 244 seconds)
898. # [08:38] * Joins: zewt (~x@c-24-62-196-44.hsd1.ma.comcast.net)
899. # [08:41] * Quits: eighty4 (~eighty4@unaffiliated/eighty4) (Excess Flood)
900. # [08:43] * Joins: eighty4 (~eighty4@unaffiliated/eighty4)
901. # [08:56] * Quits: rniwa (~rniwa@216.239.45.130) (Quit: rniwa)
902. # [08:57] * Joins: RobbertAtWork (~Robbert@a83-160-99-114.adsl.xs4all.nl)
903. # [09:02] <RobbertAtWork> I had this idea about the Component Model: if you allow to register existing tagNames without the x- prefix, web pages could reserve the privilege of creating scripts (against XSS). (function() { var script = HTMLScriptElement; var secretTagName = randomTagName(); Element.register("script", function(){}); Element.register(secretTagName, HTMLScriptElement); })()
904. # [09:03] <RobbertAtWork> execute this in the <head> and no scripts after that will be evaluated.
905. # [09:05] * Quits: zewt (~x@c-24-62-196-44.hsd1.ma.comcast.net) (Ping timeout: 255 seconds)
906. # [09:09] * Joins: zewt (~x@24.62.196.44)
907. # [09:09] * Joins: rimantas (~rimliu@93.93.57.193)
908. # [09:12] * Joins: ezoe (~ezoe@112-68-245-60f1.kyt1.eonet.ne.jp)
909. # [09:14] * Quits: zewt (~x@24.62.196.44) (Ping timeout: 260 seconds)
910. # [09:16] * Quits: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Remote host closed the connection)
911. # [09:18] * Joins: zewt (~x@c-24-62-196-44.hsd1.ma.comcast.net)
912. # [09:22] * Joins: Lachy (~Lachy@cm-84.215.59.50.getinternet.no)
913. # [09:22] * Quits: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net) (Quit: tomasf)
914. # [09:24] * Quits: ezoe (~ezoe@112-68-245-60f1.kyt1.eonet.ne.jp) (Ping timeout: 240 seconds)
915. # [09:26] * Joins: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net)
916. # [09:40] * Quits: agektmr (~Adium@220.109.219.244) (Quit: Leaving.)
917. # [09:43] * Joins: agektmr (~Adium@220.109.219.244)
918. # [09:48] * Joins: ezoe (~ezoe@203-140-90-86f1.kyt1.eonet.ne.jp)
919. # [09:54] * nunnun is now known as nunnun_away
920. # [09:54] * Quits: jacobolus (~jacobolus@adsl-99-35-227-57.dsl.pltn13.sbcglobal.net) (Remote host closed the connection)
921. # [10:09] * Joins: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net)
922. # [10:11] * Quits: Lachy (~Lachy@cm-84.215.59.50.getinternet.no) (Quit: Computer has gone to sleep.)
923. # [10:12] * Joins: david_carlisle (~chatzilla@86.188.197.189)
924. # [10:13] * Joins: richt (~richt@pat-tdc.opera.com)
925. # [10:25] * Joins: Rich_Clark (~chatzilla@94-193-82-82.zone7.bethere.co.uk)
926. # [10:27] * Joins: Necrathex (~nectop@82-170-160-25.ip.telfort.nl)
927. # [10:27] * Quits: nattokirai (~nattokira@rtr.mozilla.or.jp) (Quit: nattokirai)
928. # [10:28] * Joins: necrodearia (~mizery@unaffiliated/necrodearia)
929. # [10:29] * Joins: joepie91 (~joepie91@s514735fe.adsl.wanadoo.nl)
930. # [10:31] * Quits: necrodearia (~mizery@unaffiliated/necrodearia) (Remote host closed the connection)
931. # [10:31] * nunnun_away is now known as nunnun
932. # [10:33] * Joins: zhaying1 (~zhaying@adsl-072-148-156-026.sip.mia.bellsouth.net)
933. # [10:35] * Quits: zhaying (~zhaying@adsl-072-148-156-026.sip.mia.bellsouth.net) (Ping timeout: 255 seconds)
934. # [10:39] <annevk> zcorpan, good question
935. # [10:39] <annevk> zcorpan, sicking suggested we keep it because browsers keep the state around internally
936. # [10:40] <zcorpan> the isWhiteSpace thing?
937. # [10:40] <annevk> yes
938. # [10:40] <foolip> Hixie, rniwa, Opera support document.getItems(), but not the spec changes that were made a few days ago of course
939. # [10:40] * Joins: ZombieLoffe (ZombieL@unaffiliated/zombieloffe)
940. # [10:41] <annevk> I'll add a comment to https://bugzilla.mozilla.org/show_bug.cgi?id=687422
941. # [10:48] * Joins: connrs (~connrs@212.159.122.160)
942. # [10:49] * Joins: Rik` (~Rik`@195.212.22.251)
943. # [10:57] * Joins: virtuelv (~virtuelv_@213.236.208.22)
944. # [11:00] * Quits: Rik` (~Rik`@195.212.22.251) (Remote host closed the connection)
945. # [11:03] * Joins: Lachy (~Lachy@cm-84.215.59.50.getinternet.no)
946. # [11:05] <RobbertAtWork> annevk: I always though element content whitespace was a different thing
947. # [11:05] <RobbertAtWork> [
948. # [11:06] <RobbertAtWork> http://www.w3.org/TR/REC-xml/#dt-elemcontent says element content is content of elements that must contain only child elements
949. # [11:06] <RobbertAtWork> so the contents of a <ul> element for example
950. # [11:06] * jgraham reads a little backscroll, finds js being described as a "functional" language, gives up
951. # [11:06] <annevk> yeah it is a different thing, but browsers never implemented the attribute based on semantics of the language so it became to mean isWhiteSpace as far as implementations go
952. # [11:06] <RobbertAtWork> so I figured for white-space text nodes between <ul> and <li> isElementContentWhitespace would be true
953. # [11:07] <RobbertAtWork> while for whitespace text nodes in <li> elements it would be false
954. # [11:07] <annevk> yeah
955. # [11:08] <RobbertAtWork> So I'd say: add isWhiteSpace to the DOM4 standard, rename the current implementations, and let isElementContentWhitespace return false as long as it isn't implemented
956. # [11:08] <annevk> is the latter useful?
957. # [11:09] <annevk> or the former for that matter, nobody brought up a use case yet :)
958. # [11:09] <RobbertAtWork> yeah, it would fix implementations that depend on it's functionality
959. # [11:10] * Quits: virtuelv (~virtuelv_@213.236.208.22) (Quit: Ex-Chat)
960. # [11:10] <annevk> it's probably going to return undefined
961. # [11:10] <annevk> as it already does in some browsers
962. # [11:11] <Philip`> jgraham: Would you prefer it to be called a dysfunctional language?
963. # [11:11] * Quits: riven (~riven@pdpc/supporter/professional/riven) (Ping timeout: 255 seconds)
964. # [11:12] <jgraham> Philip`: Depends how annoyed I am with it at the time :)
965. # [11:12] <RobbertAtWork> XML Information Set says on the subject of element content whitespace "If there is no declaration for the containing element, …, this property has no value", so I guess null or undefined is okay with me, although null is more like other DOM properties
966. # [11:12] * Joins: riven (~riven@pdpc/supporter/professional/riven)
967. # [11:14] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
968. # [11:14] * Joins: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
969. # [11:14] * Quits: Lachy (~Lachy@cm-84.215.59.50.getinternet.no) (Quit: Computer has gone to sleep.)
970. # [11:14] <annevk> RobbertAtWork, I mean we would remove it for now
971. # [11:15] <RobbertAtWork> annevk: fine
972. # [11:19] * Joins: mokush (~quassel@cl-86-125-163-136.cablelink.mures.rdsnet.ro)
973. # [11:19] <RobbertAtWork> annevk: isWhiteSpace is quite useful for minifying, for scripts that know what whitespace is ignorable. Xopus uses it to minimize the amount of nodes in memory, removes the ignorable whitespace according to the current Schema
974. # [11:21] * Quits: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
975. # [11:24] <zcorpan> wouldn't you want to minify on the server side?
976. # [11:27] <RobbertAtWork> wouldn't you want to use the DOM for that?
977. # [11:28] <RobbertAtWork> using the DOM is the easiest approach for several minifying passes
978. # [11:28] <zcorpan> using the DOM for that seems horrible
979. # [11:28] <RobbertAtWork> removing all type attributes from style elements is way easier using DOM than regexp
980. # [11:29] <zcorpan> you're not limited to DOM and regexp on the server
981. # [11:31] <zcorpan> anyway, i think we shouldn't design the DOM around server-side use cases
982. # [11:31] <zcorpan> doing so introduced a lot of bloat to the DOM that we're now trying to clean up in DOM4
983. # [11:31] <RobbertAtWork> then I want to minify on the client
984. # [11:32] <zcorpan> why?
985. # [11:32] * Joins: Lachy (~Lachy@213.236.208.22)
986. # [11:39] * Quits: mokush (~quassel@cl-86-125-163-136.cablelink.mures.rdsnet.ro) (Read error: Connection reset by peer)
987. # [11:40] * Joins: mokush (~quassel@cl-86-125-163-136.cablelink.mures.rdsnet.ro)
988. # [11:41] <RobbertAtWork> zcorpan: I'll get back to you on that, have to go now
989. # [11:42] * Quits: RobbertAtWork (~Robbert@a83-160-99-114.adsl.xs4all.nl) (Quit: RobbertAtWork)
990. # [11:43] <zcorpan> k
991. # [11:43] * nunnun is now known as nunnun_away
992. # [11:44] * Joins: virtuelv (~virtuelv_@pat-tdc.opera.com)
993. # [11:45] * Quits: gavin_ (~gavin@76.14.70.183) (Remote host closed the connection)
994. # [11:45] * Joins: gavin_ (~gavin@76.14.70.183)
995. # [11:57] * Quits: lAeternusl (~kvirc@rs.gridnine.com) (Read error: Connection reset by peer)
996. # [12:00] * Joins: Areks (~kvirc@rs.gridnine.com)
997. # [12:03] * Joins: Vampire (~MC@unaffiliated/vampire)
998. # [12:03] * Parts: Vampire (~MC@unaffiliated/vampire)
999. # [12:09] * Joins: smaug____ (~chatzilla@ZYYKMMMCXXXVII.gprs.sl-laajakaista.fi)
1000. # [12:22] * Quits: mokush (~quassel@cl-86-125-163-136.cablelink.mures.rdsnet.ro) (Remote host closed the connection)
1001. # [12:30] * Quits: agektmr (~Adium@220.109.219.244) (Remote host closed the connection)
1002. # [12:30] * Joins: necolas (~necolas@5e0c0fc8.bb.sky.com)
1003. # [12:33] * Joins: agektmr (~Adium@2401:fa00:4:1012:fa1e:dfff:fee6:d74e)
1004. # [12:36] * Joins: roc (~chatzilla@202.61.222.68.static.rev.eftel.com)
1005. # [12:36] * Quits: twisted` (~twisted@205.189.73.45) (Ping timeout: 240 seconds)
1006. # [12:38] * Joins: twisted` (~twisted@205.189.73.45)
1007. # [12:45] <jgraham> Hixie: BTW one concreate reason to prefer DOM-in-JS is that it may provide performance wins. JS-C++ boundaries are generally bad for perf. especially as you can't JIT across them
1008. # [12:51] <smaug____> (that argument was covered last night.)
1009. # [12:52] <smaug____> (and it is very valid one, although kind of implementation detail)
1010. # [12:52] <jgraham> Oh, like I say hundreds of lines of argument were too much to read
1011. # [12:53] <smaug____> :)
1012. # [12:55] <jgraham> I'm not sure dismissing it as an implementation detail is valid though; implementation details can be critical particularly if they are a fundamental characteristic of all sucessful implementations
1013. # [12:56] * Joins: cygri (~cygri@80.169.32.154)
1014. # [12:57] * Quits: annevk (~annevk@EM114-48-71-193.pool.e-mobile.ne.jp) (Ping timeout: 248 seconds)
1015. # [12:57] * Joins: dirkpennings (~Vuurbal@90-145-26-140.bbserv.nl)
1016. # [12:58] * Quits: MikeSmith (~MikeSmith@EM114-48-71-193.pool.e-mobile.ne.jp) (Ping timeout: 252 seconds)
1017. # [13:02] * Joins: bga_ (~bga@95-55-46-124.dynamic.avangarddsl.ru)
1018. # [13:05] * Joins: MikeSmith (~MikeSmith@EM1-113-202-1.pool.e-mobile.ne.jp)
1019. # [13:06] * Joins: FlorianX1 (~Florian_S@p4FE2CEB5.dip.t-dialin.net)
1020. # [13:08] * Quits: Necrathex (~nectop@82-170-160-25.ip.telfort.nl) (Quit: Necrathex)
1021. # [13:09] * Quits: FlorianX (~Florian_S@p4FE2CA21.dip.t-dialin.net) (Ping timeout: 240 seconds)
1022. # [13:17] * Joins: Necrathex (~nectop@82-170-160-25.ip.telfort.nl)
1023. # [13:20] * Quits: dominicc|home (~dominicc@114.167.184.208) (Quit: dominicc|home)
1024. # [13:24] * temp02 is now known as temp01
1025. # [13:49] * Quits: jdong_ (~quassel@222.126.155.250) (Ping timeout: 255 seconds)
1026. # [13:52] * Quits: heycam|away (~cam@wok.mcc.id.au) (Ping timeout: 258 seconds)
1027. # [13:54] * Joins: jonatasnona (~jonatas@lba.inpa.gov.br)
1028. # [13:57] <gsnedders> (Esp. with a tracing JIT DOM-in-JS should be able to provide good perf, because you'll simply cut out a lot of the complexity)
1029. # [14:00] <jgraham> What's extra sensory perception got to do with anything?
1030. # [14:01] <gsnedders> …
1031. # [14:02] <jgraham> o
1032. # [14:02] <jgraham> ^man with third eye
1033. # [14:02] <jgraham> Unless you are using a proportionally spaced font for irc, in which case it sucks to be you
1034. # [14:05] * Quits: roc (~chatzilla@202.61.222.68.static.rev.eftel.com) (Ping timeout: 258 seconds)
1035. # [14:05] * Joins: roc (~chatzilla@202.61.222.68.static.rev.eftel.com)
1036. # [14:14] * Quits: necolas (~necolas@5e0c0fc8.bb.sky.com) (Remote host closed the connection)
1037. # [14:15] * Joins: necolas (~necolas@5e0c0fc8.bb.sky.com)
1038. # [14:16] * Joins: annevk (~annevk@EM1-113-202-1.pool.e-mobile.ne.jp)
1039. # [14:18] * Quits: agektmr (~Adium@2401:fa00:4:1012:fa1e:dfff:fee6:d74e) (Quit: Leaving.)
1040. # [14:24] * Joins: MacTed (~Thud@18.111.2.104)
1041. # [14:27] * Joins: karlcow (~karl@nerval.la-grange.net)
1042. # [14:28] * Joins: benjoffe_ (~benjoffe_@CPE-121-218-225-100.lnse4.cht.bigpond.net.au)
1043. # [14:34] * Joins: jdaggett (~jdaggett@y230056.dynamic.ppp.asahi-net.or.jp)
1044. # [14:41] * Joins: micheil (~micheil@92.40.253.92.threembb.co.uk)
1045. # [14:43] <matjas> what’s the appropriate markup for stuff like “Note: foo bar baz” or “Update: foo bar baz” in blog posts? currently i just use <p> for both, with an extra <ins> for updates
1046. # [14:43] <matjas> perhaps <small> would be better?
1047. # [14:44] <annevk> <p> seems fine
1048. # [14:44] <annevk> in specs we use <p class=note>foo bar baz
1049. # [14:44] <annevk> we don't do updates
1050. # [14:45] <matjas> cool, thanks
1051. # [14:48] * Quits: karlcow (~karl@nerval.la-grange.net) (Remote host closed the connection)
1052. # [14:50] * Joins: jdong_bot_ (~jdong_bot@117.79.233.156)
1053. # [14:53] * Quits: ZombieLoffe (ZombieL@unaffiliated/zombieloffe)
1054. # [14:55] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
1055. # [14:57] <annevk> oooooh yeeah
1056. # [14:57] <annevk> Xbox 360 is finally getting server-side storage for gamertags and such
1057. # [14:59] * Quits: salavas (~salavas@c83-248-102-83.bredband.comhem.se) (Read error: Operation timed out)
1058. # [15:00] * Quits: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
1059. # [15:04] * Joins: miketaylr (~miketaylr@206.217.92.186)
1060. # [15:04] * Quits: smaug____ (~chatzilla@ZYYKMMMCXXXVII.gprs.sl-laajakaista.fi) (Read error: Connection reset by peer)
1061. # [15:04] * Quits: miketaylr (~miketaylr@206.217.92.186) (Remote host closed the connection)
1062. # [15:06] * Quits: tantek (~tantek@74.73.189.229) (Quit: tantek)
1063. # [15:07] * Quits: micheil (~micheil@92.40.253.92.threembb.co.uk) (Quit: http://brandedcode.com | http://github.com/miksago)
1064. # [15:07] * Joins: miketaylr (~miketaylr@206.217.92.186)
1065. # [15:12] * Quits: virtuelv (~virtuelv_@pat-tdc.opera.com) (Quit: Ex-Chat)
1066. # [15:19] * Quits: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net) (Quit: tomasf)
1067. # [15:21] * Joins: davidb (~davidb@66.207.208.98)
1068. # [15:23] * Quits: jdaggett (~jdaggett@y230056.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
1069. # [15:24] * Joins: agektmr (~Adium@p2156-ipbf5107marunouchi.tokyo.ocn.ne.jp)
1070. # [15:26] * Quits: dirkpennings (~Vuurbal@90-145-26-140.bbserv.nl) (Ping timeout: 258 seconds)
1071. # [15:26] * bga_ is now known as bga_|away
1072. # [15:40] * Joins: GlitchMr (~glitchmr@178-36-62-199.adsl.inetia.pl)
1073. # [15:41] * ericc|away is now known as eric_carlson
1074. # [15:42] * Quits: jonatasnona (~jonatas@lba.inpa.gov.br) (Quit: Saindo)
1075. # [15:43] * Quits: zhaying1 (~zhaying@adsl-072-148-156-026.sip.mia.bellsouth.net) (Quit: Leaving.)
1076. # [15:47] * bga_|away is now known as bga_
1077. # [15:55] * Parts: espadrine (~thaddee_t@acces2299.res.insa-lyon.fr)
1078. # [15:55] * Joins: espadrine (~thaddee_t@acces2299.res.insa-lyon.fr)
1079. # [15:57] * Joins: tomasf (~tomasf@109.58.175.4)
1080. # [16:09] * Quits: david_carlisle (~chatzilla@86.188.197.189) (Ping timeout: 245 seconds)
1081. # [16:10] * Quits: rimantas (~rimliu@93.93.57.193) (Quit: Leaving)
1082. # [16:12] * Joins: scor (~scor@drupal.org/user/52142/view)
1083. # [16:21] * Quits: tomasf (~tomasf@109.58.175.4) (Ping timeout: 252 seconds)
1084. # [16:26] * Quits: agektmr (~Adium@p2156-ipbf5107marunouchi.tokyo.ocn.ne.jp) (Quit: Leaving.)
1085. # [16:28] * Joins: tomasf (~tomasf@109.58.173.44)
1086. # [16:28] * Quits: roc (~chatzilla@202.61.222.68.static.rev.eftel.com) (Remote host closed the connection)
1087. # [16:33] * Joins: rabbi1 (~manjunath@49.249.127.51)
1088. # [16:34] * Joins: _bga (~bga@95-55-42-221.dynamic.avangarddsl.ru)
1089. # [16:36] * Quits: bga_ (~bga@95-55-46-124.dynamic.avangarddsl.ru) (Ping timeout: 244 seconds)
1090. # [16:44] * Quits: tomasf (~tomasf@109.58.173.44) (Ping timeout: 256 seconds)
1091. # [16:45] * Joins: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com)
1092. # [16:45] * Joins: GlitchMr42 (~glitchmr@178-36-61-141.adsl.inetia.pl)
1093. # [16:47] * slightlyoff is now known as slightlyoff_afk
1094. # [16:48] * Quits: GlitchMr (~glitchmr@178-36-62-199.adsl.inetia.pl) (Ping timeout: 248 seconds)
1095. # [16:48] * Joins: smaug____ (~chatzilla@ZMMMCCXXII.gprs.sl-laajakaista.fi)
1096. # [16:49] <annevk> discussing standards on twitter sucks badly
1097. # [16:49] <annevk> can someone make it stop?
1098. # [16:50] <annevk> Google+ sort of works, but excludes Ms2ger; mailing lists really would be best
1099. # [16:51] <jgraham> echo '127.0.0.1 twitter.com' >> /etc/hosts
1100. # [16:52] * GlitchMr42 is now known as GlitchMr
1101. # [16:54] <Philip`> The W3C ought to develop a social network platform designed for discussing and developing specifications, rather than expecting people to use antiquated things like mailing lists or inappropriate things like Twitter
1102. # [16:55] <astearns> tldr: gamily standards!
1103. # [16:55] * nunnun_away is now known as nunnun
1104. # [16:55] <astearns> *gamify
1105. # [16:56] <hsivonen> annevk: yeah, I can't figure out how slightlyoff_afk wants node renames to behave or what the use case for node renames is
1106. # [16:56] <annevk> he just wants everything to be a function
1107. # [16:57] <annevk> and then since new Element() would be pointless, he suggested something about a writable local name, which of course would not work, but never mind that
1108. # [16:58] * Quits: smaug____ (~chatzilla@ZMMMCCXXII.gprs.sl-laajakaista.fi) (Ping timeout: 252 seconds)
1109. # [16:58] <hsivonen> it would be kinda unfortunate if the platform implementation couldn't be organized into classes the way it can be organized if a node can't change what element it represents
1110. # [16:59] <hsivonen> node renaming is like every element being input type=foo
1111. # [16:59] * Quits: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi)
1112. # [17:00] * Quits: jdong_bot_ (~jdong_bot@117.79.233.156) (Remote host closed the connection)
1113. # [17:00] <jgraham> Making the interface of an Element immutable seems like an important invariant to preserve
1114. # [17:01] <annevk> anyway I doubt he really wants to change that
1115. # [17:02] <annevk> he's just trying to make his vague case for constructors everywhere
1116. # [17:03] * Joins: thiessenp (~thiessenp@changeme.ebuddy.com)
1117. # [17:04] <hsivonen> "constructors everywhere" isn't a use case. what's the motivation for constructors everywhere? is there a blog post about this?
1118. # [17:07] * Joins: shetech (~shetech@c-76-126-167-49.hsd1.ca.comcast.net)
1119. # [17:08] * _bga is now known as bga_|away
1120. # [17:08] * Quits: maikmerten (~merten@ls5dhcp200.cs.uni-dortmund.de) (Remote host closed the connection)
1121. # [17:13] <annevk> yes, but I didn't get it
1122. # [17:13] * Quits: MacTed (~Thud@18.111.2.104) (Quit: The computer fell asleep)
1123. # [17:13] <annevk> I think it has something to do with the idea that the DOM has to be written in terms of ECMAScript
1124. # [17:13] <annevk> and ECMAScript does not know objects you cannot new?
1125. # [17:14] <annevk> but how this helps anyone...
1126. # [17:14] <jgraham> http://www.w3.org/mid/CANr5HFU5PVs0ad_KDE+zVjKgrKFfpF_E0zFvVPx7BymJc9nedQ@mail.gmail.com
1127. # [17:14] <jgraham> Well of course you can create objects that you cannot new using ES
1128. # [17:15] * Joins: david_carlisle (~chatzilla@86.188.197.189)
1129. # [17:18] <jgraham> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1186 is a trivial example
1130. # [17:19] <jgraham> The problem seems to be a belief that not being able to do new HTMLFooElement() even where that doesn't make sense, is screwing over authors
1131. # [17:19] * Quits: Areks (~kvirc@rs.gridnine.com) (Ping timeout: 240 seconds)
1132. # [17:20] * slightlyoff_afk is now known as slightlyoff
1133. # [17:20] <jgraham> In general having constructors where they make sense doesn't seem like a bad idea
1134. # [17:21] <jgraham> They don't really make sense on HTMLElement and "subclasses" though becase there isn't a 1:1 mapping between interface objects and instances
1135. # [17:22] <jgraham> (that is, not every instance you might want to create has a corresponding interface object)
1136. # [17:25] <annevk> yeah, I think we should add them for Text/Comment/Document
1137. # [17:25] <annevk> dunno about Element
1138. # [17:25] * Joins: smaug____ (~chatzilla@cs181151161.pp.htv.fi)
1139. # [17:29] * Joins: ZombieLoffe (ZombieL@unaffiliated/zombieloffe)
1140. # [17:33] * Quits: Lachy (~Lachy@213.236.208.22) (Quit: Computer has gone to sleep.)
1141. # [17:34] * Quits: thiessenp (~thiessenp@changeme.ebuddy.com) (Quit: thiessenp)
1142. # [17:34] * slightlyoff is now known as slightlyoff_afk
1143. # [17:35] * Joins: jkomoros (komoroske@nat/google/x-gciloggzzbkiioue)
1144. # [17:37] * Joins: erlehmann (~erlehmann@dslb-092-078-130-083.pools.arcor-ip.net)
1145. # [17:37] * bga_|away is now known as bga_
1146. # [17:39] * Joins: myakura (~myakura@FL1-203-136-164-250.tky.mesh.ad.jp)
1147. # [17:44] * Quits: shetech (~shetech@c-76-126-167-49.hsd1.ca.comcast.net) (Quit: Leaving.)
1148. # [17:51] * dglazkov|away is now known as dglazkov
1149. # [17:52] <dglazkov> good morning, Whatwg!
1150. # [17:52] <Hixie> mornin'
1151. # [17:52] <smaug____> hyvää iltaa
1152. # [17:53] <dglazkov> anything with umlauts is cool by definition
1153. # [17:54] <jgraham> Finnish isn't a real language it's just a conspiracy to make the rest of the world feel stupid
1154. # [17:54] <smaug____> :p
1155. # [17:54] <Hixie> what's vietnamese then? :-)
1156. # [17:57] <astearns> a conspiracy to prop up the diacritic industry
1157. # [17:58] <miketaylr> a purveyor of fine sandwiches
1158. # [17:58] <jgraham> Oh is that the basis you were comparing on? I was going to say that vietnamese didn't seem very gramatically complex
1159. # [17:59] <jgraham> (although I only glanced at wikipedia, so maybe it is)
1160. # [17:59] <jgraham> whereas the dead giveaway that Finnish is a conspiracy is that they go around talking about 15 cases for nouns
1161. # [17:59] <astearns> omniglot tells me that Vietnamese has six tones. that seems complex
1162. # [17:59] <jgraham> To speak, sure
1163. # [18:00] <jgraham> I rather suspect it would entirely exclude me from the set of potential vietnamese speakers, for example
1164. # [18:02] * Quits: zcorpan (~zcorpan@c-699de355.410-6-64736c14.cust.bredbandsbolaget.se) (Quit: zcorpan)
1165. # [18:02] <scor> Hixie: what was the rationale for conflatin type and vocabulary into @itemtype?
1166. # [18:02] * Joins: jarek (~jarek@unaffiliated/jarek)
1167. # [18:04] * Joins: brucel (~brucel@cpc4-smal11-2-0-cust879.perr.cable.virginmedia.com)
1168. # [18:04] * Quits: myakura (~myakura@FL1-203-136-164-250.tky.mesh.ad.jp) (Remote host closed the connection)
1169. # [18:05] * bga_ is now known as bga_|away
1170. # [18:06] * Joins: othermaciej_ (~mjs@c-24-6-209-189.hsd1.ca.comcast.net)
1171. # [18:06] * Quits: GlitchMr (~glitchmr@178-36-61-141.adsl.inetia.pl) (Read error: Connection reset by peer)
1172. # [18:06] * Joins: GlitchMr (~glitchmr@178-36-34-9.adsl.inetia.pl)
1173. # [18:10] <Hixie> scor: i don't understand the question
1174. # [18:13] * Joins: rillian_ (~rillian@184.71.182.138)
1175. # [18:15] * Joins: J_Voracek (~J_Voracek@71.21.195.70)
1176. # [18:15] * Joins: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi)
1177. # [18:17] * Quits: miketaylr (~miketaylr@206.217.92.186) (Read error: Connection reset by peer)
1178. # [18:17] * Joins: miketaylr (~miketaylr@206.217.92.186)
1179. # [18:23] * Joins: MacTed (~Thud@18.111.2.104)
1180. # [18:26] * bga_|away is now known as bga_
1181. # [18:27] <hsivonen> the rules under "If the element is a time element with a @datetime attribute" in https://dvcs.w3.org/hg/htmldata/raw-file/24af1cde0da1/microdata-rdf/index.html illustrate what's wrong with RDF datatyping
1182. # [18:28] <Hixie> hey, i'm an author on that document
1183. # [18:28] <Hixie> go figure
1184. # [18:28] <Hixie> i didn't even know it existed!
1185. # [18:29] <hsivonen> Hixie: is part of the text copied and pasted from something you wrote?
1186. # [18:29] <Hixie> i assume so
1187. # [18:31] * Joins: gkellogg (~gregg@c-98-248-150-91.hsd1.ca.comcast.net)
1188. # [18:31] <scor> Hixie: sorry, got side tracked. when you took RDFa and designed microdata, what drew you to combine the concepts of vocabulary namespace with the type (in @itmetype)?
1189. # [18:33] <scor> Hixie: RDFa distinguishes the two, but afaik microdata conflates them (this is not a critizism, I just trying to understand what was the rational for combining them)
1190. # [18:34] <gkellogg> About @datetime data typing, I didn't invent this, but found it in a tracker bug I thought Hixie had agreed with; it makes sense to me anyway.
1191. # [18:34] <Hixie> scor: i didn't take RDFa to design microdata
1192. # [18:35] <hsivonen> http://lists.w3.org/Archives/Public/public-html-xml/2011Oct/0022.html
1193. # [18:35] <gkellogg> About the new Microdata-RDF doc, Jeni asked me to resurrect it, and of course, it borrows heavily from the previous Microdata spec
1194. # [18:35] <Hixie> gkellogg: the text hsivonen mentions is the right way to map <time> to RDFa but it illustrates what's wrong with RDF datatyping nonetheless
1195. # [18:35] <Hixie> gkellogg: (note, <time> is likely going away)
1196. # [18:36] <Hixie> scor: RDF doesn't really have a concept of a vocabulary at the syntax level
1197. # [18:36] * Quits: J_Voracek (~J_Voracek@71.21.195.70) (Quit: disconnected: Jace Voracek - Jace@Jace-Place.com)
1198. # [18:36] <annevk> hsivonen, you posted that for entertainment I hope?
1199. # [18:37] <gkellogg> Hixie: I heard that, to be replaced by <data> I suppose?
1200. # [18:37] <annevk> surprised nobody has replied with, "Agreed, it's called XHTML5, you can use it today."
1201. # [18:37] <annevk> or some such
1202. # [18:37] <Hixie> gkellogg: yeah, something like that
1203. # [18:38] <Hixie> gkellogg: wouldn't affect the spec you're writing much except you'd have to add more types to the list hsivonen mentioned (and rename the element and attribute names, of course)
1204. # [18:38] <gkellogg> Martin Heff has complained about the lack of data typing in Microdata, and would like to see a way to infer this from referenced vocabularies. We considered this for RDFa but rejected it.
1205. # [18:38] * Joins: annacc (~Adium@74.125.59.1)
1206. # [18:39] <gkellogg> Hixie: I intend to follow both HTML5 and Microdata specs as they continue to evolve. Your participation, direct or indirect would be welcome.
1207. # [18:39] <annevk> Hixie, I looked at the fullscreen stuff and integrating it directly into HTML might not be a bad idea
1208. # [18:39] <Hixie> gkellogg: microdata has data typing, it's just in the vocabularies rather than in the data (since otherwise you have to repeat it with every property use, which seems silly)
1209. # [18:40] <annevk> Hixie, then again, I can probably define most methods as a separate thing and HTML would just define things such as <iframe allowfullscreen>
1210. # [18:40] <Hixie> annevk: let's do that (the split), i'd rather not have to start defining rendering if i can help it
1211. # [18:40] <Hixie> annevk: the rendering section is bad enough
1212. # [18:41] <gkellogg> Hixie: to be more specific, rules for creating RDF from Microdata with data typed literals. Vocabulary-based typing relies on the processor to do this on it's own, without it's being stated explicitly in the generated RDF. Otherwise, I agree that the way to do it is through datatype inference.
1213. # [18:42] * Quits: jarek (~jarek@unaffiliated/jarek) (Quit: jarek)
1214. # [18:43] * Quits: Rich_Clark (~chatzilla@94-193-82-82.zone7.bethere.co.uk) (Ping timeout: 252 seconds)
1215. # [18:44] <Hixie> gkellogg: no i mean the microdata vocabulary, not the rdf vocalubary. The microdata to RDF convertor would have to know about the microdata vocabulary to add the data typing
1216. # [18:44] * cygri how about strongly deprecating?
1217. # [18:44] <Hixie> gkellogg: (there's not really much point in processing data for which you don't know the vocabulary, anyway, it's not like you can actually do anything with the type information in that case)
1218. # [18:44] * cygri </joking>
1219. # [18:45] * cygri is an idiot. wrong chat window
1220. # [18:46] <gkellogg> In my spec, there's always a vocabulary as in every @itemprop results in a URI. If that URI can be dereferenced and it is an RDFS (or OWL) schema, you could use it to find range information that could be used for datatype inference, but this isn't the SWIG discussion list :)
1221. # [18:46] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
1222. # [18:47] <scor> Hixie: in microdata, is there any difference between a vocabulary and a type? it seems the type in @itemtype defines the vocabulary
1223. # [18:47] <Hixie> scor: a vocabulary in microdata is a group of short names that are defined in a spec and grouped under one (or more) type(s)
1224. # [18:48] <Hixie> scor: it's not equivalent to the type concept in rdf
1225. # [18:48] <Hixie> scor: which is just another property value
1226. # [18:48] <scor> Hixie: so would you say that a microdata vocabulary has the same URI as the type or not?
1227. # [18:48] <Hixie> scor: a vocabulary in microdata doesn't have a url
1228. # [18:49] <scor> ah, so how is it defined? by its popular name?
1229. # [18:49] <Hixie> the same way, e.g., HTML's vocabulary is defined. In a spec.
1230. # [18:49] <hsivonen> annevk: I posted it out of bewilderment about how XHTML5 connects to "Obama Care"
1231. # [18:52] <gkellogg> hsivonen: I missed your discussion on mapping <time> datatypes, can you re-post?
1232. # [18:53] <Hixie> gkellogg: http://krijnhoetmer.nl/irc-logs/whatwg/20111013#l-1181
1233. # [18:54] * Quits: richt (~richt@pat-tdc.opera.com) (Remote host closed the connection)
1234. # [18:54] <gkellogg> Hixie: sorry, I can't fix RDF data typing, it is what it is :)
1235. # [18:54] <jgraham> hsivonen: He could have been honest and titled the email "XHTML5: THINK OF THE CHILDREN!"
1236. # [18:54] <Hixie> gkellogg: i highly recommend ignoring RDF in general :-)
1237. # [18:55] <gkellogg> Hixie: I gathered that :) Sadly, RDF tends to be a kind of addiction, perhaps we need a 12-step program :)
1238. # [18:55] * Joins: MikeSmith_ (~MikeSmith@EM114-48-43-28.pool.e-mobile.ne.jp)
1239. # [18:57] <Hixie> can't help you there :-)
1240. # [18:57] <jgraham> gkellogg: Don't they ask about that at immigration? "Are you now, or have you ever been, addicted to RDF? YES [ ] NO [ ]"
1241. # [18:58] * Quits: annevk (~annevk@EM1-113-202-1.pool.e-mobile.ne.jp) (Ping timeout: 260 seconds)
1242. # [18:58] * Parts: brucel (~brucel@cpc4-smal11-2-0-cust879.perr.cable.virginmedia.com)
1243. # [18:58] * Parts: annacc (~Adium@74.125.59.1)
1244. # [18:59] <scor> lol. is it a crime nowadays?
1245. # [18:59] * Quits: MikeSmith (~MikeSmith@EM1-113-202-1.pool.e-mobile.ne.jp) (Ping timeout: 260 seconds)
1246. # [18:59] * MikeSmith_ is now known as MikeSmith
1247. # [19:00] * Quits: jkomoros (komoroske@nat/google/x-gciloggzzbkiioue) (Quit: jkomoros)
1248. # [19:02] * Joins: ap_ (~ap@2620:149:4:1b01:dd80:f648:2885:e274)
1249. # [19:02] * Joins: tomasf (~tom@85.229.217.94)
1250. # [19:03] * Joins: annevk (~annevk@EM114-48-43-28.pool.e-mobile.ne.jp)
1251. # [19:03] * Joins: Areks (~Areks@176.14.214.163)
1252. # [19:04] * Quits: david_carlisle (~chatzilla@86.188.197.189) (Ping timeout: 240 seconds)
1253. # [19:05] * Joins: david_carlisle (~chatzilla@86.188.197.189)
1254. # [19:06] * Quits: GlitchMr (~glitchmr@178-36-34-9.adsl.inetia.pl) (Read error: Connection reset by peer)
1255. # [19:06] * Quits: ezoe (~ezoe@203-140-90-86f1.kyt1.eonet.ne.jp) (Ping timeout: 252 seconds)
1256. # [19:06] * Joins: jkomoros (komoroske@nat/google/x-xgtjyugsubspught)
1257. # [19:08] * Joins: GlitchMr (~glitchmr@178-36-34-9.adsl.inetia.pl)
1258. # [19:09] * Joins: hasather_ (~hasather_@84.38.144.96)
1259. # [19:09] * Quits: jkomoros (komoroske@nat/google/x-xgtjyugsubspught) (Client Quit)
1260. # [19:13] * Quits: david_carlisle (~chatzilla@86.188.197.189) (Ping timeout: 256 seconds)
1261. # [19:18] <hsivonen> gkellogg: http://krijnhoetmer.nl/irc-logs/whatwg/20111013#l-1181 was all I said
1262. # [19:20] * jernoble|afk is now known as jernoble
1263. # [19:20] <gkellogg> hsivonen: got it, thanks. The main problem here is that there's really no way, except if the property range can be narrowed, do do _any_ datatype inference without performing datatype inference from the corresponding vocabulary description. If there's another way to get better datatype information out of a doc without relying on external resources, I'd like to know.
1264. # [19:23] <hsivonen> gkellogg: I wasn't suggesting that the algorithm was wrong
1265. # [19:23] * Quits: rabbi1 (~manjunath@49.249.127.51) (Quit: Leaving.)
1266. # [19:24] <hsivonen> gkellogg: I was suggesting that RDF could do without having datatyping in the first place
1267. # [19:25] * Quits: tmzt (~tmzt@adsl-76-253-134-36.dsl.akrnoh.sbcglobal.net) (Read error: Connection reset by peer)
1268. # [19:25] * Joins: tmzt (~tmzt@adsl-76-244-149-183.dsl.akrnoh.sbcglobal.net)
1269. # [19:26] <Hixie> when i tell a group that use cases would be helpful if they want the spec changed, after three years of telling them this, they should not respond with "ah, thanks, that's helpful, we'll look for use cases" as if this was the first time they'd heard that use cases might be the best way to give feedback.
1270. # [19:26] * Quits: ap_ (~ap@2620:149:4:1b01:dd80:f648:2885:e274) (Read error: Connection reset by peer)
1271. # [19:27] * Joins: ap_ (~ap@2620:149:4:1b01:dd80:f648:2885:e274)
1272. # [19:27] * Quits: othermaciej_ (~mjs@c-24-6-209-189.hsd1.ca.comcast.net) (Quit: othermaciej_)
1273. # [19:27] * darin__ is now known as fishd
1274. # [19:27] <gkellogg> Hixie: W3C HTML Data TF is specifically chartered to identify such use cases.
1275. # [19:28] <Hixie> jeni's reply suggested that the idea of getting use cases was a novel one
1276. # [19:28] <Hixie> so if you're right, apparently not everyone has read the charter
1277. # [19:29] * Quits: nonge_ (~nonge@p5B326835.dip.t-dialin.net) (Quit: Verlassend)
1278. # [19:30] <gkellogg> Hixie: http://www.w3.org/2011/htmldata/track/actions/7
1279. # [19:31] <Hixie> gkellogg: http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0068.html "OK, that's helpful"
1280. # [19:31] <Hixie> anyway
1281. # [19:31] <Hixie> i'm not complaining or anything
1282. # [19:32] <Hixie> use cases are great
1283. # [19:32] <Hixie> i've been asking for them for forever now
1284. # [19:33] * Joins: arv__ (arv@nat/google/x-lnrvaksphujffbzn)
1285. # [19:35] <gkellogg> Hixie: experience with other groups indicates that collecting use cases is always problematic; it seems like a chore. However, as you point out, you can't really derive requirements without use cases. But in their absence, you may need to draw on anecdotal evidence.
1286. # [19:35] <Hixie> no, in their absence, you don't do anything. :-)
1287. # [19:39] <hsivonen> Why does MapsGL use WebGL for 2D vector graphics maps?
1288. # [19:39] <Hixie> what does it use?
1289. # [19:39] <zewt> why not?
1290. # [19:39] <hsivonen> instead of using SVG or Canvas 2D
1291. # [19:39] <Hixie> ah, dunno
1292. # [19:39] <hsivonen> zewt: WebGL isn't a 2D graphics API
1293. # [19:39] <zewt> sure it is
1294. # [19:39] <zewt> 2d is a subset of 3d
1295. # [19:40] * Joins: GlitchMr42 (~glitchmr@178-36-168-12.adsl.inetia.pl)
1296. # [19:40] <Hixie> probably easier to just code 2d as a special case of 3d?
1297. # [19:40] <zewt> opengl is very good at 2d graphics
1298. # [19:40] <Hixie> i honestly have no idea
1299. # [19:40] <hsivonen> zewt: well, MapsGL fails at anti-aliasing where SVG or Canvas 2D would give it "for free"
1300. # [19:40] <hsivonen> Hixie: maybe the reason indeed is using the same thing for both streets and the buildings
1301. # [19:41] <hsivonen> so the rendering tech doesn't change when zooming in to the building level
1302. # [19:41] <zewt> you can open antialiased webgl contexts (may or may not actually be supported, of course)
1303. # [19:41] <Hixie> drawing a map is quite a complicated problem, so i wouldn't be surprised if it was just a matter of wanting to only do it once
1304. # [19:42] <zewt> (easy to do 2d vector AA in software on anything; no so easy with OpenGL if the underlying hardware isn't good at it)
1305. # [19:42] <hsivonen> anyway, great to see Maps features that previously required Android or Flash Player now supported on the Open Web Platform
1306. # [19:42] <Hixie> indeed
1307. # [19:43] * Quits: GlitchMr (~glitchmr@178-36-34-9.adsl.inetia.pl) (Ping timeout: 258 seconds)
1308. # [19:43] * GlitchMr42 is now known as GlitchMr
1309. # [19:44] <zewt> also if you already have GPU-based map rendering for some other platform, porting to WebGL is probably easier
1310. # [19:45] <arv__> One of the reason to use WebGL over canvas/svg is performance
1311. # [19:45] * Joins: brucel (~brucel@cpc4-smal11-2-0-cust879.perr.cable.virginmedia.com)
1312. # [19:45] <hsivonen> I wonder how long it will take for a WebGL version of Google Earth to emerge
1313. # [19:50] * jernoble is now known as jernoble|afk
1314. # [19:51] * Quits: dglazkov (dglazkov@nat/google/x-amcimdnubdosyjno) (Quit: dglazkov)
1315. # [19:51] * Joins: dglazkov (dglazkov@nat/google/x-obtdntdzqotbjuoy)
1316. # [19:52] * Parts: brucel (~brucel@cpc4-smal11-2-0-cust879.perr.cable.virginmedia.com)
1317. # [19:52] * jernoble|afk is now known as jernoble
1318. # [19:53] * Quits: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com) (Quit: Reading http://davidwalsh.name)
1319. # [19:57] * Joins: Telling (~unknown@109.57.201.112)
1320. # [19:59] * Joins: rillian__ (~rillian@184.71.166.126)
1321. # [20:03] * Quits: rillian_ (~rillian@184.71.182.138) (Ping timeout: 256 seconds)
1322. # [20:07] * Joins: zcorpan (~zcorpan@c-699de355.410-6-64736c14.cust.bredbandsbolaget.se)
1323. # [20:09] * Quits: bga_ (~bga@95-55-42-221.dynamic.avangarddsl.ru) (Ping timeout: 252 seconds)
1324. # [20:09] * Joins: bga_ (~bga@95-55-42-221.dynamic.avangarddsl.ru)
1325. # [20:10] * Quits: Telling (~unknown@109.57.201.112) (Quit: ...)
1326. # [20:11] * Quits: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net) (Ping timeout: 258 seconds)
1327. # [20:14] * Parts: zcorpan (~zcorpan@c-699de355.410-6-64736c14.cust.bredbandsbolaget.se)
1328. # [20:16] * Joins: mkanat (mkanat@nat/google/x-gkecdnkywwmpglwo)
1329. # [20:19] <gsnedders> hsivonen: Well, supported on the "Open Web" if your UA string is correct.
1330. # [20:20] <gsnedders> (which I'm not sure really counts as open web, thus the scare quotes)
1331. # [20:25] * Joins: mokush (~quassel@cl-86-125-150-199.cablelink.mures.rdsnet.ro)
1332. # [20:26] * Quits: astearns (~anonymous@c-50-132-63-33.hsd1.wa.comcast.net) (Quit: astearns)
1333. # [20:31] * Joins: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net)
1334. # [20:31] * Joins: jacobolus (~jacobolus@c-71-198-174-224.hsd1.ca.comcast.net)
1335. # [20:37] * Joins: tndH (~Rob@cpc16-seac19-2-0-cust234.7-2.cable.virginmedia.com)
1336. # [20:39] * Quits: annevk (~annevk@EM114-48-43-28.pool.e-mobile.ne.jp) (Quit: annevk)
1337. # [20:40] * Joins: shepazu (~shepazu@76-253-1-30.lightspeed.sntcca.sbcglobal.net)
1338. # [20:40] * Quits: shepazu (~shepazu@76-253-1-30.lightspeed.sntcca.sbcglobal.net) (Client Quit)
1339. # [20:42] * Joins: shepazu (~shepazu@76-253-1-30.lightspeed.sntcca.sbcglobal.net)
1340. # [20:45] * Quits: ralphholzmann (~ralph@74.207.234.151) (Quit: WeeChat 0.3.5)
1341. # [20:48] * Joins: ralphholzmann (~ralph@li76-151.members.linode.com)
1342. # [20:49] * Quits: cygri (~cygri@80.169.32.154) (Quit: cygri)
1343. # [20:51] * Quits: jacobolus (~jacobolus@c-71-198-174-224.hsd1.ca.comcast.net) (Remote host closed the connection)
1344. # [20:52] * Quits: shepazu (~shepazu@76-253-1-30.lightspeed.sntcca.sbcglobal.net) (Quit: shepazu)
1345. # [20:54] * Joins: astearns (~anonymous@192.150.22.5)
1346. # [20:54] * Quits: smaug____ (~chatzilla@cs181151161.pp.htv.fi) (Ping timeout: 258 seconds)
1347. # [20:56] * Joins: ojan (ojan@nat/google/x-suhelznecvkjxzly)
1348. # [20:57] <manu-db> hsivonen, dglazkov, Hixie: Any public feedback on http://convergence.io/ from browser manufacturers yet? (removing CAs via Network Perspectives and Notaries?)
1349. # [20:58] * Quits: dglazkov (dglazkov@nat/google/x-obtdntdzqotbjuoy) (Quit: dglazkov)
1350. # [20:58] * Quits: arv__ (arv@nat/google/x-lnrvaksphujffbzn) (Quit: arv__)
1351. # [21:02] * Joins: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
1352. # [21:02] * Joins: shepazu (~shepazu@76-253-1-30.lightspeed.sntcca.sbcglobal.net)
1353. # [21:03] * jernoble is now known as jernoble|afk
1354. # [21:05] <hober> gsnedders: indeed
1355. # [21:05] * Quits: mokush (~quassel@cl-86-125-150-199.cablelink.mures.rdsnet.ro) (Remote host closed the connection)
1356. # [21:06] * Quits: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net) (Remote host closed the connection)
1357. # [21:06] * Quits: shepazu (~shepazu@76-253-1-30.lightspeed.sntcca.sbcglobal.net) (Client Quit)
1358. # [21:06] * Quits: FlorianX1 (~Florian_S@p4FE2CEB5.dip.t-dialin.net) (Quit: Leaving.)
1359. # [21:06] * Joins: rniwa (~rniwa@216.239.45.130)
1360. # [21:07] * Joins: shepazu (~shepazu@76-253-1-30.lightspeed.sntcca.sbcglobal.net)
1361. # [21:10] * Quits: Areks (~Areks@176.14.214.163) (Read error: Connection reset by peer)
1362. # [21:10] * Joins: Areks (~Areks@176.14.214.163)
1363. # [21:10] * Joins: othermaciej_ (~mjs@17.245.88.29)
1364. # [21:13] * bga_ is now known as bga_|away
1365. # [21:13] * Joins: tantek (~tantek@64.20.183.131)
1366. # [21:13] * Joins: hij1nx (~hij1nx@75-150-66-254-NewEngland.hfc.comcastbusiness.net)
1367. # [21:15] * Joins: smaug____ (~chatzilla@cs181151161.pp.htv.fi)
1368. # [21:17] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 276 seconds)
1369. # [21:22] * Joins: dbaron (~dbaron@63.245.220.240)
1370. # [21:29] * Joins: mpt (~mpt@canonical/mpt)
1371. # [21:34] * Joins: jwalden (~waldo@2620:101:8003:200:224:d7ff:fef0:8d90)
1372. # [21:35] * Joins: Telling (~unknown@109.57.201.112)
1373. # [21:37] * bga_|away is now known as bga_
1374. # [21:42] * Joins: weinig (~weinig@2620:149:4:1b01:f1c8:5c52:e89e:5a3b)
1375. # [21:46] * Joins: J_Voracek (~J_Voracek@71.21.195.70)
1376. # [21:46] * Quits: J_Voracek (~J_Voracek@71.21.195.70) (Client Quit)
1377. # [21:46] * Joins: Lachy (~Lachy@178.74.10.250)
1378. # [21:52] <Hixie> Philip`: http://www.w3.org/Bugs/Public/show_bug.cgi?id=14421
1379. # [21:53] * Quits: Telling (~unknown@109.57.201.112) (Quit: ...)
1380. # [21:58] * Joins: heycam|away (~cam@203.98.73.35)
1381. # [21:58] * heycam|away is now known as heycam
1382. # [21:58] * Joins: arv__ (~arv@173-164-240-133-SFBA.hfc.comcastbusiness.net)
1383. # [22:02] * Quits: hoodow (~hoodow@pdpc/supporter/active/hoodow) (Read error: Operation timed out)
1384. # [22:02] * Quits: Lachy (~Lachy@178.74.10.250) (Quit: Computer has gone to sleep.)
1385. # [22:05] * Joins: Lachy (~Lachy@178.74.10.250)
1386. # [22:08] * Quits: miketaylr (~miketaylr@206.217.92.186) (Quit: miketaylr)
1387. # [22:08] * jernoble|afk is now known as jernoble
1388. # [22:11] * Joins: nessy (~Adium@124-168-52-143.dyn.iinet.net.au)
1389. # [22:13] * Quits: GlitchMr (~glitchmr@178-36-168-12.adsl.inetia.pl) (Read error: Connection reset by peer)
1390. # [22:14] * Joins: dglazkov|away (dglazkov@nat/google/x-mypadlnonhfbpydb)
1391. # [22:16] * Joins: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com)
1392. # [22:17] * Joins: david_carlisle (~chatzilla@dcarlisle.demon.co.uk)
1393. # [22:17] * Quits: davidwalsh (~davidwals@75-135-74-55.dhcp.mdsn.wi.charter.com) (Client Quit)
1394. # [22:22] * Joins: miketaylr (~miketaylr@206.217.92.186)
1395. # [22:22] * Joins: hoodow (~hoodow@2001:41d0:2:b214:20::5)
1396. # [22:22] * Quits: hoodow (~hoodow@2001:41d0:2:b214:20::5) (Changing host)
1397. # [22:22] * Joins: hoodow (~hoodow@pdpc/supporter/active/hoodow)
1398. # [22:24] * Quits: Areks (~Areks@176.14.214.163) (Ping timeout: 240 seconds)
1399. # [22:26] * Joins: Telling (~unknown@109.57.201.112)
1400. # [22:30] * Quits: Telling (~unknown@109.57.201.112) (Client Quit)
1401. # [22:35] * Quits: davidb (~davidb@66.207.208.98) (Quit: davidb)
1402. # [22:38] * Joins: adtykfhyipoh (185b44cc@gateway/web/freenode/ip.24.91.68.204)
1403. # [22:39] * Quits: hij1nx (~hij1nx@75-150-66-254-NewEngland.hfc.comcastbusiness.net) (Quit: hij1nx)
1404. # [22:40] <adtykfhyipoh> hey
1405. # [22:40] <adtykfhyipoh> I've got a question
1406. # [22:42] * Joins: sicking (~chatzilla@206.15.76.122)
1407. # [22:42] <adtykfhyipoh> sicking
1408. # [22:42] <adtykfhyipoh> hello
1409. # [22:42] <sicking> hello
1410. # [22:42] <adtykfhyipoh> I have a question about javascript
1411. # [22:42] <adtykfhyipoh> I need to save an array of the image tags on a website (var images = document.getElementsByTagname("img");) and I need it stored in another array
1412. # [22:43] <adtykfhyipoh> so that when all the images are changed, the copy of the images array is unchanged
1413. # [22:43] * Quits: adtykfhyipoh (185b44cc@gateway/web/freenode/ip.24.91.68.204) (Quit: Page closed)
1414. # [22:44] * Quits: MacTed (~Thud@18.111.2.104) (Quit: The computer fell asleep)
1415. # [22:49] <zewt> irc is hard
1416. # [22:50] * Quits: shepazu (~shepazu@76-253-1-30.lightspeed.sntcca.sbcglobal.net) (Quit: shepazu)
1417. # [22:51] <bga_> dom has so many shortcuts. doc.images, doc.links, window[id] etc
1418. # [22:51] <bga_> but ppl use long пУИЕТ
1419. # [22:52] <bga_> *gEBTN
1420. # [22:52] <bga_> Ж.
1421. # [22:52] <bga_> *:/
1422. # [22:52] <bga_> stupid autoswitcher
1423. # [22:52] * Joins: hij1nx (~hij1nx@75-150-66-254-NewEngland.hfc.comcastbusiness.net)
1424. # [22:53] * Joins: KevinMarks (~KevinMark@12.1.121.89)
1425. # [22:55] * dglazkov|away is now known as dglazkov
1426. # [22:56] * Quits: tantek (~tantek@64.20.183.131) (Ping timeout: 276 seconds)
1427. # [23:02] * Joins: cpearce (~chatzilla@60.234.54.74)
1428. # [23:03] * Quits: miketaylr (~miketaylr@206.217.92.186) (Quit: miketaylr)
1429. # [23:05] * Quits: nessy (~Adium@124-168-52-143.dyn.iinet.net.au) (Quit: Leaving.)
1430. # [23:06] <smaug____> window[id] works in general only in quirks mode
1431. # [23:06] <smaug____> (and it should be actually removed since it is so error prone)
1432. # [23:07] <bga_> but its handy :)
1433. # [23:07] * Quits: dbaron (~dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
1434. # [23:12] * Joins: dbaron (~dbaron@nat/mozilla/x-glzpmudgynvdpsvu)
1435. # [23:14] * Quits: othermaciej (~mjs@17.212.155.82) (Quit: othermaciej)
1436. # [23:14] * othermaciej_ is now known as othermaciej
1437. # [23:14] * Joins: necolas_ (~necolas@5e0c0fc8.bb.sky.com)
1438. # [23:16] <ojan> TabAtkins: do you know any of the editors of http://dev.w3.org/csswg/css3-writing-modes ?
1439. # [23:16] <ojan> TabAtkins: I'd like to see the spec change for http://lists.w3.org/Archives/Public/www-style/2011Sep/0375.html
1440. # [23:16] <ojan> TabAtkins: not sure who/how to nag about it
1441. # [23:17] * Quits: necolas (~necolas@5e0c0fc8.bb.sky.com) (Ping timeout: 260 seconds)
1442. # [23:23] * Quits: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
1443. # [23:34] * Joins: roc (~chatzilla@202.61.222.68.static.rev.eftel.com)
1444. # [23:38] * Quits: arv__ (~arv@173-164-240-133-SFBA.hfc.comcastbusiness.net) (Quit: arv__)
1445. # [23:44] * Quits: KevinMarks (~KevinMark@12.1.121.89) (Quit: The computer fell asleep)
1446. # [23:46] * Quits: tomasf (~tom@85.229.217.94) (Quit: tomasf)
1447. # [23:47] * jernoble is now known as jernoble|afk
1448. # [23:52] * Quits: necolas_ (~necolas@5e0c0fc8.bb.sky.com) (Remote host closed the connection)
1449. # [23:52] * Joins: necolas (~necolas@5e0c0fc8.bb.sky.com)
1450. # [23:53] * jernoble|afk is now known as jernoble
1451. # [23:53] <smaug____> ojan: so you want fantasai
1452. # [23:58] <ojan> smaug____: oh? is she one of the editors?
1453. # [23:58] * ojan doesn't know her real name
1454. # [23:58] <smaug____> ojan: the spec says Elika
1455. # [23:59] <ojan> smaug____: thx
1456. # [23:59] <smaug____> ojan: anyway, I copy-pasted your comment to her (she is in moznet)
1457. # [23:59] <smaug____> though, apparently afk
1458. # Session Close: Fri Oct 14 00:00:00 2011

The end :)